Conbee detected as Raspbee

[AgentAnguz]

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.

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

[manup]

Firmware not connected is suggesting the connection between ConBee and deCONZ isn't established.

Which linux system is this? Note the linux user which runs deCONZ needs to have access to the USB device. Usually the user needs to be in the group dialout, so that deCONZ can access /dev/ttyUSB0.

sudo gpasswd -a pi dialout

Restart might be required.

[AgentAnguz]

This is a hass.io system. HassOS 1.12

[manup]

Ah ok, which device did you specify in the Hass.io/deCONZ Add-on?

[AgentAnguz]

I put in /dev/ttyUSB0

core-ssh:~# hassio hw info
audio:
"0":
devices:
- chan_id: "0"
chan_type: digital audio playback
- chan_id: "1"
chan_type: digital audio playback
name: bcm2835_alsa - bcm2835 ALSA
type: ALSA
disk: []
gpio:

• gpiochip0
• gpiochip128
  input: []
  serial:
• /dev/ttyUSB0
• /dev/ttyAMA0

[AgentAnguz]

I have an Aeotec Z-wave USB stick which is unplugged right now, but it shows up as /dev/ttyAMC0 and it works fine.

[manup]

/dev/ttyUSB0 looks correct.
Have you tried using the Update to 0x262f0500 button in the Phoscon App?

[AgentAnguz]

Yes. If I click the Update button a cog is rotating for a while and returns with OK.
Then Firmware shows "Not connected" but I just saw it changed to a different value, something like 262B0500 or similar, but changed back to "Not connected".
The log is showing this:
12:00:11:900 Announced to internet
12:00:11:901 discovery server date: Tue, 05 Feb 2019 11:00:11 GMT
12:00:11:901 local time seems to be ok
12:02:13:618 dev /dev/ttyAMA0
12:04:23:624 dev /dev/ttyAMA0
12:06:33:627 dev /dev/ttyAMA0
12:08:43:625 dev /dev/ttyAMA0
12:10:11:867 Announced to internet
12:10:11:867 discovery server date: Tue, 05 Feb 2019 11:10:11 GMT
12:10:11:868 local time seems to be ok
12:10:26:239 GW firmware start update (device not connected)
12:10:46:085 GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10
no device specified use RaspBee (/dev/ttyAMA0)
using firmware file: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x262f0500.bin.GCF
reset target
error: bootloader not responding
device used by other application?
12:10:46:085 GW firmware update exit code 0
12:10:47:086 Wait reconnect after firmware update
12:10:48:087 Wait reconnect after firmware update
12:10:49:087 Wait reconnect after firmware update
12:10:50:085 Wait reconnect after firmware update
12:10:51:086 Wait reconnect after firmware update
12:10:52:087 Wait reconnect after firmware update
12:10:53:087 Wait reconnect after firmware update
12:10:54:087 Wait reconnect after firmware update
12:10:55:086 Wait reconnect after firmware update
12:10:56:087 Wait reconnect after firmware update
12:10:56:629 dev /dev/ttyAMA0
12:10:57:086 Wait reconnect after firmware update
12:10:58:087 Wait reconnect after firmware update
12:10:59:087 Wait reconnect after firmware update
12:11:00:085 Wait reconnect after firmware update
12:11:01:087 Wait reconnect after firmware update
12:11:02:086 Wait reconnect after firmware update
12:11:03:086 Wait reconnect after firmware update
12:11:04:085 Wait reconnect after firmware update

[AgentAnguz]

As I don't have any active setup, lights, switches or anything else, I can reset the gateway if needed.

[manup]

This looks like /dev/ttyUSB0 isn't available for some reason.

As I don't have any active setup, lights, switches or anything else, I can reset the gateway if needed.

No this does nothing especially since the connection isn't working currently.

Can you please try without the POE-hat I don't know if it matters but seems to be the only difference here?

Do you have any other USB-devices connected?

[AgentAnguz]

I have no other USB devices connected ATM no.
I'll dismount the PoE HAT later in the afternoon, getting back to you. Thanks!

[AgentAnguz]

The /dev/ttyAMA0 is the bluetooth device, isn't it? I can try and disable it.
https://community.home-assistant.io/t/disable-bluetooth/56048
(edit: added link)

[manup]

The /dev/ttyAMA0 is the bluetooth device, isn't it? I can try and disable it.

Shouldn't be a problem, the problem is the missing or not accessible /dev/ttyUSB0 interface

[manup]

perhaps another service is accessing it?

[AgentAnguz]

