[ST Edge] Breaking boundaries: supporting Blue Iris motion alerts and Shelly wifi Motion Sensors

I truly understand the point of this exercise and really like it. Meanwhile I find it frustrating as well from the point, why the edge drivers has to be that much limited to make things work you need to throw a “man in the middle”. It just kills the point of having a single central controller (hub). Now you have two devices a hub and a device which has to run 24/7. And you have to make sure that your 24/7 devices is updated regularly and not vulnerable etc.
If anybody does that much work just to interface a device, I think it is capable to set up a different hub which does not require at all to run two devices just to interface.

Otherwise, I would make things that way to support push and not pull, that the Forward bridge could start communication with the hub, get the port number and be able to forward messages to the Hub.

And for the sake of power consumption, and being green if you don’t have a computer running 24/7, would this thing be able to run on MicroPython? Then you could port it to an ESP device.

1 Like

I run it on a Raspberry Pi which has very low power consumption. You could even run it on a Pi Zero, which gets pretty close to ESP territory.

I don’t know if it could run on MicroPython. HTTP support is the key module needed.

Having a Pi also gives me a way to run my SmartApps locally so I don’t have to worry about when Groovy/DTH goes away. (If/when they expand Edge to be able to run SmartApps then we’ll really have something!)

Also, the promise of Matter might eventually lessen the need for things like this bridge server, but I think there will be special cases well into the future…


I completely agree. I think I could find justification for either side of the argument but in the end, any of my frustration or valid arguments won’t get me any closer since I’m unlikely to influence much in the IOT/Smart Home industry. I just keep hoping that the talented and generous folks of this community keep doing what they do best (and, hopefully love doing). Also since this is an area of personal interest, it compounds the value I get from spending the time learning (education and working product). I assume it will be better in the future with matter and any other local execution availability.

Realistically, my BI runs on a Windows machine anyway so extra services or containers that use minimal CPU isn’t the detriment it would be for those using the Shelly (or other) devices. I just got an RPi at Christmas and I’m sure I’ll find a way to improve my setup. In the end, I’m a consumer using consumer grade devices and services, and should only expect results I can achieve.

Hi again,

So I am getting 400 errors again when BI posts to the bridge server. I had neglected to bind my ST hub’s IP. SInce I needed to move it in my range, it is now different. Some parts of the bridge server seem to be aware both other pieces still reflect the original IP. I tried change settings on the driver devices and I see the updates but it still seems to reflect the old IP.

Any thoughts on how i can correct this or do I just need to rebuild? Either answer is fine since I feel good about the opportunity to learn.

Thanks again!

Let me make sure I understand what happened:

  • You had things working ok
  • Then you changed your hub’s IP address to make it static (?)
  • After that, your bridge server logging output is showing 400 errors when BI sends a message

Please confirm if all of the above is true, so I can make sure I understand the scenario.

EDIT: Hold off on what I wrote in my original post; let me think of how best to deal with this


A couple more questions for you:

  • If what I asked about the scenario was true, and you changed your hub IP address, did you do it without rebooting the hub? In other words, did the IP address get changed ‘on the fly’ by your router?
  • Did your BI address or bridge server address change at all?

I’m going to suggest that you reboot your hub. This will ensure all your devices get a fresh registration with the bridge server. You may see some errors reported in the bridge server log until it clears out all the old unused hub IP:port address it had from before, but that’s normal.

You’re probably going to tell me that you had already rebooted your hub when you made the IP address change, and if that’s the case, I’m not sure why the registrations wouldn’t have gotten reset at that point.

For future reference, when you see the bridge server reporting 400 errors when BI sends it messages, that means that the bridge server has no requests (i.e. ‘registrations’) from SmartThings devices that have said they want to receive those messages. So the bridge server doesn’t know what to do with them. This would happen if (1) the driver is not functioning, or (2) it thinks it is registered correctly with the bridge server. I’m thinking because you changed your hub IP address, the driver wasn’t aware of the change, which would have required it to re-register with the bridge server.


Thank you! That explanation definitely helps. After restart of the ST hub, I was getting new errors.

Every couple seconds or so, I would get spammed with the message below:

