search

thexperiments / esp8266_RFControl

Contol any ASK non-rolling RF device with an ESP8266 and cheap sender/receiver hardware
7 stars 3 forks source link

Warema raw sequences #1

Open myqel opened 4 years ago

myqel commented 4 years ago

Dear Thex, I try to get four warema ewfs controlled shutters/awnings workinh with RFControl library, but keeping it on an AVR (ATTiny85 is planned). The person, who have them bought the flat some weeks ago and do not like the 8 channel remote control. She prefers the simple wall switch typically used for awnings. So I want to integrate the ATTiny85/433MHz TX in a on-wall switch for each shutter/awning with a battery, using the "raw data play" as simple alterantive to the remote control. (She is not interested in smart home, so the ESP solution is not in focus) My issue is the same you had and mentioned on the picmatic.org forum (https://forum.pimatic.org/topic/2207/controlling-warema-ewfs-awning-shutter-with-rawshutter-protocol), but even not DOWN is working. I recorded the compressed raw data with the library as well as play them with this library. No raw sequence is working on any channel. I checked the synthetic data with an logic analyser with separate 433MHZ RX and tried to vary the timing a little bit. No luck. Did you finally found the clue to get all commands working?

Regards, myqel

thexperiments commented 4 years ago

It is working now... however I'm currently trying to remember what the problem was in the end...

myqel commented 4 years ago

Thanks for the answer!

Finally, I got it working, too. The issue was the program I used with an Arduino Uno: It collected only 4 timings (the fixed maximum number regardless of 8 time placeholders) in the "compressed" raw format.

First: Double check the sent signals with a logic analyzer, I had to include a timing offset in high and low times separately in the sendig function, there seems to be a threshold difference/variation in the RX and TX circuits.

Second: Sometimes (seldom) the long gap/prologue timing of the Warema stream (~5760us) is one timing step longer than these 5760us, around ~6700us. The first part belongs to the previous manchester bit, the second part ist the gap timing. So you would need 5 times collected for the "compressed" format in some cases beside ~840us, ~1780us, ~5760us, and ~32600us epilogue.

My solution is now to send the raw stream I collected with a logic analyser for each command and the use of offsets in sending timing. This works fine for me.

The manchester code: I can identify the 3 bits for the channel 0-7 in the first 12 bit. The two following 8-bit areas are always the same for all channels and commands. This might be the unique identifier for the system installed in the house. The up/down/stop commands are represented by 3 different bits in the first 12 bit in always the same combination for each command. I cannot investigate further in the protocol as I have only access to this one system of simar shutter receivers.

Regards; myqel