All devices in phoscon are not reachable

[Sturmhorst]

All devices are not reachable. In Phoscon all devices are greyed out. Can not control any of them.

Deconz is located on a RP 3+ with a Raspbee Head.

[rikroe]

I had the same issue a week ago - no devices respond to Phoscon/REST API calls. Also, switches in a group don't toggle the respective lights anymore.

What fixed it for me (probably more of a workaround) was starting a device search in Phoscon and then factory-resetting/reconecting the light. They will be found and mapped to the groups but all group/scene config has to be redone. Same for switches.

[manup]

No reset shouldn't be needed.

Have you tried logging out and in again?
Also restarted the Raspberry Pi?

[Sturmhorst]

i restarted the Pi, restarted Deconz and tried the login method

[manup]

Hmm strange can you please create a backup in the Phoscon App and send it to mpi@dresden-elektronik.de

I saw in the other issue you've updated from firmware version 0x26240500, I can check that all parameters are still valid.

[Sturmhorst]

The Mail is on the way.

[eddy2501]

I have somehow the same problem....Running the Deconz app in Ubuntu 16.04LTS, REST API installed too...
After restart of my VM all lights and sensors missing in the Deconz app... Phoscon shows them but says not reachable.... Firmware is the latest.....

[fbrinker]

I had somewhat the same problem, but couldn't determine what caused this. Updated the Conbee firmware and the app (docker container) at the same time and afterwards all my devices were greyed out. But it still seemed to work right after the updates

Couldn't manage to reenable them. At the end i had to delete the old entries and paired them again (at the moment i have only one light bulb, one dimmer and one power socket, so it was no big deal).

[Sturmhorst]

manup helped me alot with this issue. Thanks

[manup]

The underlying bug is in the firmware, we're hunting this for quite a while now and have pin pointed it last week. The next firmware version will contain a fix for that.

Problem:

• The parameters: panid, network key and sometimes channel get invalid values in RAM. Likely due memory corruption, or bad initialization after soft reset.
• More dramatic these invalid values will be written to NVRAM and are applied also on further restarts.

The database file which is also part of the backup luckily logs all changes to the configuration. That's the reason the original working parameters are not lost and can be restored to get the network in operational state again without the need to reset all devices. Currently this can be done only manually.

So beside the firmware bugfix we'll add a page to Phoscon App to easily inspect and revert the configuration to a working state.

[eddy2501]

OK..
When will the new firmware be available?

[manup]

When will the new firmware be available?

Within the next two weeks.

[moritzschaefer]

I have a firmware version from the 30th of January. Should this include the fix already? I still observe the same issue. @manup how is it possible to manually restore the origional working parameters?

[SebSemmi]

I have a firmware version from the 30th of January. Should this include the fix already? I still observe the same issue. @manup how is it possible to manually restore the origional working parameters?

I have the same issue. How can I fix this manually? Would another sample backup help to fix this problem?

[manup]

Hi, sorry for the delay, tomorrow version 2.05.59 will be released which contains a simple page to diagnose and revert to previous working Zigbee configuration just a button press.

The page will just list all known previous configurations and by pressing the Load button it will be applied.

The backups which I requested in the last weeks showed that either PANID, Channel or Network key were scrambled, so if that is the case, just select the previous known working version.

This is a screenshot of the page, note the many different configurations here are just from my tests, it will look very uniform in your setups, so that invalid configurations can be easily spottet.

The actual firmware fix to prevent the issue for good is planned for 2.05.60.

[moritzschaefer]

Ok, till then I just won't reboot my Pi :)

[eddy2501]

Dumb question... How can I update my stick with ubuntu? My phoscon app says 2.05.20 is the newest

[moritzschaefer]

@manup Are there any updates on this? I would like to restart my Pi for several weeks now but don't want to fight with this bug after a restart..

[manup]

You can install the 2.05.60 version now with the new firmware.

The bug shouldn't occur anymore. Also the above mentioned new page allows fixing the config easily even if the bug wold occur :)

[butschi]

@manup Just happened to me with these FW versions:

Product ConBee II
Version 2.05.64 / 22/04/2019
Firmware 26490700

I will try to use the hidden page recovery thingy now …

… well, that did unfortunately not work. I only had one entry in the Zigbee configuration history page. I tried loading that one again, anyway. In my setup as a Hass.io addon I always have to restart the addon after such changes or the Phoscon app will be unreachable.

