Re: [weewx-user] Re: Multiple full sensor data with one SDR-Stick

[f4n...@gmail.com]

Thanks I will definitely try it out. 

In the meantime I discovered, in an other weewx instance where the WH65 is 
the secondary/extra sensor, which sends 3 to 4 packets per minute, that the 
plots daily to monthly only contain the current wind gust after each 60 
seconds, while the statistics sucessfully keep the max gust of the full 
minute. (as shown in my other thread)

I'm using soilMoist for that sensor and aggregate type = max is already set 
for weekly and mothly in skin.conf. Is there anything else I could try to 
fix this?

an oldman schrieb am Donnerstag, 3. März 2022 um 20:25:55 UTC+1:

> it's matthewwall weewx-sdr driver
> i just copied and pasted the parts i needed
>
> On Thursday, March 3, 2022 at 12:36:39 PM UTC-6 peterq...@gmail.com wrote:
>
>> Have you considered using Python's JSON function to put the whole thing 
>> into a dictionary so there's no need for all the if statements?
>>
>> On Thu, Mar 3, 2022, 10:26 AM an oldman  wrote:
>>
>>> this is the output for rtl_433 -M utc -M protocol -M level -F json 
>>> command for acurite atlas sensor
>>>
>>> {"time" : "2022-03-03 18:16:57", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 0, 
>>> "battery_ok" : 1, "message_type" : 39, "wind_avg_mi_h" : 3.000, "uv" : 2, 
>>> "lux" : 45830, "strike_count" : 3, "strike_distance" : 10, "exception" : 0, 
>>> "raw_msg" : "81eee78142a3e7006a0d", "mod" : "ASK", "freq" : 433.946, "rssi" 
>>> : -4.499, "snr" : 28.102, "noise" : -32.602}
>>> {"time" : "2022-03-03 18:16:57", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 1, 
>>> "battery_ok" : 1, "message_type" : 39, "wind_avg_mi_h" : 3.000, "uv" : 2, 
>>> "lux" : 45830, "strike_count" : 3, "strike_distance" : 10, "exception" : 0, 
>>> "raw_msg" : "85eee78142a3e7006a11", "mod" : "ASK", "freq" : 433.946, "rssi" 
>>> : -4.499, "snr" : 28.102, "noise" : -32.602}
>>> {"time" : "2022-03-03 18:16:57", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 2, 
>>> "battery_ok" : 1, "message_type" : 39, "wind_avg_mi_h" : 3.000, "uv" : 2, 
>>> "lux" : 45830, "strike_count" : 3, "strike_distance" : 10, "exception" : 0, 
>>> "raw_msg" : "89eee78142a3e7006a15", "mod" : "ASK", "freq" : 433.946, "rssi" 
>>> : -4.499, "snr" : 28.102, "noise" : -32.602}
>>> {"time" : "2022-03-03 18:17:07", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 0, 
>>> "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 5.000, 
>>> "temperature_F" : 14.600, "humidity" : 69, "strike_count" : 3, 
>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>> "81ee65824422c5006aeb", "mod" : "ASK", "freq" : 433.947, "rssi" : -5.061, 
>>> "snr" : 27.083, "noise" : -32.144}
>>> {"time" : "2022-03-03 18:17:07", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 1, 
>>> "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 5.000, 
>>> "temperature_F" : 14.600, "humidity" : 69, "strike_count" : 3, 
>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>> "85ee65824422c5006aef", "mod" : "ASK", "freq" : 433.947, "rssi" : -5.061, 
>>> "snr" : 27.083, "noise" : -32.144}
>>> {"time" : "2022-03-03 18:17:07", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 2, 
>>> "battery_ok" : 1, "message_type" : 37, "wind_avg_mi_h" : 5.000, 
>>> "temperature_F" : 14.600, "humidity" : 69, "strike_count" : 3, 
>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>> "89ee65824422c5006af3", "mod" : "ASK", "freq" : 433.947, "rssi" : -5.061, 
>>> "snr" : 27.083, "noise" : -32.144}
>>> {"time" : "2022-03-03 18:17:18", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 0, 
>>> "battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 5.000, 
>>> "wind_dir_deg" : 94.000, "rain_in" : 1.140, "strike_count" : 3, 
>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>> "81ee6682427872006aed", "mod" : "ASK", "freq" : 433.948, "rssi" : -3.818, 
>>> "snr" : 28.326, "noise" : -32.144}
>>> {"time" : "2022-03-03 18:17:18", "protocol" : 40, "model" : 
>>> "Acurite-Atlas", "id" : 494, "channel" : "B", "sequence_num" : 1, 
>>> "battery_ok" : 1, "message_type" : 38, "wind_avg_mi_h" : 5.000, 
>>> "wind_dir_deg" : 94.000, "rain_in" : 1.140, "strike_count" : 3, 
>>> "strike_distance" : 10, "exception" : 0, "raw_msg" : 
>>> "85ee6682427872006af1", "mod" : "ASK", "freq" : 433.948, "rssi" : -3.818, 
>>> "snr" : 28.326, "noise" : -32.144}
>>>
>>> you could add them to sdr.py i added them for some acurite sensors that 
>>> did not have them it looks something like
>>> # connection diagnostics (-M level)
>>> if 'mod' in obj:
>>> pkt['mod'] = obj.get('mod')
>>> if 'freq' in obj:
>>> pkt['freq'] = Packet.get_float(obj, 'freq')
>>> if 'rssi' in obj:
>>> pkt['rssi'] = Packet.get_float(obj, 'rssi')
>>> if 'snr' in 

Re: [weewx-user] Re: weewx-multi performance combined with multiple skins on RPi3/4

[f4n...@gmail.com]

Could weewx be configured to generate an e.g. realtime.txt / clientraw.txt 
or something like that, and another weewx system to access and read it live 
(into its own loop packets/archive records)?

tke...@gmail.com schrieb am Samstag, 5. März 2022 um 18:04:51 UTC+1:

> Nope. Won't work. Unfortunately, the state machine is tangled up in the 
> archiving service. For example, the decision on when to pause the LOOP 
> packets and generate archive records is done by StdArchive. Having two 
> instances would probably result in chaos.
>
> They really should be separated, but that's a scary project that could 
> lead to a lot of subtle bugs.
>
> On Sat, Mar 5, 2022 at 8:16 AM matthew wall  wrote:
>
>> On Saturday, March 5, 2022 at 10:33:26 AM UTC-5 f4n...@gmail.com wrote:
>>
>>> I had an Idea: If I understand the strategies wiki right: can I save to 
>>> the local sqlite database and to an external mysql database simultaneously? 
>>>
>>
>> weewx is designed to save to only one database
>>
>> i have no idea whether this would work, but you might try putting two 
>> instances of StdArchive into the service list.  that *might* let you save 
>> to two different databases.  create your own archiving service by deriving 
>> from the StdArchive class, and put it in the weewx user directory.  should 
>> not be necessary to define any methods.  then refer to it in your weewx 
>> config file:
>>
>> archive_services = weewx.engine.StdArchive, user.MyArchive
>>
>> If so, I could send it to a mysql database on my webhosting and then 
>>> access it with another weewx installation on another computer and let the 
>>> heavier skins run there?  So:
>>>
>>> raspberry Pi A [sqlite local reports] --> webserver [mysql] <--> 
>>> raspberry Pi B (or other computer) [skin reports]
>>>
>>> Could I access the mysql database simultaneously with weewx on system B? 
>>> Would it run reports automatically without an attached weather station?
>>>
>>
>> this is the 'standard' way to do it.  make weewx save to a mysql 
>> database, either on the computer doing the collection, or on the computer 
>> doing the aggregated reports.  then make the reporting instance of weewx 
>> pull data from the mysql database.
>>  
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to weewx-user+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/e2c101ac-464c-412d-8daa-e32752e98effn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c3f517c9-aedb-4aaa-892b-467822de8ac7n%40googlegroups.com.

[weewx-user] Re: Interceptor stopped working intermittently - empty queue

[f4n...@gmail.com]

I guess, either the station console stopped sending data packets or you 
have some network/firewall issue, maybe an auto-update on the router? But 
first, have you tried rebooting the display console? Is it online and 
actively uploading to ecowitt/wu? Do you use multiple subnetworks or access 
points? Is the Raspberry reachable from within the network? (ping, or 
webserver/apache if installed, ...) If no, Is the raspberry online/e.g can 
you open webpages or ping your network from it? Does it appear in your 
router DHCP client list? Does the station console appear in the router DHCP 
list? And did you already try to reboot the router? You could also try to 
specify the IP in the interceptor definitions of the conf file (IP of your 
Raspberry).

