Running Ecowitt Gateway Driver bith as a driver and a service at the same time?

[michael.k...@gmx.at]

Yes, it's possible. 

2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:27:35 weewxd[5855] DEBUG user.gw1000: Next update in 9 seconds

LOOP:   2024-01-19 18:27:35 CET (1705685255) 'altimeter': '1023.2565915245989', 'appTemp': '-4.6378894597484965', 'barometer': '1026.3446847507096', 'cloudbase': '972.4294835518078', 'dateTime': '1705685255', 'daymaxwind': '2.1', 'dayRain': '4.7', 'dewpoint': '-6.267050581532717', 'ET': 'None', 'extraHumid6': '62', 'extraHumid7': '61', 'extraHumid8': '58', 'extraTemp6': '14.8', 'extraTemp7': '19.9', 'extraTemp8': '20.6', 'heatindex': '-1.9000000000000008', 'humidex': '-1.9', 'inDewpoint': '12.462345522375951', 'inHumidity': '60', 'inTemp': '20.5', 'lightning_distance': 'None', 'lightning_last_det_time': '1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 'outHumidity': '72', 'outTemp': '-1.9', 'p_dayRain': '0.0', 'p_monthRain': '26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 'p_weekRain': '11.8', 'p_yearRain': '26.5', 'pressure': '971.0', 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': '1023.8', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': '0.0', 'weekRain': '15.2', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': '1.45', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': '-1.9000000000000008', 'windDir': 'None', 'windGust': '1.3', 'windrun': 'None', 'windSpeed': '0.0', 'ws90_batt': '3.28', 'ws90_sig': '4', 'yearRain': '50.4'

But why would anybody want to do this? I have two GW2000 devices and want to store and show data of as many of my sensor possible in a single weewx instance. Yet configuring the driver both, as driver and a service at the same time, seems to work as I hoped at least foor LOOP: two device queries, on LOOP data.

The question now: is it possible to configure the driver/service in a way, they uses their own ip_address and is it possible to map the Wind/Dir/Gust of the WS90 bound to the one GW2000, to e.g. us_windSpeed/us_windDir/us_windGust (us for ultrasonic) just like p_rain for the haptic array?

Or isn't this possible and do I have to combine the Interceptor driver with the Ecowitt Gateway Driver, one as a service, the other as a Driver to achieve this? If yes, how could this be possible, I tried it with Interceptor as a driver and Ecowitt Gateway Driver as a Service and get not device data:

2024-01-19 18:46:59 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:07 weewxd[13771] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:47:09 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:16 weewxd[13771] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:47:19 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:25 weewxd[13771] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:47:29 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:34 weewxd[13771] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:47:39 weewxd[13771] DEBUG user.interceptor: empty queue
2024-01-19 18:47:43 weewxd[13771] DEBUG user.gw1000: Next update in 9 seconds
2024-01-19 18:47:49 weewxd[13771] DEBUG user.interceptor: empty queue

[michael.k...@gmx.at]

The empty queue is probably because of running it in WSL and being in a different IP range than the Console:

2024-01-19 18:47:39 weewxd[13771] DEBUG user.interceptor: empty queue

$ ip addr

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:a1:b2:53 brd ff:ff:ff:ff:ff:ff
    inet 172.19.239.191/20 brd 172.19.239.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::215:5dff:fea1:b253/64 scope link
       valid_lft forever preferred_lft forever

And the console has 10.0.1.106

I need to set up WSL to be in the same network or try this on another machine.

Anyway, @grj80: have you ever considered collecting data from more than one ecowitt console device with the driver? For me this would make perfect sense, but I can very well understand, if it doesn't to you :D

[michael.k...@gmx.at]

Ignore that empty queue, I forgot that the console device actively reports to a certain IP...

[gjr80]

The Gateway driver has supported simultaneous driver/service operation since v0.5.0b5. It is not a configuration I recommend due to the fragility of the configuration (if the driver crashes or the device using the driver fails/locks up data from the service device is also lost) and the ease of running dual WeeWX instances on the same device (particularly under WeeWX v5).

