Somfy Connexoon/Tahoma jailbreak


Apologies for starting a topic and just posting a link. I had typed this whole story as a topic here, but it wouldn’t let me post it because I’m a “new user”. So, here goes:

Long story short, I’ve spent the last two days jailbreaking the Somfy Connexoon to get it to work without the need for an internet connection or Somfy account. I succeeded, soft of, but I’m unable to test any further because I don’t have any devices to connect to it yet :slight_smile:.

The reason I wanted to share this with you is to see if:

  • This project is interesting to anyone and if I should contintue to make it production ready
  • If there is anyone who can give me some tips and / or pointes about the “pairing mode”
  • There is anyone who can offer me some help in general.

I did try a search on the forum, but all of the posts that I found were talking about using the cloud version of the Somfy API’s, not the local ones.

Please let me know if this isn’t the intended way of sharing information. Again, I had wanted to post it here without external links but it didn’t allow me to do so.


What you discovered is amazing. For all the Somfy users, a local API is what we look for. No soldering required is really good.

Buy I’m curious. Why have you a Conexoon without any Somfy device?

About integrating this within HA, once the local API well identified it should not be too complex. @imick’s component (GitHub - iMicknl/ha-tahoma: Custom component for Home Assistant to interact with smart devices via Somfy TaHoma or other OverKiz based API's.) can be probably adapted.

About the token, do you think you can sniff request coming from the Somfy server?

Thanks :slight_smile:.

Because the devices are still on back-order ;).

No, this is a different service altogether, with its own authentication mechanism. Once you get SSH access you can get a token by running this command:

dbus-send --print-reply --system --type=method_call --dest=com.overkiz.utilities.local /com/overkiz/utilities/local/tokensService com.overkiz.utilities.local.tokensService.createWithRandomKey string:"test" string:"local" int32:2147483648

I suspect that there is an alternative way to do it, but I wasn’t able to find it (yet). The reason I think that is that as soon as you start the “local” service it starts broadcasting its presence via mDNS over the network. There are also some open UDP ports. My guess would be that you need a mobile app to set it up in that case, but I haven’t had any luck finding it.

I’ve already talked with @imick on Discord and he gave me some pointers. When I have some free time I’ll have a go at some proof-of-concept code.

Fyi, it seems to work with miner tweaks to the pyhoma library:

I’ll have to wait for proper devices to be sure, but this looks promising :slight_smile:

1 Like

Hello Donny,

First of all great work.
I’m allways in for some hacking :wink: but i’m not a programmer or something, and i do’nt like cloud solutions either.
Do you think, when i use your guide to “root” the software, the orignally functions to somfy will still keep working? Now we are using the official HA addon to control the 2 blinds via the somfy cloud.
It woul be nice to experiment with the “open” variant of yours, while the somfy variant will still be working.

Thanks, regards,

Hey Donny,

Any updates? Or did you settle for the Velux KFL200 local box :D.

Hello I’ve a cozytouch myself and would highly appreciate to remote this device locally as I hate cloud services. Any progress here ?

No, the local API seems crippled on purpose. Whatever you do you cannot seem to add new devices. Another option would be to snuff the DBUS messages but my Connexoon was un-rooted by an update and haven’t gotten around to re-rooting it.

Okay so I put some more time into this. I tweaked the Tahoma integration a bit to allow for communication with the local API:

It can now talk to the connexoon over HTTP directly to its local IP address without the need for any sort of cloud:

I’ve also gotten several questions from people wanting to know how exactly you modify the firmware once you extract it (see my blog for instructions on that). No guarantees but here are my notes on that:

mkdir ubi-root
mkdir ubi-rootB
mkdir extract

sudo modprobe nandsim first_id_byte=0xec second_id_byte=0xa1 third_id_byte=0x00 fourth_id_byte=0x15;
sudo flash_erase /dev/mtd0 0 0

sudo nandwrite /dev/mtd0 ubi-volume.bin
sudo modprobe ubi
sudo ubiattach -p /dev/mtd0 -O 2048

sudo mount -t ubifs -o rw /dev/ubi0_7 ubi-root
sudo mount -t ubifs -o rw /dev/ubi0_9 ubi-rootB

cd ubi-root/etc/rc5.d
sudo ln -s ../init.d/dropbear S06dropbear
cd ubi-root/etc/rc2.d
sudo ln -s ../init.d/dropbear S06dropbear

cd ubi-rootB/etc/rc5.d
sudo ln -s ../init.d/dropbear S06dropbear
cd ubi-rootB/etc/rc2.d

sudo ln -s ../init.d/dropbear S06dropbear

