Good new/bad news: I think the latest firmware update broke something. I set up a test, and there is something that’s not working right. I don’t know if it has to do with the problems you are seeing, but it has to do with the Edge driver socket server. It doesn’t seem to be working right and the result is that it is hanging edgebridge when it tries to forward a message. This would affect multiple drivers potentially… ugh.
Give me some time to look at this and I’ll keep you posted. No sense you doing anything more until I get this figured out.
@TAustin My hub got an update at 2023-01-19 8:12 PM UTC, which is when phonepresence stopped working for me as well as a custom LAN Device Trigger. The POST requests to the hub simply hang and timeout. Hopefully you are able to figure out how to fix it. Awesome work!
As I mentioned above and some of you have found out the hard way, there seems to be a change in the socket library in recent firmware updates that has resulted in communications no longer working between edgebridge and the Edge driver. (TMI for most, but it appears to be in the Thread:register_socket method.)
I will take this issue up with the SmartThings staff, but in the meantime, in order to get things working again I had to make some code changes in the following drivers:
LAN Motion
LAN Presence
LAN Contact
LAN Trigger
LAN Trigger Multi
Not everyone has experienced these issues yet, so you may not see any change with these updates. But for those that have reported their motion or presence no longer being triggered, hopefully this will fix that.
I found in my testing that there are some cases where this problem may cause your edgebridge app to get ‘stuck’. There are no tell-tail messages in the log output, so you won’t know just by looking at the log. So if after the driver updates, you are still having problems or your edgebridge app seems to be locked up, you should restart it.
For example on Linux:
sudo systemctl restart edgebridge
If you are running it in a terminal window or command prompt window, then just Ctrl-c/Ctrl-break out of it and restart it again.
I hope this averts this particular crisis. Please let me know if things are working ok.
Be sure you get the driver updates first. If you still have the earlier ones, they can just hang edgebrige up if edgebridge tries to send anything to the hub.
I just set this up and everything seems to be working. Has anyone experimented with sending data the other direction. With the previous integration I could update Blue Iris profiles based on the Security status in Smarthings. Arm (stay), Arm (away) and Disarmed. This seems a little more complicated then what the bridge does today. I guess it would have to be more specific to blue iris itself
Re: the endless stream of “HTTP Send error sending response:”, which seems to eventually take down the edgebridge. Where the only thing hitting the server at the moment is the edgebridge_monitor. Since, I found the Google Sheets stuff much more to my liking (better than doing webhook calls to a server I pay for, to create entries in google sheets.)
Made the error message stop with this little change:
Hi - Sorry to hear about the problems you were having. Can you give me any more insight as to what could have been causing the endless errors in the first place? It seems that Edgebridge was receiving something and trying to forward it back out. Or maybe some socket error was happening that wasn’t getting caught?
Glad you found a patch and I may need to incorporate it into the code!
New issue cropped up for me…
For some reason my registrations file keeps populating with the wrong address for my hub.
Instead of 192.168.1.59 it keeps changing itself to 169.254.40.143
There is nothing at that address so naturally it fails. I’ve deleted reg file and trying to “resync” by changing a device address back and forth but it keeps setting to this unknown IP.
Tue Mar 14 21:21:23 2023 GET request received from: (‘192.168.1.6’, 64663)
Tue Mar 14 21:21:23 2023 >>>>> Forwarding to SmartThings hub
Tue Mar 14 21:21:23 2023 Sending POST: http://169.254.40.143:36967/192.168.1.6/GET/Garage/motion/active to 169.254.40.143:36967
Tue Mar 14 21:21:23 2023 FAILED sending message to Edge hub [‘169.254.40.143’, 36967]
Here is the log when I’m editing IP address back/forth to resync
Tue Mar 14 21:24:26 2023 DELETE request received from: (‘192.168.1.59’, 55758)
Tue Mar 14 21:24:26 2023 Request to remove registration (‘192.168.1.5’, None)
Tue Mar 14 21:24:26 2023 Registration 1 DELETED
Tue Mar 14 21:24:26 2023 Updated registrations: [{‘devaddr’: [‘192.168.1.6’, None], ‘edgeid’: ‘e8a1a0b7-32e4-4882-8d38-45a96ead543d’, ‘hubaddr’: [‘169.254.40.143’, 36967]}]
Tue Mar 14 21:24:26 2023 **********************************************************************************
Tue Mar 14 21:24:26 2023 POST request received from: (‘192.168.1.59’, 55760)
Tue Mar 14 21:24:26 2023 Request to register device at (‘192.168.1.6’, None)
Tue Mar 14 21:24:26 2023 Registration record ADDED
Tue Mar 14 21:24:26 2023 Updated registrations: [{‘devaddr’: [‘192.168.1.6’, None], ‘edgeid’: ‘e8a1a0b7-32e4-4882-8d38-45a96ead543d’, ‘hubaddr’: [‘169.254.40.143’, 36967]}, {‘devaddr’: (‘192.168.1.6’, None), ‘edgeid’: ‘e8a1a0b7-32e4-4882-8d38-45a96ead543d’, ‘hubaddr’: (‘169.254.40.143’, 36967)}]
I have updated all three versions of edgebridge (edgebridge.py, edgebridge.exe, edgebridge executable for Pi) in the github repository. This change ensures all headers sent by the originator (Edge driver, for example) are passed through when forwarding requests on to addresses outside the LAN.
For example, if you ever had a problem accessing a RESTful API that required an specific authorization key in the header, this update should correct that.
Unless you specifically need this update, it’s not mandatory to update your systems right away. The former version will continue to run just fine.
