captain-coredump / weatherflow-udp Goto Github PK

Looking in https://github.com/weewx/weewx/blob/master/bin/weeutil/log.py we see

def log_open(log_label='weewx'):
syslog.openlog(log_label, syslog.LOG_PID | syslog.LOG_CONS)

Which is apparently overridden by --log-label command line options.

Looking in https://github.com/captain-coredump/weatherflow-udp/blob/master/bin/user/weatherflowudp.py we see

def logmsg(level, msg):
syslog.syslog(level, 'weatherflowudp: %s: %s' %
(threading.currentThread().getName(), msg))

So when you enable syslog filtering the weatherflowudp loggings says in syslog

e.g.
Sep 9 00:00:30 weather64 /weewxd: weatherflowudp: MainThread: driver version is 1.10
Sep 9 00:00:30 weather64 /weewxd: weatherflowudp: MainThread: sensor map is {}
Sep 9 00:00:30 weather64 /weewxd: weatherflowudp: MainThread: *** Sensor names per packet type

The recomendation for syslog is here: https://github.com/weewx/weewx/wiki/logging
:programname,startswith,"wee_" /var/log/weewx/weewx.log
:programname,startswith,"wee_" ~
:programname,isequal,"weewx-vantage" /var/log/weewx/vantage.log
:programname,isequal,"weewx-vantage" ~
:programname,isequal,"weewx-rainwise" /var/log/weewx/rainwise.log
:programname,isequal,"weewx-rainwise" ~

readme says:

log_raw_packets = False

Enable writing all raw UDP packets received to syslog,
(**or wherever weewx is configured to send log info**).  Will
fill up your logs pretty quickly, so only use it as
a debugging tool or to identify sensors.

So either the readme needs go be updated to offer up a change to /etc/rsyslog.d/10-weewx.conf or the log location ought to be changed o whatever the parent "--log-label" command line argument suggests or default to "weewx".

Workaround of course it to look in syslog but it took me a few minutes to figure out they had not been redirected.

I must say that I am only parroting your instructions and I am really a fish out of water here. I did get weewx installed and working but I got to the following point and got this error. I trued it without the sudo and has a permission problemm

MacBook-Pro:weewx Kurt$ sudo ./bin/wee_extension --install weatherflow-udp-master.zip
Password:
Request to install 'weatherflow-udp-master.zip'
Extracting from zip archive weatherflow-udp-master.zip
Traceback (most recent call last):
File "./bin/wee_extension", line 88, in
main()
File "./bin/wee_extension", line 80, in main
ext.install_extension(options.install)
File "/Users/Shared/weewx/bin/weecfg/extension.py", line 113, in install_extension
self.tmpdir, self.logger)
File "/Users/Shared/weewx/bin/weecfg/init.py", line 1773, in extract_zip
with open(path, 'wb') as dest_file:
FileNotFoundError: [Errno 2] No such file or directory: '/var/tmp/__MACOSX/._weatherflow-udp-master'

Hi,

I have been fiddling with a problem for a few hours and I finally need to resort to some advice. I am not a coder but I'm familiar with weewx and the weatherflow udp extension as I have it running successfully on a few raspberry pi's. I also have it running on one Mac Mini and this is the one that is confusing me.

Currently, weewx is installed and working. If I put it on 'Simulator' then it works and broadcasts to windguru. If I change to 'WeatherFlowUDP' then nothing happens. From the log it seems to me like the sensor_map is not being loaded, but I've made sure the [[sensor_map]] section is in the weewx.conf - also important to note that I've confirmed that the Mac mini and the base station of the weather station are on the same network and I can also ping successfully. Any suggestions?

Here's the weatherflow section in my weewx.conf
https://www.dropbox.com/s/jxa1fxiad0kb4v8/sample_sensor_map.rtf?dl=0

Here's the output from the weewx.log
https://www.dropbox.com/s/15xiak0qe05fzl6/sample_weewx_log.rtf?dl=0

