FYI no issues with Tom’s driver. Just not registered
On Fri, Feb 23, 2024 at 9:29 PM Jamie Stephens
wrote:
> I'm not code savvy but I seem to recall I personally was running this fork
> from tkeffer that he ported to python 3
> https://github.com/tkeffer/weatherflow-udp/tree/master
> I might
I'm not code savvy but I seem to recall I personally was running this fork
from tkeffer that he ported to python 3
https://github.com/tkeffer/weatherflow-udp/tree/master
I might roll back tot hat and see if the issue go away, I don't think it
was ever committed to the main
On Friday, February
Source is at
https://github.com/captain-coredump/weatherflow-udp/blob/master/bin/user/weatherflowudp.py
if
some driver experts wanted to suggest fixes. This one is beyond me other
than to suggest that since weewx v5 does not support python2 anymore that
perhaps the try/except block needs
i went ahead and opened up a issue with the driver, had another crash today
On Thursday, February 22, 2024 at 1:20:16 PM UTC-5 vince wrote:
> Jamie - I didn't change anything related to how the driver actually works.
> I just added one line to hopefully get it to register vs. v5 weewx. The
>
Jamie - I didn't change anything related to how the driver actually works.
I just added one line to hopefully get it to register vs. v5 weewx. The
map shows a few v5 sites using that driver now, so that part seems to be
working.
On Thursday, February 22, 2024 at 7:24:23 AM UTC-8 Jamie
Thanks Tom, this is the new updated driver that Vince got pushed on this
thread. maybe it was a one off
On Thursday, February 22, 2024 at 10:07:45 AM UTC-5 Tom Keffer wrote:
> It looks like the author of the driver is trying to insert a string into a
> byte array. You should file an issue on
It looks like the author of the driver is trying to insert a string into a
byte array. You should file an issue on the repository's issue list.
On Thu, Feb 22, 2024 at 6:00 AM Jamie Stephens
wrote:
> i manually restarted it and it's running right now just the registry push
> error but not
i manually restarted it and it's running right now just the registry push
error but not exited
Feb 22 08:50:19 weewx weewxd[68909]: ERROR weewx.restx: StationRegistry:
Failed to publish record 2024-02-22 08:50:00 EST (17086098>
will report back if weewx crashes again
On Monday, February 19,
thread exited last night and won't restart
Feb 21 17:08:31 weewx weewxd[763]: File "/usr/share/weewx/weewxd.py",
line 166, in main
Feb 21 17:08:31 weewx weewxd[763]: engine.run()
Feb 21 17:08:31 weewx weewxd[763]: File
"/usr/share/weewx/weewx/engine.py", line 204, in run
Feb 21
Thanks for the fix, I didn't;t even noticed it was not working
On Monday, February 19, 2024 at 4:25:28 AM UTC-5 Ton Karsten wrote:
> Thank you for resolving the error message.
>
> Op ma 19 feb 2024 om 01:36 schreef bell...@gmail.com :
>
>> Thanks for pushing it over the goal line. Always the
Thank you for resolving the error message.
Op ma 19 feb 2024 om 01:36 schreef bell...@gmail.com :
> Thanks for pushing it over the goal line. Always the hardest part.
>
> On Sunday 18 February 2024 at 19:33:41 UTC-5 vince wrote:
>
>> Update - the upstream author was nice enough to merge my PR
Thanks for pushing it over the goal line. Always the hardest part.
On Sunday 18 February 2024 at 19:33:41 UTC-5 vince wrote:
> Update - the upstream author was nice enough to merge my PR for this
> problem, so you can simply upgrade your driver to the latest version and
> your station
Update - the upstream author was nice enough to merge my PR for this
problem, so you can simply upgrade your driver to the latest version and
your station registration should work again with weewx v5.
weectl extension install
Not at all obvious to my eyes, nor do I know how to lint to find that
stuff, but you're better at this than I am :-)
FWIW - I have a fork of this driver that I added this workaround to...
- wget
https://github.com/vinceskahan/weatherflow-udp/archive/install_example_sensor_map.zip
Good to here. Work around or bug fix, I guess that is in the eye of the
beholder….
While the docs may need some ‘sprucing up’, if one performs static code
analysis; the error is pretty obvious. Here is the lint error I got when I
removed it
‘bin/user/MQTTSubscribe.py:2155:4: W0236: Method
I can confirm that adding @property in the driver and restarting weewx
'does' work as a workaround, assuming you didn't use example.com as your
host (sigh - another undocumented thing).
# add the next line here around line 289 in the driver or so...
@property
def
Quick look of the code and it looks like ‘example.com’ is rejected. Seems
the error logging could be improved. I’ll poke around and see if I can
create a decent pull request. But, I may have to defer to the experts.
On Sunday 18 February 2024 at 13:30:44 UTC-5 vince wrote:
> I tried to do so
I tried to do so but am still getting BAD REQUEST trying to register a test
pi. Of course now it'll wait a day til trying again. Sigh.
I opened https://github.com/weewx/weewx/issues/936 on this one rather than
get multiple conversations all cross-intermingled here.
On Sunday, February 18,
I’d try adding the missing @property decorator. All signs point to that
being the problem. It can’t hurt and it fixes a bug.
On Sunday 18 February 2024 at 01:01:05 UTC-5 vince wrote:
> Meaning what for users or devs ?
>
>
> On Saturday, February 17, 2024 at 3:45:38 PM UTC-8 Tom Keffer wrote:
>
Ah, I see that now. Thanks.
On Saturday 17 February 2024 at 18:45:38 UTC-5 Tom Keffer wrote:
> The difference is that to upload to the station registry, V5 uses an HTTP
> POST with a serialized JSON payload, while V4 uses an HTTP GET. The GET
> sent an "unbound method" to the registry as a
Meaning what for users or devs ?
On Saturday, February 17, 2024 at 3:45:38 PM UTC-8 Tom Keffer wrote:
> The difference is that to upload to the station registry, V5 uses an HTTP
> POST with a serialized JSON payload, while V4 uses an HTTP GET. The GET
> sent an "unbound method" to the
The difference is that to upload to the station registry, V5 uses an HTTP
POST with a serialized JSON payload, while V4 uses an HTTP GET. The GET
sent an "unbound method" to the registry as a query parameter. We get a lot
of those, so I included a bit of code to salvage the hardware type from the
There are 75 currently registered sites using this driver but 'all' are
showing as running 4.x so I'm guessing something changed in v5 weewx..
On Saturday, February 17, 2024 at 1:44:38 PM UTC-8 bell...@gmail.com wrote:
> Theory:
> Drivers are suppose to implement hardware_name as a
Theory:
Drivers are suppose to implement hardware_name as a property. The driver is
missing the @property for hardware_name. When WeeWX accesses it as
property, for example, instance.hardware_name it returns the function
definition.
Try adding the @property decorator to hardware_name in the
Tom - I can duplicate this here with 5.0.2 running vs. my wfudpsimulator
tool since I don't have actual hardware any more
If registering is enabled, you get that error when the archive period rolls
around.
I added some debugging to restx that might help.
# Delay the registration by a
I am seeing the same issue. Here is my startup through a reporting cycle
log with debug=1
Feb 17 06:07:18 Garagepi weewxd-weatherflow[1999]: INFO weewx.engine: Using
binding 'wx_binding' to database 'weatherflow.sdb'
Feb 17 06:07:18 Garagepi weewxd-weatherflow[1999]: INFO weewx.manager:
Potentially. The station registry is being passed some bad information.
It's possible that information is needed elsewhere in the program.
Set debug=1, then restart weewxd. Post the log from startup through the
first reporting cycle.
Also, please note which version of the driver you ended up
When I restart weexw with the WeatherFlowUDP driver in use, I get the
following error messages once:
feb 15 16:00:17 raspberrypi weewxd.py[8060]: weatherflowudp: MainThread:
Listening for UDP broadcasts to IP address on port 50222, with
timeout 90 and share_socket False...
feb 15 16:00:17
Okay thanks.
Op wo 14 feb 2024 om 18:12 schreef vince :
> The weatherflow-udp driver works just fine on v5.
>
> On Wednesday, February 14, 2024 at 7:47:17 AM UTC-8 Ton Karsten wrote:
>
>> Thanks for sharing.
>> Which version are you using?
>> This:
The weatherflow-udp driver works just fine on v5.
On Wednesday, February 14, 2024 at 7:47:17 AM UTC-8 Ton Karsten wrote:
> Thanks for sharing.
> Which version are you using?
> This: https://github.com/captain-coredump/weatherflow-udp
> Or this one: https://github.com/rongrimes/weewx-tempest-pi
>
Thanks for sharing.
Which version are you using?
This: https://github.com/captain-coredump/weatherflow-udp
Or this one: https://github.com/rongrimes/weewx-tempest-pi
Op woensdag 14 februari 2024 om 16:26:59 UTC+1 schreef Tom Hogland:
> I'm currently using WeatherflowUDP with weewx 5.0.2 and it's
I'm currently using WeatherflowUDP with weewx 5.0.2 and it's working fine.
On Wednesday, February 14, 2024 at 5:31:50 AM UTC-9 Ton Karsten wrote:
> I use the WeatherFlow Tempest for my weather station.
> I have equipped my weather station with the latest version of weewx.
> Is the WeatherFlowUDP
32 matches
Mail list logo