You could also install FOSHKplugin 

 and 
see if it gets any data.

uwe.sc...@gmail.com schrieb am Donnerstag, 10. März 2022 um 06:23:46 UTC+1:

> That is the section of the weewx.conf:
>
> ##
>  
>
>
> [Interceptor] 
># This section is for the network traffic interceptor driver. 
>
># The driver to use: 
>driver = user.interceptor 
>
># Specify the hardware device to capture.  Options include: 
>#   acurite-bridge - acurite internet bridge, smarthub, or access 
>#   observer - fine offset WH2600/HP1000/HP1003, ambient WS2902 
>#   lw30x - oregon scientific LW301/LW302 
>#   lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge 
>#   ecowitt-client - any hardware that uses the ecowitt protocol 
>#   wu-client - any hardware that uses the weather underground protocol 
>device_type = ecowitt-client 
>port = 8100 
>mode = listen 
>iface = wlan0 
>
>
> ##
>
> The weatherstation is set to the given port 8100 and the IP adress of the 
> Raspberry.
>
> As said, it was working before and stopped somewhere in the middle of the 
> day. No reboot in between, nothing touched as i wasn't even at home at this 
> time.
>
>
> Uwe S. schrieb am Mittwoch, 9. März 2022 um 15:15:22 UTC+1:
>
>> Hi all,
>>
>> i do have an Ecowitt HP2551 and pulling the data via WeeWX Interceptor 
>> running as ecowitt-client.
>>
>> Since this morning Weewx Interceptor shows only "empty queue" with 
>> debugging enabled.
>> local Website is not updated and no data is uploaded to any of the web 
>> services.
>>
>> Below is my logfile after i've restarted the weewx service. What can i do 
>> to get it back working?
>> Device is a Raspberry 4 with Raspberry OS Bullseye installed. Worked for 
>> 2 weeks without issues
>>
>> Tried reinstalling Interceptor, but the problem remain the same
>> Mär 08 20:25:54 Raspi42 systemd[1]: Starting LSB: weewx weather system... 
>> ░░ Subject: A start job for unit weewx.service has begun execution ░░ A 
>> start job for unit weewx.service has begun execution. Mär 08 20:25:54 
>> Raspi42 python3[7508]: weewx[7508] INFO __main__: Initializing weewx 
>> version 4.7.0 Mär 08 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO 
>> __main__: Using Python 3.9.2 (default, Mar 12 2021, 04:06:34) Mär 08 
>> 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO __main__: Platform 
>> Linux-5.10.92-v7l+-armv7l-with-glibc2.31 Mär 08 20:25:54 Raspi42 
>> python3[7508]: weewx[7508] INFO __main__: Locale is 'de_DE.UTF-8' Mär 08 
>> 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO __main__: Using 
>> configuration file /etc/weewx/weewx.conf Mär 08 20:25:54 Raspi42 
>> python3[7508]: weewx[7508] INFO __main__: Debug is 1 Mär 08 20:25:54 
>> Raspi42 python3[7508]: weewx[7508] INFO __main__: PID file is 
>> /var/run/weewx.pid Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] DEBUG 
>> __main__: Initializing engine Mär 08 20:25:54 Raspi42 python3[7511]: 
>> weewx[7511] INFO weewx.engine: Loading station type Interceptor 
>> (user.interceptor) Mär 08 20:25:54 Raspi42 weewx[7497]: Starting weewx 
>> weather system: weewx. Mär 08 20:25:54 Raspi42 systemd[1]: Started LSB: 
>> weewx weather system. ░░ Subject: A start job for unit weewx.service has 
>> finished successfully ░░ A start job for unit weewx.service has finished 
>> successfully. Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO 
>> user.interceptor: driver version is 0.53 Mär 08 20:25:54 Raspi42 
>> python3[7511]: weewx[7511] INFO user.interceptor: device type: 
>> ecowitt-client Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO 
>> user.interceptor: mode is listen Mär 08 20:25:54 Raspi42 python3[7511]: 
>> weewx[7511] INFO user.interceptor: listen on :8100 Mär 08 20:25:54 Raspi42 
>> python3[7511]: weewx[7511] INFO user.interceptor: sensor map: {'pressure': 
>> 'pressure', 'barometer': 'barometer', 'outHumidity': 'humidity_out', 
>> 'inHumidity': 'humidity_in', 'outTemp': 'temperature_out', 'inTemp': 
>> 'temperature_in', 

[weewx-user] Re: Interceptor stopped working intermittently - empty queue

[Uwe S.]

That is the section of the weewx.conf:

## 


[Interceptor] 
   # This section is for the network traffic interceptor driver. 

   # The driver to use: 
   driver = user.interceptor 

   # Specify the hardware device to capture.  Options include: 
   #   acurite-bridge - acurite internet bridge, smarthub, or access 
   #   observer - fine offset WH2600/HP1000/HP1003, ambient WS2902 
   #   lw30x - oregon scientific LW301/LW302 
   #   lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge 
   #   ecowitt-client - any hardware that uses the ecowitt protocol 
   #   wu-client - any hardware that uses the weather underground protocol 
   device_type = ecowitt-client 
   port = 8100 
   mode = listen 
   iface = wlan0 

##

The weatherstation is set to the given port 8100 and the IP adress of the 
Raspberry.

As said, it was working before and stopped somewhere in the middle of the 
day. No reboot in between, nothing touched as i wasn't even at home at this 
time.


Uwe S. schrieb am Mittwoch, 9. März 2022 um 15:15:22 UTC+1:

> Hi all,
>
> i do have an Ecowitt HP2551 and pulling the data via WeeWX Interceptor 
> running as ecowitt-client.
>
> Since this morning Weewx Interceptor shows only "empty queue" with 
> debugging enabled.
> local Website is not updated and no data is uploaded to any of the web 
> services.
>
> Below is my logfile after i've restarted the weewx service. What can i do 
> to get it back working?
> Device is a Raspberry 4 with Raspberry OS Bullseye installed. Worked for 2 
> weeks without issues
>
> Tried reinstalling Interceptor, but the problem remain the same
> Mär 08 20:25:54 Raspi42 systemd[1]: Starting LSB: weewx weather system... 
> ░░ Subject: A start job for unit weewx.service has begun execution ░░ A 
> start job for unit weewx.service has begun execution. Mär 08 20:25:54 
> Raspi42 python3[7508]: weewx[7508] INFO __main__: Initializing weewx 
> version 4.7.0 Mär 08 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO 
> __main__: Using Python 3.9.2 (default, Mar 12 2021, 04:06:34) Mär 08 
> 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO __main__: Platform 
> Linux-5.10.92-v7l+-armv7l-with-glibc2.31 Mär 08 20:25:54 Raspi42 
> python3[7508]: weewx[7508] INFO __main__: Locale is 'de_DE.UTF-8' Mär 08 
> 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO __main__: Using 
> configuration file /etc/weewx/weewx.conf Mär 08 20:25:54 Raspi42 
> python3[7508]: weewx[7508] INFO __main__: Debug is 1 Mär 08 20:25:54 
> Raspi42 python3[7508]: weewx[7508] INFO __main__: PID file is 
> /var/run/weewx.pid Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] DEBUG 
> __main__: Initializing engine Mär 08 20:25:54 Raspi42 python3[7511]: 
> weewx[7511] INFO weewx.engine: Loading station type Interceptor 
> (user.interceptor) Mär 08 20:25:54 Raspi42 weewx[7497]: Starting weewx 
> weather system: weewx. Mär 08 20:25:54 Raspi42 systemd[1]: Started LSB: 
> weewx weather system. ░░ Subject: A start job for unit weewx.service has 
> finished successfully ░░ A start job for unit weewx.service has finished 
> successfully. Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO 
> user.interceptor: driver version is 0.53 Mär 08 20:25:54 Raspi42 
> python3[7511]: weewx[7511] INFO user.interceptor: device type: 
> ecowitt-client Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO 
> user.interceptor: mode is listen Mär 08 20:25:54 Raspi42 python3[7511]: 
> weewx[7511] INFO user.interceptor: listen on :8100 Mär 08 20:25:54 Raspi42 
> python3[7511]: weewx[7511] INFO user.interceptor: sensor map: {'pressure': 
> 'pressure', 'barometer': 'barometer', 'outHumidity': 'humidity_out', 
> 'inHumidity': 'humidity_in', 'outTemp': 'temperature_out', 'inTemp': 
> 'temperature_in', 'windSpeed': 'wind_speed', 'windGust': 'wind_gust', 
> 'windDir': 'wind_dir', 'windGustDir': 'wind_gust_dir', 'radiation': 
> 'solar_radiation', 'dewpoint': 'dewpoint', 'windchill': 'windchill', 
> 'rain': 'rain', 'rainRate': 'rain_rate', 'UV': 'uv', 'txBatteryStatus': 
> 'battery', 'extraTemp1': 'temperature_1', 'extraTemp2': 'temperature_2', 
> 'extraTemp3': 'temperature_3', 'extraHumid1': 'humidity_1', 'extraHumid2': 
> 'humidity_2', 'soilTemp1': 'soil_temperature_1', 'soilTemp2': 
> 'soil_temperature_2', 'soilMoist1': 'soil_moisture_1', 'soilMoist2': 
> 'soil_moisture_2', 'soilMoist3': 'soil_moisture_3', 'soilMoist4': 
> 'soil_moisture_4', 'leafWet1': 'leafwetness_1', 'leafWet2': 
> 'leafwetness_2', 'pm2_5': 'pm2_5', 'extraTemp4': 'temperature_4', 
> 'extraTemp5': 'temperature_5', 'extraTemp6': 'temperature_6', 'extraTemp7': 
> 'temperature_7', 'extraTemp8': 'temperature_8', 'extraHumid3': 
> 'humidity_3', 'extraHumid4': 'humidity_4', 'extraHumid5': 'humidity_5', 
> 'extraHumid6': 'humidity_6', 'extraHumid7': 'humidity_7', 'extraHumid8': 
> 'humidity_8', 'soilTemp3': 'soil_temperature_3', 

Re: [weewx-user] Weewx 4.7.0 & Weewx -WD

[DR]

Gary,

Pardon me for jumping in on this thread, butseeing Weather Display and 
clientraw.txt terms grabbed my attention.


I've read through this message, and it lead me to the WeeWx-WD (end of 
life) and the WeeWx-Saratoga portions, which I read, and partially 
understand.