So, after the addon restart everything was exactly the same as before. All devices unreachable.

I also tried backing the GW up, wiping the addon and loading the backup again. Not working, either.

I guess I will have to start over, which kind of sucks, because I just did exactly that, because I could not pair more Ikea remotes. The second time everything worked pretty good.

Not sure if it matters, but one thing I did is: besides mostly Ikea stuff, I also have a Hue bulb, that I could not pair, even after resetting it. So, I went in the old webapp and tried the Touchlink reset thing, which could not find the bulb. I might have done a few other things, but before that everything worked fine and after that the problem occurred.

[manup]

The above bug was only related to ConBee and RaspBee not ConBee II.

Starting from scratch usually shouldn't be needed. Does the log shown anything useful?
Is the firmware shown as connected (aka the firmware version) in Phoscon App > Menu > Settings > Gateway?

[butschi]

The FW version was shown just fine, the logs did not show anything that helped me, anyway.

What I did was what @rikroe suggested and repaired all lights and switches without removing them. The group configurations worked like before but I had to redo all the scenes, just like he experienced, as well.

If it is helpful I can hook you up with a before/after backup of the gateway.

[bhansson]

Same problem here, had to remove and pair everything again. Where do I find that new page to restore previous settings?

Product ConBee
Version 2.05.64 / 4/22/2019
Firmware 260B0500

[manup]

Where do I find that new page to restore previous settings?

Currently only described in the respective release note:

https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/V2_05_59

Product ConBee
Version 2.05.64 / 4/22/2019
Firmware 260B0500

I'd recommend to upgrading your ConBee firmware to 0x26330500 to prevent the problem happen again. If the update isn't shown in Phoscon App > Menu > Settings > Gateway you can update it manually:

https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Update-deCONZ-manually

[lordkev]

This happened to me as well with a ConBee II after rebooting the Pi running Hassio. Haven't been able to figure out how to get them back and I've already had to re-add everything once from the same thing happening. Resetting 15 bulbs every time I reboot isn't really an option...

Running the latest 0x26490700 firmware already on the ConBee II and these are all standard Hue lights if that makes any difference.

[jordyverbeek]

I have the same problem with ConBee II.
Firmware: 0x26490700
All lights are grayed out. The only error I see in the logs is about Invalid admin password hash.

Any news on this ?

[Smanar]

Have you tried a previous backup, if you can ?

[jordyverbeek]

I have the same problem with ConBee II.
Firmware: 0x26490700
All lights are grayed out. The only error I see in the logs is about Invalid admin password hash.

Any news on this ?

This started happening after I rebooted my server. My OS messed up the ACM assignments, so deconz and zigbee2mqtt were both listening on /dev/ttyACM1. Problem had nothing to do with deconz.

[sberryman]

Where is this hidden page? I'm having the issue where all devices are listed in PWA but unreachable. Happened spontaneously yesterday. I have managed to add another (new) device which connects fine so it has to be some id changing.

Product: RaspBee
Gateway: 2.05.66
Firmware: 26330500

Edit: Found the instructions in the release notes for 2.05.59
https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/V2_05_59

[edtwodth]

I have the same problem now with Deconz now ... Conbee II, firmware 264A0700, hassio, raspberry Pi 3 b+

Just installed hassio today and started from scratch, after abot 2 hous alle lights where greyed out ...

The alt+click didn't work

[moritzschaefer]

I get

/usr/bin/GCFFlasher_internal.bin: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.28' not found (required by /usr/lib/libwiringPi.so)

when I try to update the firmware as described here https://hub.docker.com/r/marthoc/deconz/

[mountainsandcode]

Have had my setup crash two times while running Deconz through Docker on a Synology DS with Conbee II. Setup becoming inoperative upon any shutdown/ halt/ reboot/ power loss. Using the same hardware and setup on a Raspberry Pi (installation in Raspbian) WITHOUT docker I have no issues, even with power losses or shutdowns.

Probably makes sense if we try to standardize the reporting here to see if there is some sort of issue, e.g., while using docker

[thenightfighter]

Same shit here... unbelievable that this bug is there for a year now and still not fixed...

[ultimateguy]

I got my setup up and running. I'm not sure if this will help anyone but figured I would share just in case.

