Version 2.1.4 is ready for testing: https://homey.app/a/com.gruijter.zigbee2mqtt/test
- Added support for left/right switch (Livolo TI0001).
Thx to Niels Nijveldt for adding this device!
2 Likes
Is there a way to verify which zigbee devices should work with this app? I understood from this thread that not all devices supported by zigbee2mqtt would work?
You won’t get a definitive answer on which devices will work, because nobody will have all devices that are supported by z2m.
1 Like
Just buy the device and try.
2 Likes
Thanks for the confirmation. Would it be feasible to add a table to the first post with devices that have been tested and their result?
I agree it won’t happen.
But they could easily add a “experimental feature” where you could enable z2m homey reboots and it spawns the z2m docker… o problemo
Well sure, on paper it’s no problemo, until you look at the details. How would z2m hook into Homey’s core? Because you cannot run two Zigbee implementation against the same controller, the current implementation would need to be disabled.
If you want such an experiment to be an actual experiment (one that you can easily enable and disable), how would devices created against the z2m experiment survive disabling the experiment? Or do you think Athom will just tell the users “hey, if you turn on the experiment, your entire Zigbee network and all its devices will stop working, and again the same when you turn if off”?
Again, I don’t see it happening.
No you are to negative, i disagree…
settings → expermental features → enable z2m → popup “warning current zigbee devices will be disabled”
Homey reboots and no more internal Zigbee (error when trying to add Zigbee) and z2m with an internal port spawns ( you still need to have the z2m app)
if you go to settings → experimental features → disable z2m
Homey will reboot and the Athom stack boots again there is no need to destroy your z2m network its the same chip. yeah off-course you can’t run 2 stacks at the same time
its an Homey Pro(fessional)
what would they gain? haha community thats why it will never happen because Athom just like to circle jerk and don’t give a crap after you bought it.
but technical? totally possible…
And where do the devices that you add to z2m show up in Homey? In fact, let’s take a step back: where would you suggest new devices to be added to z2m? Via the Homey interface, or via the z2m interface?
How would you prevent users from modifying z2m settings that could cause issues? Does the experiment ship with a custom z2m?
Which means that devices that were added to z2m while the experiment was running will show up in Homey’s Zigbee network, yet they won’t have any internal Homey representation because Homey wasn’t aware that they were created.
Also, how does Homey interact with z2m? I assume you’re going to say “the experiment will obviously start an MQTT broker too”. And then what? Homey has no built-in MQTT support, so that needs to be added somehow. And you don’t want users to be able to modify anything related to MQTT in the z2m configuration, because that would break the integration with Homey.
I never said it wasn’t, I’m saying that Athom will never do it.
@JB2K @robertklep nice discussion, but could you please create a new topic if you want to discuss it further? 
3 Likes
And where do the devices that you add to z2m show up in Homey? In fact, let’s take a step back: where would you suggest new devices to be added to z2m? Via the Homey interface, or via the z2m interface?
How would you prevent users from modifying z2m settings that could cause issues? Does the experiment ship with a custom z2m?
- Z2M interface add’s devices
- Homey Z2M App (this app) adds devices to Homey
- a “reset to default button” is enough and its a pro feature… also z2m doesnt have allot in config most is webbased
Which means that devices that were added to z2m while the experiment was running will show up in Homey’s Zigbee network, yet they won’t have any internal Homey representation because Homey wasn’t aware that they were created.
Also, how does Homey interact with z2m? I assume you’re going to say “the experiment will obviously start an MQTT broker too”. And then what? Homey has no built-in MQTT support, so that needs to be added somehow. And you don’t want users to be able to modify anything related to MQTT in the z2m configuration, because that would break the integration with Homey
We have this app right? so they are added… its the same with “Home Assistant” you are creating problems that arent there. Z2M is just an extra docker its doesnt hook into Homey
The MQTT part i havent thought about… but again yes they could easily spawn that aswell “Home Assistant” has this whole add-on platform why wouldnt it work here? those problems are already tackled and again its a “Pro” device and completely optional
v2.1.5 is ready for testing: Zigbee2MQTT | Homey
- Added support for Ikea blinds (Fyrtur, Kadrilj, Praktlysing, Tredansen).
Many thanks to @Sre for adding these 
6 Likes
v2.1.5 was released as stable. New version 2.2.0 is ready for testing: Zigbee2MQTT | Homey
- Added force bridge log level to INFO on startup.
- Added Bridge flow cards for restart, allow_joining and set_log_level.
- Improved Msgs/minute counter
1 Like
Did you find a solution to this?
I have several motion sensors added in Homey, through zigbee2mqtt.
The sensor alerts that are done through zigbee2mqtt do not activate the Zone activity, while if I connect a motion sensor directly to the Homey coordinator, they do activate the Zone activity.
@Gruijter is there perhaps an attribute to be set to the motion sensor devices in order for the device to work with Zone activity? The ones I add in Homey have different “settings” options as well (including an option to exclude them from triggering Zone activity)
Devices I am currently working with:
And also a HG06335_HG07310 (cannot post more than 2 links)
I dont think it is possible.
Edit: I looked into it some more @Michael1 . It seems it automagically works for alarm_xxx capabilities. Is an alarm capability triggered on your mmwave sensors? Or is motion reported as an action? If it is an action it will not be an alarm trigger, and thus not a zone trigger.
Nope, gave up for now.
All the motion sensors I have in zigbee2mqtt are sending the object containing a boolean key “occupancy” when motion has been detected.
e.g.:
MQTT publish: topic 'zigbee2mqtt/occupancy_kantoor', payload '{"battery":100,"linkquality":135,"occupancy":false,"power_outage_count":330,"voltage":3045}'
Note that I have 2 identical sensors, 1 connected in z2m, and 1 connected to the Homey coordinator.
The one connected to the Homey coordinator does trigger the Zone activity, while the one in z2m does not.
So is it correct to say that the motion is reported as “occupancy” here or do you mean something else?
Perhaps theres a way to map the occupancy key to alarm_ ?
Occupancy is mapped to alarm_motion.occupancy in Homey. The developer docs are very unclear. Alarm_xxx should automatically trigger a zone. There is nothing I can do as app developer. I suspect that because this is a sub capability (.occupancy) the trigger doesnt work.
Did you already try removing the device in Homey and adding it again?
Thanks for clarifying! Would it make sense to report his to Athom to look at?
So it seems that they do trigger the zone alarm for this sub capability when the device is “natively” connected to Homey, but they do not when added as zigbee2mqtt device.
I removed the device and added it again, but unfortunately with the same result.
I already mentioned it on slack a while ago, but no one seems interested in zones. I already spent a lot of time on this, but yes, please do report it at Athom. Maybe one day it gets priority 