My main goal is to find some station code for WeeWx which will take my 
WeatherDisplay clientraw file and allow it to drive WeeWx.  I looked at 
this a couple years ago and was given a lead to use fileparser, but that 
station base code requires a observation name followed by the value; as 
you know clientraw.txt is just a string of numbers, which is incredibly 
well analyzed in one of the files on Saratoga 
(https://saratoga-weather.org/wdparser.php).


As a clarification, you might ask why in the world if I'm running 
Weather Display, why would I want it to feed WeeWx?  First, with Weather 
Display Brian H. has implemented an amazing number of weather station 
interfaces which just plain work.  I have a passion for hardware, and 
have at least five stations feeding Weather  Display.  Therefore not 
only am I running Weather Display, but it is functioning as an interface 
to those stations. I could fiddle with my WeeWx installations and feed 
different ones from different stations, especially if there are not 
direct drivers native to WeeWx. All I'd need to do is have Weather 
Display output through  clientraw.txt, to my WeeWx Raspberry Pi 
configurations.


I love WeeWx, and am far from a programmer, but have followed the 
discussions and made some modifications to the basic code (all 
suggested, I'm not that smart to figure it out but I'm getting better) 
and also have selected to run the Belchertown as an output skin also.


So what I'm looking for and haven't apparently found it quite yet, is 
some station driver which will take the clientraw. txt and act like a 
LOOP feeder for WeeWx.  Fileparser requires a format that is far 
different from what WD outputs.  I haven't been able to produce 
functioning code which inserts the necessary value identifiers to make 
this work.  I see this thread and hope wells up, especially after 
looking at the Saratoga examples which seem to look into a URL, analyze 
the WeatherDisplay output, and produce such a file.  As far as I can 
determine, that whole thing was done just to make the Saratoga work.


Obviously I'm missing something, like why is WeeWx involved in the 
conversion at all?  I thought (although never set it up) that WD output 
can directly drive Saratoga but I could be all wet on that conclusion.



The last question, straight out, is:  Is there a WeeWx station code that 
I can use to read WD files (not fileparser, since as I noted it needs a 
different format) and have WeeWx import those Loop-like packets?


If there is not, and my efforts to make something like this work (the 
data in the clientraw.txt  or customclientraw.txt output is very much 
enough to make WeeWx's need for data points to work), my old remaining 
possible solution is to write Brian, who has returned from a  brake, to 
see if he can implement a custom output driver that will do like his API 
code does to feed Meteotemplate and CWOS, which work slick but no doubt 
takes a bit of skill and time to write.



Whew, I'm sorry for the long message, but was inspired by the discussion 
to see if there is something out there, or that a solution is easily 
implemented, and hope to get guidance from you or others experienced 
with station driver routines.


Dale

http://ecwx.info/weewx/


--
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/125b9168-19df-4e3c-ce12-8a3dfc419b45%40gmail.com.

Re: [weewx-user] 'wee_database --calc-missing' long to execute

[Graham Eddy]

for gw1000 dataset, i had been using top and iotop previously to ascertain that 
cpu, memory and i/o usage were extremely low, and ps-efl showed it was spending 
its time waiting on interrupt. i would usually just conclude it was slow disk 
and spending all its time waiting on i/o completion *except* this is only for 
the smaller gw1000 dataset not the larger vp2 dataset. it is something to do 
with the different nature of the data (perhaps something as simple as different 
missing data being calc’ed)

to give an idea of the magnitude of the difference, using built-in shell time 
to run command:


recsreal /sec   user /sec   sys /secIdle /%
vp2 --rebuild-daily 505,336 165 148 2   9
vp2 --calc-missing  505,336 571 525 18  5
gw1000  --rebuild-daily 162,882 86  81  1   5
gw1000  --calc-missing  162,882 23,758  301 13  99

as it stands right now, for migration of production to split environment, i 
will have to
  * take a database snapshot and build the equivalent temp gw1000.sdb before 
migrating
  * do —calc-missing offline on the temp gw1000.sdb (7 hours !!)
  * dump the were-missing values in temp gw1000.sdb into a file
  * when dumped data avail, stop production system, split the databases, load 
the dumped were-missing values into gw1000.sdb
  * run —calc-missing on the interval only between dump and now ← hopefully not 
long, gw1000 data being lost!
  * start new production system on split databases

does anyone have insight into the origin of the wait-for-interrupt plaguing my 
gw1000 dataset migration? perhaps some wxxtypes in do_calculations() have a 
realtime delay built in? perhaps the yield in genBatchRecords() is not context 
switching to another thread effectively (internal python issue)? has anyone 
seen such behaviour elsewhere?

cheers
⊣ Graham Eddy ⊢

> On 9 Mar 2022, at 4:16 pm, vince  wrote:
> 
> Well I'd still try either splitting it up into pieces, or running it and 
> measuring its resource usage in another shell.   If it's not out of ram and 
> you're not pegging the CPU than waiting for i/o is the only thing left I'd 
> guess.  Run htop or the like to see.  
> 
> On Tuesday, March 8, 2022 at 7:03:37 PM UTC-8 graha...@gmail.com wrote:
> it’s an 8MB RPi 4B and RAM is abundant, though using μSD card for filesys.
> the interesting thing is that there are two datasets, one large and one 
> small, and the large one is quick but the small one is orders of magnitude 
> slower. the larger dataset (vp2-originated) gobbles >95% cpu but the smaller 
> dataset (gw1000-originated) <0.3%. it must be something to do with the nature 
> of the data, not the quantity.
> ⊣ Graham Eddy ⊢

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/28D3A6B3-A18E-4EDB-AC17-ABD2DAE1F29F%40gmail.com.

Re: [weewx-user] Weewx 4.7.0 & Weewx -WD

[Stefanos Kalaitzis]

 

Hi Gary … Thank you again !!  

clientraw.txt location now changed (Thanks!!) 

Everything working like a charm …  (day max/min outTemp times, dewpoint) 
Probably was the ajaxWEEWXwx.js because when I downloaded again and 
reinstall it all issues disappeared 

For my dashboard at https://tagarades-weather.epizy.com/WD/index.php  I 
have downloaded the World Template .ZIP 
 and the WeeWX .ZIP 
 (updated every 
2,5min - archive interval-ftp)

 

-is your Saratoga dashboard publicly accessible? I think yes , have you 
tried to access and faced some problem?? 

If you cant use the clientraw parser script try this address 
https://northmeteo.gr/weather_stations/tagarades/ (updated every 50 sec due 
to http post -post_clientraw)


When I used the weewx-wd I changed wind [values] in ajaxWEEWXwx.js file 
because I had a problem that I cant remember and somewhere I read that is 
better to change  var gust , var wind, with [2] and [1] (I guess that it 
was wrong)

Anyway now I changed these to normal only in /WD address above 
Now I have 2 equal values for wind and gust all the time and the same I 
noticed in https://saratoga-weather.org/weewx/wxindex.php 

On Wednesday, March 9, 2022 at 1:38:00 PM UTC+2 gjr80 wrote:

> Hi,
>
> I've spent a bit of time today observing your clientraw.txt and 
> Belchertown web site. On thing I have noted is that your clientraw.txt 
> only updates approximately every 1.5 to 2.5 minutes. This suggests that 
> loop packets are not coming in very often and they arrive irregularly. This 
> could be causing some odd effects, in particular with wind where there a 
> couple of fields that are calculated as aggregates over one minute. It 
> might be useful to see what loop packets you have coming in and what their 
> contents are. To do this stop WeeWX and then run WeeWX directly 
> . This will 
> display loop packets (lines starting with LOOP:) and archive records (lines 
> starting with REC:) on your console. If you like let WeeWX run for 15 
> minutes or so and capture and post the screen out (as text).
>
> Just hitting the issues you have noted so far:
>
> clientraw.txt location. Can be controlled with the rtcr_path config items 
> as per my previous post. Any luck with this?
>
> day max/min outTemp times. As you posted earlier these time are now 
> updating. Throughout today (9th) when I have looked at your clientraw.txt 
> the max/min outTemp times have been correct. It is possible to have some 
> discrepancies with these values when WeeWX is first started but I'm not 
> sure that is what was happening here. I suggest we monitor this for the 
> next couple of days, particularly for the rest of the day after a WeeWX 
> restart. If the issue comes back I can give you an instrumented version of 
> rtcr.py to give us more detail on exactly what is happening.   
>
> dewpoint. Appears to be fine as far as I can tell, every time I have 
> looked the dewpoint value in clientraw.txt has agreed with your station.
>
> avg wind speed/wind gust speed discrepancies. I gather here you are 
> looking at the Saratoga or Alternate dashboard? (is your Saratoga dashboard 
> publicly accessible? If it is could we have the address or if you don't 
> wish to make it public could you advise me via 'reply to author' or by 
> email to gjroderick at gmail dot com. There is a wealth of debug 
> information built into the dashboard). If I understand you correctly you 
> originally had field 140 (max gust in last minute) as average speed on the 
> dashboard but changed it to field 1 (average wind speed in last 60 
> seconds). You also had field 1 (average wind speed in last 60 seconds) as 
> gust speed on the dashboard but changed it to field 2 (current wind speed). 
> If that is the case I am not surprised you were initially seeing average 
> wind speed higher than the gust speed as the you had a gust speed field 
> displaying as average and an average speed field displaying as gust speed. 
> I would be sticking with the original values in ajaxWEEWXwx.js (circa 
> lines 762-772):
>
> //Wind gust
> var gust = convertWind(clientraw[140]);
> var maxgust = convertWind(clientraw[71]);
> if (maxgust > 0.0 ) {
> set_ajax_obs("ajaxmaxgust",maxgust.toFixed(1) + uomWind);
> } else {
> set_ajax_obs("ajaxmaxgust",'None');
> }
>
> //Windspeed ...
> var wind = convertWind(clientraw[2]);
>
> or perhaps changing gust to field 133 (max gust last hour) given your 
> rather long loop period.
>
> rainrate. Sounds like that is now working, unfortunately I have not 
> observed any rain on your site.
>
> Gary
> On Wednesday, 9 March 2022 at 07:50:22 UTC+10 stefanos...@gmail.com wrote:
>
>> Hi Gary ...
>> Time of min-max temp ...ok ... It wasnt the clientraw as you said but i 
>> reinstall the weewx plugin for Sarratoga template and all good
>> Now i have also  

Re: [weewx-user] Re: Ftp upload

[Tom Keffer]

We have seen this error before and it's very misleading. Despite the
message, it can be caused by problems either locally or remotely.

1. Make sure the FTP username has write permissions on the server for the
path you specified.
2. Make sure the password is correct. Does it include special characters?
If so, be sure to quote the password.
3. Does your server require FTPS?
4. Try different variations for the path option for [FTP].

If you are still stuck, post your [FTP] section, but be sure to obfuscate
your password first.

-tk

On Wed, Mar 9, 2022 at 11:28 AM vince  wrote:

> Possibly, but why would weewx try to upload a file that is not there on
> the weewx system ?
> Or is that what that #FTPlast file does ?
>
> https://groups.google.com/g/weewx-user/c/XwQqsslGKfA suggests removing
> that file which should cause weewx to upload everything it finds.
>
> On Wednesday, March 9, 2022 at 10:11:51 AM UTC-8 kk44...@gmail.com wrote:
>
>> kalli...@gmail.com schrieb am Mittwoch, 9. März 2022 um 18:27:38 UTC+1:
>>
>>> Reason: '550 /home/weewx/public_html/monthhum.png: No such file or
>>> directory'
>>>
>>
>> I would have listened to that error message and guess, the local file is
>> missing.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to weewx-user+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/70edd677-2765-4bb2-8088-60e0cf5c09a0n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEBz1PueVCztz1XW6DEMtX%2By6TqZSe6h%3Ds%2BSO0fcBYm3fA%40mail.gmail.com.

[weewx-user] Re: Ftp upload

[vince]

Possibly, but why would weewx try to upload a file that is not there on the 
weewx system ?
Or is that what that #FTPlast file does ?

https://groups.google.com/g/weewx-user/c/XwQqsslGKfA suggests removing that 
file which should cause weewx to upload everything it finds.

On Wednesday, March 9, 2022 at 10:11:51 AM UTC-8 kk44...@gmail.com wrote:

> kalli...@gmail.com schrieb am Mittwoch, 9. März 2022 um 18:27:38 UTC+1:
>
>> Reason: '550 /home/weewx/public_html/monthhum.png: No such file or 
>> directory'
>>
>
> I would have listened to that error message and guess, the local file is 
> missing.
>  
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/70edd677-2765-4bb2-8088-60e0cf5c09a0n%40googlegroups.com.

[weewx-user] Re: Ftp upload

[Karen K]

kalli...@gmail.com schrieb am Mittwoch, 9. März 2022 um 18:27:38 UTC+1:

> Reason: '550 /home/weewx/public_html/monthhum.png: No such file or 
> directory'
>

I would have listened to that error message and guess, the local file is 
missing.
 

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/4dc4224b-5abf-499f-b5eb-6fc7dad65426n%40googlegroups.com.

[weewx-user] Re: Ftp upload

[vince]

On Wednesday, March 9, 2022 at 9:27:38 AM UTC-8 kalli...@gmail.com wrote:

> Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weeutil.ftpupload: 
> Failed uploading /home/weewx/public_html/monthhum.png to server 
> francium.selfhost.de. Reason: '550 /home/weewx/public_html/monthhum.png: 
> No such file or directory'
>

Your remote [[FTP]] path is probably incorrect in your weewx.conf


-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/f74b14d9-254b-4678-9775-2dc7d58c5845n%40googlegroups.com.

[weewx-user] Ftp upload

[Kalli Gøtze]

Hi all,
I run Weewx 4.6.2 on my Notebook whit Ubuntu 20.04 it work's fine but the 
upload to my Website didn't work to Awekas it work's. 
If i run sudo tail -f /var/log/syslog it show me this 

Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weeutil.ftpupload: Failed 
uploading /home/weewx/public_html/monthhum.png to server 
francium.selfhost.de. Reason: '550 /home/weewx/public_html/monthhum.png: No 
such file or directory'
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine: 
ftpgenerator: (2): caught exception '': 550 
/home/weewx/public_html/monthhum.png: No such file or directory
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
    Traceback (most recent call last):
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
  File "/home/weewx/bin/weewx/reportengine.py", line 429, in run
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
    n = ftp_data.run()
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
  File "/home/weewx/bin/weeutil/ftpupload.py", line 210, in run
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
    ftp_server.storbinary(stor_cmd, fd)
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
  File "/usr/lib/python3.8/ftplib.py", line 494, in storbinary
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
    with self.transfercmd(cmd, rest) as conn:
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
  File "/usr/lib/python3.8/ftplib.py", line 389, in transfercmd
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
    return self.ntransfercmd(cmd, rest)[0]
Mar  9 17:50:52 kalli-HP-8440p weewx[17683] ERROR weewx.reportengine:   
  File "/home/weewx/bin/weeutil/ftpupload.py", line 119, in 
ntransfercmd

I don't know what i have to do,can someone help?
regards Karl

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5e8e9af3-e768-4c94-b345-fb5e6c44d3dan%40googlegroups.com.

Re: [weewx-user] Re: WeeWX WebP image plot test

[Tom Hogland]

I don't know much about Python :-) but I see cnopts=pysftp.CnOpts() in the
sftp.py script. This leads down the typical rabbit-hole of Google, grep,
etc. and I find the pysftp project cookbook and added
"cnopts.compression=True" in there. We'll see if it works - the cookbook
says that compression is off by default.

So far (one cycle) it looks about the same - no errors, and "26 files, 34
seconds" versus the last uploads of 21 files, 32 seconds. (Second cycle -
21 files, 30.9 seconds. Faster, but tiny...)

I may look into alternate providers, but I host this with Gandi (in
Luxembourg) for $5/mo for a pre-configured and running host. As long as
sftp works I'm happy to use it.

On Wed, Mar 9, 2022 at 2:55 AM paul.ba...@gmail.com <
paul.bartho...@gmail.com> wrote:

> 1. SFTP can be used with compression (-C option) but I don't know if it is
> used or not in Weewx.
> 2. I tried to compress all my weewx images with tar and/or gzip.  At best
> I get less than 30 % reduction.  May be it is just enough for you.
> 3. gzip (or better the library behind it) is in fact used by ssh, sftp,
> tar etc. So in your case you should just be sure to use compressionwhatever
> the transfer protocol.
>
> When lines were very slow, the default was always WITH compression. Now,
> with much, much faster lines available, the default is NO compression, as
> compression would slow down the process...
>
> Regards, PaulB
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAMwKJErL0TSsFEtxadKAcPdXBTbbShzAPbgzwdsD5_1wTn83PA%40mail.gmail.com.

[weewx-user] Re: Version 4.7.0

[sab...@gmail.com]

I updated my 4.4.0 install on a RPi3b to a fresh 64bit RPlite install.  So 
far everything looks good.  I did encounter one small issue. Since this was 
a completely clean install I had to set up the start up scripts to launch 
WeeWx when the RPi reboots.  I install my weewx folder on an NFS mounted 
directory to my NAS that is not /home.  I updated my setup.cfg to point the 
home directory to proper location, but it appears that the home directory 
gets updated everywhere except the example startup scripts for systemd and 
init.d.  Those still need to get manually updated if your home directory is 
different than the default.

