Hi Everyone, Thanks for all the help. I finally solved my problem. As usually I was making life too hard on myself. Here's what I finally figured out.....
- The driver basically runs all the time unless it gets interrupted. - It seems to get interrupted every five minutes on the dot. - Therefore there's no reason to use a long running websocket. Five minutes gives enough data (rapid_wind every 3 sec and a obs every minute) to populate the DB. It would be lovely to catch the interruption and close the socket cleanly but not mandatory I suspect. - Just fire the websocket connection back up each time. So far this is working on a test cloud instance (look ma, no local PI as a forwarder!). I also got a version that queries/polls the rest API. To keep that one from spamming the endpoint I put in a sleep/timeout config param. I'm playing with the best amount of sleep there and I suspect anything less than 60 seconds, within reason, will work nicely. I'm leaning towards the websocket driver as being the better of the two because of the more frequent wind data. There are some other events that may be available as well but they depend on rain/lightening and today is nice and sunny. I am curious the behavior of WEEWX when a loop_packet with a duplicate epoch/timestamp is submitted since that's the primary key? Does it fail, just discard the packet silently or something else. The reason I ask is that the Tempest rest API has a date-range option that may be nice to have for archive_packets or even just refilling gaps but I'd want to know how it'd play with a duplicate record. Many thanks! Billy On Friday, May 6, 2022 at 9:58:40 PM UTC-7 Billy Jackson wrote: > Hi Vince, > > I just re-reviewed the UDP driver code. You're correct that it has a > while true loop that stays open, uses the timeout to wait long enough for a > new UDP packet etc.... It's how it's called that seems to be the > difference. In my syslog I see the genLoopPackets called every five > minutes on the dot. My guess is that's how often weewx calls the driver. > At the top of Captain Coredump's genLoopPackets method is where he > opens/binds the UDP socket. Hence the need for multi-threading. > > I sure have a lot to learn. Thanks for the pointer Rich! Vince, many > many thanks for your help in both forums. > > Billy > > On Friday, May 6, 2022 at 9:18:25 PM UTC-7 Billy Jackson wrote: > >> Thank you! I'll check this out. I'm also looking closely at the queue >> module. It looks like at least one MQTT driver makes use of that as well. >> >> Billy >> >> On Friday, May 6, 2022 at 5:47:40 PM UTC-7 [email protected] wrote: >> >>> I am guessing that run_forever is a blocking call. So, you probably need >>> to move it into a thread. >>> Here, https://github.com/weewx/weewx/wiki/multi-threaded-service, is a >>> write up on writing a multi-threaded WeeWX service. It could be adapted for >>> a driver. I'd probably (ok, I do in MQTTSubscribe) use a queue to >>> communicate between the threads. >>> >>> This answer talks about getting python websockets data in a separate >>> thread >>> >>> https://stackoverflow.com/questions/29145442/threaded-non-blocking-websocket-client#:~:text=1-,Answer,-Sorted%20by%3A >>> >>> Hope this helps you get going. >>> rich >>> >>> >>> On Wednesday, 4 May 2022 at 00:49:38 UTC-4 [email protected] wrote: >>> >>>> Hi, >>>> >>>> I'm trying to write a driver for my Tempest WS. I currently have the >>>> UDP driver from captain-coredump up and running (thank you!) on a pi but >>>> I'd like to pump data straight from the websockets API into weewx also. I >>>> may expand it to capture archive packets from the rest API also. >>>> >>>> The prototype is here... https://github.com/livysdad27/tempestAPI >>>> >>>> I borrowed a LOT from captain-coredump's driver. Where I'm struggling >>>> is with the getLoopPackets generator. I've attempted to use the >>>> on_message >>>> handler for this but have read in another thread that it doesn't work well >>>> due to running in a separate thread. My websockets code is a bit simple >>>> and I'm not completely sure how drivers get called for sure. >>>> >>>> Is it even realistic to try and run a websocket-client app >>>> implementation with "run_forever" and expect it to work correctly with >>>> weewx? My suspicion is weewx is starting, entering the websocket app and >>>> sitting there forever because I don't get report or other messages after >>>> it >>>> kicks off. >>>> >>>> Super grateful for any help/pointers! >>>> >>>> Billy >>>> >>> -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/88deb7f7-d661-42a4-b1a0-13dfffa35f93n%40googlegroups.com.
