I believe that support for simulated motion sensors is missing in the Maker API. When I try to use the Virtual Motion Sensor driver and then issue a command from to the maker API:
The device turns on as expected. So I know it's not a Token, firewall or IP issue. When set as a virtual motion sensor and I issue a request for the commands for that device, I get this response:
So, it appears that active is the correct command to issue. Am I missing something that needs to be in the request?
Just for the heck of it, I tried the Virtual Contact sensor and Virtual Lock drivers, and those worked perfectly (I didn't test every command for the lock just lock/unlock). However, the virtual presence sensor did also not respond as I would have suspected, either. Using arrived and departed, as the docs say, did not change the status of the device.
EDIT: Looks like a fix was just posted for virtual presence. Thank you @bravenel!!!
We didn't originally consider sensors as things that should be updated via an API. Normal sensors report their status and typically don't get updated. We are looking at our virtual sensors and their exposed commands and how we might tackle these use cases going forward.
Ah. I see. So, a fix just went in for presence and it works for contact. Why would you not whitelist the rest of the commands? A virtual motion sensor is literally one of the examples on the maker api page in the new wiki. https://docs.hubitat.com/index.php?title=Hubitat™_Maker_API
Here's a screenshot:
Now, the commands are listed incorrectly but I wasn't going to bother commenting about that. If you aren't going to support these capabilities, that's your choice. But you should take them down off the Wiki so people don't spend time trying to figure out if what they are doing is wrong.
Appreciate you finding the mistake in documentation, it has been corrected. We are evaluating the commands and options for a future release. Your feedback is valuable and we want to balance access with security.
This is being evaluated. We ran out of time for this release and wanted to get it out and not hold it up while we sorted out the whitelist issue. The mismatch between the document and the app is a simple editing mistake.
@patrick If the balance between security and functionality is the game you are trying to play, and I completely understand. I’m just spit balling here but how about possible functionality to put the decisions to what custom commands that a user wants to have accessible to the api in the hands of the user. For example you already have a choice as to what devices get exposed.. what if for each device we could select what commands we would like to expose as well. Just food for thought as if I turn off the cloud endpoints I really wouldn’t be as concerned with the security of exposing for instance the custom commands that update rpm settings from my pool pump hahaha. Maybe I’m in the night here but it seems like a good idea to me.
We are considering all options. Since the API is not built in and requires you to install it, then add only the devices you want to expose. We are considering either removing the approved command list or something where the user might be able to choose specific commands to restrict.
The issue is simple, a checkbox list of commands that you have to choose either way would be massive and cumbersome. An input box where you enter a comma separated list of commands to not allow would be easy, but not terribly user friendly and prone to errors in entry that have to be guarded against.
Here's a perfect debatable 50/50 argument. Locks. I can say, you shouldn't be able to change lock codes via Maker API as a security issue. Yet someone else could see this a a huge feature being able to change the locks on a rental unit remotely without having to be onsite with just a click of a url.
We haven't reached a final decision yet, looking for more feedback.
The user is taking the time to install the app, expose the endpoints, expose the external endpoints, and then add the device. I think if they've gone through all that they have assume the risk themselves. If you add a checkbox to the app acknowledging the risks, then that should suffice for "informing the customer".
I don't disagree. However, some people just follow instructions and don't understand risks. So at the minimum we need a way to warn them. Like I said, we are open to ideas and considering a few different options at this point.
Yeah...maybe a checkbox. At the end of the day, you can only protect people so much. We have people automating garbage disposals for goodness sake! LOL
No, I don't think I'm going to. We have people exposing themselves willingly to getting their hands ripped off and they're worried about people's data being stolen out of the hubitat cloud. To me, that is the very definition of insanity.
Back to the useful part of the discussion. I mean as I see it the maker API is a more advanced feature so if the text input box and or a warning message is the easiest to implement as far as user disabling certain commands then I’d say that probably works and would be a viable start. A maker api is definitely less of a maker api though if its locked from the maker Haha. Obviously the more polished app appprach would look nicer but I guess It’s something after getting something basic out there and working on your other priorities that you could always come back to and make more user friendly. Just my 2cents. I’ve engaged enough so maybe others will have better ideas for you. Thanks for taking the time to engage and more importantly thanks for putting out there this awesome feature as I can already see it becoming one of my favorite and most used features.
I just searched the threads and can't find the "fix" I can't trigger the devices when it's a virtual motion sensor and I use "active" or "inactive" changing it back to a virtual switch and "on" and "off" works fine.
I'm trying to use this as a motion sensor tied to my BlueIris camera system. ST had an integration for this and the Maker API would be a nice direct link from my BI server to the HE hub. Testing with the "Switch" and it works great. However I now can't add the camera as a combined motion sensor in a Hubitat simple lighting rule because...it's a switch!
Yes, knew I could use a switch. But right now that selection is Motion and I have 3 other motion sensors in a simple lighting rule. This particular one turns on lights that light a path. So I can't add a switch and I'd have to duplicate all my rules. It can be done. Looks like another RM rule or webcore piston.
Would be nice to easily just use a camera as a motion sensor and the maker API seems like an easy way to do that.