Thu Jan  6 01:24:15 2022  POST command received from: ('192.168.xx.xx', 52484)
Endpoint:  /api/register?devaddr=192.168.xx.xx&edgeid=e8a1a0b7-32e4-4882-8d38-xx&hubaddr=192.168.xx.xx:60009
Request to register device at ('192.168.xx.xx', None)
Existing registration was REPLACED
192.168.xx.xx - - [06/Jan/2022 01:24:15] "POST /api/register?devaddr=192.168.xx.xx&edgeid=e8a1a0b7-32e4-4882-8d38-xx&hubaddr=192.168.xx.xx:60009 HTTP/1.1" 200 -
Updated registrations: [{'devaddr': ['192.168.xx.xx', None], 'edgeid': 'e8a1a0b7-32e4-4882-8d38-xx', 'hubaddr': ['192.168.xx.xx', 44331]}, {'devaddr': ('192.168.xx.xx', None), 'edgeid': 'e8a1a0b7-32e4-4882-8d38-xx'hubaddr': ('192.168.xx.xx', 60009)}]

The driver crashed so I rebooted again. Then I edited the settings causing the device to re-register with the bridge. That seems to have fixed things. I think I caused this by editing the driver while the IP for the hub was incorrect (between when I changed it and rebooted).

In continuing to review, I noticed there are usually 1 or 2 failed requests to my hub on different ports (2 failed requests but the 3rd is successful). See below –

Thu Jan  6 01:36:47 2022  GET command received from: ('192.168.xx.xx', 51722)
Endpoint:  /Cam1/motion/active

>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:44331/192.168.xx.xx/GET/Cam1/motion/active to 192.168.xx.xx:44331
FAILED sending message to Edge hub ['192.168.xx.xx', 44331]

>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:60009/192.168.xx.xx/GET/Cam1/motion/active to 192.168.xx.xx:60009
FAILED sending message to Edge hub ['192.168.xx.xx', 60009]

>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:50819/192.168.xx.xx/GET/Cam1/motion/active to 192.168.xx.xx:50819
Message forwarded to Edge ID e8a1a0b7-32e4-4882-8d38-xxx
192.168.xx.xx - - [06/Jan/2022 01:36:52] "GET /Cam1/motion/active HTTP/1.1" 200 -

I just wanted to pass this along as I wasn’t sure if this is expected behavior. Again, I think I’m good with the 400 errors as your explanation greatly helps me understand root cause.

Thanks again and I will do my best not to break anything again for a while.

I can offer some addition insight on what you were seeing:

The ‘spam’ messages you were seeing, which included:

Existing registration was REPLACED

Was because the driver during re-installation was caught in a infinite loop of restarting. This is a terrible bug in the Edge platform and is the issue I was referring to in my earlier posts about problems updating drivers. Although SmartThings is aware of the issues, unfortunately this being a beta platform, they have been in no hurry to issue a fix. It’s a big problem though for any LAN-type drivers. So you were correct that the driver had ‘crashed’, and luckily the reboot cleared it. (sometimes it won’t and that’s when you have to delete and reinstall the driver).

The 1 or 2 failed requests that you saw should soon disappear. This is the result of ‘old’ IP/port numbers (44331 & 60009) being still registered with the bridge server, but are no longer alive (because you rebooted the hub and they changed). These get automatically cleared out after 3 failures, so these messages should fairly soon go away.

Anyway, I’m glad you are back up and running and I appreciate the info you provided. It will help me make the driver more robust.


If the manufacturers will include it… The other is SmartThings’ minimalis approach to any integration. (You know the fit a circle shaped object into a square shaped hole approach.)

An MQTT client would make sense to implement as an Edge driver and use it with a local MQTT server. But running a client for each device is a bit of overkill…

We discussed this with Paul Osborne before in the Edge announcement topic.

1 Like

You are probably right on being tied to your test channel.

I am enrolled in your distribution channel and have the motion driver installed from there. I no longer see it in your test channel you messaged me, so can’t uninstall from there. If I add anything, it is still the 12-17 version. Sounds like I may need to uninstall the devices and driver, maybe wait some time, reboot, reinstall, and redo the devices?

I’m also happy to get the CLI going if there is some directions on how to do so. Thanks!

Thanks again for the explanation. Everything has been rock solid.

If you do spend any further time adding features, the ability to send a web request within the device would be the only suggestion I have to offer.

My DTH type devices always say “checking” in the dashboard presentation so absolutely love that I can see motion at a glance. I also appreciate that they all still worked even though I lost internet for about 15 minutes (I use them to trigger outdoor floods).

Thanks again and please let me know if there is anything else I can test.

1 Like

Let’s get you set up with the CLI. Then you can use that to install the updated driver. I don’t know why it wouldn’t be automatically happening as long as you explicitly selected that driver to install from my regular channel. I want to try and avoid disrupting your setup and having to recreate everything!

I’m going to assume you have a Windows machine for the instructions below, but Mac and Linux is also supported.

  • Go to this link to download the Windows zip file.
  • With Windows File Explorer, navigate to your Windows downloads folder and unzip the file (highlight the downloaded zip file and select Extract / Extract all from the menus at the top of the window). Here you can also chose where to extract the file, so I would chose C:\Users\<yourid>
  • Open a command prompt window (search for ‘command prompt’ to find the app)
  • Normally you are sitting in the C:\Users\<yourid> folder and hopefully this is where you extracted the smartthings.exe file to. If you extracted it to a different location, you’ll have to navigate to that folder first.
  • To make sure it is working type

smartthings -v

You should get the version info

  • Now try an actual CLI command and type

smartthings devices

Because you are running a command for the first time, it will open up a browser window and ask you to sign in to your SmartThings account and authorize access. Do that and then when it says you can close the browser, do so and return to your command prompt window. You should shortly see a complete list of all your Smartthings Devices (not just Edge!).

  • You’re all set. Reference this document for a list of all the commands you can use.

Please note that you CANNOT just double-click on the smartthings.exe file from the Windows File Explorer. It must be run from a command prompt window.

Some key commands you’ll probably want to use are below. Note that these are the ‘quick’ versions of these commands, which will then prompt you for any additional input needed like, selecting which hub, which driver, which channel, etc. As you get proficient, you can provide those inputs as parameters on the command line. Just reference the document above.

List installed Edge drivers:

smartthings edge:drivers:installed

Start logging:

smartthings edge:drivers:logcat

Install (or update) an Edge driver:

smartthings edge:drivers:install

Uninstall an Edge driver (you’ll need to delete all devices first):

smartthings edge:drivers:uninstall

EDIT: Some additional info as you try to update your driver…

I’d recommend opening a second command prompt window and starting logging for the driver in question there. That way you’ll be able to see what’s going on as you issue commands from the first command prompt window.

Once you’ve started logging, confirm which driver is installed by checking the version info back in your first window. Then you can try to install the newer driver. Just be sure to select my shared projects channel (ID=e6e29aeb-2793-4ebf-b8f6-e37b69e32c61), and the LAN Motion driver (ID=e8a1a0b7-32e4-4882-8d38-45a96ead543d) when prompted.

Keep an eye on the log output to make sure the install doesn’t get hung up on repeating cosock errors or just hangs. If that happens, you could try rebooting your hub. You’ll have to stop and restart logging if you do this, as it won’t automatically resume when the hub is back up. So Ctrl-c out of logging, reboot your hub, wait a couple minutes to let your hub restart, then start logging again. You’ll be able to see if the driver is quiet (that’s good) or if it is still in an endless re-install loop. If none of that is successful, then at that point I’d say you will have to delete your devices, uninstall the driver, and install it again. Wait a minute between uninstalling and installing.


That all worked perfectly. Driver updated and devices still properly working. Thank you again for all the work and assistance!


Couple of questions. Is this method going to work even when the IDE is deprecated? Currently I only use BI Fusion for motion alerts as I don’t do much with profiles at the current time (continuos recording in BI).

Second, for us that are a little green at this depth of SmartThings, any chance of a step by step walkthrough (complete with screenshots for the slower among us) for getting this up and running on our hubs? They were a tremendous help in BI Fusion and I think it would appeal to a broader group. If I had the chops to understand it all thoroughly I would make them myself and share, but alas it’s Greek to me for the most part.

Hi there. Yes, this approach is all centered around the new Edge platform (still in beta) and has no dependencies on the legacy stuff (IDE/ Groovy).

I can definitely look at beefing up the instructions. Have you read the ones here?

Admittedly, the full how-to is split between the bridge server app and the LAN Motion driver since they are two independent things, but when used together, provide a solution for local BI motion alerts. Probably between @netcsk and I, we can put a complete how-to together in short order.

1 Like

I wrote a little something here:
[RELEASE] BI Fusion v3.0 - Adds: Blue Iris Device Type Handler, Blue Iris Camera DTH, Motion Sensing - #500 by netcsk?
It also links to another post with some BI specific commands, which probably just solidifies that it would be helpful to make a guide.

1 Like

Yes your post is how I stumbled on this haha. I haven’t tried running this method yet, mainly because from reading the install I am not exactly sure what I will be doing (again, that’s a me issue, not a dev issue). BI fusion was fairly straight forward with the guide. I remember a couple hiccups but didn’t struggle too much with them. Still plan on giving it a go, but like all kids pictures (screenshots) help me a ton lol

@TAustin it appears yesterday’s firmware update broke my motion sensors with all of them showing offline. A hub reboot did not help. Is there an easier way you know of to get them back other than deleting the devices, driver, and setting them back up?

Is is possible that the IP address of your hub changed?

Here’s what I would try:

Go in to the device settings for your SmartThings motion device(s) and temporarily change the bridge address to something else (wrong) and press OK. Wait a couple seconds, then change it back to what it should be. That will force a re-registration with the bridge server, which might be needed if the hub rebooted. Watch the bridge server log output for any errors.

If the above doesn’t work, I would restart the bridge server, then perform the steps above again.

Let me know if that gets things going again.

That worked perfectly. No hub IP changes (static IP and I confirmed the lease). Thanks!

1 Like