I have a javascript implementation that’s overall working fine. I open my web socket connection, start listening for obs_st and rapid_wind, and all is right with the world…for a while.
After approximately 24 hours the obs_st messages stop coming - but rapid_wind continues without issue.
In my error handling logic, I watch when it’s been too long since I’ve heard an update and do a listen_stop, listen_start for obs_st messages, which elicits just a single update message and no more.
So once I end up in this state, the only updates that I get at that point forward for obs_st is when my error handler kicks in (roughly every 7 minutes) Meanwhile, rapid-wind is unaffected and continues to come in uninterrupted.
If I close the app (killing the connection) and re-open the app it will be fine again for 24 hours.
What am I missing…? Should I just kill and re-open the connection every 24 hours pre-emptively? That just seems like voodoo, but sometimes voodoo does the trick.
I am having the same problem with the PiConsole. Just like you are seeing, websocket messages stop arriving for some reason. A reboot of the console can fix it, but only for some unknown period of time.
I think it is a bug in the API on the WF side that they are looking into, but I haven’t heard if they have been able to identify it (@corrineb)
Ah - ok - that’s kinda what I suspected. If it helps in troubleshooting, I’ve left my devices (2 clients, device id in my original post) in their error-handling state - rapid wind continues on happily, other measurements only updating when the stop/start which again only triggers a single message.
It happened to me again last night on my Weewx box that fetches data via the Websocket. obs_st packets just stopped around 20:30 GMT, while rapid_wind continued.
I caught the failure in progress - my error recovery tries to fix it, and fails eventually with too many connections. I would really love if someone could look over this log and tell me where I’m going wrong? Once I go into recovery, it doesn’t seem like there’s a way to clean up and I eventually get locked out such that I have to kill the app and wait.
@peter I’ve been having issues with my Weewx implementation as well. It’s compounded by a lack of power that comes and goes, I just installed a powerbooster.
Do you mind sharing what driver you’re using for Weewx?
Not sure I can really help here, as I don’t know javascript. From your description, it sounds like when your code catches the failure to send messages, it doesn’t actually close the websocket connection before opening a new one. As the issue is with the messages not being sent (rather than the websocket connection failing), you need to find a way to shut the existing connection down before opening a new one.
Unfortunately, the driver I am using is not really in a shareable state. It is something I have hacked together with a lot of aspects hard-coded to my specific setup. Sorry!
No worries. I pulled one together but it could use some improvements in a few areas so I’m always curious to learn more and see what I could do better. I need to improve my error handling and my reconnection code works when Weatherflow recycles the connection for some reason but in some states it doesn’t seem to be happy and doesn’t reconnect without a full restart. I have a ticket open with them on the second item.
Good luck on that front! I might build one against the REST API as well in the future.