Other than that, it was a smooth update.

Thanks
Scott


On Tuesday, March 1, 2022 at 5:57:08 PM UTC-6 tke...@gmail.com wrote:

> This version fixes a bunch of minor things, as well as introduces some 
> minor new features.
>
> Change log:
>
> Introduced new option "generate_once". If True, templates will be generated
> only on the first run of the reporting engine. Thanks to user Rich! PR #748.
>
> Added option wee_device --current for vantage.
>
> Fixed two typos in the Standard skin.
>
> Fixed spelling mistakes in the Norwegian translations.  Thanks to Aslak! 
> PR#746
>
> Supply a sensible default context for group_deltatime when no context has been
> specified.
>
> If windGustDir is missing, extract a value from the accumulators.
>
> Fixed typo that shows itself if no [Labels]/[[Generic]] section is supplied.
> Fixes issue #752.
>
> Fixed calculation of field "bar_reduction" for Vantage type 2 LOOP packets.
>
> Fix problem that prevents windSpeed and windDir from being displayed in
> the RSS feed. Fixes issue #755.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3f82190d-13f8-44d5-a1da-fc1570418143n%40googlegroups.com.

[weewx-user] Interceptor stopped working intermittently - empty queue

[Uwe S.]

Hi all,

i do have an Ecowitt HP2551 and pulling the data via WeeWX Interceptor 
running as ecowitt-client.

Since this morning Weewx Interceptor shows only "empty queue" with 
debugging enabled.
local Website is not updated and no data is uploaded to any of the web 
services.

Below is my logfile after i've restarted the weewx service. What can i do 
to get it back working?
Device is a Raspberry 4 with Raspberry OS Bullseye installed. Worked for 2 
weeks without issues

Tried reinstalling Interceptor, but the problem remain the same
Mär 08 20:25:54 Raspi42 systemd[1]: Starting LSB: weewx weather system... 
░░ Subject: A start job for unit weewx.service has begun execution ░░ A 
start job for unit weewx.service has begun execution. Mär 08 20:25:54 
Raspi42 python3[7508]: weewx[7508] INFO __main__: Initializing weewx 
version 4.7.0 Mär 08 20:25:54 Raspi42 python3[7508]: weewx[7508] INFO 
__main__: Using Python 3.9.2 (default, Mar 12 2021, 04:06:34) Mär 08 
20:25:54 Raspi42 python3[7508]: weewx[7508] INFO __main__: Platform 
Linux-5.10.92-v7l+-armv7l-with-glibc2.31 Mär 08 20:25:54 Raspi42 
python3[7508]: weewx[7508] INFO __main__: Locale is 'de_DE.UTF-8' Mär 08 
20:25:54 Raspi42 python3[7508]: weewx[7508] INFO __main__: Using 
configuration file /etc/weewx/weewx.conf Mär 08 20:25:54 Raspi42 
python3[7508]: weewx[7508] INFO __main__: Debug is 1 Mär 08 20:25:54 
Raspi42 python3[7508]: weewx[7508] INFO __main__: PID file is 
/var/run/weewx.pid Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] DEBUG 
__main__: Initializing engine Mär 08 20:25:54 Raspi42 python3[7511]: 
weewx[7511] INFO weewx.engine: Loading station type Interceptor 
(user.interceptor) Mär 08 20:25:54 Raspi42 weewx[7497]: Starting weewx 
weather system: weewx. Mär 08 20:25:54 Raspi42 systemd[1]: Started LSB: 
weewx weather system. ░░ Subject: A start job for unit weewx.service has 
finished successfully ░░ A start job for unit weewx.service has finished 
successfully. Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO 
user.interceptor: driver version is 0.53 Mär 08 20:25:54 Raspi42 
python3[7511]: weewx[7511] INFO user.interceptor: device type: 
ecowitt-client Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO 
user.interceptor: mode is listen Mär 08 20:25:54 Raspi42 python3[7511]: 
weewx[7511] INFO user.interceptor: listen on :8100 Mär 08 20:25:54 Raspi42 
python3[7511]: weewx[7511] INFO user.interceptor: sensor map: {'pressure': 
'pressure', 'barometer': 'barometer', 'outHumidity': 'humidity_out', 
'inHumidity': 'humidity_in', 'outTemp': 'temperature_out', 'inTemp': 
'temperature_in', 'windSpeed': 'wind_speed', 'windGust': 'wind_gust', 
'windDir': 'wind_dir', 'windGustDir': 'wind_gust_dir', 'radiation': 
'solar_radiation', 'dewpoint': 'dewpoint', 'windchill': 'windchill', 
'rain': 'rain', 'rainRate': 'rain_rate', 'UV': 'uv', 'txBatteryStatus': 
'battery', 'extraTemp1': 'temperature_1', 'extraTemp2': 'temperature_2', 
'extraTemp3': 'temperature_3', 'extraHumid1': 'humidity_1', 'extraHumid2': 
'humidity_2', 'soilTemp1': 'soil_temperature_1', 'soilTemp2': 
'soil_temperature_2', 'soilMoist1': 'soil_moisture_1', 'soilMoist2': 
'soil_moisture_2', 'soilMoist3': 'soil_moisture_3', 'soilMoist4': 
'soil_moisture_4', 'leafWet1': 'leafwetness_1', 'leafWet2': 
'leafwetness_2', 'pm2_5': 'pm2_5', 'extraTemp4': 'temperature_4', 
'extraTemp5': 'temperature_5', 'extraTemp6': 'temperature_6', 'extraTemp7': 
'temperature_7', 'extraTemp8': 'temperature_8', 'extraHumid3': 
'humidity_3', 'extraHumid4': 'humidity_4', 'extraHumid5': 'humidity_5', 
'extraHumid6': 'humidity_6', 'extraHumid7': 'humidity_7', 'extraHumid8': 
'humidity_8', 'soilTemp3': 'soil_temperature_3', 'soilTemp4': 
'soil_temperature_4'} Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] 
DEBUG user.interceptor: start tcp server Mär 08 20:25:54 Raspi42 
python3[7511]: weewx[7511] DEBUG weewx.engine: Loading service 
weewx.engine.StdTimeSynch Mär 08 20:25:54 Raspi42 python3[7511]: 
weewx[7511] DEBUG weewx.engine: Finished loading service 
weewx.engine.StdTimeSynch Mär 08 20:25:54 Raspi42 python3[7511]: 
weewx[7511] DEBUG weewx.engine: Loading service weewx.engine.StdConvert Mär 
08 20:25:54 Raspi42 python3[7511]: weewx[7511] INFO weewx.engine: 
StdConvert target unit is 0x1 Mär 08 20:25:54 Raspi42 python3[7511]: 
weewx[7511] DEBUG weewx.engine: Finished loading service 
weewx.engine.StdConvert Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] 
DEBUG weewx.engine: Loading service weewx.engine.StdCalibrate Mär 08 
20:25:54 Raspi42 python3[7511]: weewx[7511] DEBUG weewx.engine: Finished 
loading service weewx.engine.StdCalibrate Mär 08 20:25:54 Raspi42 
python3[7511]: weewx[7511] DEBUG weewx.engine: Loading service 
weewx.engine.StdQC Mär 08 20:25:54 Raspi42 python3[7511]: weewx[7511] DEBUG 
weewx.engine: Finished loading service weewx.engine.StdQC Mär 08 20:25:54 
Raspi42 python3[7511]: weewx[7511] DEBUG weewx.engine: Loading service 
weewx.wxservices.StdWXCalculate Mär 08 20:25:54 Raspi42 

