Again - anything in the driver page would be a hack.
Not really. Adding a configuration option there that lets the driver be configured to only open/close while in certain modes wouldn't be any sort of hack. That's about having a fully-featured driver.
1 Like
I’ll have to disagree with you. Drivers should expose inherent properties of devices, not extraneous constructs like the time of day, the phase of the moon, or the weather. Those are properties explicitly designed to be used by apps to control the use of a device by a driver.
In either event, since the code for community drivers is available including the MyQ drivers, you can always modify it.
3 Likes
Having it respect the mode of the hub is no different from being able to assign LED behaviour or association groups of a z-wave device.
If you don't want to use the functionality, you don't have to. But having it there would save a tonne of workaround hacks to accomplish the same goal.
Glad I'm not having to convince you, and that it's dman2306 who is maintaining this codebase. To be clear: I was aware of those potential hacks well before you suggested them... but felt that a better solution was a feature request.
Hubitat's model is to not expose app functions in devices. That's why this isn't done in any built-in device drivers.
4 Likes
Perhaps you missed what I was putting down. I'll be more blunt.
I wasn't asking you.
This is not a feature of a device driver, event filters containing attributes not specifically belonging to the device most certainly do not belong as part of the device driver code.
8 Likes
That's actually not possible in Hubitat's device/driver model. Only apps have access to location mode. (See: developer docs for device inputs and related docs). That is quite possibly all that was meant above. 
Since this driver requires a "service manager app" to do its work, however (and that's where the open/close commands actually get sent to MyQ's cloud servers from), an option could be added at the app level to not do something in certian mode(s). That would take a few modifications but looks possible; you could also easily add the generic "mode" input to the app and have Hubitat automagically restrict everything in the app (this would also include reporting of open/close states) from running during that time--super-easy, but probably not 100% desirable.
6 Likes
Question, If I had say two dimmers that use the same driver. One could benefit from your suggestion, the other not. Its not clear how this would work.
1 Like
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.
This started about having the MyQ garage door not respond to open commands either due to HSM armed status or due to HE mode.
Now that's just rude. A senior member of the community was nicely trying to point out that what you "want" was not just a hack but an actual deviation of the design of the underlying system and yet you persist to say you'll get it anyways because someone else maintains the code. Interesting that you as a "developer" (your little title says it)... is that self appointed? nevermind... but as a "developer" instead of talking about getting someone else to do it. Um... why don't you go develop what you want? Then you can show it off and make yourself feel better.
9 Likes
That title is not deserved in this case, given his insistence on a hack.
If you read my note right above this (or go back to the original thread and read the complete back-and-forth), you'll note that I wasn't asking for him to solve this. I was asking for a way for the device's action functionality to be disabled an enabled by an outside status.
As for the Developer flag... that magically appeared when I looked at something at one point and I never bothered to figure out how to remove it. I haven't learned groovy to do the dev work on this myself.
I think @mike.maxwell addressed this directly. Event filters (such as mode/hsm) not specifically belonging to a device do not belong as part of the device driver code.
What you want to do should be done in an app (RM or something you choose to write).
Edit. So suggesting do so in an app would not be a hack. Suggesting the opposite would be the hack (and @bertabcd1234 pointed out, generally not possible).
2 Likes
I agree. He's disrespected one of the nicest, most helpful souls here. That's NOT how we treat each other here. No matter how senior or noob you are. If you don't like what's being said, instead of making yourself look like a big @$$, you should ignore or flag the post.
7 Likes
Who was being a complete jerk by insisting that he had the only worthwhile solution and that the way the thing worked was perfect.
I tried (less directly) telling him that he's off-track and was trying to solve it in a manner already considered and found wanting, but he just didn't get the clue.
Point out a single message in which I made either claim. I'll bet you cannot.
2 Likes
I think you're not getting the clue.
We Don't treat others like that here. Ev-er
If you don't want input from everyone, then don't post it for all to see.
4 Likes
When something is done outside of the design of a system.... that is a hack. I understand you may not like that yet this is how driver's work within this system. There's a layered approach to provide a separation of duties/functions and they should not be intertwined. Separation of such makes things more efficient (yes it may seem odd if you're not a developer) and flexible to be able to expand upon the framework. Which is what an app would do to provide what you're wanting not something at the driver level that would affect all other users.
Yes I saw your statement of "if you don't want it don't use it" (paraphrased). That's difficult when it's part of the driver someone is using and if that part of the code is bad or has some negative interaction then other's are affected without their choice to use that functionality. Hence you put those "options" at another layer to truly make them "optional".
I see you're new, with only a few posts and I'm guessing a Wink refugee. There's a lot of things done differently with Hubitat than most other systems with a very strong methodology from it's cousin SmartThings. So as a friendly suggestion you may want to play around with the system a bit more before jumping to changing things just yet. Not sure if your nickname having doctor implies anything yet most doctors like to study something before cutting it open? Most....anyways.
5 Likes
I need to go and get some popcorn. The show is about to start.
4 Likes
2 Likes