I have another USB stick on my Raspberry Pi in addition to the Conbee II. That other stick is a HUSBZB-1 that I use for my Z-Wave devices. The device path for my Z-Wave integration in Home Assistant was set to something like /dev/ttyAMA0. Problem is that Linux does not have a set order in which it loads USB devices on boot, so that device path will not always point to the same device if there are 2 or more USB devices connected.

I reconfigured BOTH the Z-Wave stick and the Conbee II using their "by-id" paths instead of the generic /dev/ttyAMA0 type of path. These can found by going to the Home Assistant UI -> Hass.io in the sidebar -> System tab -> Hardware.

The Conbee II path looks something like /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2126718-if00 and the HUSBZB-1 path looks like
/dev/serial/by-id/usb-Silicon_Labs_HubZ_Smart_Home_Controller_513000FF-if00-port0. (There is another identical entry ending with if01-port0 for the Zigbee part of the HUSBZB-1, which I'm not using.)

This works so far. Hard rebooted and Deconz is still working. Fingers crossed that it stays this way.

[sverleysen]

I also use the by-ID path but I still have the issue.

[psanwald]

I ran into the same problem. Greyed out Zigbee items without functionality. Also the Raspberry is hanging on reboot/shutdown. After a while I have to pull the plug, to get the system up and running again.

Version 2.05.72 (12.12.2019)
Firmware 264A0700

[GreyEarl]

Same here. Devices unreachable, though I can reboot the gateway to get the sensors working again. Sensors will initialy be greyed out, but after the first report of each sensor they will displayed as online.

Conbee II on Raspberry 3B+

[xmaska]

I did face with the same issue after an electricity outage.

• All devices were listed but as 'not reachable' in the Phoscon page
• I have xiaomi sensors (Aqara window and weather) and OSRAM on/off sensor
• forced updates from sensors did not help
• restart of my Raspberry PI 4 and Conbee II did not help
• backup / restore from Phoscon did not help

I have ended up re-pairing all my devices. It was a real pain and I believe this makes this device almost useless. I did now a fresh backup after all this, next time I'll try to restore this one.
I might try to reproduce this case before adding new devices. If this won't be fixed I'll buy a (much cheaper) MQTT device and forget about Conbee.

Let me know if you need any further details. Thank you!

[psanwald]

For the moment I have learned the following "rules" in this situation:

1. Never, ever reboot a working Phoscon system (use a ups and hope they might fix this bug soon)
2. Don't panic when all actors are suddenly disabled. After a few new searches and re-pairing of one or two items they might all reconnect automatically.
3. If the phoscon app tells you, there is no contact sensor x, but the deCONZ Adapter in ioBroker says, there is one, ioBroker is always right ;)
4. ZigBee is a mesh and your controller is the center. Always remember, to begin pairing with the closest, "always on" devices.

Following these "rules", I got a nice running conBee-Phoscon-system connected to openHAB and ioBroker with Osram Sensors/Lights, Paulmann LEDs, Schwaiger Door Sensors. It is very fast and way more reliable than my CC2531-network, that I run parallel.

[Homee-BC]

The problem seems to persist. Today I have sent a mail to the support. But it is more than frustrating that there is no solution from the manufacturer, because the issue has been around for a long time.

If there is no solution from support I will reset the device and send it back to the manufacturer, which is a pity, because until reboot the device is great - but only until reboot.

Are there any news about that issue?

[xmaska]

I had a couple of power outages and this issue seems not happening anymore. First time I did reset the device and added all my sensors and switches back and made a fresh backup. Not sure if this helps anyone but maybe worth a try doing the boring part from scratch once more. On long term I will get a UPS...

[Homee-BC]

Update:

I have now once again dealt with the problem.
Reboot of the container no problem, reboot of the Raspberry no problem either - as long as the ConBee 2 stick is powered.
But if you unplug the stick or shut down the machine, the problem occurs.

The tactic to get a running environment via the backup fails completely. Lights are there briefly - but not controllable - and then after about 2 minutes they are gone again.

My firmware: 264A0700

Why is there no reaction from the manufacturer?

[eche86]

Hello,

I have the same issue. Just after setting up all lights and define the automations everothing works fine. But as soon as you restart the Raspberry starts the issues. The main issues is some lights dissapear and even you restarts the deCONZ component. The only way is set up it again.

