I’d like to share a project I’ve been working on that could be of interest to anyone wanting local integration of Blue Iris motion alerts or Shelly Motion Sensor devices.
This project also has broader application, and demonstrates how Edge driver developers can ‘break free’ from two current limitations of Edge drivers:
Edge drivers cannot reserve a specific port number for communication, making it prohibitive to configure LAN based devices to initiate extemporaneous HTTP requests to a driver
Some home automation LAN devices - that may not have an official integration with SmartThings - allow for the configuring of HTTP messages to be sent to a specific IP:port upon specific triggers. Two examples:
– Shelly wifi Motion Sensors
– Blue Iris video management server (motion detected by a camera)
Because an Edge driver can’t be relied upon to be listening at a specific port, we can’t configure devices such as these, resulting in missed opportunity for additional device integration. Integration via the cloud may be an option, but we want to be LOCAL!
Edge drivers cannot directly communicate OUT to any endpoint outside your LAN.
Why would you want to do this? Wouldn’t it negate the point of local-only execution?
Well yes, it may, but there could be cases where gaining access to a RESTful API, for example, may open up some interesting possibilities for Edge drivers:
– Execute a SmartThings RESTful API request to get the status of some other device, e.g. get the temperature from another SmartThings device and use that value in your Edge device. (Getting closer to SmartApp-like actions now!)
– Get data from any number of interesting RESTful API endpoints on the web (weather, ISS location, crypto prices, TV schedules, etc.)
I’m introducing two things to address the above:
Forwarding Bridge Server
This is a simple server application that runs on any always-on computer on your LAN and passes messages to an Edge driver from LAN-based devices & applications, OR forwards HTTP requests from an Edge driver (Web Requestor included!) to any URL.
For further information see the github repository and README file.
LAN Motion Driver
Using the Forwarding Bridge Server, this is an otherwise standard Edge driver supporting motion sensor and tamper alerts that can be used to implement localBlue Iris motion devices and Shelly Motion Sensor devices.
For further information see the github repository and README file.
Big thanks to @netcsk for guiding me and testing for the Blue Iris solution.
@TAustin , Thank you for the amazing opportunity to locally integrate BI with ST. I got everything up and running but hit a snag. I was attempting to test the http requests from a machine other than my BI server and was getting 400 errors. I ran the tests from the same machine and voila, it came back with 200 and showed motion on the sensor.
Thanks again for all your work on this. Since my first internet outage after having a BI server and SmartThings, I’ve been stressing on how to make this all work (let alone what to do when Groovy goes away). I can’t thank you enough!
Glad you got it working. Is is possible when you were trying to test from another machine that you didn’t have the right ‘device’ address (your non-BI machine) in the SmartThings device setting?
So I don’t have a total handle on how this is all setup (just learned about http requests last weekend) but it seems to me it expected the device/IP/Port to be the one to make the request to bridge. The error in the bridge was invalid endpoint and showed my machines IP (not the same as my BI server).
My guess is it needs the request to come from my BI machines IP or be able to include the port number of the BI machine in the devaddr (its blank and it wouldn’t retain the value in the device if I tried to include it).
I’m happy to provide any of the bridge console messages, etc. if it’s helpful.
Update
On a side note, is there any chance the driver could include a way to be triggered within an automation? I had planned on using your web requestor to send manual triggers to BI but I was hoping to have the driver do the heavy lifting of the configuration. The current BI DTH creates devices with a momentary capability for manual triggering.
Example: Motion Detector is triggered, also trigger 3 BI/LAN Motion devices.
When you configure the device address in the SmartThings device Settings, I would advise omitting the port number (it’s required for the bridge server address). Although the documentation shows a port number as optional for the device address, I haven’t done much testing with it included. The only time a port number would ever need to be specified for the device address, is if you had multiple unique things running on the same IP address wanting to talk to Edge via the bridge server.
Yes, I could include this. I hadn’t expected it to be needed, but I guess I was wrong! I intend to do some re-writing of that driver in the not-too-distant future so I will add it then. If that gets pushed out, I’ll see if I can do a quick update sooner.
Just wanted to provide some feedback from over the last few days. I’ve noticed some of the lan motion sensors staying triggered/active. At first I figured it was BI’s fault but everything on the DTH side was synced with BI motion states.
In reviewing the bridge server, I noticed each request to the bridge had several post requests to ST to various EDGE ID’s and ports. I’m not versed enough to understand if its connected but I’m wondering if ST has some type of velocity cap on web requests (via the driver or otherwise).
Since you said you were looking at making some revisions, I figured I’d pass along this behavior and symptoms. Side note, I toggled the auto-revert and I’ll assume that will correct the behavior.
Are you basing this observation based on the dashboard state or based on the state shown on the device details screen? The reason I ask is because there are app issues with Edge devices where the dashboard state does not get correctly updated. The details screen always seems to be accurate, however.
If you are going by what you see on the dashboard, then the next time you see this happening, check what’s on the details screen.
How many SmartThings motion devices do you have set up for your BI cameras?
I reviewed both the dashboard and each device screen and both reported motion. I’ve included a screenshot of the history of one of the sensors and corresponding DTH device. I’m not convinced its not BI still so I’ll keep a close eye on these.
In total, I have 7 cameras each with a IDE DTH device and LAN motion sensor device.
I masked some of the values (I have no idea what is considered sensitive) but in case its helpful, here is what a single request to my bridge looks like:
Sun Jan 2 23:23:22 2022 GET command received from: ('192.168.xx.xx', 26124)
Endpoint: /[Camera Name]/motion/inactive
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:60067/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:60067
Message forwarded to Edge ID XXXX-03a0-411e-b940-9459f4878a43
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:46881/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:46881
Message forwarded to Edge ID XXXX-565d-4c67-9409-48947474c38a
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:57047/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:57047
Message forwarded to Edge ID XXXX-42a3-472e-b6b3-bc7806d19b1b
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:57047/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:57047
Message forwarded to Edge ID XXXX-d160-4ca2-bf07-e48dd868e2d6
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:47903/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:47903
Message forwarded to Edge ID XXXX-7c48-49e5-8c9d-1cca439108d2
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:47903/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:47903
Message forwarded to Edge ID XXXX-93a4-431e-8482-98715c312af9
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:60391/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:60391
Message forwarded to Edge ID XXXX-a52e-4adc-8162-f08af2180704
>>>>> Forwarding to SmartThings hub
Sending POST: http://192.168.xx.xx:60391/192.168.xx.xx/GET/[Camera Name]/motion/inactive to 192.168.xx.xx:60391
Message forwarded to Edge ID XXXX-29e1-4b7e-bcf9-7fcfd6e0e144
192.168.xx.xx - - [02/Jan/2022 23:23:23] "GET /[Camera Name]/motion/inactive HTTP/1.1" 200 -
I’ve reworked the LAN motion driver and I’ve tested it with 7 ‘devices’ banging on it through the bridge 500 times in rapid sequence. All the updates were accurately captured and no devices were left in a motion state.
Part of these changes will also get rid of the multiple bridge transactions you are seeing for only one request.
Give me one more day of testing and I’ll have an updated driver for you to try out.
I’m planning to include this in my update, but wanted to check with you on something: I will include a momentary button not shown on the device details screen, but available as an automation action. My approach is when that button is pressed by your automation, it will cause the motionSensor to go to active for 1 second, and then revert back to inactive. Does this work for you?
That absolutely does.
I do feel I should ask though – any chance that it could send a local web request when activated? If not, I can use the web requestor driver to achieve the action I need.
I think the BI smartapp essentially creates an option for other sensors to trigger a BI cam. My hope is that it would be a straightforward port from your web requestor driver. If there isn’t any use for the Shelly devices or otherwise, feel free to omit.
I’m only asking to help avoid any automation/routine limits. I’ve included a screenshot of the option in the BI smartapp to help clarify.
Thanks again for the extremely communicative updates.
That is a great point! I think you can forget everything after “That absolutely does”.
It seems logical to use the web requestor and an automation. I have only used a few presets so I don’t see it being a problem until the automation cap.
