dresden-elektronik / deconz-rest-plugin

deCONZ REST-API plugin to control ZigBee devices
BSD 3-Clause "New" or "Revised" License
1.9k stars 499 forks source link

Conbee detected as Raspbee #1221

Closed AgentAnguz closed 4 years ago

AgentAnguz commented 5 years ago

I bought the Conbee USB stick and when inserted into my Raspberry Pi 3B+ with PoE HAT attached to the GPIO interface, I see Phoscon showing the device being a Raspbee. image

I haven't tried to remove the PoE HAT though.

Berglund commented 4 years ago

I see the same issue using Home Assistant. Using /dev/ttyACM0 works, but as I have multiple USB devices the path changes. If I use /dev/serial/by-id/usb... the stick is detected as a RaspBee. Let me know if I can help debug somehow.

yapishkahilt commented 4 years ago

The issue just came up for me a couple of days ago. Running Hassio on RPi3B+ also with Aeotec Z-wave stick. Conbee shows up as Raspbee, version listed is 2.05.75, firmware 260B0500. I've tried upgrading the firmware to 26330500 after removing the z-wave stick; during the update, it briefly indicates that my firmware is up to date, but after restarting deconz it's back to the old firmware. What's really strange is that when the issue first started, I initially lost connectivity to seven of my eight bulbs, but I could still control one bulb. Now that one is also showing up as "unavailable" as well. I'm not advanced enough to debug (wouldn't really know what that entails) but I volunteer my device to be a guinea pig for any other experiment attempting to resolve the issue.

yapishkahilt commented 4 years ago

Leaving the z-wave stick unplugged, I uninstalled and reinstalled deconz. The installation process seemed to hang, so I rebooted HA. I then went back to the dashboard and found that deconz had in fact been installed. The only thing I did in the config area was paste the path copied from the hardware area (not ACM0). The bulbs all appeared connected and were controllable again, but in deconz, Gateway was a blank page. I restarted HA server to see if that would do anything; this time, Gateway asked me for a login, but didn't recognize my password. After resetting my password, no devices showed up. I restored from a recent backup, and all the bulbs showed up as available, but when going into HA Overview, they were Unavailable. Rebooted HA, and now the lights are available and controllable. My device still displays as a Raspbee instead of a Conbee, and I can't update the firmware, but at least I can control the connected devices.

I don't know if any of the above is useful, as I'm a total noob with no deep understanding of how this stuff works, but I figured I'd share just in case it contains any info that may be of help.

kh-online commented 4 years ago

same issue here. Trying to run marthoc/deconz:armhf docker container on a new ubuntu 20.04 64bit on RPI4. I created udev rules to appear /dev/ttyACM0 as /dev/ZIGBEE. When i start the container with --device=/dev/ttyACM0 , deconz sees the Conbee II. Deconz version is 2.05.75 / 8.3.2020. When I use the /dev/ZIGBEE symbolic link, it is shown as Raspbee device, Firmware 2640700. However, it works correctly but should be fixed.

Update: I guess this has to with the names I'm using for the symbolic links. I also use a OpenHAB installation with an AEOTEC zwave stick. I created a udev rules that makes that stick visible as /dev/ZWAVE. OpenHAB then does not offer this as a valid serial device, until I named that symbolic link /dev/ttyZWAVE. So the "tty" string in the name seemed to be important.

I tried the same thing now with my Deconz container: when I name the link to /dev/ttyUSB-CONBEE, the Deconz software says product is "Conbee", wheras /dev/ZIGBEE claimed to be a "Raspbee". So the names of those links do matter somehow.. Unfortunately I can't solve that issue completely..

Update again: when I change the name of the symlink again, to "ttyACM-CONXYZ" , the Conbee II is now shown correctly as Conbee II. So the words "tty" and "ACM" in that symlink name seem to do the trick.

yapishkahilt commented 4 years ago

I spoke too soon. About 30 minutes after everything was working, all of a sudden all my zigbee devices became unavailable again. When I reboot HA, they become available, but it's just a matter of time before they again become unavailable (usually after I've gone up two flights of stairs and want to turn off my lights, of course).

UPDATE: kh-online, your guidance worked for me as well. I changed the link to /dev/ttyUSB0 and now it's being recognized as Conbee rather than Raspbee. Thank you!

Unfortunately it did nothing to fix the firmware updating issue. Everything executes successfully, but every time the Conbee restarts, the old firmware is still running and I'm encouraged to update. Given that it persists after resolving the Conbee/Raspbee device recognition issue, I now gather that the firmware update issue is unrelated (i.e., a separate headache).

Kangaburra commented 4 years ago

My Conbee II is also showing up as Raspbee in DeCONZ. Using "/dev/ttyACM0" as suggested by others didn't help either. Running HassOS 3.13 / Supervisor v225 on RPi3B. Have re-imaged and tried from scratch, same results.

Mimiix commented 4 years ago

Continue in https://github.com/dresden-elektronik/deconz-rest-plugin/issues/2579