[weewx-user] Problems WeeWX Belchertown with MQTT

[Geni]

I have WeeWX 4.7.0, Blechertown 1.3b1 on a Raspberry 3 with the HiveMQ MQTT 
broker.
When trying to get MQTT running I am so far that the following is reported 
in the syslog:

Mar  9 13:03:58 Wetter-Raspi weewx[12415] INFO weewx.restx: MQTT: Published 
record 2022-03-09 13:03:59 CET (1646827439)
Mar  9 13:04:00 Wetter-Raspi weewx[12415] INFO weewx.restx: MQTT: Published 
record 2022-03-09 13:04:01 CET (1646827441)

Can I control what arrives at the broker with MQTT.fx?
What is published by WeeWX?

Site: https://wetter.affolter.familyds.net/
There you can only see that it is waiting for the connection.
Can I get a weewx.conf from a working system?


Thank You,

Geni

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/843108c6-fbfe-40d6-b2c9-2a730edd5eean%40googlegroups.com.

Re: [weewx-user] Re: WeeWX WebP image plot test

[paul.ba...@gmail.com]

1. SFTP can be used with compression (-C option) but I don't know if it is 
used or not in Weewx.
2. I tried to compress all my weewx images with tar and/or gzip.  At best I 
get less than 30 % reduction.  May be it is just enough for you.
3. gzip (or better the library behind it) is in fact used by ssh, sftp, tar 
etc. So in your case you should just be sure to use compressionwhatever the 
transfer protocol.

When lines were very slow, the default was always WITH compression. Now, 
with much, much faster lines available, the default is NO compression, as 
compression would slow down the process...

Regards, PaulB



Le Tuesday, March 8, 2022 à 7:17:20 PM UTC+1, vince a écrit :

> You might consider finding another service provider that 'does' support 
> rsync.
>
> If you're comfortable setting up a small webserver, Amazon Lightsail is 
> under $4 per month.
>
> On Tuesday, March 8, 2022 at 9:40:06 AM UTC-8 tom.h...@gmail.com wrote:
>
>> I thought of that, but the only supported method I can use is sftp.
>>
>> On Tue, Mar 8, 2022 at 7:44 AM Paul R Anderson  wrote:
>>
>>> Totally agree with Tom rsync is incredible if your hosted server 
>>> supports it try it, you'll never go back.
>>> Spoiled here with fiber 300 Mbps upload and download here but here are 
>>> WeeWX rsync transfers for my site here 10 North of Boston Massachusetts, to 
>>> my host in Newark, NJ
>>>
>> [snip]
>>>
>>
>>> On Tue, Mar 8, 2022 at 11:13 AM Tom Keffer  wrote:
>>>
 About 10 years ago, I switched to rsync and was astonished at how much 
 faster it is. Maybe an order of magnitude! It completely solved my upload 
 problem.



-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/815fd7c7-ee1d-40e8-8689-0c0aae9df4een%40googlegroups.com.

Re: [weewx-user] Weewx 4.7.0 & Weewx -WD

[gjr80]

Hi,

I've spent a bit of time today observing your clientraw.txt and Belchertown 
web site. On thing I have noted is that your clientraw.txt only updates 
approximately every 1.5 to 2.5 minutes. This suggests that loop packets are 
not coming in very often and they arrive irregularly. This could be causing 
some odd effects, in particular with wind where there a couple of fields 
that are calculated as aggregates over one minute. It might be useful to 
see what loop packets you have coming in and what their contents are. To do 
this stop WeeWX and then run WeeWX directly 
. This will display 
loop packets (lines starting with LOOP:) and archive records (lines 
starting with REC:) on your console. If you like let WeeWX run for 15 
minutes or so and capture and post the screen out (as text).

Just hitting the issues you have noted so far:

clientraw.txt location. Can be controlled with the rtcr_path config items 
as per my previous post. Any luck with this?

day max/min outTemp times. As you posted earlier these time are now 
updating. Throughout today (9th) when I have looked at your clientraw.txt 
the max/min outTemp times have been correct. It is possible to have some 
discrepancies with these values when WeeWX is first started but I'm not 
sure that is what was happening here. I suggest we monitor this for the 
next couple of days, particularly for the rest of the day after a WeeWX 
restart. If the issue comes back I can give you an instrumented version of 
rtcr.py to give us more detail on exactly what is happening.   

dewpoint. Appears to be fine as far as I can tell, every time I have looked 
the dewpoint value in clientraw.txt has agreed with your station.

avg wind speed/wind gust speed discrepancies. I gather here you are looking 
at the Saratoga or Alternate dashboard? (is your Saratoga dashboard 
publicly accessible? If it is could we have the address or if you don't 
wish to make it public could you advise me via 'reply to author' or by 
email to gjroderick at gmail dot com. There is a wealth of debug 
information built into the dashboard). If I understand you correctly you 
originally had field 140 (max gust in last minute) as average speed on the 
dashboard but changed it to field 1 (average wind speed in last 60 
seconds). You also had field 1 (average wind speed in last 60 seconds) as 
gust speed on the dashboard but changed it to field 2 (current wind speed). 
If that is the case I am not surprised you were initially seeing average 
wind speed higher than the gust speed as the you had a gust speed field 
displaying as average and an average speed field displaying as gust speed. 
I would be sticking with the original values in ajaxWEEWXwx.js (circa lines 
762-772):

//Wind gust
var gust = convertWind(clientraw[140]);
var maxgust = convertWind(clientraw[71]);
if (maxgust > 0.0 ) {
set_ajax_obs("ajaxmaxgust",maxgust.toFixed(1) + uomWind);
} else {
set_ajax_obs("ajaxmaxgust",'None');
}

//Windspeed ...
var wind = convertWind(clientraw[2]);

or perhaps changing gust to field 133 (max gust last hour) given your 
rather long loop period.

rainrate. Sounds like that is now working, unfortunately I have not 
observed any rain on your site.

Gary
On Wednesday, 9 March 2022 at 07:50:22 UTC+10 stefanos...@gmail.com wrote:

> Hi Gary ...
> Time of min-max temp ...ok ... It wasnt the clientraw as you said but i 
> reinstall the weewx plugin for Sarratoga template and all good
> Now i have also  max rain/rate value correct  but i dont know about 
> rain/rate because it stop raining
> Wind values are mystery I edited the ajaxweewx js file and i put [1] 
> for avg_speed instead of [140] and [2] for gust_speed instead of [1]
>
>
> On Tuesday, March 8, 2022 at 8:59:33 AM UTC+2 Stefanos Kalaitzis wrote:
>
>> Hi Gary ... Thanks !!
>>
>> Also Time of min-max temp still not updated 
>>
>> On Tuesday, March 8, 2022 at 12:31:21 AM UTC+2 gjr80 wrote:
>>
>>> > How do you find me...??
>>> That was not too difficult, your user name sounded very Greek so I 
>>> looked at the WeeWX user map  and there 
>>> are not that many stations in Greece. I knew you were using SDR and there 
>>> are not that many SDR stations around. Finding clientraw.txt was the 
>>> clincher.
>>>
>>> > 1. I cant change path of clientrraw.txt (always is saved to 
>>> puplic_html and i want to public_html/WD) even if i edit the rtcr.py
>>> I still need to finish off documenting the WeeWX-Saratoga options. You 
>>> can change the location that clientraw.txt is saved using the rtcr_patth 
>>> setting under [WeewxSaratoga] [[RealtimeClientraw]] in weewx.conf, eg:
>>>
>>> [WeewxSaratoga]
>>> 
>>> [[RealtimeClientraw]]
>>> # Path to clientraw.txt. Can be an absolute or relative path. 
>>> Relative
>>> # paths are relative to HTML_ROOT. Optional, default setting is 
>>> to use
>>> # HTML_ROOT.
>>> rtcr_path = 

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

