Testing the BPUP in my ISY/Polyglot integration, I notice something (I think) new: every call to the REST appears to use a new connection despite the fact that I am using sessions in Python requests. I.e., in each call I see “Resetting dropped connection: zzbl48XXX.local”. Are sessions not something I need to be using in the REST API? Does the Bond Bridge drop the connection after each HTTP call?
Note that I did just upgrade 2.14.5 firmware. It could be that as well. Did persistent connections get dropped in the latest firmware?
@residualimages Any insight here?
@kingwr - sorry, I haven’t had time to dig into BPUP / the Polyglot nodeserver for awhile (healthcare IT as a day job - you can imagine how #2020 is going).
Technically I even paused the Polyglot Bond nodeserver usage (
) since there are a few things I’m able to work out quicker with direct Network Resources (mostly the Patch using _m:4 for State correcting, and cross integrating with Hue emulator nodeserver for Harmony control).
Hoping @jacob, @merck or one of the other Bond team members have a chance to wander in this week.
While it may appear so from the original post, note that this question doesn’t have anything to do with BPUP. I just happened to notice that my REST calls were receiving this warning (the resetting of the connection) when I was testing the updated integration with the BPUP code. The integration has used HTTP sessions from the beginning, but I don’t remember seeing this warning. Doesn’t mean it hasn’t been there all along.
1 Like
It’s likely that it’s been there all along: the Bond’s HTTP server closes the client socket after it sends the response content. This should be what’s causing the dropped connection.
I went back through the old logs, and I wasn’t seeing the connection reset error with the old version of the integration, even after the firmware upgrade. Turns out that these errors are going to root logger and get lost in the Polyglot infrastructure. They only show up in debugging the code in VSC. I removed all the HTTP session code.
BTW, BPUP works great - a nice improvement over 10s polling.
3 Likes
We love the BPUP over here. Curious: are you acting as a client to subscribe to BPUP messages? Or are you just listening to the broadcasts?
@merck I wasn’t aware there were broadcasts. I am opening a UDP socket connection to the bridge on port 30007 and sending the keep-alive datagram every 90 seconds (or so).
There is a broadcast option, but you need to enable it via the API. (We felt it was not right to broadcast by default.)
Docs link for it:
http://docs-local.appbond.com/#tag/BPUP/paths/~1v2~1api~1bpup/patch
1 Like
So not really a UDP broadcast in the strictest sense of the word, but more of a removal of the need for the keep-alive datagram?
Basically make the same UDP connection to port 30007 and then make a REST call to enable the BPUP “broadcast.” and you’re done. No loop for keep-alive. Is there any other advantages/disadvantages?
So not really a UDP broadcast
No, it’s really a broadcast.
If you enable BPUP broadcast, as I described above, Bond will transmit a UDP packet to 255.255.255.255:30007 for every single state change. So, you just need to listen locally to port 30007 (without binding to the first client!) and you will pick up state changes from every Bond on the subnet!
Oh, OK. I will give it a try in the next version.
1 Like