Hello everyone 
I’m bumping this post to try to unblock the situation. With @lmilcent on vacation, does anyone have Zigbee at home and could test @AlexTrovato’s PR, particularly the behavior with wireless buttons?
For my part I’d really like to, but you’d need to be able to configure your own MQTT server because when everything is in production you can’t test on another instance.
You have to admit it’s not easy to test.
I admit that, like @VonOx, I don’t know where to start to test without risking breaking production for the duration of the test…
- If we shut down production for the duration of the test? Will the config be restored?
- Is it better to make a copy of the current production SSD and test?
- Does it only affect certain types of buttons? For my part I only have simple buttons / presence detectors / door tags, is it worth testing?
Same question as Thomas.
As for me, I only have a SNZB 01
Indeed these are real questions — if it’s hard to test, nobody tests and I completely understand you! I wouldn’t know how to answer, you’d need to check with @AlexTrovato or @cicoub13.
Would someone like to take the lead on this topic? (Set up a clear protocol for testing Zigbee2mqtt?)
To come back to the original subject, if the conclusion is that we’re not ready to release these Zigbee2mqtt improvements in the short term, I propose reverting the commit Zigbee2mqtt : Handle custom device mappings (#1383) · GladysAssistant/Gladys@8581d2e · GitHub to unblock master. Then, @AlexTrovato I suggest you open a PR that includes all the Zigbee2mqtt improvements (this commit + your button fix), and that we do more intensive testing once someone here has put in place a non-breaking test protocol. We’ll merge later when it’s ready.
What do you think?
Because on my side several of you tag me on topics asking when there will be a release of various fixes, and in the meantime I’m powerless and stuck 
1 Like
And wouldn’t backing up the DB and all the devices via Gladys Plus be a solution?
No, because the Zigbee2mqtt integration is not currently able to recover on its own after a restore.
Yes, I’m talking about this thread.
Ok so, following @_Will_71’s post, you think that by just retrieving these files we’re good.
Listen, that needs to be confirmed. I’m ready to test it as well; my zigbee2mqtt setup isn’t critical at the moment.
Maybe it would be best to create another topic to talk about that famous Zigbee2mqtt test protocol?
Can someone take the lead, and we’ll keep this topic to discuss @lmilcent’s original bug.
1 Like
@AlexTrovato Did you compile a recent image?
Good evening,
Here are the tests I carried out.
Shutdown of my RPI (Raspberry Pi) that runs Gladys in production. I then retrieved the SONOFF Zigbee dongle and plugged it into an old server running Ubuntu.
I installed @AlexTrovato’s image (I hope it’s the right image to test) and reimported the Gladys database from my RPI as well as the zigbee2mqtt files.
Then I started Gladys, checked the logs and started the z2m service and I successfully recovered all my devices without needing to re-pair them.
I tested my Xiaomi button and here are the values it returns
1 click => 1
2 clicks => 2
long press => 5
I put my Zigbee dongle back on my RPI, restarted and I get the same values on my button
1 click => 1
2 clicks => 2
long press => 5
Let me know if you need any other tests.
3 Likes
The image is atrovato/zigbee2mqtt. It contains the small fix for the click button.
Thank you!!!
1 Like
Hi @_Will_71 and thanks a lot for volunteering to test!
Great that it’s working
@AlexTrovato since this test is successful, are there any other things left to test? Are you confident that for the rest it’s safe and that there are no risks to deploy this to production now, or do you prefer the revert-the-commit + more testing approach?
1 Like
@pierre-gilles, with pleasure — I’ll try to contribute as much as I can for now 
1 Like
I’m fairly confident. There’s still work to do on z2m, but these changes allow all binary devices to work, since z2m provides different behavior for each device.
1 Like
Ok, I trust you then 
Edit: It’s merged!
1 Like
It’s deployed!
2 Likes
So I’m not sure that @lmilcent’s mapping issue only concerned the wireless switches. Since upgrading to v4.8.4 my contact sensors are working backwards and as a result they break my open-detection scenes.
In the image below all my windows are closed but I have the icon showing the window open!
Below is the value in zigbee2mqtt
1 Like
Yep, me too, it’s the same as you @_Will_71
It’s reversed.