Where is the problem? in deCONZ component or Phoscon software?

deCONZ: 5.3.2 (FW 264A0700)
HassOS 3.13

[AnthonyMavic]

Exact same issue here.
I'm running everything with docker-compose and had to restart it.
All sensors but one were unreachable. I've tried to load a backup file, then all devices were gone unreachable.

I'm seriously disappointed.

software: 2.05.75
firmware: 264A0700

[fume68]

Same issue here.

Debian amd64
Docker
software: 2.05.75
firmware: 264A0700

Hope for "killing" this bug quickly

[andreasscherbaum]

Have the same issue, it's a new Raspbee II, current firmware. After a reboot it forgets all devices and I have to re-learn all of them.
The device is running on a Raspberry Pi B+ with Raspbian and all updates are installed.

[Mimiix]

I'll make sure this gets looked into.

For everyone mentioning issues with HA and the .77 update: Please reffer to #2875

[andreasscherbaum]

@Mimiix Let me know if I can help debugging this.
Currently I have this setup on a dedicated Pi, and it's not yet "in production".

[Mimiix]

@andreasscherbaum On the 0.77 issue? There's a dedicated channel on Discord. Feel free to join that. @manup is there too!

[andreasscherbaum]

@Mimiix On getting the issue with losing devices revolved.
You got a link to the Discord channel, please?

[Mimiix]

https://discord.gg/vj7QAGM

[Mimiix]

As this seems stale, i will close this issue.

However, if you still have this issue i would like to invite you to open a new issue

[lordkev]

50 comments of people having the same issue. No fix indicated. Then closed as stale. Interesting... Not that I particularly care anymore. I ditched deconz long ago for the very reason that this was never even looked into.

…

On Fri, Jun 26, 2020 at 1:57 AM Dennis D ***@***.***> wrote: Closed #1185 <#1185>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEGDEHL4IV2IPFGVSJEZK3RYRBEPANCNFSM4GSQ6PSQ> .

[Mimiix]

@lordkev

50 comments of people having the same issue. No fix indicated.

As i've learned from other issues: hardly every issue is the exact same. That being said, we need information on each case. I recently closed a issue like this and 2 people opened a seperate case after it. After getting their information their cases were similar in the fact they didn't update anything, but other than that the issues weren't the same.

Then closed as stale. Interesting...

Fixing stuff works both ways in this kind of stuff. DE needs information to do so.

Not that I particularly care anymore. I ditched deconz long ago for the very reason that this was never even looked into.

I can't argue that. That's why i reached out and opened to help and make sure everyone get the help they need. Now i am trying to fix stuff.

I would like to ask you in this case: Please leave emotions out as it won't bring us anywere. If you still need any help, please open another issue and i'll make sure it gets sorted.

[pjcarly]

Why open another issue, when you could just leave this one open?
The above issues aren't resolved and plenty of people (me included) are having the same problems.

[Mimiix]

@pjcarly As i've mentioned in my previous comment:

As i've learned from other issues: hardly every issue is the exact same. That being said, we need information on each case. I recently closed a issue like this and 2 people opened a seperate case after it. After getting their information their cases were similar in the fact they didn't update anything, but other than that the issues weren't the same.

I've had a discussion about what you mention here

Down the line: Not one issue is the same. If the issue is the same, it is easier to merge those people into one issue. This issue is from 26 jan 2019. Meaning it has been open for exactly 1 year and 5-6 months. Stuff changed. Not only on deCONZ end but also on your local hardwares end.

If people open their own issues with all related information , which is asked in the bug report templates, it's easier to find structural issues.

[psanwald]

@lordkev Please, update your phoscon system to the latest versions as described here:
Version 2.05.78
Firmware: 26580700 (for conbeeII)
You will see, that the behaviour of losing the devices changed in the meantime. It may be not completely solved, but the guys behind the software need information about current problems in this matter. If you still experience problems, you are free to open new issue. But this one is just plain deprecated. I think, Mimiix decided right to close this case.

[pjcarly]

After talking on Discord for a few minutes a possible solution to my issues were presented.

Apparently firmware updates do not work through a Home Assistant Add-on, and because of that i'm still running an ancient version of the Conbee firmware, which is probably the reason for the unreachable devices.