Problem solved - your hint was extremely helpful. Really, the Engine part 
was corrupt. My previous post of Engine was an excerpt from my BACKUP copy 
of weewx.conf (taken before uninstall). Due to my uninstall the entry 
archive_services was completely corrupt into

archive_services = w, e, e, w, x, ., e, n, g, i, n, e, ., S, t, d, 
A, r, c, h, i, v, e

Now weewx 4.7.0 is up an running. Of course I did a comparision of "my" 
weewx.conf with the new one from 4.7.0, but based on my BACKUP copy.

Thank you very much, Michael

Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:37:12 UTC+1:

> [Engine]
>
> # The following section specifies which services should be run and in 
> what order.
> [[Services]]
> prep_services = weewx.engine.StdTimeSynch
> data_services = ,
> process_services = weewx.engine.StdConvert, 
> weewx.engine.StdCalibrate, weewx.engine.StdQC, 
> weewx.wxservices.StdWXCalculate
> xtype_services = weewx.wxxtypes.StdWXXTypes, 
> weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater, 
> weewx.wxxtypes.StdDelta
> archive_services = weewx.engine.StdArchive
> restful_services = weewx.restx.StdStationRegistry, 
> weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
> weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS
> report_services = weewx.engine.StdPrint, weewx.engine.StdReport
>
> [The weewx.conf in use is the one running successfully for weewx 4.5.1 but 
> with forecast removed. Sadly I did NOT check if weewx 4.5.1 would start 
> after uninstalling forecast. Thus maybe this uninstall is the rooot cause 
> of my problem?]
>
> Regards, Michael
>
> gjr80 schrieb am Mittwoch, 9. März 2022 um 09:24:13 UTC+1:
>
>> Please post a copy of the [Engine] stanza from weewx.conf.
>>
>> Gary
>>
>> On Wednesday, 9 March 2022 at 18:19:36 UTC+10 miwa...@googlemail.com 
>> wrote:
>>
>>> Setting debug=1  within weewx.conf enhances the amount of messages, but 
>>> still a crash:
>>>
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
>>> StdWXCalculate will use data binding wx_binding
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxservices.StdWXCalculate
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdWXXTypes
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdWXXTypes
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdPressureCooker
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdPressureCooker
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdRainRater
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdRainRater
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdDelta
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdDelta
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service w
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>> Caught unrecoverable exception:
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>>   Empty module name
>>>
>>> The logging seems to be interrupted by that hard error - see the 
>>> incomplete last DEBUG message.
>>>
>>> Regards, Michael
>>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:
>>>
 I've now compared the log messages from the successful start of weewx 
 4.5.1 with the current one - the difference occures with data binding 
 wx_binding:

 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 StdConvert target unit is 0x1
 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 Archive will use data binding wx_binding
 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 Record generation will be attempted in 'hardware'
 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 Using archive interval of 300 seconds (specified in weewx configuration)

 I did read the weewx upgrade guide before upgrading - but there are no 
 hints for potential risks.

 Regards, Michael
 Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:

> I'm using a patched version of wh23xx driver successfully with weewx 
> 4.5. After upgrade to 4.7.0 weewx crashes on startup:
>
> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
> Loading station type WH23xx (user.wh23xx)
> Mär 09 08:03:34 imurr9 

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

[gjr80]

That looks fine. I'm having trouble seeing how such an an error will 
truncate a log entry. Nor do I see uninstalling the forecast extension 
would cause such a problem. Keeping debug = 1 can you restart WeeWX and 
post the WeeWX log from the WeeWX startup through until the error occurs.

One other thing, are you sure this is the weewx.conf that is actually being 
used? What do you see as the [Engine] stanza in a wee_debug 
 report?

Gary
On Wednesday, 9 March 2022 at 18:37:12 UTC+10 miwa...@googlemail.com wrote:

> [Engine]
>
> # The following section specifies which services should be run and in 
> what order.
> [[Services]]
> prep_services = weewx.engine.StdTimeSynch
> data_services = ,
> process_services = weewx.engine.StdConvert, 
> weewx.engine.StdCalibrate, weewx.engine.StdQC, 
> weewx.wxservices.StdWXCalculate
> xtype_services = weewx.wxxtypes.StdWXXTypes, 
> weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater, 
> weewx.wxxtypes.StdDelta
> archive_services = weewx.engine.StdArchive
> restful_services = weewx.restx.StdStationRegistry, 
> weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
> weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS
> report_services = weewx.engine.StdPrint, weewx.engine.StdReport
>
> [The weewx.conf in use is the one running successfully for weewx 4.5.1 but 
> with forecast removed. Sadly I did NOT check if weewx 4.5.1 would start 
> after uninstalling forecast. Thus maybe this uninstall is the rooot cause 
> of my problem?]
>
> Regards, Michael
>
> gjr80 schrieb am Mittwoch, 9. März 2022 um 09:24:13 UTC+1:
>
>> Please post a copy of the [Engine] stanza from weewx.conf.
>>
>> Gary
>>
>> On Wednesday, 9 March 2022 at 18:19:36 UTC+10 miwa...@googlemail.com 
>> wrote:
>>
>>> Setting debug=1  within weewx.conf enhances the amount of messages, but 
>>> still a crash:
>>>
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
>>> StdWXCalculate will use data binding wx_binding
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxservices.StdWXCalculate
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdWXXTypes
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdWXXTypes
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdPressureCooker
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdPressureCooker
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdRainRater
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdRainRater
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service weewx.wxxtypes.StdDelta
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Finished loading service weewx.wxxtypes.StdDelta
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>>> Loading service w
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>> Caught unrecoverable exception:
>>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>>   Empty module name
>>>
>>> The logging seems to be interrupted by that hard error - see the 
>>> incomplete last DEBUG message.
>>>
>>> Regards, Michael
>>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:
>>>
 I've now compared the log messages from the successful start of weewx 
 4.5.1 with the current one - the difference occures with data binding 
 wx_binding:

 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 StdConvert target unit is 0x1
 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 Archive will use data binding wx_binding
 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 Record generation will be attempted in 'hardware'
 Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
 Using archive interval of 300 seconds (specified in weewx configuration)

 I did read the weewx upgrade guide before upgrading - but there are no 
 hints for potential risks.

 Regards, Michael
 Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:

> I'm using a patched version of wh23xx driver successfully with weewx 
> 4.5. After upgrade to 4.7.0 weewx crashes on startup:
>
> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
> Loading station type WH23xx (user.wh23xx)
> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather 

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

[Engine]

# The following section specifies which services should be run and in 
what order.
[[Services]]
prep_services = weewx.engine.StdTimeSynch
data_services = ,
process_services = weewx.engine.StdConvert, 
weewx.engine.StdCalibrate, weewx.engine.StdQC, 
weewx.wxservices.StdWXCalculate
xtype_services = weewx.wxxtypes.StdWXXTypes, 
weewx.wxxtypes.StdPressureCooker, weewx.wxxtypes.StdRainRater, 
weewx.wxxtypes.StdDelta
archive_services = weewx.engine.StdArchive
restful_services = weewx.restx.StdStationRegistry, 
weewx.restx.StdWunderground, weewx.restx.StdPWSweather, 
weewx.restx.StdCWOP, weewx.restx.StdWOW, weewx.restx.StdAWEKAS
report_services = weewx.engine.StdPrint, weewx.engine.StdReport

[The weewx.conf in use is the one running successfully for weewx 4.5.1 but 
with forecast removed. Sadly I did NOT check if weewx 4.5.1 would start 
after uninstalling forecast. Thus maybe this uninstall is the rooot cause 
of my problem?]

Regards, Michael

gjr80 schrieb am Mittwoch, 9. März 2022 um 09:24:13 UTC+1:

