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

I can say that I’ve noticed this occurring only one time (the reset not being picked up). That said, it may have occurred and I just not noticed with my relatively small number of cameras integrated in (3).

I think what @Rodd62 is asking for is to allow a two way street from a single device. So acting as a motion sensor like current but also the ability to send a POST back to the server to trigger the camera (what your web requestor does). I’m personally happy with them being separate devices, especially since the web commands have function way beyond just triggering cameras (like sever settings), but maybe there is a device limit I’m unaware of.

I’m ready to push out this driver update for the LAN Motion device driver. I’m hoping it addresses the issues @Rodd62 has been seeing, as well as satisfies the request to be able to manually activate motion for these devices through automations.

But here’s the the challenge: for some reason this driver has been extremely problematic for me whenever I try to install an update. It frequently fails due to some unknown Edge platform bugs and I have to first uninstall my current driver and then install the updated driver. This is my experience as a developer using the CLI tool to install drivers. I don’t know if you all will experience the same issues with this being installed through the channel enrollment process. You might, so I wanted to provide this warning: IF it appears that after the driver has been updated, your devices are unresponsive, you can first try to reboot your hub and then confirm if the new driver is in fact installed (see below) and devices are back to being operational. If that doesn’t work, then I’m afraid you’ll have to delete your current devices and uninstall the driver. Then re-install and hopefully it will all be working OK.

I very much apologize for these potential problems, as I know it’s always a pain to have to redo your configurations and automations. Unfortunately this is the price we pay trying to use a beta-level platform. If I see this is a common problem for folks, I will try a different approach next time.


How to tell if you have the new update installed on your hub:

Go to Settings for the LAN Motion device and tap Driver
Look for the Version which should be:

2022-01-04T03:50:17.573862

2 Likes

Since you have the CLI, you can view logging for this driver update and let me know how it goes!

1 Like

I actually have not setup CLI. That said, I haven’t seen a driver revision come through yet.

Sounding like a broken record (but I hope it doesn’t sound insincere), but thank you again. I rebooted my hub while waiting in line at the pharmacy and by the time I got home, the driver was updated. I haven’t noticed any problems and I haven’t noticed any incongruities between driver and DTH devices.

Everything looks great. I figured out the missing piece (I struggle with business requirements at work too) to what I’m looking to do. @netcsk stated it well. I need the momentary to allow triggering of the device but I also need a field to store post data and send a web request when the momentary is triggered. Then I can use a routine like the one below (without having to add the the 3 separate web request actions).

As a very early preview, I plan to have my various motion detectors trigger an autocast of my cameras (various views) to all of my Nest Hubs and select Chromecasts.

Thanks again (to you too, @netcsk ) for your working adding local integration of Blue Iris with SmartThings!

1 Like

I’ve tried [minimally] to install and learn the CLI so if you’d like more log-based feedback, I’m happy to reprioritized that learning.

Edit: Nevermind, @TAustin post here enlightened me to what I was doing wrong.

As to your other question that I missed (I think 100% of my posts are in this thread…), I did not try Rules yet (reason for exploring CLI) but the “limit” I was referring to is discussed here (though not by ST peeps): Automation 200 limit? - #18 by joshua_lyon

Can you share what exactly happened when the driver was updated? You said you rebooted your hub. Did you have to do that because the driver & devices seemed to be dead?

I guess I thought you had it; my bad!

You probably installed the original driver from my test channel when we were working on this originally. This update is now coming from my regular shared projects channel, so you may need to select this driver from there to get the update.

2 Likes

I rebooted it simply to accelerate the update. I’ve read (or thought I had) that rebooting can trigger the drivers to update quicker. Either way, I tested automations and they can be triggered and I checked the driver version and its starts with 2022.

1 Like

OK thanks. FYI, if you’ve got the CLI, you can use that to install any available driver immediately. Just use the command:

smartthings edge:drivers:install

You’ll select your hub, the channel you want to install from, and the specific driver to install. That way you don’t have to wait for it to happen by itself. The caveat is that you may run into the update problems I mentioned earlier! So maybe letting the process happen automatically is a more reliable way go, I don’t know…

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.

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…

3 Likes

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!

@Rodd62
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

@Rodd62

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.

2 Likes

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
Port=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.

2 Likes

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!