According to the Ezlo developers, we cannot control manually virtual security sensor devices on their platform.
They say you cannot trip / un-trip a Virtual Motion sensor for example, in the Action of a Meshbot rule. ( I have checked and you cannot) and they say you cannot also send in a HTTP command to the Ezlo controller to trip / un-trip a Virtual Security Sensor device either. (You can actually).
I for example have BlueIris running on my server and that sends out HTTP commands to my Vera Plus to control virtual motion sensors. For example when motion on a camera is detected or stopped etc.
Other types of Virtual Security Sensors would likely include:
Motion Sensors
Door / Window Sensors
Siren
Door Lock
Force Sensor
Garage Door
Any others?
I would like to hear other examples of how you are using Virtual Security Sensor devices on your Vera hubs in your Scenes and Logic and Setup etc.
So it seems virtual devices on my Ezlo Plus hub are still somewhat lacking in functionality and manual control the user has over them.
From my testing it seems Virtual Devices (on Ezlo firmware hubs) can be controlled and have their states changed and values set via the HTTP Server API and also via the Web Sockets API (MSR using web sockets) but not via their own Meshbot rules Actions and that seems very odd.
I think they need to change this so all virtual devices can be control in their Meshbot rules engine.
I use a virtual temperature sensor as a work around for (the lack of) a binary input from a ESP32 based IO module I created.
I poll the IO module using a temperature sensor IP device and then set up a pattern match to trap the response value. In my case the temperature response is only a 1 or a zero. I then have a virtual switch associated with a meshbot that changes the state of the virtual switch to match the last “temperature” reading. This way my digital input is now stored in a binary state via the virtual switch and I can use it in downstream meshbots.
So not a very normal case and definitely a work around because there was not way to filter a pattern to a binary variable. At least I wasn’t able to sort it out.
I also use a similar scheme to read an actual temperature probe on my IO module and there it can be any value fro -30 to 140 degrees. Here the IP Device template again polls the IO Module and then traps the temp reading from the return string using this pattern match:
Probe Number 2 in F is: (%s%g%d%d%d.%d%d)
I saw elsewhere folks were having trouble parsing HTML response strings and I had to sort all that out by trial an error. A little more on that here…
I have just worked out why some virtual devices appear in a Meshbot rules Action for you to control them and why some other virtual device types do NOT.
In the Online API Tool you can look at a devices “Items”. The important setting is “hasSetter”
If FALSE then the device cannot be controlled in a Meshbot rules Action.
If TRUE then it can and will appear in that device list drop down menu in a Meshbot rules Action.
For example here is a VIRTUAL Switch device. hasSetter = True
Yet my new VIRTUAL Temp sensor device. hasSetter = False
This setting also seems to have zero affect on the HTTP Server API or Web Sockets API. As both can be used to control the states and values of these Virtual devices.
Which is why you can use the 3rd party MSR logic engine for example to set a virtual temp sensors current value. But you cannot do that in their own native Meshbot’s rules engine.
Also regarding REAL physical “Security Sensor” devices paired to an Ezlo controller. I have been told by the devs and tested it for myself. You cannot manually control say a real motion sensor device. You cannot manually trip / un-trip it, like you could on the old Vera firmware hubs.
On the Ezlo platform there is no way to do that in the web UI unlike on Vera UI7 web interface. And you cannot use the Web Sockets API or the HTTP Server API to override a real “Security Sensor” device like a motion sensor.
This is by design apparently and makes the Ezlo platform more secure than the old Vera one in this regard.
The downside is it does make your testing of your rules and logic a bit more tricky. Say my rule trigger is a real motion sensor detecting motion. I have to go find that real motion sensor in the house and wave at it to set it off.
Or what the Ezlo devs are saying is to test your rules and logic with a virtual motion sensor instead temporarily, but then how do you manually trip it ? For your tests?
They need to add something into the Ezlogic web GUI for virtual devices, so a user can easily change their states and values.
Currently the only way I can trip a virtual motion sensor is to send a HTTP command in to my Ezlo hub and not every user will be able to figure out how to do that !
What if I am lucky enough to have two houses and my real motion sensor is many miles away? I can’t trip that by walking in front of it, to test my rules logic and actions. So for testing purposes a virtual motion sensor would make sense if I can manually trip / un-trip that easily?
Edit
Maybe something like this crude mock up for controlling virtual devices for testing purposes.
I guess you could OR a virtual switch in your logic wherever the motion sensor is. This way you could toggle the VSwitch to test downstream logic. As long as it is off it will be ignored by the logic.
After your meshbot is debugged you could delete the VSwitch or just leave it hidden.