> Please post a copy of the [Engine] stanza from weewx.conf.
>
> Gary
>
> On Wednesday, 9 March 2022 at 18:19:36 UTC+10 miwa...@googlemail.com 
> wrote:
>
>> Setting debug=1  within weewx.conf enhances the amount of messages, but 
>> still a crash:
>>
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
>> StdWXCalculate will use data binding wx_binding
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxservices.StdWXCalculate
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdWXXTypes
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdWXXTypes
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdPressureCooker
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdPressureCooker
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdRainRater
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdRainRater
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service weewx.wxxtypes.StdDelta
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Finished loading service weewx.wxxtypes.StdDelta
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
>> Loading service w
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: Caught 
>> unrecoverable exception:
>> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>>   Empty module name
>>
>> The logging seems to be interrupted by that hard error - see the 
>> incomplete last DEBUG message.
>>
>> Regards, Michael
>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:
>>
>>> I've now compared the log messages from the successful start of weewx 
>>> 4.5.1 with the current one - the difference occures with data binding 
>>> wx_binding:
>>>
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>> StdConvert target unit is 0x1
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>> Archive will use data binding wx_binding
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>>> Record generation will be attempted in 'hardware'
>>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
>>> archive interval of 300 seconds (specified in weewx configuration)
>>>
>>> I did read the weewx upgrade guide before upgrading - but there are no 
>>> hints for potential risks.
>>>
>>> Regards, Michael
>>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:
>>>
 I'm using a patched version of wh23xx driver successfully with weewx 
 4.5. After upgrade to 4.7.0 weewx crashes on startup:

 Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
 Loading station type WH23xx (user.wh23xx)
 Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: 
 weewx.
 Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
 Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
 StdConvert target unit is 0x1
 Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO 
 weewx.wxservices: StdWXCalculate will use data binding wx_binding
 Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
 Caught unrecoverable exception:
 Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
   Empty module name
 Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
   Traceback (most recent call last):
 

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

[gjr80]

Please post a copy of the [Engine] stanza from weewx.conf.

Gary

On Wednesday, 9 March 2022 at 18:19:36 UTC+10 miwa...@googlemail.com wrote:

> Setting debug=1  within weewx.conf enhances the amount of messages, but 
> still a crash:
>
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Finished loading service weewx.wxservices.StdWXCalculate
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Loading service weewx.wxxtypes.StdWXXTypes
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Finished loading service weewx.wxxtypes.StdWXXTypes
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Loading service weewx.wxxtypes.StdPressureCooker
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Finished loading service weewx.wxxtypes.StdPressureCooker
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Loading service weewx.wxxtypes.StdRainRater
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Finished loading service weewx.wxxtypes.StdRainRater
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Loading service weewx.wxxtypes.StdDelta
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Finished loading service weewx.wxxtypes.StdDelta
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
> Loading service w
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: Caught 
> unrecoverable exception:
> Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: 
>   Empty module name
>
> The logging seems to be interrupted by that hard error - see the 
> incomplete last DEBUG message.
>
> Regards, Michael
> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:
>
>> I've now compared the log messages from the successful start of weewx 
>> 4.5.1 with the current one - the difference occures with data binding 
>> wx_binding:
>>
>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>> StdConvert target unit is 0x1
>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
>> Archive will use data binding wx_binding
>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Record 
>> generation will be attempted in 'hardware'
>> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
>> archive interval of 300 seconds (specified in weewx configuration)
>>
>> I did read the weewx upgrade guide before upgrading - but there are no 
>> hints for potential risks.
>>
>> Regards, Michael
>> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:
>>
>>> I'm using a patched version of wh23xx driver successfully with weewx 
>>> 4.5. After upgrade to 4.7.0 weewx crashes on startup:
>>>
>>> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>>> Loading station type WH23xx (user.wh23xx)
>>> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: 
>>> weewx.
>>> Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>>> StdConvert target unit is 0x1
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO 
>>> weewx.wxservices: StdWXCalculate will use data binding wx_binding
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>>> Caught unrecoverable exception:
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>     Empty module name
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>     Traceback (most recent call last):
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>   File "/usr/share/weewx/weewxd", line 147, in main
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>     engine = weewx.engine.StdEngine(config_dict)
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>   File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>     self.loadServices(config_dict)
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>   File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>     obj = weeutil.weeutil.get_object(svc)(self, config_dict)
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>   File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in 
>>> get_object
>>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>>     mod = __import__(module)
>>> Mär 09 08:03:35 

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

Setting debug=1  within weewx.conf enhances the amount of messages, but 
still a crash:

Mär 09 09:14:43 imurr9 python3[859]: weewx[859] INFO weewx.wxservices: 
StdWXCalculate will use data binding wx_binding
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxservices.StdWXCalculate
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdWXXTypes
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdWXXTypes
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdPressureCooker
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdPressureCooker
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdRainRater
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdRainRater
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service weewx.wxxtypes.StdDelta
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: 
Finished loading service weewx.wxxtypes.StdDelta
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] DEBUG weewx.engine: Loading 
service w
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__: Caught 
unrecoverable exception:
Mär 09 09:14:43 imurr9 python3[859]: weewx[859] CRITICAL __main__:  
 Empty module name

The logging seems to be interrupted by that hard error - see the incomplete 
last DEBUG message.

Regards, Michael
Michael Waldor schrieb am Mittwoch, 9. März 2022 um 09:02:39 UTC+1:

> I've now compared the log messages from the successful start of weewx 
> 4.5.1 with the current one - the difference occures with data binding 
> wx_binding:
>
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
> StdConvert target unit is 0x1
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Archive 
> will use data binding wx_binding
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Record 
> generation will be attempted in 'hardware'
> Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
> archive interval of 300 seconds (specified in weewx configuration)
>
> I did read the weewx upgrade guide before upgrading - but there are no 
> hints for potential risks.
>
> Regards, Michael
> Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:
>
>> I'm using a patched version of wh23xx driver successfully with weewx 4.5. 
>> After upgrade to 4.7.0 weewx crashes on startup:
>>
>> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>> Loading station type WH23xx (user.wh23xx)
>> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: weewx.
>> Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
>> StdConvert target unit is 0x1
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO 
>> weewx.wxservices: StdWXCalculate will use data binding wx_binding
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>> Caught unrecoverable exception:
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     Empty module name
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     Traceback (most recent call last):
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weewxd", line 147, in main
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     engine = weewx.engine.StdEngine(config_dict)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     self.loadServices(config_dict)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     obj = weeutil.weeutil.get_object(svc)(self, config_dict)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>   File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in 
>> get_object
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     mod = __import__(module)
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     ValueError: Empty module name
>> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__:   
>>     Exiting.
>>
>> But I have to admit - before updating I did deinstall the old forecast 

[weewx-user] Re: Weewx 4.7.0 with wh23xx driver fails

['Michael Waldor' via weewx-user]

I've now compared the log messages from the successful start of weewx 4.5.1 
with the current one - the difference occures with data binding wx_binding:

Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: 
StdConvert target unit is 0x1
Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Archive 
will use data binding wx_binding
Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Record 
generation will be attempted in 'hardware'
Feb 13 09:08:36 imurr9 python3[500]: weewx[500] INFO weewx.engine: Using 
archive interval of 300 seconds (specified in weewx configuration)

I did read the weewx upgrade guide before upgrading - but there are no 
hints for potential risks.

Regards, Michael
Michael Waldor schrieb am Mittwoch, 9. März 2022 um 08:43:55 UTC+1:

> I'm using a patched version of wh23xx driver successfully with weewx 4.5. 
> After upgrade to 4.7.0 weewx crashes on startup:
>
> Mär 09 08:03:34 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
> Loading station type WH23xx (user.wh23xx)
> Mär 09 08:03:34 imurr9 weewx[21356]: Starting weewx weather system: weewx.
> Mär 09 08:03:34 imurr9 systemd[1]: Started LSB: weewx weather system.
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.engine: 
> StdConvert target unit is 0x1
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] INFO weewx.wxservices: 
> StdWXCalculate will use data binding wx_binding
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> Caught unrecoverable exception:
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   Empty module name
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   Traceback (most recent call last):
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weewxd", line 147, in main
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   engine = weewx.engine.StdEngine(config_dict)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine.py", line 93, in __init__
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   self.loadServices(config_dict)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weewx/engine.py", line 161, in loadServices
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   obj = weeutil.weeutil.get_object(svc)(self, config_dict)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
> File "/usr/share/weewx/weeutil/weeutil.py", line 1150, in get_object
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   mod = __import__(module)
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   ValueError: Empty module name
> Mär 09 08:03:35 imurr9 python3[21370]: weewx[21370] CRITICAL __main__: 
>   Exiting.
>
> But I have to admit - before updating I did deinstall the old forecast 
> module using wee_extension --uninstall=forecast
>
> I tried to exchange my old wh23xx.py by the patched one from neighbouring 
> thread 
>
> But I guess that I have a different problem. any ideas?
>
>
> Regards, Michael
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/23e17f2b-49cd-4b1e-9c79-c6e7f8754583n%40googlegroups.com.