Notwithstanding, if you wish to use simultaneous driver/service operation the driver configuration is placed under the [GW1000] stanza as normal and the service configuration is placed under the [GW1000Service] stanza. Otherwise the driver and service are configured as per independent operation.

Finally, be aware this is not a configuration I routinely, in fact I suspect it has not bee touched since it was added to v0.5.0b5 so there may be issues.

Gary

[michael.k...@gmx.at]

Thank you! I'll see how far I get and I'll consider the mentioned drawbacks.

[michael.k...@gmx.at]

Here is what I've observed, I can't tell if everything is an issue or if it is working as designed. (What I am trying to achieve, I will post in another reply)

I've configured an instance which reads from one GW2000 device (receiving from a WS68 sensor array) configured as driver, and another GW2000 device (receiving from a WS90 sensor array) as service. I've configured both with the same poll_interval:

[GW1000] #WS68
    # This section is for the Ecowitt Gateway driver.
   
    # How often to poll the API, default is every 20 seconds:
    poll_interval = 10
    ip_address = 10.0.1.85
    max_tries = 360
   
    # The driver to use:
    driver = user.gw1000

[GW1000Service] #WS90
    # This section is for the Ecowitt Gateway driver.
   
    # How often to poll the API, default is every 20 seconds:
    poll_interval = 10
    ip_address = 10.0.1.86
    max_tries = 360
   
    # The driver to use:
    driver = user.gw1000

    [[field_map]]
        ws90_windDir = winddir
        ws90_windSpeed = windspeed
        ws90_windGust = gustspeed
        ws90_daymaxwind = daymaxwind
        ws90_uvradiation = uv
        ws90_UV = uvi
        ws90_luminosity = light
        p_rain = p_rain
        p_stormRain = p_rainevent
        p_rainRate = p_rainrate
        p_dayRain = p_rainday
        p_weekRain = p_rainweek
        p_monthRain = p_rainmonth
        p_yearRain = p_rainyear

Starting weewxd, there is one LOOP every 10 Seconds, it seems it is containing values from the device configured in [GW1000Service] including the values from [[field_map]], which I didn't expect from skimming through the driver's code.  In my understanding  [[field_map]]  replaces the default field map, leading to a LOOP packet only containing the configured  [[field_map]], but obviously I was wrong :) :

LOOP:   2024-01-22 06:16:03 CET (1705900563) 'altimeter': '1025.4477187548832', 'appTemp': '-6.253423533619011', 'barometer': '1028.5013923390995', 'cloudbase': '1041.4809012741189', 'dateTime': '1705900563', 'daymaxwind': '6.6', 'dayRain': '0.0', 'dewpoint': '-6.533418604408247', 'ET': 'None', 'extraHumid6': '59', 'extraHumid7': '61', 'extraHumid8': '57', 'extraTemp6': '14.7', 'extraTemp7': '20.5', 'extraTemp8': '21.3', 'heatindex': '-1.5999999999999994', 'humidex': '-1.6', 'inDewpoint': '9.08853654596964', 'inHumidity': '51', 'inTemp': '19.5', 'lightning_distance': 'None', 'lightning_last_det_time': '1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 'outHumidity': '69', 'outTemp': '-1.6', 'p_dayRain': '0.0', 'p_monthRain': '26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 'p_weekRain': '0.0', 'p_yearRain': '26.5', 'pressure': '973.1', 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': '1025.9', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': '0.0', 'weekRain': '0.0', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': '1.44', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': '-5.128915747986651', 'windDir': '206', 'windGust': '4.2', 'windrun': 'None', 'windSpeed': '2.7', 'ws90_batt': '3.28', 'ws90_daymaxwind': '7.7', 'ws90_luminosity': '0.0', 'ws90_sig': '4', 'ws90_UV': '0', 'ws90_uvradiation': '0.0', 'ws90_windDir': '206', 'ws90_windGust': '2.6', 'ws90_windSpeed': '2.1', 'yearRain': '50.4'