Perhaps. I wouldn't know. My hass.io skills are limited :)
I've not set up the /dev/ttyUSB0 in any other service though, but what's automagically polling / using it, I don't know.

[AgentAnguz]

After a reboot I get this in the logs:

12:57:13:227 found node plugin: libstd_otau_plugin.so - STD OTAU Plugin
12:57:13:227 COM: --dev: /dev/ttyUSB0
12:57:13:255 dev /dev/ttyAMA0
12:57:13:477 Device firmware version 0x260B0500
12:57:13:500 unlocked max nodes: 200
12:57:13:787 Device protocol version: 0x0104
12:57:13:811 new node - ext: 0x00212effff029d04, nwk: 0x0000
12:57:14:059 Current channel 11
12:57:14:123 CTRL ANT_CTRL 0x02
12:57:14:252 Device protocol version: 0x0104
12:57:14:443 Current channel 11
12:57:14:508 CTRL ANT_CTRL 0x02
12:57:16:725 dev /dev/ttyAMA0
###
12:57:16:729 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x262f0500.bin.GCF
12:57:16:729 GW firmware version: 0x260b0500
12:57:16:729 GW firmware version shall be updated to: 0x262f0500
###
12:57:17:030 Announced to internet
12:57:17:030 discovery server date: Tue, 05 Feb 2019 11:57:16 GMT
12:57:17:030 	 local time seems to be ok
12:57:17:031 discovery found version 2.04.35 for update channel stable
12:57:18:724 don't close database yet, keep open for 900 seconds
12:57:21:694 channel is 11 but should be 15, start channel change
12:57:22:690 network configuration NOT verified!
12:57:23:691 channel change not successful.
12:57:25:991 scan finished

So, even though it shows updated in the web GUI, the logs show it's not updates. I'll remove the HAT and get back.

[AgentAnguz]

I removed the PoE HAT and powers the RPI3B+ using micro USB. Now I can detect lights and switches. Conbee is still detected as RaspBee and it doesn't seem to work with firmware upgrade

I click the update button and the cogwheel rotates, but same firmware when it's done.

[manup]

Hmm I don't know what is causing this. Which other software/add-ons are you running?

[AgentAnguz]

[manup]

And this is only hassio running or more services?

[AgentAnguz]

It's only hassio running, yes. Did a clean install some days ago from an images downloaded specifically for RPI3B

[manup]

Hmm hard to tell what's going on here.

I've only testet the update in hassio with RaspBee, will test with ConBee but it will take a while.

It is also possible manually within the hassio deCONZ container but you would need to setup ssh debugging access:

https://developers.home-assistant.io/docs/en/hassio_debugging.html

[AgentAnguz]

I got all Philips and IKEA lights added. I added IKEA motion sensors and smart outlets as well. Went smooth. But would really like to use the PoE HAT.

[pvizeli]

The Firmware update for Conbee should work. If you attach the shell and execute the command manually it works in the same container.

The Phoscon app show also a Raspbee but I attach an Conbee and start also the doCONZ binary with --dev=/dev/ttyUSB0

[pvizeli]

I think the problem is, that the flasher sees rasbee as default device:

If I attach to the same container without change any privileged, and flash it with device option, it works:

[manup]

Normally the firmware update invoked by deCONZ tries to select the proper device and calls GCFFlasher with the related parameters.

There seem to be cases here where this isn't properly handled I'll do some tests..

[AgentAnguz]

I'm sorry, but I don't know how to attach the shell. I'm quite new in this stuff. I, however, think the updater from Phoscon should work.
I returned the PoE HAT today and got a new revision. It turns out that the first revision didn't deliver clean enough power. In revision 2 a filter was applied making the input current cleaner:
https://www.raspberrypi.org/blog/poe-hat-revision/

[RyanRayNeff]

I'm also having this issue. I'm running this alongside an aeotec z-wave stick on a Raspberry Pi 3B+ running Hass.io 87.1. The conbee was appearing as the Phoscon-GW(Raspbee). The update firmware wasn't working, so I connected the conbee to a windows 10 pc, and it was recognized correctly. I updated the firmware, then reset the device, then transferred it back to the Pi, and the problem persisted. I used the official deCONZ Addon and setup the deCONZ Zigbee gateway integration.

[manup]

The issue should be fixed now with 2.05.59, the official Hass.io deCONZ add-on (version 1.3) is not yet updated and contains 2.05.58.

Note that since you have two USB devices attached, the proper device must be selected in the configuration.

[AgentAnguz]

I can confirm the issue has been resolved in the latest version. I'm now able to upgrade and the Conbee stick is detected as a stick.

