-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing to control zigbee devices after update to herdsman 2.1.9 with no error raised #1294
Comments
Hello, |
@juergiboy Are you using the iobroker zigbee adapter or zigbee2mqtt.io ? |
@asgothian I am using both at this time. |
But the error itself you described only affects the zigbee adapter ? I would love to know if a similar error also affects zigbee2mqtt.io installations which move from an older version with the 0.4.x herdsman to installations with the 2.1.9 herdsman. |
@asgothian Yes, the error affects the zigbee adapter. |
A. |
Make sure you read the change notes for the devices which have changed since then. There are quite a lot of devices which have significant changes in their message structure. |
Hello,
I have again a strange issue, which affects a number of installations using the cc2531 / cc2538 coordinators. I have been trying to catch it for about 2 months now, but never had direct access to an affected installation. Now I do.
The situation is:
I have a working installation with a cc2538 using zigbee-herdsman 0.41.2 with approx 30 devices (good mix of routers / end devices where communication to the devices work flawlessly.
After an update to the current stable zigbee adapter, which uses zigbee-herdsman 2.1.9 and latest 20.x zigbee-herdsman-converters, the system does no longer work properly.
The coordinator receives messages from the zigbee-network as before. All devices can report their status changes, and remotes will work as intended. But it no longer sends any data to the devices. It is impossible to control any device, open the network, etc. What confuses me is that no error is raised, the code simply stops, as is visible in this example of log messages:
Trying to set a state on a plug with the zigbee-herdsman 2.1.9 on an old database:
Note that no error message appears before the next attempt to switch the device is made (last log entry)
Below is another test I made after some manual intervention.
This is the same device, using the same hardware (coordinator, computer) with the identical code as the one above, and identical network parameters (PanID, ExtPanID, Channel, TransportKey). The only thing which was done was to start the instance with no devices to generate shepherd.db and nvbackup.json, then stop it, copy the entry from the shepherd.db for this device from the shepherd.db of the 'nonworking' instance to the new instance, before starting it again.
Note that the message with the tag ELEVATED O05 comes approx 280 ms after the message tagged ELEVATED OX. The following ELEVATED I.. tagged messages show the response from the device - with this instance, I am able to control the device.
Here is the appropriate code:
Note how the only call between the two messages is the call to convertSet ?
I have to admit that I am completely at a loss as to what is causing this, but there are a significant number of installations out there using the cc2538 coordinator still, and I would love to be able to offer them a way to retain their zigbee Networks while migrating to the current zigbee-herdsman and converters.
A.
p.s. these tests are made with 2.1.9 due to the fact that 3.0 and the converters 21.x introduce changes to a large number of devices which requires a significant amount of work before I can move to this.
The text was updated successfully, but these errors were encountered: