Tilt implementation

[mhofer117]

First off, thanks for this great project! Our blinds were recently motorized with some elero system. I got everything (except tilt) working with some cheap chinese 868 mhz CC1101 module and an esp32 board.

For the tilt, my blinds seem to work differently than what is currently implemented. These are my blinds This is my remote

When closing (down), the tilt should be 0 (closed), correct. When opening (up), the tilt should be 1 (open), wrong.

The normal down/up actions are actually short tilt/up/down actions on my blinds. In addition, there are other commands (douple or long click on the remote) to go all the way down/up/tilt.

These are the commands i collected from the logs:

• check: selecting a blind on my sender does not log anything, however 0x00 seems to be correct
• stop: 0x10
• up (short tilt open/up action): 0x20 single click on up arrow
• up completely: 0x21 long click down arrow (1-2s)
• restore saved tilt position: 0x24 douple click on the up arrow
• down (short tilt close/down action): 0x40 single click on down arrow
• down completely with no tilt: 0x41 long click down arrow (1-2s)
• down completely and restore saved tilt position: 0x44 double-click on down arrow

For the moment, i set command_up=0x21 and command_down=0x44 which lets me control the blinds quite well in home assistant. However, the tilt implementation only allows tilt opening in home assistant. Tilt closing does not seem to be implemented, even though the button is there.

For proper implementation, I would need to be able to set command_tilt_up and command_tilt_down independently. In addition, I would need something like tilt_open_duration and tilt_close_duration to track / set the tilt correctly.

Would such an implementation be realistic without breaking the existing solution from (#1)? I am willing to contribute code, but am not really familiar with the esphome platform, so would need some pointers.

[andyboeh]

So to sum up, you need two tilt commands, up and down, while the current implementation only supports one. Right?

[mhofer117]

Basically yes. It also seems to be what the HA controls expect (or setting a specific tilt value): buttons sliders

[andyboeh]

Great! Supporting a second command without breaking the existing implementation should be trivial and estimating the position isn't too hard (and very similar to estimating the blind's position). I'll come up with something during the next days.

[andyboeh]

Sorry that it took so long, I discovered some serious bugs with how the CC1101 module is handled and I'm still resolving it (see the fix_tx branch).

Finally, I had a look at your request. Looking through the available commands, I see no option like "tilt close" - which command would you send in this case? Or should we send 0x41 (i.e. down completely) followed by stop once the target position is reached?

[luusl]

I think I have a similar remote and there is no tilt full open and tilt full close option. The only commands are 0x20: open one step further and 0x40: close one step more. In my case there are about 9-10 steps from complete closed tilt to complete open tilt and the other way round.

[andyboeh]

@luusl Do you know which remote and which receiver you have? AFAICT, the tilt position can be programmed individually in the Combio-868 JA receiver.

We could also send out multiple pulses with a short or configurable delay to reach the desired tilt position. Thinking about it, this could be the way to go? Internally, we would need to keep track of the last movement state so that the tilt is always correctly set.

So many different options and not exactly easy to implement with no venetian blinds at hand.

[mhofer117]

No worries about the timeline, the integration is already very useful as is. My remote is a VarioCom 284450002: https://www.elero.com/en/products/control-systems/variocom I grabbed all the commands in the OP from the debug log.

I checked again and the 0x24 command from douple tap on up arrow does not tilt a fixed amount, but restores the individually saved tilt position, similar to 0x44 - just without moving down first.

So I believe the correct implementation would be as you suggest to send 0x20/0x40 repeatedly. Especially if other remotes do not support 0x21/0x41. In the logs I cannot see the remote sending multiple 0x20/0x40, so maybe they just send the same command for the duration the buttons are pressed?

[luusl]

My external venetian blinds are made by Schlotterer, so the remote control is also branded Schlotterer, but is exactly the same as the Elero VarioTel-2, the radio receiver is an Elero Combio-868 JA Pulse Plus.

[andyboeh]

