This would help. My imagination is not good enough come up with most complex solutions. Same goes with all automations, especially those with virtual devices.
That makes sense, I believe. Though Iām still not sure what I would define on both ends to make Blue Iris post to the driver.
Just to be clear, Blue Iris is an agnostic IP camera software, running on an always on windows machine, doing motion detection (or reciving motion triggers from the cameras) and recording. In my case, any middle man service would be running on the same machine as blue iris.
Right now, Blue Iris Fusion smartapp motion trigger integration is setup so that Blue Iris sends to api.smartthings.com.
Sorry for the basic question, but other than the issue of not knowing the destination port, is it as simple as defining a unique URL to my hub IP (192.168ā¦:???/unique? param1=CamXMotion) on blue iris and the same but from my blue iris IP in the driver setting?
Right.
You canāt use Web Requestor to do this, if that is what you are thinking. It is designed as an initiator of HTTP requests, not an always-listening server.
But if you wanted to use an Edge driver, you could run my forwarding server on your blue iris machine, then you would configure blue iris with a URL that points to the forwarding server. Then you would need an Edge driver (which Iāve already created for my shelly motion sensor) to implement the SmartThings motion device that would be the recipient of the blue iris messages via the forwarding server. This is all assuming you were trying to use Edge for local processing.
If local execution is not your priority, one other alternative is to use webCoRE (although not strategic). You can define a piston with its own dedicated URL to which you could send your blue iris messages (without any intervening server) and that piston could trigger a virtual motion sensor device. This is similar to what you already have running, just using webCoRE instead of a SmartApp.
I have two at the moment.
- I have a rule that attempts to connect to an IP address and port on the TV every few minutes. If I get a 200 the TV is switched on and I set a virtual motion sensor active which keeps the motion controlled lighting on. The LAN Device Monitor might actually be a more elegant solution but this does a job.
- I make announcements by sending HTTP requests to a tablet running Tasker with Autoremote as a web server. That either makes the announcements itself or uses Autocast to a Google Cast device. Laggy but better than nothing. I still hope that one day there will be direct integration with Google speakers.
3 Likes
Iām using it to publish my SmartThings location mode changes to my local Home Assistant instance. Itās been more reliable than any of the Groovy methods of triggering off location mode.
2 Likes
Thanks and sorry for my confusion. I look forward to seeing your local server and testing it out!
Iāll keep you in mind for an early tester. 
Itās been a while since I used autoremote how exactly do you make the post webrequest run locally with an IP address? Are you running a forwarding service? If not that is amazing, please show me an example of a url post. Thank you in advance!
I use a task in Tasker that runs Actions > Plugin > AutoRemote > WiFi which can start and stop a web server on the Tasker host device on port 1817. That web server means I can use a URL of the form:
http://192.168.1.80:1817/?message=ANNOUNCE=:=Speaker=:=Message
I think you can add a path before the ?message if you want to but I am not entirely sure.
What I then choose to do is create a profile in Tasker using Profiles > Event > Plugin > AutoApps and that will trigger the tasker event if a ācommand filterā is found in the URL, and in my example that is ANNOUNCE=:=.
The =:= separator is part of the AutoApps command format. It just means you can get some parsing done for you by the tasker action if that floats your boat.
I donāt particularly recommend this as a solution, it is just a rather laggy fudge I came up with before I lost any enthusiasm I had for Tasker and the AutoApps and at the time I built it into DTH, thus teaching myself how they worked. I also am not terribly keen on Cast-Web-API style man-in-the-middle solutions, mainly because it just seems incredible that they are necessary.
Just wanted to drop you a line and thank you for the Autoremote tip. Iām now running local commands to tasker. With the harmony remote app for tasker I can now turn on and off my air conditioning locally. I canāt thank you enough, the possibilities are endless!
Good to hear it works for you. I have just switched to a different tablet as my previous one was just too old and was becoming unusable. Sadly I struggle to keep AutoRemote WiFi responsive on the newer (but still old) one.
Iām using tasker and Autoremote on an Nvidia shield tv and as of yet has been working great!
This works perfectly for making Blue Iris perform actions based on SmartThings events. HUGE thanks to @TAustin for making this and his sidebar assistance.
For example, this can perform the same functions, completely local and without groovy, that the existing BI Fusion Smartapp allows for, like syncing the BI server Profiles to SmartThings location modes (e.g. ST changes to Away, set BI Profile to 1) and allows for triggering cameras based on SmartThings events (e.g. opening door triggers a camera).
A few notes without trying to completely derail the flexibility of this edge driver on a specific use:
- Just like BI Fusion, it still requires unchecking āUse Secure Session Keys and Login Pageā in the BI Web Server settings and requires you run the web server, of course. This means you donāt want to give your server WAN access but instead use Stunnel or with a VPN, though that is typically good advice anyway. This limitation is detailed in the BI Help file directly but also says it is possible to elevate permissions from specific IPs, so I may just be missing something here (could not get it to work otherwise). Check the BI Fusion link above for some more details on this.
- The URL youād use from the Web Requestor to drive BI to trigger a camera would be:
GET:http://[BIServerIP]:[Port]/admin?camera=[ShortCamName]&trigger&user=[BIUserName]&pw=[BIPassword]
If wanting to do a profile change, itād be similar, with:
http://[BIServerIP]:[Port]/admin?profile=[Number]&lock=[0, 1, or 2 for run, temp, or hold]&user=[BIUserName]&pw=[BIPassword]
There is a huge amount of possibility here - check the BI Help file in the HTTP Interface section for all the options. - If you ever plan to trigger more than one camera in a single automation, do not put them in the same device because automations in ST only allow a single device and the devices can only do one command per use in automations.
3 Likes
Notice of Driver update:
A minor fix has been made to the driver to improve handling of non-text values for extracted key values.
As I made this change, I uncovered an anomaly in the way SmartThings may handle output fields in the app: if you extract and display a value that SmartThings interprets as a date/time value, the mobile app may keep expecting a date/time value. So if you change the extraction key to look at some other value in the response data that is text or numeric, for example, the app may display āInvalid Dateā. The issue does seem to clear itself after closing and reopening the app and it will again display other data types ok. Just be awareā¦
2 Likes
Is anybody else using Web Requestor v1.2 to send Get Requests to a tablet running Fully Kiosk Browser, seems Iām getting app overlay, or itās just me?
I think this one needs escalating.
@nayelyz can you help please? This driver returns the result of web requests in a āresponseā attribute and weāve discovered that if you display the attribute value in the details view it will actually try and interpret the value as HTML rather than showing the raw code. That seemed to have some interesting potential, but it rather seems like bad stuff can happen too. In this case it looks like the DOM can be messed with. My worry is whether engineered code could do something worse than make a mess.
1 Like
Just to be clear, do you want to report the acceptance of HTML in the capability value because it causes strange behavior in the app?
I reported before that the HTML was being accepted, if in this case, it is causing major issues in the app, I can share those comments with the team so they consider putting a higher priority on it.
Sort of. I have no problem with HTML being accepted in capability values. It is the way it is handled that concerns me.
It would appear that HTML in attributes isnāt being safely handled as can be seen from the device history tab @Alwas posted, and he tells me that it still looked like that fifteen hours later. It shouldnāt be possible for anything like that to happen, even if the Fully Browser has responded with eleventy billion pages of HTML when a simple āOKā would do.
My personal opinion is that HTML in values should generally be displayed as raw text and not interpreted, but if you want to interpret it then at least sandbox it.
If you have already reported an issue then nothing I have said should really be a surprise to the team. However the Edge drivers have increased the pace of community development so much that protecting users from themselves may need prioritising.
1 Like
I totally agree, I already added the picture and the comments shared above in my report.
Thank you for your input to help us know better the impact of this issue.
1 Like
Right now I throw whatever HTTP response I get into a simple text field capability. To mitigate these types of issues, I should probably limit the number of characters I put to something reasonable. But I agree with @orangebucket that the platform shouldnāt allow itself to get messed up because a dumb developer like me overloads a text field - whether itās HTML code or whatever.
So my question is: IS there supposed to be a character limit on text field values? and if so, what is it?