Strange as it May sound yes the update was Successfully completed. The error are about software that is missing to flash the conbee stick. All usb related.
If you restart the addon it should state that the firmware is up to date.
Iāve just developed a new deCONZ Add-on for Hass.io (sorry @gjong, definitely not trying to step on your toes at all, Iāve had a look at your Add-on and itās excellent work, but Iām aiming for both Conbee and RaspBee support).
- This add-on should support both Conbee and RaspBee.
- This add-on relies on a Docker Hub image (not local build) which should make installing fast, on both amd64 and armhf; and, there is a build pipeline in place to automatically update the image and add-on when a new deCONZ beta is released.
- This add-on should persist your ZigBee network data in your config folder in a subfolder called ādeconzā (which will persist through version updates).
- This add-on runs on the host network and allows you to change the listening ports of the webui and websockets interfaces with config variables (should help with uPNP detection with the PWA WebUI).
I would be grateful for any beta testers since this is my first Add-on - Iāve verified that it works on my end on a RasPi 3, but more testing is definitely needed.
To install, add this repo to your Hass.io Add-On Store tab: https://github.com/marthoc/hassio-addons.
Thanks!
6 Likes
@marthocoo its good to have a central image that would work for both the Raspbee and the Conbee. I only build one for the Raspbee because none of the other docker images seemed to work. To look if it works properly with the Raspbee I installed your image and uploaded a backup I took from my own docker image.
Though it took several attempts to upload the backup it finally worked and I can confirm the image works within Hassio with the Raspbee. All the lights, groups and sceneās where imported and seem to work.
@gjong Thanks for testing! Unfortunately in doing more testing it appears that my addon doesnāt persist the configuration like I thought it did - seems that there are more places on the filesystem that user data are stored. Does your addon persist config through an upgrade/reinstall? Iāve raised an issue with the deCONZ dev to see if I can get something added to deCONZ itself that would help with this. Until then Iāve added some info to the addon regarding backing up and restoring config before upgrading as a workaround.
It does persist through updates of the addon. I store the data in /data/deconz and then symlink it to the default deCONZ folder. But I doubt that it will last a uninstall and re-install, since that directory is then removed by resinos.
Iāve had issues with the default hassio mounts not working properly, but that was fixed when I moved over to the debian-base image of franck.
@gjong Interesting - I didnāt consider that the directory is removed during uninstall (maybe defeats the point of persisting?) but not upgrade. Maybe mine will work fine during upgrade then since all Iām doing is changing rootās homedir to /data, so that the .local/share/dresden-elektronik/deCONZ subfolder is created inside /data.
@marthocoo Iām trying to get the HASS io plugin working. How do i specify which USB device to use?
I have a conbee connected to hass. It shows up in the hardware listing when i SSH into HASS and give the command āhassio host hardwareā .
I also have other Serial usb devices connected to my hass io (smart meter reading).
If i go to the webpage, i only see a conbee gateway with the ip address hass IO, no conbee device as i previous had on an other system running deconz.
So does it work? If the gateway is discovered on that page it should be working.
@marthocoo After some experimenting i found the source.
It works only if the deconz usb device is the only usb serial device connected to hass io.
Any idea how to do a work around ?
My suggestion would be to use a conif paramter with the usb name of the conbee gateway. I would use the /dev/by-id/ device path to always point to the conbee gateway.
Iām going to take a look into this but I donāt have a quick fix unfortunately. May involve some rethinking of how the addon works. First I need to do some tests against the base Docker image to see if this problem is present there too.
Can you do me a favour? Open an issue at https://github.com/marthoc/hassio-addons and include more details - specifically can you figure out what ttyUSB number the Conbee is being assigned when your other serial device is also attached?
I will do that.
Another thing i noticed.
When i restart the host container, it does not add all of the devices. I have a lot of them ( approximate 40). Each time it is different which ones. I think this has to do with the fact that deconz has not yet listed all of the devices before Homeassistants plugin asks deconz for the device listing.
@Robban Could this be the case ?
Could be. What happens if you restart Deconz afterwards?
I have on my to do list to add support for adding new devices without restarting hass. Might help with this
Sorry. Not 100% today, I meant HASS of courseā¦ Will all devices be available if you restart hass after everything is up and running?
Ok. Would you mind enabling debug for deconz component to see if you get any messages from Deconz about added devices?
Iām guessing youāre on RaspBerry Pi? I think it may be a limitation of the hardware, or a limitation of the Hass.io platform.
Hardware maybe because there isnāt enough resources to load all the devices quickly enough.
Platform maybe because Hass.io doesnāt let you block startup until your Add-on is ready to go - you can just specify what phase of startup your Addon gets loaded in (and Iām loading the Add-on as early as possible). I think there may also be a deCONZ issue as when using Conbee on armhf deCONZ basically tries to find RaspBee first, times out, and then finds Conbee. So that introduces some delay too.
In the short term, youāll have to resort to restarting the HA container to pick up all deCONZ devices, Iām sorry to say.
An ugly work around for this would be to use the discovery function. It takes some additional time before the discovery component is complete and would possibly give deconz the extra time it needs to start up.
A small warning is that with config entries coming up, discovery might become faster to load after the initial set up so it might only solve it for a few weeks.
No problem, What scenario specific do you want me to record ?