TAustin,
I was not able to make the server run using CFG file.
It works only if I do a CD into PY file before run it.
- CD into edgebridge.py path;
- python3 edgebridge.py
TAustin,
I was not able to make the server run using CFG file.
It works only if I do a CD into PY file before run it.
That is to be expected. The configuration file is looked for in the current working directory.
Perhaps a command line option to specify the config file location could be an enhancement I could make.
Or set an environment variable.
My response comes very late, but I hope it might still help at least someone potentially in the future. I had this exact issue, and it was caused by the changed hub address. I also tried deleting the reg file and “resyncing” by changing the LAN-trigger device address in ST back and forth to create a new reg file, but it kept setting the old hub IP and PORT every time.
Removing the LAN-trigger device from SmartThings and adding it again fixed the problem.
Question to @TAustin, is it possible to sync the LAN-trigger edge driver with the new hub IP and PORT after it has been added in any way, maybe even from ST API? Or is it possible to query the new IP and PORT somehow, and then manually update the reg file (or make a script do it), to avoid needing to remove and add the device in ST and update all rules. My issue is that the router is controlled by my ISP and I don’t know how to set a static IP to the ST hub.
Just so I understand - the situation you are trying to deal with is when the IP address for SmartThings hub itself changes? What about the PC running edgebridge, is its address also changing?
No, only the ST hub IP changed. The IP of the system running edgebridge, and the system sending LAN trigger messages through edgebridge to ST remained same. Edgebridge Monitor showed “online” all the time in ST, and also the LAN trigger devices in ST showed “online” in ST all the time (because the IPs in ST (set by user) were correct.
OK thanks. Let me think about a way to address this.
Thanks, I now switched to MQTT broker + your MQTT Device edge driver. I believe that it should not have the same issue since MQTT uses publish/subscribe model, do I understand right?
Great work by the way!
Yes, using MQTT is a good way to go and will hopefully work better for you.
I have a question, though, regarding the issue you were having. Do you happen to know if your hub restarted when its IP address changed or is it possible that its assigned IP address changed “dynamically” and there was no restart? The reason I ask is because if the hub restarted, it would be restarting the drivers. In which case the LAN trigger driver would be re-registering with edgebridge. But if that’s not happening and a re-registration never took place, then I can see where the registrations could then become invalid since they are still pointing to the old hub IP.
Would you mind direct messaging me the contents of your .registrations file?
Can I see somewhere in logs if the ST hub restarted? At least I didn’t restart it and there was to my knowledge no internet interruptions or power cuts. So if it didn’t restart by itself for some reason, I think it may not have restarted. I don’t know why the IP had changed though, it hadn’t happened before.
Unfortunately, I already deleted my reg file. But I tried recreating it many times (by changing device settings) and it created a reg file with hub IP 192.168.1.12 (old one), whereas the new was 192.168.1.25 (same subnet). Recreating the device changed it to the new one. I hope this helps.
I have a QNap TS-453 with 8gb memory do you think I will be able to do what you have done and do you have any more details to share that would help with this?
I also have a smart things hub from Aeotec so I’m not sure whether this could be used instead.
Not in the Edgebridge logs. If you were running in debug mode and you were using the Edgebridge monitor device, then it might be possible to infer an interruption on the hub side. With the new advanced app, it doesn’t show hub reboots like the old IDE did, which is a real bummer.
Let me know if you were able to get things going again or need some further help.
Has anyone gotten this working with a Synology NAS? I pulled the image from /brenthaag/edgebridge/ but am not sure how to set it up. I’m a Docker newbie so am hoping for a tutorial… Thank you!
Hello @TAustin, quick question, the latest hub update (0.54.10) broke all edge integrations using the edgebridge and LAN devices, as per what I’ve read in the forums im not the only one having this issues with LAN devices, any chance you have some time to take a look? I can provide logs or anything relevant for troubleshooting.
Thanks in advance!
-FR
I too have received the 0.54.10 hub update and have similar issues. I’m finding the hub is constantly failing to respond on the prior port, then EdgeBridge gets the current port and replaces it in .registrations, but it still isn’t able to talk to the driver on the hub.
Here’s what the log looks like before the hub update:
Tue Sep 24 13:54:47 2024 GET request received from: ('192.168.80.11', 49379)
Tue Sep 24 13:54:47 2024 Endpoint: /doorway/motion/active
Tue Sep 24 13:54:47 2024 >>>>> Forwarding to SmartThings hub
Tue Sep 24 13:54:47 2024 Sending POST: http://192.168.80.10:60901/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:60901
Tue Sep 24 13:54:48 2024 Message forwarded to Edge ID e8a1a0b7-32e4-4882-8d38-45a96ead543d
Tue Sep 24 13:54:48 2024 Response sent
Tue Sep 24 15:32:53 2024 **********************************************************************************
Tue Sep 24 15:32:53 2024 GET request received from: ('192.168.80.11', 51978)
Tue Sep 24 15:32:53 2024 Endpoint: /doorway/motion/active
Tue Sep 24 15:32:53 2024 >>>>> Forwarding to SmartThings hub
Tue Sep 24 15:32:53 2024 Sending POST: http://192.168.80.10:60901/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:60901
Tue Sep 24 15:32:53 2024 Message forwarded to Edge ID e8a1a0b7-32e4-4882-8d38-45a96ead543d
Tue Sep 24 15:32:53 2024 Response sent
Tue Sep 24 16:13:47 2024 **********************************************************************************
Tue Sep 24 16:13:47 2024 GET request received from: ('192.168.80.11', 53085)
Tue Sep 24 16:13:47 2024 Endpoint: /doorway/motion/active
Tue Sep 24 16:13:47 2024 >>>>> Forwarding to SmartThings hub
Tue Sep 24 16:13:47 2024 Sending POST: http://192.168.80.10:60901/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:60901
Tue Sep 24 16:13:47 2024 Message forwarded to Edge ID e8a1a0b7-32e4-4882-8d38-45a96ead543d
Tue Sep 24 16:13:47 2024 Response sent
Here’s what the log looks like after the hub update. Note: I’ve also tried normal things like rebooting the hub, clearing/setting the port values in the driver settings, etc.
Wed Sep 25 10:47:01 2024 POST request received from: ('192.168.80.10', 54030)
Wed Sep 25 10:47:01 2024 Endpoint: /api/register?devaddr=192.168.80.11&edgeid=e8a1a0b7-32e4-4882-8d38-45a96ead543d&hubaddr=192.168.80.10:53137
Wed Sep 25 10:47:01 2024 Request to register device at ('192.168.80.11', None)
Wed Sep 25 10:47:01 2024 Registration record ADDED
Wed Sep 25 10:47:01 2024 Response sent
Wed Sep 25 10:47:01 2024 Updated registrations: [{'devaddr': ['192.168.80.11', None], 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ['192.168.80.10', 60901]}, {'devaddr': ('192.168.80.11', None), 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ('192.168.80.10', 53137)}]
Wed Sep 25 15:14:15 2024 **********************************************************************************
Wed Sep 25 15:14:15 2024 GET request received from: ('192.168.80.11', 62284)
Wed Sep 25 15:14:15 2024 Endpoint: /doorway/motion/active
Wed Sep 25 15:14:15 2024 >>>>> Forwarding to SmartThings hub
Wed Sep 25 15:14:15 2024 Sending POST: http://192.168.80.10:60901/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:60901
Wed Sep 25 15:14:17 2024 FAILED sending message to Edge hub ['192.168.80.10', 60901]
Wed Sep 25 15:14:17 2024 >>>>> Forwarding to SmartThings hub
Wed Sep 25 15:14:17 2024 Sending POST: http://192.168.80.10:53137/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:53137
Wed Sep 25 16:14:22 2024 FAILED sending message to Edge hub ('192.168.80.10', 53137)
Wed Sep 25 16:14:22 2024 HTTP Send error sending response:
Wed Sep 25 16:14:32 2024 **********************************************************************************
Wed Sep 25 16:14:32 2024 POST request received from: ('192.168.80.10', 42692)
Wed Sep 25 16:14:32 2024 Endpoint: /api/register?devaddr=192.168.80.11&edgeid=e8a1a0b7-32e4-4882-8d38-45a96ead543d&hubaddr=192.168.80.10:55145
Wed Sep 25 16:14:32 2024 Request to register device at ('192.168.80.11', None)
Wed Sep 25 16:14:32 2024 Existing registration was REPLACED
Wed Sep 25 16:14:32 2024 Response sent
Wed Sep 25 16:14:32 2024 Updated registrations: [{'devaddr': ['192.168.80.11', None], 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ['192.168.80.10', 60901]}, {'devaddr': ('192.168.80.11', None), 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ('192.168.80.10', 55145)}]
Thu Sep 26 16:37:37 2024 **********************************************************************************
Thu Sep 26 16:37:37 2024 GET request received from: ('192.168.80.11', 56941)
Thu Sep 26 16:37:37 2024 Endpoint: /doorway/motion/active
Thu Sep 26 16:37:37 2024 >>>>> Forwarding to SmartThings hub
Thu Sep 26 16:37:37 2024 Sending POST: http://192.168.80.10:60901/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:60901
Thu Sep 26 16:37:39 2024 FAILED sending message to Edge hub ['192.168.80.10', 60901]
Thu Sep 26 16:37:39 2024 >>>>> Forwarding to SmartThings hub
Thu Sep 26 16:37:39 2024 Sending POST: http://192.168.80.10:55145/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:55145
Thu Sep 26 17:37:45 2024 FAILED sending message to Edge hub ('192.168.80.10', 55145)
Thu Sep 26 17:37:45 2024 HTTP Send error sending response:
Thu Sep 26 17:37:51 2024 **********************************************************************************
Thu Sep 26 17:37:51 2024 POST request received from: ('192.168.80.10', 49800)
Thu Sep 26 17:37:51 2024 Endpoint: /api/register?devaddr=192.168.80.11&edgeid=e8a1a0b7-32e4-4882-8d38-45a96ead543d&hubaddr=192.168.80.10:50711
Thu Sep 26 17:37:51 2024 Request to register device at ('192.168.80.11', None)
Thu Sep 26 17:37:51 2024 Existing registration was REPLACED
Thu Sep 26 17:37:51 2024 Response sent
Thu Sep 26 17:37:51 2024 Updated registrations: [{'devaddr': ['192.168.80.11', None], 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ['192.168.80.10', 60901]}, {'devaddr': ('192.168.80.11', None), 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ('192.168.80.10', 50711)}]
Fri Sep 27 09:08:25 2024 **********************************************************************************
Fri Sep 27 09:08:25 2024 POST request received from: ('192.168.80.10', 55280)
Fri Sep 27 09:08:25 2024 Endpoint: /api/register?devaddr=192.168.80.11&edgeid=e8a1a0b7-32e4-4882-8d38-45a96ead543d&hubaddr=192.168.80.10:49639
Fri Sep 27 09:08:25 2024 Request to register device at ('192.168.80.11', None)
Fri Sep 27 09:08:25 2024 Existing registration was REPLACED
Fri Sep 27 09:08:25 2024 Response sent
Fri Sep 27 09:08:25 2024 Updated registrations: [{'devaddr': ['192.168.80.11', None], 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ['192.168.80.10', 60901]}, {'devaddr': ('192.168.80.11', None), 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ('192.168.80.10', 49639)}]
Fri Sep 27 10:18:31 2024 **********************************************************************************
Fri Sep 27 10:18:31 2024 GET request received from: ('192.168.80.11', 63398)
Fri Sep 27 10:18:31 2024 Endpoint: /doorway/motion/active
Fri Sep 27 10:18:31 2024 >>>>> Forwarding to SmartThings hub
Fri Sep 27 10:18:31 2024 Sending POST: http://192.168.80.10:60901/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:60901
Fri Sep 27 10:18:33 2024 FAILED sending message to Edge hub ['192.168.80.10', 60901]
Fri Sep 27 10:18:33 2024 >>>>> Forwarding to SmartThings hub
Fri Sep 27 10:18:33 2024 Sending POST: http://192.168.80.10:49639/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:49639
Fri Sep 27 11:18:38 2024 FAILED sending message to Edge hub ('192.168.80.10', 49639)
Fri Sep 27 11:18:38 2024 HTTP Send error sending response:
Fri Sep 27 11:18:38 2024 Scrubbing registration record: {'devaddr': ['192.168.80.11', None], 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ['192.168.80.10', 60901]}
Fri Sep 27 11:18:46 2024 **********************************************************************************
Fri Sep 27 11:18:46 2024 POST request received from: ('192.168.80.10', 49462)
Fri Sep 27 11:18:46 2024 Endpoint: /api/register?devaddr=192.168.80.11&edgeid=e8a1a0b7-32e4-4882-8d38-45a96ead543d&hubaddr=192.168.80.10:48647
Fri Sep 27 11:18:46 2024 Request to register device at ('192.168.80.11', None)
Fri Sep 27 11:18:46 2024 Existing registration was REPLACED
Fri Sep 27 11:18:46 2024 Response sent
Fri Sep 27 11:18:46 2024 Updated registrations: [{'devaddr': ('192.168.80.11', None), 'edgeid': 'e8a1a0b7-32e4-4882-8d38-45a96ead543d', 'hubaddr': ('192.168.80.10', 48647)}]
Fri Sep 27 16:31:31 2024 **********************************************************************************
Fri Sep 27 16:31:31 2024 GET request received from: ('192.168.80.11', 58926)
Fri Sep 27 16:31:31 2024 Endpoint: /doorway/motion/active
Fri Sep 27 16:31:31 2024 >>>>> Forwarding to SmartThings hub
Fri Sep 27 16:31:31 2024 Sending POST: http://192.168.80.10:48647/192.168.80.11/GET/doorway/motion/active to 192.168.80.10:48647
Fri Sep 27 17:31:36 2024 FAILED sending message to Edge hub ('192.168.80.10', 48647)
Fri Sep 27 17:31:36 2024 HTTP Send error sending response:
Fri Sep 27 17:31:42 2024 **********************************************************************************
I just tried generating a motion event while the cli was running (edge:drivers:logcat) and it seems like nothing is getting through to the driver. The log shows the EdgeBridge got as far as “Sending POST” but then no response from the driver.
If I look at the logs I just posted, there seems to be a consistent 60 minute period before it times out and it finally places a “FAILED” message in the log.
So clearly something in the hub is no longer allowing EdgeBridge to talk to the hub and the specific LAN Motion Driver. Clearly the update (0.54.10) is doing something different than before.
Here’s the CLI logcat, after 60 minutes.
2024-10-02T06:26:23.024283917Z FATAL LAN Motion Device Driver 1.5 Driver with e8a1a0b7-32e4-4882-8d38-45a96ead543d reached heartbeat timeout, sending stop after 60m
2024-10-02T06:26:34.353124169Z TRACE LAN Motion Device Driver 1.5 Setup driver thisDriver with lifecycle handlers:
DeviceLifecycleDispatcher: thisDriver
default_handlers:
init:
infoChanged:
driverSwitched:
added:
removed:
doConfigure:
child_dispatchers:
I’m glad it’s not just me! I’ve been messing with this for several days now without any luck. I’ll be happy to post any logs or information that might help fix the issue.
@bittenkitten - I am not an expert by any means, either…and it’s been a long time since I set it up, but it’s still running fine. Do you have “Container Manager” installed on your NAS? From there, you can install the image and get it up and going. I’ll have to see if I can remember how I did it all…but you will need to create/edit the edgebridge.cfg with your ST token (you’ll have to create one here for it: Samsung account).
I hope that helps get you going in the right direction.
Other LAN Edge drivers have reported issues with the new hub update (0.54.10).
The culprit appears to be the getpeername() function which I can confirm is being called in the watch_socket function (line 188) of the LAN Motion Driver.
It appears @TAustin isn’t actively monitoring these threads but is there someone on the Dev Team (@nayelyz can you help?) that knows why this call to getpeername() appears to cause things to “blow up” since the 0.54.10 hub update?