I have a Weatherflow SKY, AIR and hub in service now. This project is exciting as I'd like basically to own my own weather data and log it in a local database (happy for it to go out to smartweather's databases as well, I don't mind sharing but I do want to keep it locally as well).

Reading the README though I am left with an uncertainty that I think it would be nice to address there. Namely how does weatherflow-udp see the Hub's transmissions.

I am rather ignorant in this space. I suspect the Weatherflow hub sends UDP packets back to the weatherflow.com and that we can sniff those on the way past. But the only place they'd be reliably visible is on my gateway router surely. The README currently suggests they are broadcast on the LAN. That seems a lot of unnecessary traffic depending entirely on the frequency of the data I guess, and is worth clarifying. Of course if they are broadcast then any device on my LAN could see them.

Clarifying all this would be pleasing.

install.py file is looking for the "bin/user/weatherflowudp.py" file but in the git the file found in "bin/user/" is udpbroadcast.py

I have noticed that at times data is missing either partially or the whole ob when sent to CWOP. I haven't been able to find a cause for this. I tried changing the udp timeout time and the weewx.conf StdArchive time and it doesn't seem to help. I am running WeeWX 3.8.2. I don't get any errors when data is missed. Since Weewx changes the time when data is sent to CWOP (which reduced the stress on CWOP servers), I am wondering if this is causing data to be missed at times.

http://www.findu.com/cgi-bin/raw.cgi?call=CW9009
https://mesowest.utah.edu/cgi-bin/droman/meso_base_dyn.cgi?stn=C9009&unit=0&timetype=LOCAL

Hi,

I have a weather station with Raspberry Pi and a WeatherFlow Tempest sensor. It has been working perfectly for a few months. Suddenly it is reporting an incorrect wind speed on windguru. On the Weatherflow app for iPhone it says 10 knots which is accurate according to the real wind on the beach. However, on windguru it's showing 15-18 knots, or something like that. In other words, higher than it really is. I've had this issue in the past with a kph/mph conversion error within python. Could it be something like this?

It's just very strange because a few days ago it was accurate and I didn't make any change or update to the Raspberry Pi. Is anyone else having this issue?

Thank you.

Hello
Just learning weewx and especially how to install your extension as I also have the weatherflow air ...
Can you please explain in a few extra words how to install your extension ?
What to download where and what command to use (wee_extension --install ??)
post install command ?
thanks
eric

Getting this error when attempting to run weewx with the plugin.

Jun 19 07:04:18 NodePi weewx[27339]: **** for packet in self.console.genLoopPackets():
Jun 19 07:04:18 NodePi weewx[27339]: **** File "/usr/share/weewx/user/weatherflowudp.py", line 271, in genLoopPackets
Jun 19 07:04:18 NodePi weewx[27339]: **** s.bind((self._udp_address,self._udp_port))
Jun 19 07:04:18 NodePi weewx[27339]: **** File "/usr/lib/python2.7/socket.py", line 228, in meth
Jun 19 07:04:18 NodePi weewx[27339]: **** return getattr(self._sock,name)(*args)
Jun 19 07:04:18 NodePi weewx[27339]: **** error: [Errno 98] Address already in use
Jun 19 07:04:18 NodePi weewx[27339]: **** Exiting.
Jun 19 07:05:38 NodePi wee_device[27414]: The driver user.weatherflowudp does not include a configuration tool: 'module' object has no attribute 'configurator_loader'
Jun 19 07:06:36 NodePi wee_device[27481]: The driver user.weatherflowudp does not include a configuration tool: 'module' object has no attribute 'configurator_loader'

Consistently the rain totals being reported to remote services (e.g., WeatherUnderground, PWS Weather) are in excess (by approximately 50%) of those totals being recorded by my Tempest weather station. For example, today my Tempest shows 0.28" of accumulation, and WU and PWS both show 0.44" of accumulation. This is VERY consistent behavior from day to day.

I added the following to the sensor map and was able to record the RSSI level and have it display in the widget on the page:

