Yup... could be integrated... and pretty reasonable price too.
1 Like
@doctorkb, I think your request isn't unreasonable, but I can't help but think that you've misunderstood @aaiyar in one way or another, and I'm not sure why you've taken such offense to what he was saying to you. As many others have said, he's one of the most kind and helpful members of this community. And, to be honest, most of your posts in this thread seem to indicate that you're a pretty decent guy, too.
In my reading of his replies, he wasn't saying that your request as a whole (to disable door controls at the app OR driver level) would be a hack. I feel like he was pointing out that it wouldn't be right to do it at the driver level. But he did say that it was something that could be done at the app level.
And I think he's right; it probably could be added to the MyQ app, but I don't know that app at all, so I can't be sure.
2 Likes
Went to bed early last night and I miss all the fun. 
4 Likes
@doctorkb, @jeubanks
Ok I sat down at a computer this morning it looks like it is disabled via an HTTP POST
POST HTTP://hubitat.local/device/disable?id={ID}&disable={true|false}
4 Likes
I submitted a feature request to the dev. My original request identified "driver/app" -- I don't care exactly where it would be implemented. He proceeded to start listing all sorts of hacks (which I identified to him as not desirable) that would solve it, then continued on to say why it wouldn't be an appropriate feature to add, which, frankly, isn't his decision to make.
It got to the point where his desire to have the last word went beyond my patience.
To be clear - I never perceived him calling my feature request a hack. The hacks were all the ridiculous ways he wanted to layer on additional functionality to accomplish it, rather than let the feature request stand. I've had enough issues with hub performance in the past (resolved as of late, thanks to a certain unnamed beta feature) to not want to introduce unnecessary processing when there'd be a simple solution that could resolve it.
Brilliant, thanks! This will certainly do for now!
Could I suggest posting that in my other thread from January about RM being able to disable/enable a device? Rule Machine disable / enable a device?
I was thinking it could be configured on a per-device basis.
That said, I'd settle for a flag that could be turned on and off via HSM or RM to say whether the device will execute actions or not.
I'm sorry, I have to agree with the others. If I have 20 dimmers (not unusual) that are partly "configured" in the "driver", for this type of platform I believe it it violates the original intent.
I asked a similar question and it was quickly pointed out that what I was asking for could easily be accomplished in an RM rule. I quite honestly had not considered the rule option and thanked the poster. This sounds similar.
You can disagree with me but you cannot discount me 
1 Like
So you're saying, that having a flag in the driver as to whether or not it should process requests violates the intent?
Perhaps some intent needs to be amended, then...
But hubitat staff have responded to say that the driver is the wrong place to do what you’re suggesting...
1 Like
I wonder when the mods are gonna drive a stake through the heart of this thread? 100+ posts of pointlessness!
3 Likes
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.
2 Likes
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...
8 Likes
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.
1 Like
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.
6 Likes
However I think there is now an agreeable solution!
