commit d8b2a70 is running smoothly.
michael.k...@gmx.at schrieb am Sonntag, 28. Januar 2024 um 12:14:48 UTC+1:
>
> 0.6.0b6 still contains the wrong case for
> self.latest_sensor_data['datetime']
>
> https://github.com/gjr80/weewx-gw1000/blob/fcd562c2dc7b33015f8a29683d0e1cf35d385470/bin/user/gw1
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
gjr80 schrieb am Sonntag, 28. Januar 2024 um 01:55:20 UTC+1:
> Thank you, yes, self.latest_sensor_data['date
Thank you, yes, self.latest_sensor_data['dateTime'] should be
self.latest_sensor_data['datetime']. Fixed in 0.6.0b6.
Gary
On Sunday 28 January 2024 at 04:59:19 UTC+10 michael.k...@gmx.at wrote:
> Seems like, changed it to
> if self.latest_sensor_data is None or sensor_data['datetime'] >
> self.
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.
michael.k...@gmx.at schrieb am Samstag, 27. Januar 2024 um 14:31:43 UTC+1:
> Case typo?
>
> if self.latest_sensor_data is None or senso
Case typo?
if self.latest_sensor_data is None or sensor_data['datetime'] >
self.latest_sensor_data['dateTime']:
michael.k...@gmx.at schrieb am Samstag, 27. Januar 2024 um 14:24:58 UTC+1:
> That part worked. You can tell by the weewx.restx: MQTT: Published record
> entries in the log, there is o
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.
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.
gjr80 schrieb am Mittwoch, 24. Januar 2
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
inde
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 schrieb am Mittwoch, 24.
It should just work. It works with a dual driver/service implementation on
my test VM.
Gary
On Wednesday 24 January 2024 at 07:50:29 UTC+10 michael.k...@gmx.at wrote:
> I will. Just curious: what to expect from b5? Will it behave differently
> or produce other logs?
>
> gjr80 schrieb am Diens
I will. Just curious: what to expect from b5? Will it behave differently or
produce other logs?
gjr80 schrieb am Dienstag, 23. Januar 2024 um 22:19:27 UTC+1:
> Try b5, same link as my previous post to download.
>
> Gary
>
> On Wednesday 24 January 2024 at 04:55:16 UTC+10 michael.k...@gmx.at wrot
Try b5, same link as my previous post to download.
Gary
On Wednesday 24 January 2024 at 04:55:16 UTC+10 michael.k...@gmx.at wrote:
> I ran weewxd manually, weewxd_console.log is the console output,
> weewxd.log is from the log file.
>
> gjr80 schrieb am Montag, 22. Januar 2024 um 20:40:14 UTC+
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
On Tuesday 23 January 2024 at 04:55:32 UTC+10 michael.k...@gmx.at wrote:
> When I configure like so
> [GW1000]
> debug_loop = True
>
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.gw10
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
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 G
Thank you! I'll see how far I get and I'll consider the mentioned drawbacks.
gjr80 schrieb am Samstag, 20. Januar 2024 um 10:47:29 UTC+1:
> 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
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
Ignore that empty queue, I forgot that the console device actively reports
to a certain IP...
michael.k...@gmx.at schrieb am Samstag, 20. Januar 2024 um 08:52:04 UTC+1:
> The empty queue is probably because of running it in WSL and being in a
> different IP range than the Console:
> 2024-01-19
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: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 00:15:5d:a1:b2:53 brd ff:ff:ff:
20 matches
Mail list logo