{{tag>project hack gw60 zb40 rollladen rollo fenster blinds}}

======= Making my Blinds smart and open automatically ======= 

===== Premise =====
The blinds in my bedroom in my flat should open automatically and gradually to wake me up.
Opening time should be setable via webinterface and may depend on calculcated sunrise times as well as on weather.
Since it's a rented flat, all changes must be easily reversible or easily be handed over and maintainable by a non-technical person.


==== Options ====
<WRAP right>{{:xro:superrollo_gw60.jpg?direct&400 |}} \\ {{:xro:superrolllo_zb40.jpg?direct&400 |}}</WRAP>
  * [[http://www.amazon.de/Rolladenmotor-elektromechanischer-Rohrmotor-verschiedene-Rolladenantrieb/dp/B00NHQL7LU/ | Rollladenmotor]] \\ This was the first option I looked at. Could be easily controlled with a µC and some relays. Decided against it because:
    * reversing it is at least as much work as installing it
    * handing it over to another tenant would mean adding easily controlled and maintainable commercial buttons and controller hardware, which I wanted to avoid
  * [[http://www.amazon.de/SuperRollo-Rolladenmotor-Gurtwickler-Rolladen-Rollotron/dp/B0030ZERHY/ | Superrollo GW60]] 
    * decided on this, since it seemed like a easily installed plug in solution
    * the option to add a [[http://www.amazon.de/SuperRollo-ZB40-FUNKSET/dp/B004FI3UNC/ | ZB40 433MHz remote]] suggested the GW60 should be very hackable.

==== Investigating the GW60 ====

=== making contact ===

In my endeavour to be least invasive as possible, I first tried to construct a protoboard with spring contacts that would slide into the GW60 just like the ZB40 does. Inside the GW60 there are 8 contacts for a slide-in addon. The ZB40, as seen from the product image, connects to the first four. The result came out rather well that I expected but then turned out to have contact problems with the pins. Then I decided to just solder on some wires.

=== probing the waters ===

Measuring the pins on the GW60 I discovered the following:

The GW60 is supplied with 24V by a separate DC power supply.

^Pins from Left to Right^^
^PIN# ^ Voltage ^ Notes ^
| 1 | GND | directly connected to GND plane on PCB and to GND of DC power supply |
| 2 | GND, DataPin | can be pulled to 5V with a 100 Ohm resistor |
| 3 | 5V, DataPin  | can be pulled to GND with a 100 Ohm resistor |
| 4 | 5V  | 5V Power for the ZB40, directly connected to voltage regulator on board|
| 5 | -   | not connected to anything ??|
| 6 | -   | not connected to anything ??|
| 7 | GND | directly connected to GND plane on PCB and to GND of DC power supply |
| 8 | 24V | directly connected to 24V of DC power supply|

=== making conversation ===

Next step: figuring out how to control the GW60 via Pins 2 and 3.

After several attempts to just toggle pins resulted in nothing, we suspected some serial interface. Opening up the GW60 again,
I traced the lines to two 1KOhm resistors and then to the TX/RX input pins of a [[http://ww1.microchip.com/downloads/en/DeviceDoc/40001262F.pdf |PIC16F90]] microcontroller.

^PIN# ^ Use ^ Notes ^
| 1 | GND | directly connected to GND plane|
| 2 | RX | connected to [[http://ww1.microchip.com/downloads/en/DeviceDoc/40001262F.pdf |PIC16F90]] Pin 12 (RX) via 1kOhm resistor |
| 3 | TX | connected to [[http://ww1.microchip.com/downloads/en/DeviceDoc/40001262F.pdf |PIC16F90]] Pin 10 (TX) via 1kOhm resistor  |
| 4 | 5V | 5V Power from voltage regulator on PCB |

That strongly suggested a TTL serial interface, so I broke out my USB-TTL-serial connector.

<code sh>
for speed in 38400 19200 9600 4800 ; do stty -F /dev/ttyUSB0 $speed -raw; for ((i=0;i<0x10000; i++)); do echo -e "$(printf "\\\x%x" $i)" >| /dev/ttyUSB0; done; done
</code>

Did not make the GW60 move an inch, so maybe it was time for some research. Looking up the [[http://www.produktinfo.conrad.com/datenblaetter/625000-649999/646696-an-01-ml-FUNKSET_ZB40_de_en.pdf | manual of the ZB40 remote]] (something I should have done much earlier), it was clear that the GW60 needed to be put into a pairing mode to register a ZB40's remote. Obviously brute-forcing commands would have no effect them. Since it's likely that communication between ZB40 and GW60 flows in only one direction, that also suggested that some kine of ID would be send along.

The ZB40 can select one of three or all three rollos and send commands UP, DOWN, STOP. Simplest minimum implementation would require at least 4 bits. So I could hope that one-byte bruteforcing might still yield results. Two byte bruteforcing while also guessing the bps would be impossible in the 60s pairing mode window of the GW60. Unfortunately: NO LUCK.

Yes, at this point I could just a well have soldered something on the PCB and simulated button presses. But I was curious now, so I grudgingly ordered a overpriced ZB40 with even more prohibitive 9,90 shipping costs from Germany.

=== Listening In ===
<WRAP right>{{:xro:superrollo_zb40.jpg?direct&400 |}}</WRAP>
Next step: Listening in on the ZB40 talking to the GW60 using my OpenBench Logic Analyzer.

{{:xro:rollo_gw60_zb40_signal.tar.xz|OpenBench LogicSniffer recorded signals, Sigrok format}}

Testing the included RF Remote as well as other 433MHz remotes, it would seem the ZB40 receiver just down-modulates the signal into the baseband and pipes the raw signal to the gw60. The actual signal sent by the remote look quite strange though. It's pulse-width modulation for sure.
Seems to me that the receive (not the remote) could easy be replaced by the contents of this [[http://www.pollin.de/shop/dt/MzIyODcyOTk-/Computer_und_Zubehoer/Hardware/Maeuse_Unterlagen_Joystick/PC_Funkfernbedienung_mit_USB_Empfaenger_X10.html|Remote's USB-Stick]]

==== Update ====

Finally resumed the project with a different approach.

Bought a second ZB35 remote and soldered the contacts to a ESP8266.

Fotos [[https://galley.realraum.at/index.php?/category/ZB35RemoteSuperrollo|here]]