rxCheckPercent = rssi.ST-00006682.device_status

My issue is that it appears the graph for the data is only scaled for positive percentage:

How does one change the scale for that chart? I have been reading quite a bit on the WeeWx site but can't seems to understand how charts in skins work.

Thanks.

Never mind...I kept digging and digging and found the scaling in the skin directory and in the skin.conf file. There were one for each time domain, day, week,month,year.

         [[[dayrx]]]
#            yscale = 0.0, 100.0, 25.0
            yscale = -99, 0, 25.0
            [[[[rxCheckPercent]]]]

I don't know how long it's been like this, but I see lots of messages in the logfile saying "Unknown packet type: 'light_debug'".

Jan 6 08:32:18 qnap user.err weewx[6349] ERROR user.weatherflowudp: Unknown packet type: 'light_debug'

I wonder if this is caused by a new version of the firmware, at least the Tempest says it is on v147 while https://weatherflow.github.io/Tempest/releases/firmware.html seems to say that the latest is v143 but that's just guessing. I say this because I noticed a slight pause in measuring, so I wonder if that may have been updating of the firmware. But that's wild guessing., it may have been this way for days, I really don't know. Logfiles (due to these messages) no longer go back to where measuring stopped this night so can't check.

I am trying to run WeeWX w/ the Weatherflow-UDP driver in a FreeBSD 12.2 Jail. I installed all the requirements using python3.8, and I have my jail configured so it can use promiscuous mode (this required using VNET, and enabling BPF... before I did this, I couldn't tcpdump the UDP traffic from the weatherflow), but weewx is crashing in weatherflow-udp...

Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: Caught OSError: [Errno 49] Can't assign requested address
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** Traceback (most recent call last):
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** File "bin/weewxd", line 157, in main
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** engine.run()
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** File "/usr/home/weewx/bin/weewx/engine.py", line 208, in run
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** for packet in self.console.genLoopPackets():
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** File "/usr/home/weewx/bin/user/weatherflowudp.py", line 298, in genLoopPackets
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** s.bind((self._udp_address,self._udp_port))
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** OSError: [Errno 49] Can't assign requested address
Dec 1 01:54:06 weewx2 weewx[49521] CRITICAL main: **** Waiting 10 seconds then retrying...

I'm a novice at python and BSD, but some random googling suggests you have to use a different technique to listen to UDP broadcasts

Unless I've gone astray somewhere, the basic install process doesn't work with weewx 4.1. The environment:

• Fresh Raspbian lite install

• Fresh weewx 4.1 install, simulator selected during setup

• Download zip of github repository:
  wget -nd https://github.com/captain-coredump/weatherflow-udp/archive/master.zip

• Renamed master.zip to weatherflow-udp-master to match Readme:
  mv master.zip weatherflow-udp-master.zip

• Install via wee-extension:
  wee_extension --install weatherflow-udp-master.zip

• Appears to go correctly:
  (output from wee_extension):
  Request to install 'weatherflow-udp-master.zip'
  Extracting from zip archive weatherflow-udp-master.zip
  Saving installer file to /usr/share/weewx/user/installer/weatherflowudp
  Finished installing extension 'weatherflow-udp-master.zip'

• weewx.conf is unmodified, simulator driver is not replaced, weatherflow driver is not added.

So it seems that the process as documented in the Readme doesn't work with a fresh weewx 4.1 installation. I'm proceeding to just do a manual install, may try to debug the install issue later.

** A quick glance (without reading the weewx docs) seems to indicate there is a missing 'Config' stanza from the install.py file. Will dig into it further if I get a chance.

I'm not sure if it's possible to gather the battery status from the UDP stream and plug it into the WeeWx basic web page... is it?

Would this be something that can be controlled in the Weewx.conf file? or something that is part of the style sheet for the web page? I'm in no way a programmer, so I apologize for the ignorant question!

Hi,

A few months ago you helped me to realise that the [[sensor_map]] was not indented correctly and that fixed the problem. Now, somehow I am back at this problem and I'm trying to trouble shoot. Here is the summary:

• weewx is running on MacOS and it has been working for about a year, but now it is not working anymore.
• when I switch back to 'Simulator', weewx posts to windguru correctly - so we know that weewx is working properly. For now, I have left it set on 'Simulator' to prove that it is working. UPDATE - I turned simulator off because it is posting the wrong data to windguru and confusing people.
• when the driver was set to 'WeatherFlowUDP', the weewx log file is here, you can see that weatherflowudp is enabled but no [[sensor_map]] is being loaded.
• At the same time, I have triple checked that the 'WeatherFlow' section in weewx.conf and all the indentation seems right, you can see it here

Please let me know if you have any good ideas?

Originally posted by @foilandwater in #22 (comment)

Any help is greatly appreciated. I am quite new to raspberry pi (and GitHub) and I'm stuck. Have WeeWx installed and running on Raspberry Pi. Simulator page looks good. Ran this command: wee_extension --install weatherflow-udp-master.zip and all looks good to this point. I see my station name on browser page with simulator data. I don't see that the wee extension replaced the simulator. I have made several attempts to edit weewx.conf all resulting in a variety of errors/failure. What am I missing? Thanks

Hi,

Thanks to all the parties involved in making all these amazing pieces of software that helps us interface everything. I am successfully using this WeatherFlowUDP on 2 different Raspberry Pi's with a Tempest weather system. It's working well and it's broadcasting to Windguru, no worries. I am trying to set up a 3rd station using a Mac mini this time and it is 99% of the way there, but not working.

The WeatherFlowUDP extension is installed, I've used udp_address = 0.0.0.0 because the others threw out an error, but now it's ok. When I run the driver directly so that I can grab the packets using (log_raw_packets = True) I'm not seeing the packets. I've tried running the driver directly with sudo python3 ./bin/weewxd weewx.conf and I've also tried running it as a daemon. The packets are neither seen directly as an output, or in the weewx.log file.

If I put the weewx.conf back to 'Simulator' and run the driver manually, then I see the fake packets and it broadcasts to windguru.

I can't get past the sensor map step - would appreciate any suggestions.

Thanks.

Hi all,

First of all - Merry Christmas!

My Weewx installation fails to start with following error:

weewx[2060] CRITICAL main: Caught unrecoverable exception:
weewx[2060] CRITICAL main: **** Could not fetch records from WeatherFlow webservice: <Response [500]>
weewx[2060] CRITICAL main: **** Traceback (most recent call last):
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/weewxd", line 154, in main
weewx[2060] CRITICAL main: **** engine.run()
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/weewx/engine.py", line 178, in run
weewx[2060] CRITICAL main: **** self.dispatchEvent(weewx.Event(weewx.STARTUP))
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/weewx/engine.py", line 245, in dispatchEvent
weewx[2060] CRITICAL main: **** callback(event)
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/weewx/engine.py", line 584, in startup
weewx[2060] CRITICAL main: **** self._catchup(self.engine.console.genStartupRecords)
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/weewx/engine.py", line 697, in catchup
weewx[2060] CRITICAL main: **** for record in generator(lastgood_ts):
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/user/weatherflowudp.py", line 620, in genStartupRecords
weewx[2060] CRITICAL main: **** for packet in readDataFromWF(since_ts + 1, self., self._devices, self._device_dict, self._batch_size):
weewx[2060] CRITICAL main: **** File "/usr/share/weewx/user/weatherflowudp.py", line 329, in readDataFromWF
weewx[2060] CRITICAL main: **** raise DriverException("Could not fetch records from WeatherFlow webservice: {}".format(response))
weewx[2060] CRITICAL main: **** user.weatherflowudp.DriverException: Could not fetch records from WeatherFlow webservice: <Response [500]>
weewx[2060] CRITICAL main: **** Exiting.

I have set token = TOKEN in the WeatherFlowUDP configuration.
I can access both
https://swd.weatherflow.com/swd/rest/observations/device/DEVICE_ID?token=TOKEN
and
https://swd.weatherflow.com/swd/rest/stations?token=TOKEN
In both cases request returns proper reply.

This issue surfaced when I restarted server and noticed that Weewx did not start.
I have not changed any configurations.

Any ideas what's wrong?

Thanks in advance!

Hi Arthur,
Thanks for doing this. I just received my AIR unit and want to to work with in combination with weewx. But I am new to this, so how do I get weewx to use this as a driver? What do I write in the weewx.conf file?

Bjarne

I have the latest driver working on Weewx 4.1.1 and Belchertown 1.1.

Thank you very much for the driver!

I'm running weewx on a Raspberry Pi so want to absolutely minmize SD card writes. Is there a way to control logging from the driver, ideally using the new logging facility in weewx 4? I want to not log informational messages such as:

"Listening for UDP broadcasts. . ."

Regards,

Garry

Tom's got an alpha of weewx 4.0 running, which will be the one that moves to python3. Everybody with drivers and extensions needs to check their stuff for compatibility and make the generally minor edits needed. I ran your driver through 2to3 and it came up with some minor patches needed (untested).

My 'recollection' is that this should work with both versions of python as a result (untested).

--- weatherflowudp.py	(original)
+++ weatherflowudp.py	(refactored)
@@ -138,7 +138,7 @@

 """

-from __future__ import with_statement
+
 import math
 import time
 import weewx.units
@@ -192,7 +192,7 @@
             # weewx.METRICWX = mm/mps ; weewx.METRIC = cm/kph
             'usUnits' : weewx.METRICWX}

-    for pkt_weewx, pkt_label in sensor_map.iteritems():
+    for pkt_weewx, pkt_label in sensor_map.items():
         if pkt_label.replace("-","_") in pkt:
            packet[pkt_weewx] = pkt[pkt_label.replace("-","_")]

@@ -205,7 +205,7 @@
             serial_number = pkt['serial_number'].replace("-","_")
             pkt_type = pkt['type']
             pkt_label = serial_number + "." + pkt_type
-            pkt_keys = pkt.keys()
+            pkt_keys = list(pkt.keys())
             for i in pkt_keys:
                 pkt_item = i + "." + pkt_label
                 packet[pkt_item] = pkt[i]
@@ -268,7 +268,7 @@
         self._sensor_map = stn_dict.get('sensor_map', {})
         loginf('sensor map is %s' % self._sensor_map)
         loginf('*** Sensor names per packet type')
-        for pkt_type in fields.keys():
+        for pkt_type in list(fields.keys()):
             loginf('packet %s: %s' % (pkt_type,fields[pkt_type]))

     def hardware_name(self):

I have been using weatherflow-udp for a few months and I have seen some gaps in the data in weewx during that time. A couple of days ago I installed MQTTSubscribe to add an interior sensor. That new service has caused weewx to exit occasionally due to the weatherflow data time stamps being out of order as it tried to append the data.

Jun 20 11:05:35 MITX-6930 weewx[16315]: weatherflowudp: MainThread: raw packet: {'serial_number': 'SK-00015052', 'type': 'rapid_wind', 'ob': [1561053931, 0.98, 342], 'hub_sn': 'HB-00011764'}
Jun 20 11:05:35 MITX-6930 weewx[16315]: weatherflowudp: MainThread: parsed packet: {'serial_number.SK_00015052.rapid_wind': 'SK-00015052', 'type.SK_00015052.rapid_wind': 'rapid_wind', 'hub_sn.SK_00015052.rapid_wind': 'HB-00011764', 'time_epoch.SK_00015052.rapid_wind': 1561053931, 'ob.SK_00015052.rapid_wind': [1561053931, 0.98, 342], 'wind_speed.SK_00015052.rapid_wind': 0.98, 'wind_direction.SK_00015052.rapid_wind': 342, 'time_epoch': 1561053931}
Jun 20 11:05:35 MITX-6930 weewx[16315]: weatherflowudp: MainThread: Loop packet: {'windDir': 342, 'windSpeed': 0.98, 'usUnits': 17, 'dateTime': 1561053931}
Jun 20 11:05:35 MITX-6930 weewx[16315]: MQTTSubscribeService: Packet prior to update is: 2019-06-20 11:05:31 PDT (1561053931) dateTime: 1561053931, usUnits: 17, windDir: 342, windSpeed: 0.98
Jun 20 11:05:35 MITX-6930 weewx[16315]: MQTTSubscribeService: Processing interval: 1561053928.000000 1561053931.000000
Jun 20 11:05:35 MITX-6930 weewx[16315]: MQTTSubscribe: TopicManager queue size is: 0
Jun 20 11:05:35 MITX-6930 weewx[16315]: MQTTSubscribeService: Queue was empty
Jun 20 11:05:35 MITX-6930 weewx[16315]: MQTTSubscribeService: Packet after update is: 2019-06-20 11:05:31 PDT (1561053931) dateTime: 1561053931, usUnits: 17, windDir: 342, windSpeed: 0.98
Jun 20 11:05:35 MITX-6930 weewx[16315]: restx: MQTT: Published record 2019-06-20 11:05:31 PDT (1561053931)
Jun 20 11:05:37 MITX-6930 weewx[16315]: weatherflowudp: MainThread: raw packet: {'firmware_revision': 43, 'serial_number': 'SK-00015052', 'type': 'obs_sky', 'obs': [[1561053914, 29168, 3.06, 0.0, 0.0, 0.68, 1.52, 7, 3.39, 1, 243, None, 0, 3]], 'hub_sn': 'HB-00011764'}
Jun 20 11:05:37 MITX-6930 weewx[16315]: weatherflowudp: MainThread: parsed packet: {'wind_avg.SK_00015052.obs_sky': 0.68, 'type.SK_00015052.obs_sky': 'obs_sky', 'rain_accumulated.SK_00015052.obs_sky': 0.0, 'hub_sn.SK_00015052.obs_sky': 'HB-00011764', 'precipitation_type.SK_00015052.obs_sky': 0, 'uv.SK_00015052.obs_sky': 3.06, 'firmware_revision.SK_00015052.obs_sky': 43, 'wind_gust.SK_00015052.obs_sky': 1.52, 'wind_direction.SK_00015052.obs_sky': 7, 'local_day_rain_accumulation.SK_00015052.obs_sky': None, 'obs.SK_00015052.obs_sky': [[1561053914, 29168, 3.06, 0.0, 0.0, 0.68, 1.52, 7, 3.39, 1, 243, None, 0, 3]], 'wind_sample_interval.SK_00015052.obs_sky': 3, 'illuminance.SK_00015052.obs_sky': 29168, 'report_interval.SK_00015052.obs_sky': 1, 'time_epoch.SK_00015052.obs_sky': 1561053914, 'solar_radiation.SK_00015052.obs_sky': 243, 'time_epoch': 1561053914, 'wind_lull.SK_00015052.obs_sky': 0.0, 'battery.SK_00015052.obs_sky': 3.39, 'serial_number.SK_00015052.obs_sky': 'SK-00015052'}
Jun 20 11:05:37 MITX-6930 weewx[16315]: weatherflowudp: MainThread: Loop packet: {'skyBatteryVoltage': 3.39, 'precipitationType': 0, 'windBatteryStatus': 3.39, 'UV': 3.06, 'radiation': 243, 'rain': 0.0, 'dateTime': 1561053914, 'illuminance': 29168, 'windLull': 0.0, 'usUnits': 17}
Jun 20 11:05:37 MITX-6930 weewx[16315]: MQTTSubscribeService: Packet prior to update is: 2019-06-20 11:05:14 PDT (1561053914) dateTime: 1561053914, illuminance: 29168, precipitationType: 0, radiation: 243, rain: 0.0, skyBatteryVoltage: 3.39, usUnits: 17, UV: 3.06, windBatteryStatus: 3.39, windLull: 0.0
Jun 20 11:05:37 MITX-6930 weewx[16315]: MQTTSubscribeService: Processing interval: 1561053931.000000 1561053914.000000
Jun 20 11:05:37 MITX-6930 weewx[16315]: engine: Main loop exiting. Shutting engine down.
Jun 20 11:05:37 MITX-6930 weewx[16315]: engine: Shutting down StdReport thread
Jun 20 11:05:37 MITX-6930 weewx[16315]: engine: StdReport thread has been terminated
Jun 20 11:05:37 MITX-6930 weewx[16315]: restx: Shut down MQTT thread.
Jun 20 11:05:37 MITX-6930 weewx[16315]: restx: Shut down Wunderground-RF thread.
Jun 20 11:05:37 MITX-6930 weewx[16315]: MQTTSubscribe: Disconnected with result code 0
Jun 20 11:05:37 MITX-6930 weewx[16315]: engine: Caught unrecoverable exception in engine:
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****  start time (1561053931) is greater than stop time (1561053914)
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****  Traceback (most recent call last):
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/weewx/engine.py", line 890, in main
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      engine.run()
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/weewx/engine.py", line 191, in run
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet))
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      callback(event)
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/user/MQTTSubscribe.py", line 609, in new_loop_packet
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      target_data = self.subscriber.get_accumulated_data(topic, start_ts, self.end_ts, event.packet['usUnits'])
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/user/MQTTSubscribe.py", line 529, in get_accumulated_data
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      return self.manager.get_accumulated_data(topic, start_ts, end_ts, units)
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/user/MQTTSubscribe.py", line 277, in get_accumulated_data
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      accumulator = weewx.accum.Accum(weeutil.weeutil.TimeSpan(start_ts, end_ts))
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****    File "/usr/share/weewx/weeutil/weeutil.py", line 256, in __new__
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****      raise ValueError("start time (%d) is greater than stop time (%d)" % (args[0], args[1]))
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****  ValueError: start time (1561053931) is greater than stop time (1561053914)
Jun 20 11:05:37 MITX-6930 weewx[16315]:     ****  Exiting.

The RSSI value for both the sky and air sensors is good so I don't understand why there would be a gap in the timestamps unless there is something else going on.

i pulled down the recent update that fixed the weewx station registry. now i get some random crashes that cause weewx to exit. its pretty random sometimes will run 8 hours other times 2 days between crashes

`× weewx.service - WeeWX
Loaded: loaded (/lib/systemd/system/weewx.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Fri 2024-02-23 07:50:57 EST; 7h ago
Docs: https://weewx.com/docs
Process: 760 ExecStart=weewxd /etc/weewx/weewx.conf (code=exited, status=1/FAILURE)
Main PID: 760 (code=exited, status=1/FAILURE)
CPU: 31min 39.845s

Feb 23 07:50:57 weewx weewxd[760]: File "/usr/share/weewx/weewxd.py", line 166, in main
Feb 23 07:50:57 weewx weewxd[760]: engine.run()
Feb 23 07:50:57 weewx weewxd[760]: File "/usr/share/weewx/weewx/engine.py", line 204, in run
Feb 23 07:50:57 weewx weewxd[760]: for packet in self.console.genLoopPackets():
Feb 23 07:50:57 weewx weewxd[760]: File "/etc/weewx/bin/user/weatherflowudp.py", line 313, in genLoopPackets
Feb 23 07:50:57 weewx weewxd[760]: m0 = m[0].replace(",null",",None") # Python 2
Feb 23 07:50:57 weewx weewxd[760]: TypeError: a bytes-like object is required, not 'str'
Feb 23 07:50:57 weewx systemd[1]: weewx.service: Main process exited, code=exited, status=1/FAILURE
Feb 23 07:50:57 weewx systemd[1]: weewx.service: Failed with result 'exit-code'.
Feb 23 07:50:57 weewx systemd[1]: weewx.service: Consumed 31min 39.845s CPU time.`