[manup]

Which version are you using? Does the device work otherwise?

The display of the device graphic should normally have no impact on functionality.

[manup]

Can you please provide the logs as shown in the Hassio Add-on.

[pvizeli]

Works fine with conbee2 on my env

[ghost]

Problem solved. Was a config error by me using the wrong device. mån 24 juni 2019 kl. 16:18 skrev Pascal Vizeli <notifications@github.com>:

…

Works fine with conbee2 on my env — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1221?email_source=notifications&email_token=AHNII5PEDZ5CTCRVT2E4YWDP4DJUVA5CNFSM4GULVOY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYNCOII#issuecomment-505030433>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHNII5MU2YBUS2LVPTMPRUTP4DJUVANCNFSM4GULVOYQ> .

[ghorsie]

I have the conbee and after changing the path to the device it now is shown as a raspbee.
The device works and I am sure that the path is correct.

I changed the path from /dev/ttyUSB1 to /dev/serial/by-id/usb-FTDI_FTi230X_Basic_UART_DM01H1DB-if00-port0. This is a symbolic link to the correct usb device which in my case is pointing to the /dev/ttyUSB1

[brettjenkins]

I've got the same issue as @ghorsie - updating firmware within the docker works fine though and everything seems to work fine

[pvizeli]

Is fixed with latest version of Add-on

[noohi]

Just noticed this issue, Conbee II is detected as RaspBee on latest Home Assistant (0.102.2 docker) + deconz (2.05.71 docker) with USB symlink.

Can I fix it manually for the vanilla Home Assistant like it was for the Hassio Add-on?

Thanks.

[galaris]

Same with home assistant hassOS 2.12 (supervisor 192), deCONZ addon 232. Configured conbee II as /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_...

shows up as raspbee

[pvizeli]

That is an issue inside deconz docker container. The Add-on work because we handle udev inside container

[sebastien-k]

I have the same issue; my Conbee II suddenly became a RaspBee last night, I can't control anything anymore. Does anyone found the solution have his Conbee II detected as a Conbee II ?

I'm using on a :

• HassOS 3.8
• Home Assistant 0.104.3
• deCONZ 5.1
• Hass.io 195

(on a Raspberry Pi 3 B+)

Thanks for your help!

[Scharunge]

My Issue is the same as sebastien-k described. My Conbee II, wich was previously detected correctly somehow appears to be a RaspBee now.

My System is also the same:

• HassOS 3.8
• Home Assistant 0.104.3
• deCONZ 5.1
• Hass.io 195
  (on a Raspberry Pi 3 B+)

only the ConBee Firmware is different:

• Firmware: 26490700

I can control my devices but every few hours or sometimes minutes all devics are unavailable in Home Assistant for some time before they are suddenly available again.

[Scharunge]

My Issue is the same as sebastien-k described. My Conbee II, wich was previously detected correctly somehow appears to be a RaspBee now.

My System is also the same:

• HassOS 3.8
• Home Assistant 0.104.3
• deCONZ 5.1
• Hass.io 195
  (on a Raspberry Pi 3 B+)

only the ConBee Firmware is different:

• Firmware: 26490700

I can control my devices but every few hours or sometimes minutes all devics are unavailable in Home Assistant for some time before they are suddenly available again.

I fixed the problem by not using /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_

but my connected Devices are still unavailable for a few seconds from time to time.

[sebastien-k]

I fixed the problem by not using /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_

but my connected Devices are still unavailable for a few seconds from time to time.

Good news.
What did you use then?

[Scharunge]

I used "device": "/dev/ttyACM0"

[xavieraijon]

I used "device": "/dev/ttyACM0"

I have same problem, and fixed using this device. Thanks!

[liudger]

I used "device": "/dev/ttyACM0"

Worked for me too. Exactly the same error. This needs fixing!

[jeanclode76]

Yes, I have the exact same problem and it really needs fixing !!!!! Using device /dev/ttyACM0 is NOT a reliable solution when you have multiple usb devices !

[Bellumatt]

Hi there!
Same issue here!!!
I connected it to the RPI4B via /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DEXXXXXX-if00
A result:

Conbee2 detected as raspbee.
Running HassOS 3.12 and got also this error message in the logs after I installed the Conbee2:
20-04-01 11:40:39 WARNING (MainThread) [supervisor.api.ingress] Ingress for QXncXpRLctIeVKeivD_ztUt8raaEFvt1hbvt9U5RalI not available

Any hints how to solve the issue??
Many thanks

[Berglund]

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]

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]

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]

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]

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]

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]

Continue in #2579