I’m posting here because my issue is related. If needed, I can create a separate thread.
When I try to modify one of my plugs, I end up with this screen:
I’ve moved the thread to a new topic.
There is indeed an error when Gladys starts
2024-01-04T11:31:10+0100 <error> index.js:16 (process.<anonymous>) TypeError: Cannot destructure property 'model' of 'definition' as it is null.
at convertDevice (/src/server/services/zigbee2mqtt/utils/convertDevice.js:13:11)
at /src/server/services/zigbee2mqtt/lib/getDiscoveredDevices.js:14:17
at Array.map (<anonymous>)
at Zigbee2mqttManager.getDiscoveredDevices (/src/server/services/zigbee2mqtt/lib/getDiscoveredDevices.js:14:6)
at Zigbee2mqttManager.handleMqttMessage (/src/server/services/zigbee2mqtt/lib/handleMqttMessage.js:36:23)
at MqttClient.<anonymous> (/src/server/services/zigbee2mqtt/lib/connect.js:64:12)
at MqttClient.emit (node:events:517:28)
at MqttClient._handlePublish (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:1277:12)
at MqttClient._handlePacket (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:410:12)
at work (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:321:12)
at Writable.writable._write (/src/server/services/zigbee2mqtt/node_modules/mqtt/lib/client.js:335:5)
at doWrite (/src/server/services/zigbee2mqtt/node_modules/readable-stream/lib/_stream_writable.js:409:139)
at writeOrBuffer (/src/server/services/zigbee2mqtt/node_modules/readable-stream/lib/_stream_writable.js:398:5)
at Writable.write (/src/server/services/zigbee2mqtt/node_modules/readable-stream/lib/_stream_writable.js:307:11)
at Socket.ondata (node:internal/streams/readable:809:22)
at Socket.emit (node:events:517:28)
at addChunk (node:internal/streams/readable:368:12)
at readableAddChunk (node:internal/streams/readable:341:9)
at Socket.Readable.push (node:internal/streams/readable:278:10)
at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
In fact, the release 1.35 reports unknown devices and therefore the Coordinator (the Zigbee dongle).
What @AlexTrovato had done allowed devices to be automatically mapped from their model. But some reported devices do not currently have a model.
I’ll propose an image to test the fix.
I’m fixing this: the model is just a simple attribute/parameter of the device; it isn’t used to map devices or their features.
It’s the « exposes » that allow building the devices with their features.
However, if the model isn’t provided, that shouldn’t cause a problem… so it’s indeed a bug…
Edit: I realize, on rereading, that the previous sentence, without the intonation, may be misleading… I really do mean ‹ thank you ›
And this is not an order!
I think there was a misunderstanding about your previous message @AlexTrovato ^^
It must have been misleading; on first reading I also thought you were making the fix, but I don’t think so after all! ^^
@cicoub13, do you already have something working? Do you have the time?
Otherwise I can take a look tomorrow — I started my Zigbee on Monday and indeed after debugging I thought the error came from the coordinator that wasn’t exposing
I have something working here (also available with the image cicoub13/gladys:fix-zigbee-discovery).
If @AlexTrovato can’t propose anything by Monday, this can fix the problem.
But it would be more interesting to benefit from the new version of Zigbee which allows controlling unknown devices (if we can map the features in Gladys).