I recently outfitted my house with motorised Norman top down bottom up (TDBU) cellular shades.
They offer a hub but unfortunately it only exposes the bottom rail to third party controllers like Google Home, Alexa, and Homekit.
I successfully connected the hub to Home Assistant via the Homekit Device integration and confirmed that I only have control of the bottom rail.
Hobbled.
Attempting to set the cover to any position immediately sends the top rail to the closed position at the top of the blind and only controls the position of the bottom rail.
This would be fine for single rail blinds but for TDBU it is annoying as for best privacy while maintaining my view my blinds need the middle/top rail set anywhere from 30 to 50%.
It is also unfortunate as their app has control of both rails and reports the motor battery state. The excuse from the manufacturer in their documentation is that third party controllers do not understand the concept of a middle or top rail. This is rubbish it could be exposed as a second cover. The blind itself takes care of the maximum possible positions. And there is no excuse for not exposing the battery sensor.
To gain better control I spent an entire day hacking a QuinLED ESP32 into the remote battery compartment to press the buttons for me.
This was especially tedious and fiddly as I chose to maintain the remote functionality and did not solder directly to the pushbutton pads but to the 0603 SMD components (1.55mm x 0.85mm) on the back of the PCB with fine wire wrap wire. This took a very steady hand and a stereo microscope. On the plus side none of the buttons or LEDs were multiplexed so I could use the ESP open drain outputs and GPIO inputs directly and the remote can be powered from the ESP 3.3V supply.
After some confusion with the active state of the open drain outputs (they are normally low impedance and go high impedance when active), I got it working. It has feedback of which blinds are currently selected for control:
.
.
.
Due to the limited number of i/o I dropped the top left and right favourite buttons on the remote (fully open and fully close) as these can be accomplished with the other buttons and a script. The favourite (star) button was added as this is a quick way to set my preferred open state of the blind (it is able to be set in the blind itself).
ESPHome config if you are interested: dining-blinds.yaml (4.3 KB)
I have the kitchen and dining rooms opening and closing the blinds automatically at sunrise/sunset and have some shortcut scripts for manual control that I am reasonably happy with:
.
Unfortunately as there is no state feedback I can not show which state is currently active as recording this in an input text or input select would get out of sync as soon as the physical remote was used.
Due to the laborious and fiddly nature of this hack (It really did take a whole day for one remote) and the fact that there was no cover state feedback I started looking at the nRF52840 Bluetooth SoC in the remote.
After only half an hour of failed Bluetooth scanning using the nRF Connect phone app I realised why this was a dead end:
Bastarrds!
They arenât using Bluetooth but are using a custom 2.4GHz protocol instead. 
So, where to from here?
I could hack ESP boards into another five remotes for the remaining rooms. I really loath that prospect.
Or I could start looking at hacking their hub to see what it exposes over the Ethernet port using wireshark. Particularly when it is controlling the top rail. Or see if it has any interesting exposed test ports inside.
Or I could investigate where the interesting unpopulated ports and test points on the remote connect to on the nRF chip:
.
To be continuedâŚ
