Events include digital/physical type and avoids duplicate info logging
All useful device parameter settings are exposed
Reporting Issues
Please use GitHub to report any issues so each one can have its own conversation and tracking. Please provide as much info as you can including model, firmware and the "configVals" data string. Issues · jtp10181/Hubitat · GitHub
Must PRESS CONFIGURE BUTTON and check all your parameters after changing to this driver.
Is it a possibility to decouple Sensor inputs from Motor Control?
I.e. is it possible to use a Sensor inputs as a Digital Inputs without
affecting Motor Control outputs?
I posted a minor update to GitHub to fix issues with the fingerprint, so now the driver should properly match to supported devices when they are paired. Did not increase the version since it mostly benefits new installs but if you want to update anyway just run a repair in HPM.
Per the request of @vitaliy_kh I added an option for the ZEN53 to set the position to 0 when closed, instead of leaving it at the last position. This does not impact having Open return to prior position, everything else works the same. Updated library and common code while I was in there.
However the driver behavior is exactly the same.
When "closed" the reported position remain whatever it was. Even "Set Position" command does not like values less than 5. Range 5-100 works as expected, but range 0-4 does nothing (motor could be moving a bit).
There is a new setting that you have to turn on, I did not want to change the default behavior from before so I added it as an optional setting. As for 0-4 not doing anything, I don't think anything should have changed there from before. Possibly just something with the device itself?
Ops sorry, I did not realize it is a switch for this setting. Now it works, Thank You.
Command "Set Position" behavior is a bit strange. Position increment/decrement delta must be grater than 2. Delta of 1 is not accepted (not a big deal but somewhat strange). Is this by design?
Not by my design in the driver. I tested 4 and 1 positions on my test rig here and the motor moved for just a split second in both cases. I just have a very basic motor with no hard limits just for testing. So I had to manually set the calibration limits on it.
I just tested setting it to 50 and then 51, it moved just barley for a microsecond.
Maybe your cycle duration is too low for a 1% change to warrant moving it? My cycle duration is set to 200 just arbitrarily for testing purposes. Motor is not attached to anything.
OK, this is not a big deal because delta of 1 never will be used in any automations. A little bit strange ZEN53 Motor Controller behavior but it is what it is. In my case motors are also without hard limits. I am using ZEN53 for modified Flair vents (original Flair controllers replaced with ZEN53). I also used a manual calibration but Flair mechanics is not very consistent if motor moves to the same position from different directions. To "fix" this issue my automations first moves vents to "close" and than to the desired position. Actually Flair vents have limit sensors for open/close but unfortunately ZEN53 does not have an option to use this hard limits. Using external device for checking limits status will not work because HE absolutely cannot guarantee timing. This must be embedded into ZEN53 design and potentially could be introduced just by firmware update (@agnes.zooz).
I am a bit curios why original driver did not report a real position for a "close" command?
Position attribute is a Status and I guess, always should reflect actual correct value regardless of any commands.
I was just going off of how I always had my dimmer drivers working. I don't have any shades myself so I was not totally sure how to do it. Just relying on feedback from people to make changes as needed.
Yes, this is very clear. But my point is/was: Status always should/must be correct regardless of how Device (Dimmer, Switch, Motor Controller, etc.) get to this point. To my EE eyes reporting incorrect Status does not make any sense.
I see how it does not work well for shades / motor position. For a dimmer though it impacts the dashboard tiles and how it presents in other systems. The dimmer has two separate states, the switch and level. The switch can be off, while the level is set to something else. This would tell you that when you turn it back on, the level will return to where it was before, which is the case with many dimmers in the default configuration. I believe that is why a lot of the dimmer drivers are setup like this.
I really don't want to dive into deep discussion, I think it will not somewhat productive.
But being EE for many years I designed many different things. I don't see why the Device States (yes, the Device may have multiple States/Status reporting and Dimmer is a good example) should be reported incorrectly. The Device States/Status ALWAYS must be reported correctly REGARDLESS how the Device brought to the current condition. Reporting incorrect States/Status simply does not make any sense and becomes useless.
UPDATE
Thinking a bit more about this issue I can see your point.
Actually Dimmer could be OFF and set to whatever LEVEL at the same time because these are two different devices (Switch and Dimmer under one hood). But Shades cannot be say, Closed and Partially Open at the same time. Shades is just a single device. Open/Close States are simply different representation for the Position. This is a difference between two devices.
All depend on how S1, S2 control are implemented. If they are just a logical signals then certainly firmware can reconfigure their functions. But it they are hard wired to the motor control logic the firmware will not be able to do the trick.
PS.
It is always better to use any/all input signals as a logical status. This way firmware always will be able to reconfigure functionality for these signals. {I am EE.)
this post
Support my work by clicking the Info & Purchase affiliate link below to buy!
Supported Products:
Features List:
Reporting Issues 
Find on Hubitat Package Manager (HPM):
Zooz Modules Advanced Drivers 
Donations: ---->>>> PayPal.Me <<<<---- 
Never required, always appreciated!
