I am planning to use ZEN53 (DC Motor Controller) to control Flair Smart Vents.
One Flair Smart Vent already arrived and disassembled. As I expected the actuator is a small
3V Dc Motor. In addition there are two dry contact switches for reporting "vents open" and
"vents closed" status. ZEN53 has S1 and S2 sensor inputs. These inputs are designed to
control motor with external rocker switch. But I wonder if these sensor inputs could be
decoupled from controlling motor and be presented to HE just a a sensors.
Most likely the answer is "No" but just in case I am asking this question.
Also how difficult it will be to add to the driver something like "Stop Motor by Sensor"
option (I am sure this is possible)? I.e when you send an "open" command and sensor
reports "open' status" motor will automatically stoped. (The same goes for "close" command".)
It will be nice if ZEN53 S1, S2 inputs could be used this way. But if no, I am planning to add
Shelly I4 device for reporting vents open/close status. Of course, all this logic could be easy
implemented in RM but it will be very logical to have this logic right in the ZEN53 driver.
PS.
The original Flair Vents control requires at least one Flair Puck device and it is cloud
based. It could be integrated with different Smart Thermostats but than it will be
two clouds. For myself all these clouds is absolutely no go. So, only mechanical part
from Flair Vents will be used but all controls will be custom. Only single ZEN53 could
be used because open/close status reporting is "nice to have" but not really required.
As a result Flair Vents will become ZWave Smart Vents with 100% local control.
Of course, this will require some RM rule(s) or even custom app. for controlling
these modified Flair Vents.
If the motor has electronic or physical stops in it to prevent over turning then the ZEN53 can be automatically calibrated to work with that. I think it just times it and then adjusts the timing parameter by itself. The test motor I have just spins forever so I could not test that feature.
I do not think I tested the S1/2 inputs at all but looking at my driver code there is no expectation of independent reports from the switch inputs at all. They only control the connected motor and the reports back are the assumed state of the motor.
You don't want to stop the motor before it thinks it is done, because it will leave the ZEN53 thinking it is in a partially open/closed state. You can do it, but really you just need to calibrate it correctly and then it will stop on its own after it runs for the designated number of seconds. You can calibrate with good precision, with adjustments up to 1/100th of a second.
Motor simply stops mechanically at the end points. When motors stalls at the end point
current consumption jumps from about 100mA to 300mA. I was planning to use current
sensors as a limit sensors but there are two physical dry contact limit sensors in place.
ZEN53 will be in today. I am a bit confused what this "calibration" is about. If it is timing
based calibration how does it know when motor is/have to stop? It could be built-in
current sensor and ZEN53 is looking for the significant jump in current consumption
when motor stalls at the mechanical end point. Let me see how this "calibration" will work
and what it does. The backup plan is to use the built-in limit sensors because I really don't
like anything based on timing/delays. It is too bad S1/S2 inputs cannot be used as a limit
sensors. This is all about built-in firmware and Zooz engineers should think a bit better about
adding more configurable flexibility (like they did it for ZEN17).
Actually depend on how all this calibration works I am thinking about using partial
vents open/close. But I am not sure yet how many middle positions to use (if any).
BTW the original Flair controller has 50% open(or close) setting.
Unlike end limits this is definitely time based function. As a result fins never stopped
twice at the same point. I tested all original controls "as is" before I disassembled vent
and removed all original electronics.
From what I understand when you run the calibration it will run the motor one way, until it stops, then reverse and do the same, and I think it goes back one more time. Not sure how it detects the end stops exactly but it sounds like it would work for your motor. It records how much time it takes to from one full end to the other. It saves that timing as one of the parameters and then from there out it uses that time to know how to get from full open to full closed. So if you want 50% it runs half the time, etc....
If you do try the calibration let me know, as I said I have no way to actually properly test it. I wrote the driver based on info that Zooz gave me so it should work. I can start the calibration and it spins the motor, but mine does not have any stops in it.
I have to do some minor soldering before I can run real motor. Sure, I'll let you know how
"calibration" will work. ZEN53 came yesterday and now I am playing with the device itself
without motor connected. The vents are shutters. So, I am playing with shutter mode
related parameters. I set " Motor Cycle Duration for Shutter Mode" parameter to 100:
Now for "open" and "close" command the output is active exactly for 1 sec. Of course, the
polarity depend on the command. I found that if I use setPosition value the output is active
proportionally less but now "open' command is acting as a "partial open" instead of expected
"full open". "close" command still works as expected and does "full close". The only way to
go to "full open" position I have to use "setPosition = 100". To my eyes this behavior is unlogical.
The expectation is that "open" command will do "full open" regardless what setPosition value is.
I can deal with this phenomena but I guess, driver better to be fixed (unless I am missing
something).
That was the intended design of the driver. Similar to how some smart switches can remember your last brightness and turn on to the same setting. I could add an option to the settings to turn that feature off if you always want open to set it to fully open.
EDIT: Actually I did not specifically have the driver use the last level, but I am sending the value 0xFF (255) as the level for "open" which tells the device to use the last level. Would be pretty easy to make an option to force open to send 100 instead of the special 255 value.
Well, I could be wrong but to my eyes "open" must do "full open" regardless of setPosition value.
For the dimmer which memorizes last brightness setting this is somewhat logical because
dimmer always has a mechanical control paddle. For the ZEN53 if S1, S2 wires are connected
to the mechanical control switches this logic also could be good.
Again, once I know the exact driver behavior I can deal with current logic "as is".
OK, Now I am playing with real motor connected to the ZEN53.
Unfortunately I did not catch with a logs turned on what happened when I tried "Shutter Mode"
calibration very first time. Motor actually cycled few times through open/close positions but
after these few cycles power to the motor was not turned off, reported position was "closed"
but actual position was "open". Sequential attempts to invoke calibration did not produce any
motor motion at all Here is a related logs (last two lines after calibration was started and the
rest after calibration was exit manually):
After experimenting with Motor Cycle Duration for Shutter Mode parameter value of 55
seems to be golden spot for vents cycling between "open" and "close" positions.
Setting setPosition to something in between 0 and 100 produced reasonable positioning
between "open" and "close". Frankly, the driver behavior (open to the preset value) drives me
a bit crazy but as I said I can deal with this phenomena. Basically in automations I will have to
use only "setPotion" command/value for controlling vents.
Please let me know if you want me to do some driver testing and I will be very happy to
provide you a requested info.
Result/conclusion:
I am very happy with ZEN53 plus just a mechanical portion of "Flair Smart Vents".
!00% local control is achieved just by replacing the existing control board with ZEN53.
Of course, I will need to create RM Rules or even attempt to write a custom app
because a correct vent control algorithm will not be very simple (i hope, it will not be
too complicated as well).
ZEN53 driver was updated via HPM and tested. Now everything works very well and as expected.
Furthermore, the behavior for the "open" command is user configurable.
Very BIG Thank you!
