homebridge-z2m: [Bug] problem after upgrading zigbee2mqtt to 1.35

Just promoted v1.9.3-rc.0 to a regular release (v1.9.3) and pushed it to the latest tag.

I’ll merge it back to master now and start working on making a v1.11.0-beta.3.

For me the “workaround” of @Veldkornet seemed to work -> https://github.com/itavero/homebridge-z2m/issues/794#issuecomment-1873518037

I’m back on Z2M 1.35.0 but with the “Coordinator” device exluded in the homebridge-z2m plugin in homebridge.

EDIT: mrmaximas was a little bit quicker, but same solution 😃

Seems like I introduced another bug on the master branch earlier this week, so no new beta just yet. I expect it will be relatively easy to solve, just a matter of finding some time to do so 😅

Update: The thing I thought to be a bug, actually wasn’t a bug… I’ll probably be able to push a new beta release later today.

Just published v1.9.3-rc.0 to NPM.

I believe this should solve the problem, but unfortunately I don’t have time to update Zigbee2MQTT on my production environment now to test it with the latest Zigbee2MQTT release.

If you tried it (can even be on a separate machine connecting to the same MQTT broker that your production environment is connected to), let me know if it works without the aforementioned workaround.

I just installed version V 1.9.3 rc.0 everything seems to be OK. Thank you

Got this from the log from @mrmaximas. It seems that the supported flag changed.

{
  "definition": null,
  "disabled": false,
  "endpoints": {
    /* lots of endpoints */
  },
  "friendly_name": "Coordinator",
  "ieee_address": "0x00124b002a1aa3c4",
  "interview_completed": true,
  "interviewing": false,
  "network_address": 0,
  "supported": true,
  "type": "Coordinator"
}

Probably I made the assumption when writing the plugin that supported devices would always have a device model, which might no longer be true.

Just published v1.9.3-rc.0 to NPM.

I believe this should solve the problem, but unfortunately I don’t have time to update Zigbee2MQTT on my production environment now to test it with the latest Zigbee2MQTT release.

If you tried it (can even be on a separate machine connecting to the same MQTT broker that your production environment is connected to), let me know if it works without the aforementioned workaround.

works here too, great work 👍

I just installed version V 1.9.3 rc and removed the workaround. Everything seems to be back to normal.

thank you very much for your responsiveness and this quick repair.

v1.9.3-rc.0 works fine with the workaround removed. Many thanks.

Just published v1.9.3-rc.0 to NPM.

I believe this should solve the problem, but unfortunately I don’t have time to update Zigbee2MQTT on my production environment now to test it with the latest Zigbee2MQTT release.

If you tried it (can even be on a separate machine connecting to the same MQTT broker that your production environment is connected to), let me know if it works without the aforementioned workaround.

You can remove it from the “cached accessories”

Homebridge GUI -> 3 dots at the top right -> Homebridge Settings -> Remove Single Cached Accessory (almost at the bottom of the page)

This worked for me, all up and running again!!

Thanx

You can remove it from the “cached accessories”

Homebridge GUI -> 3 dots at the top right -> Homebridge Settings -> Remove Single Cached Accessory (almost at the bottom of the page)

I have also problems after upgrading to 1.35 that seem to be connected with homebridge-z2m.

The issue is still present with v.1.11.0-beta.3, here are the logs from zigbee2mqtt:

@nefh This is an issue in Zigbee2MQTT. Not the issue being discussed here.

From what I can tell it’s also not caused by homebridge-z2m. It just gets more visible because the plugin starts requesting information from devices (like blinds).

Thanks for the feedback. I’ll try to make it a “regular” release and to merge it into the beta versions later today.

Just published v1.9.3-rc.0 to NPM.

I believe this should solve the problem, but unfortunately I don’t have time to update Zigbee2MQTT on my production environment now to test it with the latest Zigbee2MQTT release.

I have Zigbee2MQTT 1.35.0 and after updating homebridge-z2m to v1.9.3-rc.0 the issue was solved without any further change!

Thank you @itavero for the quick fix! 😄

Anyone here that’s still running v1.9.2 of the plugin thats willing to try a version that should include the fix for this?

Still need to make that release though, just checking if someone’s up for it.

Based on earlier findings I’m pretty sure it will fix it, but it would be nice to get some confirmation from others.

For me, I noticed that there was a new “Coordinator” device added after the new z2m release. I just added this to the excluded devices in the HomeBridge plugin settings, and then it started up fine.

Hey, same issue for me. I was on v1.9 and upgraded to 1.9.2. Why are you on 1.34? I can even select this in the child bridge “version tab” However, once I go back to 1.9 or any version below, I have still the same issue. Somebody has an idea why this is the case?

I’m talking about the Zigbee2MQTT version - not the Homebridge version and not the homebridge-z2m version. The issue probably lies in a change done in Zigbee2MQTT as referenced to a couple of posts above.

Oh sorry, didn’t catched that. Thank you!

Rolling back to zigbee2mqtt 1.34 fixes the issue … so it’s for sure related to the new release. Support was added for “unsupported” devices to have basic functionality working even if it is not officially supported by zigbee2mqtt.

Same problem with Profalux devices

How to roll back to 1.34 ?

Thank you

Depens on your setup … I have all running in containers so just change the tag from “koenkk/zigbee2mqtt:latest” to “koenkk/zigbee2mqtt:1.34.0” did the trick for me 😃

If you’re not running it in containers it might be more difficult…