yeah - I see it…gimme a minute to fix it…
(update)
@plains203 - change line 223 on the right where it says “time_epoch” to say “timestamp” and that’ll fix it…
yeah - I see it…gimme a minute to fix it…
(update)
@plains203 - change line 223 on the right where it says “time_epoch” to say “timestamp” and that’ll fix it…
@vinceskahan looks to have fixed it thanks!
It also looks like the mqtt feature was working as expected as well.
Now to integrate this into my openhab setup.
update - fixed --limit for events and status messages so they actually report when you want them. If you ever see bugs, please compare your copy with the lastest on github, just in case…
update:
--exclude
option to easily skip certain observations/events (typically I ignore rapid_wind)--syslog
option to syslog startup message and any unexpected JSON received by the listenerI’m currently running my host with the following options:
--exclude "rapid_wind" --mqtt --syslog
I’ll let it run for a few days and try to remember to bump the release git tag early next week.
added docker-compose.yml and Dockerfile for building and running in a container for those who like containers…
also made the MQTT topic more easily configurable rather than hard-coding it
This is just what I was looking for, thanks so much!!
update - anybody using this should probably grab the latest version or patch your code with a one-line addition I made to have it not take the whole cpu.
try:
time.sleep(0.01) # <=== add this line
msg=s.recvfrom(1024)
data=json.loads(msg[0]) # this is the JSON payload
If you patch your code, be sure to use ‘spaces’ and not ‘tabs’. Then just stop/restart your listener and you’ll see the cpu usage drop to basically zero, and the pi cpu temperature will drop a ‘lot’. My pi3plus dropped 9 degC afterward !
Updated to version 2.0b1 if folks want to try a threaded version to not let the listener miss messages (rarely) while processing the data and outputting to the screen/syslog/mqtt/etc. Also updated the README to hopefully make it a little easier to wade through.
Same link as at the top of this thread, just be sure to pick the ‘threaded’ branch. I’m going to let it run here for a week or two before merging to master and calling it version 2.0, but it looks very stable and reliable in my testing on both a pi 3+ and a i3 Intel NUC.
Thanks a lot for your time, this is great and its going to save a lot of time for everyone!
merged to master, so both branches are the same latest/greatest code
fyi - coming soon will be version 3.0
Should be updated this weekend on the github page once I catch the docs up…
RELEASE ANNOUNCEMENT
Version 3.0.0 released and GitHub repo updated.
This release supports MQTT publishing of data if you have multiple Air and/or Sky units in your station, via the optional -M switch.
Debugging-only example for a typical one-air/one-sky system:
/usr/bin/python listen.py -m --limit "rapid_wind" -n
publishing to mqtt://mqtt/wf/rapid_wind
Debugging-only example for a multi-sensor system via adding the -M option
/usr/bin/python listen.py -m --limit "rapid_wind" -n -M
publishing to mqtt://mqtt/sensors/SK-00013695/wf/rapid_wind
publishing to mqtt://mqtt/sensors/SK-00013695/wf/rapid_wind
Python version requirements are unchanged:
Is it possible to use the UDP listener outside the Hub’s network (in some other location) ? I would probably need to specify the address/port of my station at the WF site?
In the normal case UDP isn’t (at least in Home Netwaorks) not distributed into a different Network segment.
Hence, the UDP traffic coming from the Hub is only available to clients in the same IP-range.
What is your detailed network configuration and purpos or need to operate the Hub in a different network?
It is just out of curiosity. The Hub is on a remote location. I do like the blue real-time WF interface but wanted to build my own (translation, looks, etc.) on my server at home. No worries, I understand the explanation about the UDP’s purpose.
You’re may use a VPN Connection, but be aware of the configuration.
The description of UDP above isn’t quite completely accurate. UDP routes just fine. Broadcast messages, however, don’t route unless you do lots of jumping through hoops on your network gear. The WF UDP messages are a broadcast message.
If I was trying to do what you’re mentioning, I’d probably have one ‘wired’ raspi on the HUB’s network and have it publish MQTT to a tiny Internet-hosted site running the MQTT broker. I’d have a second pi at the other site subscribing to those messages at the second site and doing what ever heavy lifting you had in mind. If you limit what the Internet-facing site accepts in to just be MQTT to/from your two specific addresses (with password authentication in MQTT), it would probably be secure enough.
An Amazon Lightsail tiny instance is under $4/month but you could do it on any of the usual providers in their free-tiers that generally are good for a year. You could certainly experiment at least for free.
Thanks for suggestion, I might try this one (Hub <–ethernet–> RPi <–internet–> RPi_at_home
Cheers
You are right. I focused on Hub’s UDP Pakets…
And yes the information is transferable outside the. Network segment. But one has to transform it, what is possible with this Tool in the way you described. It’s more or less a work around for the original surcease
RELEASE ANNOUNCEMENT
Version 4.0.0 released and GitHub repo updated.
This release supports direct publishing of data to Influxdb
Minor changes: