I know exactly what you’re trying to say here as I had the very same idea. But let me clarify the real problem here:
- The RF chipset per se is not the problem - it’s readily available
- The encryption uses a AES key which we couldn’t retrieve either by disassembling nor by sniffing or any other means. We checked the mouse (set’n’go) and found that the USB serial communication data is encrypted (but not all bytes). This means that the encryption is done in the microprocessor (on hardware) or in the application (on software set’n’go etc…) This makes it very hard to understand what’s going on. Albeit and if I remember correctly some commands can be replayed by sampling them and resending it and for some of the commands we were successful.
- the chipset lacks any documentation on the protocol. The specification is only available when being a party in the io-homecontrol alliance. This is how they keep it „under control“. My personal and also my business experience says that this only works in a long-term strategy when opening up at least the APIs. I will bet that there will eventually be some interfacing products to integrate more nicely to 3rd party but until they realize how important that this will be in a IoT digital market, they will sell their own product suite which - sadly - are pretty much closed and in plain english just s***.
to sum up: yes the ADF7022 chips solve some Layer 1, Layer 2 issues but what we really need is more insight in Layer 7 or catching the next chance on any product that will be more suitable for us - such as the B&O gateway I found.
Remember our goal: it is not about breaking the AES or going into security issues - what we want is to use a product (such as the set’n’go mouse, which is affordable) but „speak“ to it. I don’t have any problem to let the pairing (key exchange) be performed by the vanilla mouse but after that we should get some API’s. After this, writing a binding is a piece of cake. None of the io-homecontrol alliance will ever be that powerful as openHAB they will never reach the speed of binding coverage needed for a true end-to-end IoT market. What they should do is to provide a gateway either with local API’s (such as the HUE) or with remote, cloud API (such as Netatmo) if they want things to be „under control* - too bad they are not rooted in the IT business and will probably never make it - but exactly this is paramount of importance for a vendor such as Velux.
The quest isn’t over - we will wait a catch the next train! Maybe they realize to catch their train when LORA and NB-LTE will be available and rethink the strategy.
leutholl