Zigbee2mqtt 1.35 - Error displaying devices

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:


As a result, I don’t dare delete the plugs…
Yet, everything seems to be working…
![Screenshot_20240103_220034_com.android.chrome|

I have the same message, indeed.

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)

I’ll look into that tonight.

1 Like

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.

2 Likes

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…

1 Like

Thanks. I had a fix ready but you know how it works better. I can test and review if needed.

1 Like

Thanks for looking into this!

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!

5 Likes

I’ve noted the issue with returning from leave.

Thanks for looking into it @cicoub13 @AlexTrovato :slight_smile:

Let me know as soon as a PR is ready for review!

Sorry, but I can’t guarantee quick availability…

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).

1 Like

Thanks @cicoub13 for the fix!

Can you make me a PR?

PR from @cicoub13 here: fix(zigbee2mqtt): Filter unknown models by cicoub13 · Pull Request #1997 · GladysAssistant/Gladys · GitHub
I think he closed it because of the misunderstanding ^^

Ok thanks @Terdious, I’ve reopened the PR!

If the tests pass, I’ll merge it into master

1 Like

Hello. Yes, sorry. That fixes the problem :+1:
@AlexTrovato had a smarter fix. That can come later.

1 Like

It’s merged and tested on my machine :slight_smile: Thanks for the fix @cicoub13, it works perfectly

Gladys Assistant v4.34.0 is being built

5 Likes

For info Gladys Assistant v4.34.0 was successfully deployed yesterday and I confirm that it does indeed fix the issue! :slight_smile:

Thanks @cicoub13 for the fix!

6 Likes

je confirme, all it s ok !

1 Like

I confirm as well!! I was able to install my 2 Zigbee setups and pair them together like a POD!! ^^

Thanks @cicoub13 for the quick response!!

1 Like

Same here, thanks :folded_hands:

1 Like