edit etc/shadow -> add root hash (both root and rootB)

sudo umount ubi-root
sudo umount ubi-rootB

for i in {0..10}; do name=$(ubinfo -d 0 -n $i | grep Name | awk '{print $2}'); sudo dd if=/dev/ubi0_$i of=extract/$name.bin; done

cd extract
for i in {0..5}; do name=$(ubinfo -d 0 -n $i | grep Name | awk '{print $2}');size=$(ubinfo -d 0 -n $i | grep Size | cut -d '(' -f 2 | cut -d ' ' -f 1); echo -en "[$name]\nmode=ubi\nimage=$name.bin\nvol_id=$i\nvol_size=$size\nvol_type=static\nvol_name=$name\nvol_alignment=1\n\n"; done > config.ini
for i in {6..10}; do name=$(ubinfo -d 0 -n $i | grep Name | awk '{print $2}');size=$(ubinfo -d 0 -n $i | grep Size | cut -d '(' -f 2 | cut -d ' ' -f 1); echo -en "[$name]\nmode=ubi\nimage=$name.bin\nvol_id=$i\nvol_size=$size\nvol_type=dynamic\nvol_name=$name\nvol_alignment=1\n\n"; done >> config.ini

ubinize -o ../ubi-volume_patched.bin -p 131072 -m 2048 -O 2048 -s 512 -Q 1056559212 config.ini
cd ..

sudo umount /dev/ubi0_*
sudo ubidetach -p /dev/mtd0
sudo rmmod ubifs ubi nandsim

./sam-ba_3.5/sam-ba -p usb -b sam9xx5-ek -a lowlevel
./sam-ba_3.5/sam-ba -p usb -b sam9xx5-ek -a extram
./sam-ba_3.5/sam-ba -p usb -b sam9xx5-ek -a nandflash:::0xc0902405 -c erase:0x20000 -c write:ubi-volume_patched.bin:0x20000 -c verify:ubi-volume_patched.bin:0x20000

Not quite sure where to go from here to be honest :).


Wow…this is amazing…local support :slight_smile:

Does it also works with the Tahoma v1?

Not sure, I don’t have one to test :slight_smile:

FYI it seems you can generate a token using this endpoint:<gateway id>/local/tokens/generate

1 Like

Neat find!

Have anyone tried this with their new TaHoma Switch hub?


It’s a great job.

I will use your guide to “root” the software.
Do you think that the original functions of Somfy will continue to work?

I use my connexoon to fly 3 integra windows with 3 flaps via the Somfy cloud.

I want to draw the dialogue between Connexoon and the servers.
Do you have an idea of the Principle of Exchanges?

Since there is no open port:
Does the Connexoon open a VPN with the servers?
Does the Connexoon act as a web client of SOMFY servers?

Does the Removal SSL do not send the connection to the servers?
Do you have technical documentation on Connexonnon

Thanks best regards,

Hello Yves,

I recently used the guide to root mij connexoon and it is working.
The old way, via the somfy cloud also keeps working, it’s a sort of hybrid situation.

Just a small tip, edit the /etc/hosts file and add:
Because else, the somfy cloud server will update and overwrite your rooted firmware and you will loose the root.

Another tip, when you reboot the connexoon or you power cycle it, you have to do again:
mount -o remount,rw /
rm /etc/lighttpd.d/ssl.conf
/etc/init.d/webserver start
/etc/init.d/local start

So i make a file in /etc/init.d and symlinked it in /etc/rc2.d and /etc/rc5.d and name it S99start symlinked to …/init.d/

Good luck,



Hi, thanks for posting about it. I also went down that route a while ago but I had not much successs controling my deives localy. They always went offline a few seconds after beeing controlled by homeassistant.

Does it currently work for you on a daily basis?

There’s currently a bug in the local version of the python tahoma API library that’s causing this disconnect. I’ll drop a message here when it’s been adressed :slight_smile:

Do you need help? In the last fix I missed that the order of the parameters should be different. (optional not before others).

1 Like

I’ve just pushed a commit that seems to fix the issue, at least for the one test user I’m in contact with :slight_smile: . If anyone else wants a go: GitHub - dmaasland/ha-tahoma: Custom component for Home Assistant to interact with smart devices via Somfy TaHoma or other OverKiz based API's.. If you’ve already installed, you also need an updated pyhoma: GitHub - dmaasland/python-tahoma-api: Async Python wrapper to interact with internal Somfy TaHoma API, or other OverKiz API's..

Disclaimer: I did the absolute bare minimum in order to make this work. Because of that I probably introduced other weird bugs. Don’t rely on this for production use :slight_smile: