@Ruurd_van_der_Noord many Thx 4 your donation! 
Hi,
Forgive me if this is my ignorance, but I have a 2 gang switch that is controlled via z2m, I wish to expose each rocker as separate devices. My understanding is that I create a group in z2m, with the endpoint selected, then add the group into homey.
The device itself has two endpoints, state_left and state_right but the group has one endpoint - state. (using MQTT Explorer, I changed the value to “OFF” and see its publishing “state”:”OFF” to the group topic)
When adding the group into homey - it seems to be loading the exposes from the device rather than from the group (so it sees two buttons) - so when I toggle through z2m directly it sets “state” to OFF or ON. But when toggling though homey its toggling “state_right” OFF which is causing a “z2m: No converter available for ‘state_right’ on ‘hall_right’: (“ON”)” error
hall_right = {“state”:“ON”}
set = {“state_right”:“OFF”}
Therefore fails.
Am I missing something? Or is there a better way to do what I am asking?
Hi @flubster
To me it sounds a bit peculiar when you’re ought to configure it with additional “group” settings or such;
Can you show it’s entries from the z2m device “Exposes” tab?
Like this one, a 3 - socket switch:
I am curious if it doesn’t show switch A and switch B by default, for example.
My 3 - socket switch (‘powerstrip B’) shows like this in MQTT Explorer:
New version 3.1.7 ready for testing:
- Fix re-connect devices.
- Fix translations.
New version 3.1.8 ready for testing: Zigbee2MQTT | Homey
- Aad many flow cards for switches (Thx @dohun0310)
- Add light transition duration support (Thx @march5350)
- Log unmapped capabilities only once
- Increase max devices to 1.000
- Stability improvements
@Jomaro Many Thx for your donation. Much appreciated! 
v3.1.9 is ready for testing:
- Added weather station support
- Added L&S lighting support
- Added curtain class mapping
- Added Aqara E1 curtain driver capabilities
- Fixed offline device trigger card
- Fixed MQTT pairing and reconnects
- Homey compatibilty >=12.11.0
Thx @OH2TH and @march5350 for their code contributions!
Hello everyone,
I’m having an issue with duplicate access to my Mosquitto via Docker. I suspect this might be related to the latest update, as I didn’t have this problem before. Perhaps there’s something wrong with the Mosquitto Docker image, but I think the problem lies elsewhere. The following is a new issue; to be more precise, it is no longer possible: After switching my entire Zigbee network to Zigbee2Mqtt and integrating it into my HP23, everything was running quite stably until a few days ago. In parallel, I have an SHS running, which is intended to replace the HP23 in the medium term. Here too, I had already set up access to Zigbee2Mqtt via a Mosquitto bridge. Since the update, however, one of the two connections keeps dropping out. The Docker log shows that both bridges are using the same name, i.e. the Mosquitto Docker regularly kicks one of the two bridges out. The only solution so far has been to delete the bridge on the SHS.
I think the two Homey instances – Homey HP23 and the SHS – need to have different names (which were generated from the IEEE-Adresse) for the bridges. However, I don’t know how to rename the bridges, as the naming seems to be handled internally within your app.
Does anyone have any idea how this could be fixed?
Thanks in advance.
I can confirm this issue after latest update… my setup also homey pro 2023 and a homey self hosted..
Hello Seinuh, thank you for confirming the error.
Come to think of it, however, the error might have existed even before the update, provided that the bridge names were already being derived from the IEEE address at that time. It’s just that I – or we – didn’t notice it because Robin Gruijter hadn’t yet explicitly developed or programmed the bridge connection’s self-healing capability. Perhaps, but never mind. The error certainly exists and, in my opinion, is based on the bridges having identical names.
One possible solution would be for Robin Gruijter to implement an option that appends an additional or freely selectable identifier, or the name of the Homey, to the bridge names. That would solve the naming problem at this time.
Another solution for me would be to set up a second Mosquitto Docker instance that listens to the first Mosquitto and mirrors it. Then the SHS could listen to the second Mosquitto, which would then run on port 1884, for example. However, it would probably be simpler (for me) to adjust the names of the bridges to some extent.
Best regards
Update: I’ve now set up a second Mosquitto instance as a Docker container for the SHS. This one is running on port 1884. I set up a new bridge to it in the SHS, and, hey presto, I re-paired 1–2 devices via Zigbee2Mqtt, and it’s working again.
I think, however, that this can or should only be a temporary solution for the moment.
Edit: You don’t need to re-pair the Zigbee2Mqtt devices. All you need to do is delete the old bridge and set up a new one on 1884. Then restart the Zigbee2Mqtt app in Homey and wait a moment. Voilà.
I had a similar issue with a Nuki Hub via MQTT (smartlock) that developer fixed it to add a string (based on mac) to the hostname..
Multiple Homey’s One Broker
Hello, total newby here. So excuse my ignorance. I have browsed this thread and googled but haven’t found anything that gives me an answer.
I have SHS (test environment) and a Pro23 (“production” environment). Been experimenting with using Homey Z2M.
I have a Sonoff dongle, Mosquitto running on a Linux machine (where the dongle is plugged). Sonoff and Mosquitto are communicating fine. Added one device and it’s fine in the Zigbee2MQTT dashboard.
On SHS I have installed Homey App Zigbee2MQTT. Create bridge and add a device. All works well. The device appears and its capabilities and insights are correct.
Problem Statement
I want to replicate the configuration on the Pro23. As soon as I create a bridge on the Pro - a second bridge - the two bridges flip-flop their connection every 10 seconds.
I have tried changing /etc/mosquitto/conf.d/default.conf so that there are two ports configured and a mirrored topic - trying to de-conflict resources as far as possible. SHS connects to one topic and port; pro to the other topic and port.
I have used mqtt explorer to confirm that the topic mirroring is working.
When I have a bridge on only one Homey everything is fine. When there are two bridges (one on each Homey), flip-flop. I have successfully tested both bridges individually, so the mosquitto configuration is working. It seems that there is some sort of contention when the second bridge is created.
Am I trying to do something stupid? Or have I just missed something obvious?
This is a bug I think. Will look into it when the weather goes bad 
Thanks Gruijter. Having said I browsed the topic, I clearly didn’t do a very good job because the messages immediately preceding DO seem closely related. Maybe after 520+ messages I was MQTT blind…
I can confirm that this type of solution works. I went down a real rabbit-hole of trying to get everything working in Docker and eventually gave up. My current configuration is:
Homey Pro → Mosquitto (prod) running on metal → zigbee2mqtt running on metal
SHS running on docker → Mosquitto (test) running on docker → Mosquitto (prod)
This is (similar to) the configuration that @Frankman talks about in his last paragraph…
v3.2.0 is ready for testing: Zigbee2MQTT | Homey
- Fix bridge and mqtt connection issues
- Massive translation update
This should fix your issues @David_Piper @Frankman @Seinuh . Please test!
@Gruijter thanks ! It’s back on track ! Send you a small donation 
Thx @Seinuh for your donation! Much appreciated
Hi Robin,
Thank you very much for your fix.
I can confirm that it is now possible again to establish a parallel bridge to the Mosquitto Docker on port 1883 from multiple Homey installations – specifically, in my case, from my HP23 and the SHS at the same time. The log from the Docker indicates that the names of the two bridges have been extended with an additional suffix, meaning the issue of duplicate names no longer exists. The different bridges are therefore no longer kicking each other out. In my case, I can stop and delete the second Mosquitto again.
Thanks, great work.
