No. The point of automation is that it works and is reliable, and ideally is as simple as possible. My old solution worked flawlessly for years, every time. 100% bullet proof. It may not be the way you'd execute the same procedure, and that's fine. If it works, properly, reliably, then your entire argument is moot.
Well, you have at least 2 people who disagree with this.
Everyone gets to plant what they want in their own garden. No harm, no foul.
More than just 2. ALMOST every single custom driver for a contact sensor includes reset commands. Obviously those developers found the concept useful.
Anyway, this debate has gotten stale. Maybe somebody from Hubitat will acknowledge the other feature request I had asked for too, but I'm pretty sure it's just lost in the mud now.
I agree. It's gone completely off track.
Everyone is absolutely OK to have and share personal opinion(s).
I am EE with near 50 years of experience (still) dealing with electronics and complex logic on a daily basis. And if I attempt to do something like it was discussed in my projects I am not sure were I will now ...
That is a totally different situation. I appreciate your input, but I'm not dealing with complicated situations here where people are paying me to use best practices to complete projects for them. There are shortcuts I take at home that I would not take at work, as this system is designed for and operated by me. If I am working on a project for someone else and they are paying me, I would take a different approach and try not to use shortcuts.
It is definitely useful but ONLY if Device itself in fact accepts and executes this command accordingly (i.e. resets it status reporting to whatever actual status is).
However artificial status change which does not reflect a correct sensor output absolutely must not exist and must not be allowed.
That is literally exactly how it worked before..... LOL
And is literally exactly what my request was for.
Then what we are talking about?
Not all Devices have this capability (i.e. resetting status by command).
For these devices artificial status change must not be allowed.
I guess, now we are in agreement and discussion should be over.
If I am correct your original request was to add ARTIFFICIAL status altering for the devices incapable to reset their status accordingly.
I asked for literally the exact behavior you just described, and how the previous driver worked. Did I word my request improperly?
The previous driver literally supported sending a command to the device to set the value. The device simply goes back to reporting it's actual state the moment the state reported a change again (ie the door closed again)
That is not what I was asking for. The devices work fine, the state changes reliably. I don't remember ever suggesting this was to fix a badly functioning device. I was asking for a command that could be sent via a custom action to manually set the state to closed for certain situations. Your wording is exactly what I was asking for when you said:
I want a command where I can tell the device to temporarily report closed until the actual status changes again, just like the custom driver supported. It's already clear from Hubitat that this is not going to happen though, so I will just work with what I have now.
I am not aware about any custom driver which alters sensor status without forcing actual sensor to report a correct status. If this is a case it must/should be fixed.
And Hubitat is 1000+% correct refusing to add this changes to the Device Drivers.
What you are asking for is not a function of a Device Driver. As I mentioned before, cases like this must/should be handled in your rules/automations. This should not be difficult if rule(s) designed as a State Machine. However it will be a nightmare to create a single complex rule with endless IF-THEN, ELSE IF - THEN, ... chained statements.
I must have missed that in this topic. Oh well!!
@a.mcdear perhaps we need to kill this pointless discussion by getting the topic closed.
I know HE haven't responded yet but I would go back to the user device driver you were using before and see how it goes. I'm not getting any issues with the custom drivers for Aqara temp, contact and motion sensors.
I was reprimanded for attempting to close the topic yesterday, LOL.
What drivers are you using for them? I'll give another driver a try.
Markus's. I've kept on V1.0.1.1123.
I've kept away from Rev b as these just work with no issues.
Dang, that's the exact driver I WAS using. Do you use Hub Mesh?
Yes I do and I haven't been getting any issues.
I seem to have some major issues with my hub, and maybe they carried over to my new hub when I migrated. I'll try one sensor at a time, maybe there was something corrupted that came over with the migration process. I tried using the migration backup twice to get back to a normal state after the issues started, but maybe just creating the devices from scratch was what actually fixed it, not the drivers..