I have installed TDEF wireless roller shutters from Jarolift everywhere in my house.
I have been using the ‘madmartin/Jarolift_MQTT’ project to control them for years. I have now created a new project on this basis in the last few weeks. Among other things, this also offers an MQTT Auto Discovery function for Home Assistant.
This means that the controller is recognised as a device and the individual shutters are automatically integrated into Home Assistant.
Have a look at it - I would be happy if there are one or two users who would like to use it in the future. As always, I am open to feedback, suggestions and enhancements.
Thanks for the project. I’ve been looking at upgrading my unreliable Jarolift_MQTT setup for a while but there was never anything better available.
I really appreciate the nice webinterface (which I will never use beyond the setup because I do the actual interactions through homeassistant ;D) and the homeassistant auto discovery.
Some feedback based on my experience setting this up:
Ethernet: I was unable to get the W5500 module working though to be honest I didn’t spend a lot of time troubleshooting. One thing that confused me is the apparent inability to use the same SPI bus from the CC1101 for the W5500 as well. When I tried that I got some error messages in my log because the pins were already in use for the transceiver.
WiFi password storage: I am not a fan of how the WiFi password is stored in plaintext in the config file which can easily be exported by anyone with access to the web UI. Currently it is possible to do a double reset to get into the setup mode, connect to the AP and export the config file to get your WiFi password. While the actual security risk of this is probably low due to the attacker already needing physical access, I believe this can be solved better.
One thing I typically do for my own projects is to store passwords separately from the rest of the configuration. This could be in the EEPROM or just in a separate file which cannot be exported. While this still allows a determined attacker to read the flash of the device to get at the password this would significantly raise the effort required.
Config import/export: During testing I was unable to import configurations at all. I am not sure if this was a bug or a user error though.
Loosing settings: Again during testing I often times ran into an issue where some settings would get lost between reboots, specifically the Jarolift settings in my case. I had to reenter the jarolift keys and serial numbers multiple times because they somehow got reset to 0 after a reboot.
Device in homeassistant: Personally I would prefer to have each shutter as an individual device in homeassistant but I saw that you already discussed this here.
CC1101 Wiring Diagram: Based on the diagram you published in your README I guess you are using an EBYTE E07 CC1101 module? If so it would be good to mention that under your wiring example since there are multiple different CC1101 modules with different pinouts on the market. For example on an EBYTE E07 module pin 6 is MOSI while on a D-SUN and many other generic modules it is GDO2.
yes I decided to use different SPI instances for the CC1101 and the optional W5500 to ensure, that they will not influence each other. Maybe it will also work on the same bus, but I wanted to be “on the safe side” Maybe I can add some more words on that in the documentation. But if you wire it as described in the description it should work. There is at least one user that has a running setup with the W5500. #17
I agree that this could be improved and I already had some ideas on how to encrypt the password in the config file. As you said, the risk is not that hight if the device is in a local network, but yes it is not the best way and I will put it on my ToDo List.
3,4) That is not known so far. I have to test a bit if I can reproduce it.
yes, for now I would like to let it as it is.
yes, there are some different modules, but I hope together with the pinout table, it should be clear how to connect the two modules. But ok, maybe I should remove the information about the PINs of the CC1101 and use only the “signals” like MOSI, MISO, etc.
@Scrath I have released a new version v1.5.0 that should address some of your feedback.
For example I have implemented AES encryption of the passwords and some improvements regarding the configuration and the import/export.
Feel free to test it and give me feedback if there is something to improve.
@dewenni sorry for my really late reply. I must have missed the notification for your post and only noticed it when I logged into the forum for an unrelated issue today.
I updated from my old version v1.3.0 to your current version v1.9.0 and the following are my impressions on your changes for each version between.
v1.4.0:
Github OTA updates: Seems great though I didn’t get to test it since I went straight from 1.3.0 to the latest version using the manual OTA update. Great job on that one btw. That was really smooth beside the controller going into setup mode due to the disabled WiFi.
Luckily I had previously scrolled down the changelog and seen that note.
v1.5.0:
I really like the Timer page even though because of the integration into homeassistant I won’t be using it myself. The bitmask selection may be a bit confusing for less technically minded people though.
Probably better to just show the selection page you get when you click on it from the get-go.
Regarding the encryption, nice job. One question though, is the key the one you have here in the config.cpp file in line 25?
If so maybe you could instead generate a key using something device specific at runtime, e.g. the ESP32 Efuse MAC which is a 64bit value you can get using ESP.getEfuseMac().
v1.7.0:
ESPWebUI Library: This seems really interesting and I’ll definitely check it out. One of my most hated parts of any ESP project is building
a webinterface for commissioning the device. In my latest project I skipped that entirely and restriced myself to a serial interface since I really
did not want to do that.
Receiving remote signals: Very nice concept. I’ve seen a surprisingly reliable version of this with the ESPSomfy-RTS project before. My Jarolift transmitter is unfortunately too far from my desk as it seems, and therefore is unable to even semi-reliably pick up my remote signals. Even when I held the remote almost up against the transmitters antenna and gave the same command 4 times I would sometimes get 3 different serial addresses printed in the log.
More ESP32 chips supported. Nice. I really like the Seeed ESP32C3 due to its size. If that chip had been supported earlier I would have definetely used it instead of the big ESP32.
v1.9.0:
Service commands: Not really sure how I would use that but I guess its nice to be able to set custom endpoints for the shutter.
I guess the shade command would be useful if I could figure out how it works? I tried moving the shutter into a halfway position, pressed “set shade” under service and then tried moving the shutter up and triggering shade again to see if it moves to the previously defined position. Either I have some issues with my shutters (which would unfortunately NOT be something new) or I don’t understand how you are supposed to use this.
This isn’t related to any specific patch but rather regarding the log page as a whole. The first thing I noticed was that the page does not load the log when entering it unless I manually press refresh. Also I have no idea what the toggle switch on this page does. Maybe add a description for it?