In the logs I cannot see the remote sending multiple 0x20/0x40, so maybe they just send the same command for the duration the buttons are pressed?

You should still see multiple packets as the log tries to capture all packets received. Maybe some of the other bytes contains a "pressed" and a "released" signal?

While I do not have venetian blinds, I bought a couple of used Combio 868 JA a few days ago. Maybe I can come up with a solution during the holiday season.

[mhofer117]

You should still see multiple packets as the log tries to capture all packets received. Maybe some of the other bytes contains a "pressed" and a "released" signal?

This may be possible. I guess the "released" signal is just a normal stop. Here is an example:

[18:26:26][D][elero:451]: rcv'd: len=27, cnt=157, typ=0x44, typ2=0x10, hop=00, syst=01, chl=01, src=0xf5c53d, bwd=0xf5c53d, fwd=0xf5c53d, #dst=01, dst=000001, rssi=-91.0, lqi=46, crc= 1, payload=[0x00 0x03 0x00 0x00 0x40 0x00 0x00 0x00 0x00 0x40]
[18:26:27][D][elero:451]: rcv'd: len=27, cnt=158, typ=0x44, typ2=0x10, hop=00, syst=01, chl=01, src=0xf5c53d, bwd=0xf5c53d, fwd=0xf5c53d, #dst=01, dst=000001, rssi=-91.0, lqi=50, crc= 1, payload=[0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00]

I also noticed that the last byte is either 0x40 or 0xc0 for down presses. No matter long or short.

Note that the stop command seems to be always sent unless the button is held for 2s, then 0x21 (up) or 0x41 (down) are sent instead:

[18:42:59][D][elero:451]: rcv'd: len=27, cnt=254, typ=0x44, typ2=0x10, hop=00, syst=01, chl=01, src=0xf5c53d, bwd=0xf5c53d, fwd=0xf5c53d, #dst=01, dst=000001, rssi=-91.0, lqi=68, crc= 1, payload=[0x00 0x03 0x00 0x00 0x40 0x00 0x00 0x00 0x00 0x40]
[18:43:01][D][elero:451]: rcv'd: len=29, cnt=255, typ=0x6a, typ2=0x10, hop=00, syst=01, chl=01, src=0xf5c53d, bwd=0xf5c53d, fwd=0xf5c53d, #dst=01, dst=23ba76, rssi=-90.0, lqi=56, crc= 1, payload=[0x00 0x03 0x00 0x00 0x41 0x00 0x00 0x00 0x00 0x80]
[18:43:01][D][elero:451]: rcv'd: len=29, cnt=26, typ=0xca, typ2=0x10, hop=0a, syst=01, chl=255, src=0x23ba76, bwd=0x23ba76, fwd=0xf5c53d, #dst=01, dst=f5c53d, rssi=-82.0, lqi=48, crc= 1, payload=[0x01 0x86 0x00 0x00 0x00 0x00 0x00 0x00 0x0b 0x10]

[mhofer117]

So I tried getting it to work on my own and so far it works OK for me: https://github.com/mhofer117/esphome-elero/tree/tilt

external_components:
  #- source: github://andyboeh/esphome-elero
  - source:
      type: git
      url: https://github.com/mhofer117/esphome-elero
      ref: tilt
cover:
  - platform: elero
    name: Esszimmer
    channel: 1
    blind_address: 0x...
    remote_address: 0x...
    open_duration: 35s
    close_duration: 36s
    supports_tilt: True
    tilt_open_duration: 2.4s
    tilt_close_duration: 1.9s

However I don't feel confident in opening a PR, as I had to change some other things which may break other use cases:

• Most of the received state messages had to be ignored, as I often got a STOPPED state and others right after starting a movement (but the movement still continued...)
• The polling during movements had to be disabled as it stopped the current movement... I probably didn't notice before because the polling offset (multiplier 5000) made it happen rarely
• Some other changes, like removing the tilt_command as it is not used and some custom logs