But On RPi4, polling the devices seems to drift apart quite quickly, producing individual LOOP packets, containing the individual values (I haven't observed that happening on my Desktop, so this might be connected to CPU power, maybe it happens after a longer period of time) 

These LOOP packets contain values from the device configured in [GW1000Service] and from the device configured in [ GW1000 ] in that order, but without values from the configured  [[field_map]] in [GW1000Service] - I didn't expect that.  

(Maybe also worth noting is that the batt/sig values from my WS68 are tagged as wh68, which I consider an undesired typo in the driver's map)

LOOP:   2024-01-22 06:16:14 CET (1705900574) 'altimeter': '1025.4477187548832', 'appTemp': '-6.463423533619011', 'barometer': '1028.5013923390995', 'cloudbase': '1041.4809012741189', 'dateTime': '1705900574', 'daymaxwind': '6.6', 'dayRain': '0.0', 'dewpoint': '-6.533418604408247', 'ET': 'None', 'extraHumid6': '59', 'extraHumid7': '61', 'extraHumid8': '57', 'extraTemp6': '14.7', 'extraTemp7': '20.5', 'extraTemp8': '21.3', 'heatindex': '-1.5999999999999994', 'humidex': '-1.6', 'inDewpoint': '9.08853654596964', 'inHumidity': '51', 'inTemp': '19.5', 'lightning_distance': 'None', 'lightning_last_det_time': '1705345360', 'lightning_strike_count': '0', 'lightningcount': '0', 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 'outHumidity': '69', 'outTemp': '-1.6', 'p_dayRain': '0.0', 'p_monthRain': '26.5', 'p_rain': '0.0', 'p_rainRate': '0.0', 'p_stormRain': '0.0', 'p_weekRain': '0.0', 'p_yearRain': '26.5', 'pressure': '973.1', 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': '1025.9', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': '0.0', 'weekRain': '0.0', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': '1.44', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'windchill': '-5.422365775103767', 'windDir': '181', 'windGust': '4.2', 'windrun': 'None', 'windSpeed': '3.0', 'ws90_batt': '3.28', 'ws90_sig': '4', 'yearRain': '50.4'
LOOP:   2024-01-22 06:16:14 CET (1705900574) 'altimeter': '1025.5520572032206', 'appTemp': '-5.833423533619011', 'barometer': '1028.6070856277995', 'cloudbase': '1041.4809012741189', 'dateTime': '1705900574', 'daymaxwind': '7.7', 'dayRain': '0.0', 'dewpoint': '-6.533418604408247', 'ET': 'None', 'extraHumid6': '59', 'extraHumid7': '61', 'extraHumid8': '57', 'extraTemp6': '14.7', 'extraTemp7': '20.5', 'extraTemp8': '21.3', 'heatindex': '-1.5999999999999994', 'humidex': '-1.6', 'inDewpoint': '8.247305751926792', 'inHumidity': '47', 'inTemp': '19.9', 'lightning_distance': 'None', 'lightning_last_det_time': 'None', 'lightning_strike_count': '0', 'lightningcount': '0', 'luminosity': '0.0', 'maxSolarRad': '0.0', 'monthRain': '50.4', 'outHumidity': '69', 'outTemp': '-1.6', 'pressure': '973.2', 'radiation': '0.0', 'rain': '0.0', 'rainRate': '0.0', 'relbarometer': '1026.0', 'stormRain': '0.0', 'usUnits': '17', 'UV': '0', 'uvradiation': '0.0', 'weekRain': '0.0', 'wh31_ch6_batt': '0', 'wh31_ch6_sig': '4', 'wh31_ch7_batt': '0', 'wh31_ch7_sig': '4', 'wh31_ch8_batt': '0', 'wh31_ch8_sig': '4', 'wh32_batt': '0', 'wh32_sig': '4', 'wh40_batt': '1.44', 'wh40_sig': '4', 'wh57_batt': '5', 'wh57_sig': '4', 'wh68_batt': '1.88', 'wh68_sig': '1', 'windchill': '-4.448607638687528', 'windDir': '205', 'windGust': '3.1', 'windrun': 'None', 'windSpeed': '2.1', 'yearRain': '50.4'

[gjr80]

Without seeing some logs it's hard to say much more than some general comments. I would suggest leaving debug = 0, but set debug_loop = True under both [GW1000] and [GW1000Service] stanzas in weewx.conf. Restart WeeWX,. This will log the field maps in use as well as a lot of packets in various states of processing. Just post a log extract showing the full WeeWX start up and a few loop packets (by a few loop packets I mean around 30 seconds of log). This should give a clear indication of what is going on.

Gary

[michael.k...@gmx.at]

When I configure like so

[GW1000]
    debug_loop = True

    # This section is for the Ecowitt Gateway driver.
   
    # How often to poll the API, default is every 20 seconds:
    poll_interval = 10
    ip_address = 10.0.1.85
    max_tries = 360
   
    # The driver to use:
    driver = user.gw1000

[GW1000Service]

    debug_loop = True

    # This section is for the Ecowitt Gateway driver.
   
    # How often to poll the API, default is every 20 seconds:
    poll_interval = 10
    ip_address = 10.0.1.86
    max_tries = 360
   
    # The driver to use:
    driver = user.gw1000

    [[field_map]]
        ws90_windDir = winddir
        ws90_windSpeed = windspeed
        ws90_windGust = gustspeed
        ws90_daymaxwind = daymaxwind
        ws90_uvradiation = uv
        ws90_UV = uvi
        ws90_luminosity = light
        p_rain = p_rain
        p_stormRain = p_rainevent
        p_rainRate = p_rainrate
        p_dayRain = p_rainday
        p_weekRain = p_rainweek
        p_monthRain = p_rainmonth
        p_yearRain = p_rainyear

WeeWX exits with

2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Initializing weewxd version 5.0.0
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Command line: /home/pi/weewx-venv/bin/weewxd
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Using Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110]
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Located at /home/pi/weewx-venv/bin/python3
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Platform Linux-6.1.42-v8+-aarch64-with-glibc2.31
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Locale: 'de_AT.UTF-8'
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Entry path: /home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: WEEWX_ROOT: /home/pi/weewx-data
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Configuration file: /home/pi/weewx-data/weewx.conf
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: User module: /home/pi/weewx-data/bin/user
2024-01-22 19:49:48 weewxd[119797] INFO weewxd: Debug: 0
2024-01-22 19:49:48 weewxd[119797] INFO weewx.engine: Loading station type GW1000 (user.gw1000)
2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayDriver: version is 0.6.0b2
2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:      device address is 10.0.1.85:45000
2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:      poll interval is 10 seconds
2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000: GatewayService: version is 0.6.0b2
2024-01-22 19:49:48 weewxd[119797] INFO user.gw1000:      max age of API data to be used is 60 seconds
2024-01-22 19:49:50 weewxd[119797] INFO user.gw1000: GatewayCollector thread has been terminated
2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd: Caught unrecoverable exception:
2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****  'GatewayService' object has no attribute 'field_map'
2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****  Traceback (most recent call last):

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****    File "/home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py", line 160, in main

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****      engine = weewx.engine.StdEngine(config_dict)

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****    File "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 89, in __init__

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****      self.loadServices(config_dict)

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****    File "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 157, in loadServices

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****      obj = weeutil.weeutil.get_object(svc)(self, config_dict)

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****    File "/home/pi/weewx-data/bin/user/gw1000.py", line 1389, in __init__

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****      loginf('     field map is %s' % natural_sort_dict(self.field_map))

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****  AttributeError: 'GatewayService' object has no attribute 'field_map'

2024-01-22 19:49:50 weewxd[119797] CRITICAL weewxd:     ****  Exiting.

It is happening when this is configured, (not when in [GW1000]):

[GW1000Service]
    debug_loop = True

[gjr80]

An old log entry remained after some earlier restructuring, try b4:

wget https://raw.githubusercontent.com/gjr80/weewx-gw1000/master/bin/user/gw1000.py

Gary

[michael.k...@gmx.at]

I ran weewxd manually, weewxd_console.log is the console output, weewxd.log is from the log file. 

[gjr80]

Try b5, same link as my previous post to download.

Gary

[michael.k...@gmx.at]

I will. Just curious: what to expect from b5? Will it behave differently or produce other logs?

[gjr80]

It should just work. It works with a dual driver/service implementation on my test VM. 

Gary

[michael.k...@gmx.at]

The log is from latest logs I posted are from b5. Sorry, I forgot to mention that I didn't use the file in your link above, I downloaded from the releases, and for b4 it says: removed, go for b5. b5 is producing two independent LOOP packets after a few on my RPi4.

[gjr80]

On Thursday 25 January 2024 at 06:56:42 UTC+10 michael.k...@gmx.at wrote:

The log is from latest logs I posted are from b5. Sorry, I forgot to mention that I didn't use the file in your link above, I downloaded from the releases, and for b4 it says: removed, go for b5. b5 is producing two independent LOOP packets after a few on my RPi4.

Sorry, but I don't understand this. The latest log you posted yesterday is very clearly from b4:

2024-01-23 19:46:51 weewxd[232660] INFO weewx.engine: Loading station type GW1000 (user.gw1000) 

2024-01-23 19:46:51 weewxd[232660] INFO user.gw1000: GatewayDriver: version is 0.6.0b4 

2024-01-23 19:46:51 weewxd[232660] INFO user.gw1000: device address is 10.0.1.85:45000

b4 and b5 have not been published to releases, they have been produced to deal with this issue and I have kept them back until I know the issue is fixed. You need to re-download the driver from the link I provided earlier in order to get b5, b3 (releases) and b4 will never work. Here is the link again:

https://raw.githubusercontent.com/gjr80/weewx-gw1000/master/bin/user/gw1000.py

Gary

[michael.k...@gmx.at]

OK, I need to sort this out a little. I think I messed up with 0.6.0bx and 0.5.0bx. Currently I've got too many things on my plate, and wasn't as focused on this topic, as I should have been, sorry for that. I'll do my homework and check everything again.

[michael.k...@gmx.at]

That part worked. You can tell by the weewx.restx: MQTT: Published record entries in the log, there is only one Loop packet every 10s (the poll interval).

But after a few archive_intervals it crashed:

2024-01-27 14:17:25 weewxd[657388] INFO weewx.engine: Main loop exiting. Shutting engine down.
2024-01-27 14:17:25 weewxd[657388] INFO weewx.engine: Shutting down StdReport thread
2024-01-27 14:17:26 weewxd[657388] INFO user.gw1000: GatewayCollector thread has been terminated
2024-01-27 14:17:27 weewxd[657388] INFO user.gw1000: GatewayCollector thread has been terminated
2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__: Caught unrecoverable exception:
2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****  'dateTime'
2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****  Traceback (most recent call last):

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****    File "/home/pi/weewx-venv/lib/python3.9/site-packages/weewxd.py", line 166, in main

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****      engine.run()

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****    File "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 206, in run

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****      self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet))

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****    File "/home/pi/weewx-venv/lib/python3.9/site-packages/weewx/engine.py", line 241, in dispatchEvent

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****      callback(event)

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****    File "/home/pi/weewx-data/bin/user/gw1000.py", line 1504, in new_loop_packet

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****      self.process_queued_sensor_data(queue_data, event.packet['dateTime'])

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****    File "/home/pi/weewx-data/bin/user/gw1000.py", line 1611, in process_queued_sensor_data

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****      if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['dateTime']:

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****  KeyError: 'dateTime'

2024-01-27 14:17:27 weewxd[657388] CRITICAL __main__:     ****  Exiting.

[michael.k...@gmx.at]

Case typo?

if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['dateTime']:

[michael.k...@gmx.at]

Seems like, changed it to

if self.latest_sensor_data is None or sensor_data['datetime'] > self.latest_sensor_data['datetime']:

and it didn't crash again so far.

[gjr80]

Thank you, yes, self.latest_sensor_data['dateTime'] should be self.latest_sensor_data['datetime']. Fixed in 0.6.0b6.

Gary

[michael.k...@gmx.at]

0.6.0b6 still contains the wrong case for  self.latest_sensor_data['datetime']

https://github.com/gjr80/weewx-gw1000/blob/fcd562c2dc7b33015f8a29683d0e1cf35d385470/bin/user/gw1000.py#L1614

[michael.k...@gmx.at]

commit d8b2a70 is running smoothly.