Additional shutter mode - single pulse motor

[Pewibe]

Have you looked for this feature in other issues and in the docs?
yes
Is your feature request related to a problem? Please describe.
Shutters like garage doors usually are driven by ONE momentary switch / are controlled by ONE pulse meaning OPEN-STOP-CLOSE-OPEN-STOP-etc. In other words the direction is switched internally by the door control and a 2nd relay is NOT needed. Why shutter mode for garage doors? For „side sectional doors“ a shutter mode is conveniant because moving the car in and out you need opening 100% but stepping in/out an opening of 20% might good enough.

Describe the solution you'd like
As there is shutter mode 1 and 2 for continues operated motoers, there should be similar 2 shutter modes for pulse motors (first relay: OFF/DOWN, second relay: OFF/UP or first relay: ON/OFF, second relay: UP/DOWN). It can be used for a pulse motor to start/stop and change it's direction or just by leaving the 2nd relay unconnected for the garage door case. Because an additional criteria is needed to select shutter mode 2a or 2b I like to suggest a new and clear command "ShutterMode (0 = off, 1/2 = duration based motors, 2/4 = pulse motors, 5 = stepper, . . ) - SetOption80 can be reused.

Describe alternatives you've considered

1. Instead of "ShutterMode " the SetOption80 can be extended (all ShutterRelay then have the same behaviour).
2. Allow a virtual relay instead of a physical one as 2nd relay.

Additional context
The command "ShutterRelay" is too unflexible because of allowing only odd numbers and force the following number as 2nd relay. Why not explicitly define both relay numbers like "ShutterRelay <number of 1st relay>,<number of 2nd relay>"?

(Please, remember to close the issue when the problem has been addressed)

[stefanbode]

This should already work. Please check the option for the momentary relays. The function should be as following:

• Pulsetime1 and 2 on the both relays. In the Wiki is something about the minimum time.
• ensure that interlock is OFF, or at least not defined on the relays

Please give feedback if this solves Your problem. If not we can work to make it happen.

[stefanbode]

Regarding the uneven relay required for shutter: for most people it is not a problem and I can make the code much shorter. I’m not sure if the relay must be always uneven. For sure they must be directly follow. So something like 2,5 is a nightmare. Also that the first relay is always for closing and the second for opening is something static to ensure the code as short as it can be. The esp is not a high end computer. You have to make compromises

[stefanbode]

Oh I see you want to have this only with one relay. I do not see this possible with current solution. You need to maintain the last direction to know where to go. Additionally functions as Shutterposition can not work anymore if the door point to the wrong direction. Additionally Shutterclose and open will not work. All in all the operation with just one relay will break down all the other stuff. These kinds of garage doors are not very smart.

[Pewibe]

Stefan
Thanks for taking care of this issue. My response to several of your thoughts

1. The function should be as following:
   • Pulsetime1 and 2 on the both relays.
   • ensure that interlock is OFF, or at least not defined on the relays

In this case shutter mode 1 is asumed and the needed stop pulse at the end of a run is missing. I tested already before writing ths issue.

2. Also that the first relay is always for closing and the second for opening is something static to ensure the code as short as it can be

Thats not to discuss because installer can reverse the wires :-)

3. So something like 2,5 is a nightmare

I will not follow you. The first number has to be stored. Now instead of calculating "N+1" for each access of 2nd nuber, you first have to store 2nd number at all.

4. These kinds of garage doors are not very smart.

To be honest, devices which need less input are always "smarter". But this is philosophie. Reality is that hundred thousand of electrical garage doors are operated by one momentary swich (or e remote control which do the same). Today garage doors have the alternative to hook up two momentary switches for open and close.

5. All in all the operation with just one relay will break down all the other stuff

I want believe that, too but I have to be carefully argumenting only theoretical. In my opinion the general problem is that there is no clear command "ShutterMode ...". So the mode is derived from several other conditions which now limit future improvement. For continues operated motors there are shutter mode 0 and 1 to differentiate between relays UP/DOWN and ON/DIRECTION. The design mistake was to not offer this 2 modes for the pulse operated motors. If we were able to use relays ON/DIRECTION, the only thing we need for single relay operation is a "auto-reverse" of the direction if stop pulse is applied. And having the freedom of defining shutter modes direct, we can define even a third mode for pulse motors like "auto-reversing pulse motor.

6. My addon:

A real problem I see concerning the synchronization of door and Tasmota after a power outage or similar. My old analog control of the door (33 years old) is always assuming 0% position after repower. Modern digital controls can do first a run to close the door during boot phase. But such problems appear with ordinary shutters, too.

Do I convinced you? Maybe give a link to the shutter code and I'll try to dig into. If you need any test please feel free to ask for my help.

[Pewibe]

I had a sneak preview in xdrv_27_shutter.ino which gives me a positive view related to the questioned changes.

1. ShutterMode is internally even present "mode" and needs an easy command to set it. In sum it maybe could save some bytes in "void ShutterInit(void)".
2. With "mask" and "old_power" as bit masks the relays have to be not odd/even and not consecutive.
3. With "direction[]" and "lastdirection[]" and "auto-reverse" could be achived easily.

[stefanbode]

Regarding "convincing". I will need to write down some stuff. Your "design mistake" is also interesting. Maybe a change makes sense. We also have the requests for direct servo motors where relay1 is ower and PWM1 controls the position with the PWM duty cycle.

[garci66]

Side comment. Potentially we could have a door-closed (and maybe a "fully open") sensor so that you can always sync state. A simple reed-switch with a magnet would be enough. That also reduces the doubts about open-stop-close push button sequence since the door could potentially stop on its own and then the next push becomes close instead of stop...

I am working on my own system for shutters and basically, the power + direct servo / PWM could be a nice addition. In my case im offloading the position-tracking to a separate arduino as I have multiple shutters and its just easier to have an arduino handle the "realtime" part and communicate to a master ESP for the "smarter" integrations / GUI / mqtt.

[Pewibe]

@garci66 I think it depents on if we are discussing the
a) inner bare motor control
My Entrematic / Normstahl door and similar ones have a build in control whichs uses sensors for door 100% open and 0% / close. They do an emergency stop and a stop does a direction change. A conveniance function on newer controls is the "automatic close" which force the motor to close the door after power up. All these functions can be done by Tasmota. One function is missing but also can be realized by hardware with 2 relay channels and current sensing to stop the door if there is a obstruction. Newer controls do a "automatic reverse ond re-opening" in such a case.
b) outer door usage
Most smart homers (like me) see the door including existing control from the manufacturer as a black box. Because of the problem that you never know for sure that door is really closed, I added a reed switch to the door. So my Tasmota door operation includes a 300ms button to open-stop-close and a second virtual switch to show the door status close / open 1..100%.

Best for shutter control automisation is case a) but b) is the case of reality (if we are talking about garage doors).

[garci66]

Hi! Indeed.. sorry for mixing up two topics. The first one, the inner bare motor control would be great for true DIYers (like myself) doing everything from scratch. (im building my own curtain motors as the retail ones are ridiculously exensive).

for outer garage doors, I agree with you. I only meant it would be good to add the reed sensor (end-stop sensors) so that tasmota can know automatically if the door is fully open / fully closed regardless of whether it triggered any action or not. (It can even help trigger an alarm if the door is opened without activation for example).

in my particular case (which is the home made shutter motors), I'll probably write my own variation of the xdrv_27_shutter code, where I send, through the serial port, the target position I want for the shutters. But the original code has way too many nooks-and-crannies so I think ill try to keep it as clean as possible.

My arduino-based shutter motors are using an encoder to know the position (and save it to EEPROM after each move completion). They communicate over modbus to the main ESP8266 tasmota (by using modbus over rs232 I can easily have as many motors in a single bus as I want) and ESP can also query the current position at startup -or any other time- to know where the curtain is. By using an encoder, I don't need to worry about timing to know how to get the curtain to 50% for example.

[stefanbode]

Hi gents, I will give the shutter module a try and will separate the relay definition from the operation mode. This makes even more sense if the PWM can be used to operate stepper motors, direct servos, or continuous servos. And all with accelerate and decelerate options. Therefore also for relays, you can define if this uses a pulse or are in sync with ON/OFF. This approach will make it easier also in the future to add more special ways to move something. The code change will take some days. I will share in in my branch for testing. If everything is ok, I will pull it back here. Feel free to test. Updates here in the case.

[garci66]

Thanks Stefan!

I would really apreciate if there would be a way to trigger or integrate with third party modules that use serial / modbus/ whatever to get the blind to a given position. In my case I don't need the timing logic as the blinds im building have a built-in encoder and thus "know" where they are at all times. Im not sure if this is possible with rules or what.. but if there is any way similar to how the "Jarolift Shutter Support" is documented in the guide. Maybe using Shutter<x>#Target but we probably need a way to feed back to the module when the target was reached and/or to update the current position at startup.

if im not misunderstainding, you would like to "abstract" away the motor control part? Maybe make it a different module? (in that case, I could plugin my code in there for example and avoid using rules)

[stefanbode]

Hi gents, I need your input. Reorganized and cleanup the code. Testing planned. I have now two options you can set manually how the shutter should behave. I have not changed that with 2 relays this must be in order. So no free choice of second relay. Just uses more space.

The position mode describes how the position of the shutter is calculated. A garage door will to the same as a normal shutter with time. COUNTER is the Stepper motor and PWM_Value is the new PWM based servo WITH endstops. And PWM_TIME is the servo without endstops. Different calculation of acceleration and where the position is.

enum ShutterPositionMode {SHT_TIME, , SHT_COUNTER, SHT_PWM_VALUE, SHT_PWM_TIME,};
enum ShutterSwitchMode {SHT_SWITCH, SHT_TWORELAYPULSE,, SHT_ONERELAYPULSE};

The Switchmode describes how the ON/OFF signals are executed. SWITCH is the default. The TWORELAYPULSE is the current pulsetime with one up and one down relay. The ONERELAYPULSE is planned to be the new garage motor that only has one pulse and where the direction is indirectly set. Here one question: If you stop before or after the middle. Does the direction change? As far as I have seen the changes in the code the new direction after a stop is based if the garage has already passed the middle position. Feedback welcome

[stefanbode]

The old failsafe mode with ON/OFF and UP/DOWN and SWITCHES does not really fit. Any good idea?

[garci66]

hi stefan,

At least most of the garage doors I've seen always do reverse the direction after a stop. Meaning if the first pulse caused it to open, the next pulse will have two options:

• if the door is still running, the click would stop it. (and the next click would start moving in the opposite direction)
• if the door finished opening and is already stopped, then the next click would reverse the direction.

As for the "SHT_COUNTER"... if there is any way to "set" the counter externally (through commands or some sort of "API" or even a global variable) would be great as we could write additional modules that get triggered based on rules and are able to update the position in realtime.

And for the shutter switch mode... if there is one mode where it only trigger rules, something like "SHT_NORELAY" it would be awesome (So that we don't need to burn relay / gpio ports when using "external" blinds controls). Like how the "Jarolift Shutter Support" section of the docs explain.

[garci66]

PS .. if you have a private branch to share / take a look, let me know.

[Pewibe]

@stefanbode Good to hear from you. Here are my comments:

1. Your question related direction change was excellent answered by @garci66 . There is even no "middle" defined at a garage door.
2. Not so important but I won't believe that "choice of second relay" really uses more space if instead of the actual shifting a function is used to deliver the 2 relay indexes.
3. Concerning "old failsafe mode" I think you should use instead of one SHT_SWITCH the two modes SHT_SWITCH_UP_DOWN and SHT_SWITCH_ON_DIR. During my tests for my garage door I found that the old failsafe mode is quite similar to what is needed. Only the second pulse to stop was missed. And the second relay which is mandatory in that mode I just ignored.
   Another possibility would be to have both ShutterSwitchMode and SutterRelayMode where the first defines the "user interface" and the second the "machine IF".
4. Regarding help, etc. I like to follow garci66 post scriptum. Additionally I didn't found "ticker.h" in the files to understand the code.

[stefanbode]

Hi all. A first version to test is available. https://github.com/stefanbode/Sonoff-Tasmota/blob/master/tasmota/xdrv_27_shutter.ino

The Positionmode and Switchmode currently are set during the INIT process as before and calculated from different parameters. This will change in the future. I already added the garage mode to make some fun and benefit from the change. After debugging and making all working again I can assure there will be no free second relay and also no virtual relay mode. I need the two relays internally to hove all the different options run in the "same code".

mode 0..2 will work like before from definition. The new garage mode needs INTERLOCK OFF and pulsetime1 5 and no pulsetime or pulsetime2 0 on the second relay.

I have tested the garage mode with "relay1 on" as the only working option. the position is calculated to correct and also the movement is correct. I now need to check how I will make shutterclose and all the rest working if the direction can only controlled indirect. But I have some ideas. e.g. a short move in the wrong direction to the direction change.

The old failsafe mode now works with switches and pulses. interesting side effect. this is an alpha release and I haven't tested the STEPPER motors. No idea, if they still work. Anyhow there was a good code cleanup and shrink. Operation for the servos is also prepared but not yet integrated. But this should now be very easy in the new layout.

[stefanbode]

Please just copy this INO file to your main project. Do not use the complete branch. There are constants missing.

[stefanbode]

New relase; Download: settings.h, i18n.h and xdrv_27_shutter.ino from the branch.

• new "Shuttermode" command to set the shuttermode if not defined.
• autodetect mode if undefined
• full support of pulse relay on all shutter modes
• auto reverse in garage mode if the direction does not match. Now fully support all shuttercommands
• autodetect of pulse relay with defined pulsetime (restart on change required)

open topic before next commit:

• validate STEPPER functionality
• feedback on the other modes if everything works. For me, it looks like all ok

[stefanbode]

@garci66 : the Mode with the virtual relay already works but is a bit a side effect. You can define for example Shutterrelay1 8; even if relay 8 is not there. There is no validation of the relay. It works for sure if no relay is defined. I do not know if when relay 1..4 is defined and you switch on relay 6 it will take relay 2. Something you can check.

[garci66]

Hi Stefan! Thats great.. This means I need to define at most two relays ( I guess I need two relays for the shutter function) and then just configure as you say?

[stefanbode]

I’m pretty sure if you only define one relay it still works.only if you have defined a second relay and use it you will get into trouble because the shutterdrivers will operate it. Be aware to set the right shutter mode for garage and set a pulsetime 5 on the first relay. For a simple shutter two relays is default

[stefanbode]

Final release can be found here: https://github.com/stefanbode/Sonoff-Tasmota/tree/patch-1
Requested integration into 8.5

[stefanbode]

@Pewibe : please close the call because you request is implemented in the last commit to the main TASMOTA development branch. Please open a new case, if there is an issue.

[ascillato2]

Closing this issue as this feature has been added by @stefanbode

Thanks 👍