I can't say. I can think of no other platform that works the way you suggest and I'm not skilled enough to weigh the pros and cons. I started to think of the graphics "driver" in my PC, however that only services one device so there is no comparison.
Just for my edification, it this discussion still procedural or has it turned philosophical?
John
They've said the driver is the wrong place to examine modes. And I accept that as being true. If, however, we can't talk about enabling/disabling whether a driver processes commands, then there's something wrong with the architecture.
I think itâs safe to say that nothing discussed in this thread at this point will be acted upon.
I would imagine that a new thread with a feature request might still be considered, assuming the request doesnât conflict with some core principle of how the platform functions.
I've tried a few permutations of this, but can't get it to actually disable. Am I missing something?
EDIT: curl works fine...
curl -d 'id=995&disable=false' http://192.168.77.221/device/disable
this is available via the web UI for diagnostic purposes only.
applications respond (or not) to device state changes, and issue (or not) device commands.
I fail to see the purpose of having a platform schema supporting the intended activation and deactivation of devices as a required part of any given automation.
In my opinion any integration or automation that requires this functionality at the driver level simply needs to be redone/rethought ect...
I can think of plenty of reasons that you'd want to be able to tell the element on the platform to not process commands. I've listed a few for this driver alone.
I could see using it as a safety for other things that shouldn't be turned off without due consideration, as well as things that shouldn't be turned on in some contexts.
The driver itself seems like the most direct place to do this. Adding a layer on top of virtual switches and the associate rules to handle it makes for unnecessary complication and processing.
Use port 8080 when executing the post from the hub to the hub.
Thanks, that fixed it!
that's the job of the app/automation that's controlling the driver!, not the driver!
and personally I can't think of one use case that would REQUIRE the device to be able to intentionally ignore commands at the platform level.
HA systems, any HA system shouldn't ever be connected to anything life safety related...
in your mind...
in my mind adding a command interface to a device to simply tell it to enable or disable command processing makes no sense what so ever...
Now having blathered on about that, the great thing about Hubitat is that if that's how you think your automations should work, then there's nothing stopping you from implementing this functionality in the drivers for your devices...
No ones stopping you in that regard.
However I think there is now an agreeable solution!
Strange thing we have water valve controls and gas valve controls and smoke alarms supported by Hubitat.
Perhaps finding a way for folks to improve the processing power of their hubs would be prudent, then... because there is enough complaint about bogging down without adding all these layers of extra processing.
Compatible with hubitat, not necessarily the same thing as âsupported.â And the ability to use such devices with hubitat doesnât always mean they are being used truly for life safety purposes.
In general I wholeheartedly agree with @mike.maxwell, DIY home automation platforms should not reasonably be expected to serve as a primary or critical component of any life safety function.
As an example, the smoke alarms Iâm familiar with are still primarily intended for local use, i.e. the smoke alarm makes a loud noise to alert the inhabitants of a dwelling that there is a smoke condition, just like any dumb smoke detector.
Anything that allows them to interface with hubitat or another hub is a bonus, and should be considered a convenience notification, IMHO.
Absolutely. Never bet your house and family on a DIY hardware/software setup. Life and safety concerns should be solid on their own, and integration with Hubitat is a cherry on top, that SHOULD NOT disable the built-in safeguards of the life and safety systems.
An example from smart locks: There's a reason that Alexa requires a code to unlock a device that it knows is a door lock. It's a real safety concern. It's certainly possible to use a virtual switch instead to control your door lock. Then Alexa wouldn't know it's a lock, and you wouldn't need a code to unlock it. But I would never recommend doing that.
I have double and triple checked. My door always asks for confirmation for open and close. I suggest that if your door does not, that there is something wrong with either the dashboard tile, or your install of the app and/or driver.
Perhaps it was a different tile I was using before, because I can confirm the same now.
Thanks!
Yep, should have happened long ago.
Download the Hubitat app
