Do you know how long a coordinator remembers devices? Is there a way to reset its memory?
You mean a Zigbee sniffer log? Do I need special hardware to create that? Or can I get it from the coordinator somehow?
It doesnāt really do this for long - it depends on the type of device, and aging policy, but in general the coordinator stores little information about the device.
The ZigBee framework does cache information though - otherwise the binding would have to rediscover devices each time.
To me, it looks like there is no communication, and the devices are not there, or the coordinator has been reset, or the network configuration changed. PRobably you should just reset everything, clear the cache (in the userdata/zigbee folder) and start again.
Yes.
You need a zigbee dongle with appropriate firmware. Most Ember firmware will be fine.
No.
That would mean a second dongle than, right?
Yes. As I said above - you canāt get this from the coordinator, so a second dongle is therefore required.
How do I reset the coordinator?
Isnāt there an option in the coordinator configuration to do this? I donāt have this in front of me, but I thought there was an initialise option?
You are right, it was hidden behind the āshow advancedā checkbox.
Iāll try a reset and empty the cache. But first I need some coffeeā¦ 
1 Like
I think ticking this ought to also clear the cache as the framework does clear the device database, but it doesnāt hurt to be sure
I reset the coordinator, removed the cache directory (that didnāt happen automatically), rebooted the Rapsberry Pi where OpenHAB is running and the Ember stick is connected to.
Unfortunately, I got the same resultā¦ 
I guess Iām running out of options. Itās really frustrating. Things were just running fine for years. Nothing has changed, apart from the upgrade to OH3ā¦
Well, OH3 is nearly exactly the same as OH2.5 - the binding was just migrated across a month or so before OH3 release. The ZigBee libraries that communicate with the network and do all the discovery are exactly the same version in both, so I donāt think this is a factor. It is more likely that when you migrated, and started the OH3 instance, that the coordinator has been reset and the network need to be re-established.
Unfortunately thereās not really a lot more I can add though unless thereās more information - sorry.
I hadnāt updated my setup for more than a year. So, there still might have been changes in the mean time.
I understand. I appreciate your help so far. Iāll keep trying to re-establish the network somehow. Iāll update this thread if thereās something new worth mentioning.
Sure - there will have been some. Weāve improved quite a lot the performance to support some commercial systems with input from Silabs, but I doubt that this will have been the cause of your system not working when changing to OH3. If there was a problem with OH3 binding that meant systems didnāt work, I would have expected to see a load of threads like this from many people.
1 Like
After some more trial and error, I got things working again. Hereās what happened:
After the upgrade to OH3, there were errors in the log about initializing the Zigbee binding. Some casting error, a string could not be cast to a BigDecimal ore something like that. I figured it could be one of the values in my Thing definition. It looked like this:
Thing zigbee:coordinator_ember:stick "Zigbee USB Stick" [zigbee_port="/dev/ttyUSB-Zigbee", zigbee_baud=57600, zigbee_flowcontrol=2, zigbee_childtimeout=864000, zigbee_concentrator=0, zigbee_meshupdateperiod=86400, zigbee_panid="HEX", zigbee_extendedpanid="HEX", zigbee_networkkey="HEX", zigbee_powermode=1, zigbee_txpower=8, zigbee_initialise=false]
(I replaced the hex IDās with āHEXā for security)
I thought the zigbee_panid might be the problem. So I converted the hexadecimal number to a decimal number and saved the .things file. I thought that would solve the problem, but it didnāt. I couldnāt find the cause and decided to delete the .things file and to create a new coordinator via the UI, as recommended as per the new OH3 docs. I noticed the old one still showed up, albeit āuninitializedā. I figured it should have been gone after I deleted the .things file, and couldnāt explain why it still was shown in the UI. But I decided to ignore it and continue.
Then came the part where I wasnāt able to discover any devices.
Somewhere along this story, I discovered that the openHABian upgrade process hadnāt upgraded the Samba shares. I use those to edit the configuration files via Visual Studio Code on my local machine. (The recommended way.) The shares still pointed to the old location: /etc/openhab2, while the files are now located in etc/openhab. I fixed that by manually editing the /etc/samba/smb.conf file. That was yesterday.
Only today I realized that I had been editing the wrong file when I was fixing the panid. And I also realized that was the reason why the old Zigbee coordinator was still showing up in the UI: the file was not deleted.
So, I decided to deleted the UI-generated Zigbee coordinator, and try to get it working via the .things file once again. I again converted the panid value to a decimal value, removed the "'s and had my old coordinator online within seconds. I had to re-discover all my devices, but once they were re-discovered, they were working again.
Thereās one question thatās still unanswered: why did the UI-generated coordinator not work as expected? There might be a conflict with the (still present, but offline) coordinator from the old .things file. Thereās only one difference in configuration I saw: I set the UI-generated coordinator to āAllow all joinsā, but the coordinator that is generated from the configuration file is by default set to āAllow only secure joiningā. I think this is only relevant for Zigbee 3.0, but maybe it is of influence.
TL;DR:
- openHABian migration from 2.5 to 3 doesnāt update the Samba shares.
- apparently, in an old version, hexadecimal strings were accepted as
panid, but they arenāt anymore.
Suggestions for improvement:
- Make openHABian migration update the Samba shares
- Document the changed behaviour of the
panid, or accept both decimal numbers and hexadecimal strings
Actually for Things I believe the UI is the only supported way. You are on your own for a text file due to the chances for errors.
Thatās an unreasonable statement, a few days after the release of 3.0. In 2.x it was not possible to do it via the UI. And now, all of a sudden, the way it was for years is āunsupportedā?!
A lot of binding docs, at least those of the Zigbee binding, still only document how to use the config files.
I think it is an easy change to the docs. If someone can tell me what the exact behavior of the binding is w.r.t. panid is (and can confirm that this changed in the past), Iād be happy to make a PR for the doc update.
I have done the coordinator with the UI in 2.X. I tended to use HABmin but the Paper UI would work too. Like the Z-Wave binding, you manually add the Coordinator You then edit to set the port & other valuesā¦
I have never defined Things manually.
You shouldnāt expect that everything is the same in OH3 as it was in OH2. Features will be removed, and some added - I donāt think itās unreasonable to do that as a product evolvesā¦
However, in this specific case, I believe it is possible to use text configuration files in the same way as in OH2. Note that if you are using things files, the file format, and the format of integers for example is not something the binding has control over so Iām not sure documenting this in the binding docs is the best place? The binding will just receive an integer - not a string - and any conversion from whatever is in the file, to the integer is done by the core.
1 Like
Absolutely incorrect. Things can still be defined/configured via files.
Only part missing is the import feature like implemented for items.
@chris I think this proves that the binding documentation is the right place. As a user, I donāt mind that the implementation is that the binding gets an integer. I just want to configure the binding. And ideally, I donāt want to read three different documents to figure out how to do that. So, from a userās perspective, some redundancy in the docs might be a good idea.
About my statement about being āunreasonableā: yes, I know software evolves over time. Thatās a good thing. But it is good practice to deprecate stuff first and make it unsupported later and then eventually remove it. Going from the primary -and in case of the Zigbee binding the only- way to being unsupported in one step - thatās unreasonable in my opinion. And by the way: I did get my setup working again by going back to that āunsupportedā things file! I didnāt get it to work via the -recommended- UI.
I was mistaken. It is still supported according to those more expert than I.