Impressive! Now it’s working perfectly 
1 Like
v2.3.1 is released for testing: Zigbee2MQTT | Homey
- Added capability mapping for measure_water, valve_state and target_distance. (thx @Kringloper)
- Stability improvements.
4 Likes
Hi,
testing your app for some Aqara Vibration sensors and it seems because you tried to make it as universal as possible, they do not appear as “vibration” sensor in the Heimdall. Is there some mapping possible for known device classes, to add them so they will be recognized as vibration/contact/motion or smoke sensors? Or there is no easy way to achieve it…just asking 
I guess it also depends how they are harmonized as well in Z2M… do you have a reference as a test ? Do you see a vibration attribute in z2m ? I dont have one of them so i dont know how they are first exposed in the mqtt payload.
1 Like
Would be great if Heimdall could support the Zigbee2MQTT sensors. But due to that I need to map all possible Z2M ‘exposes’ to a unique ‘capability’ in Homey, support needs to be added in Heimdal itself. Also Homey zone activity is not possible afaik (I asked around and asked Athom support, but triggering zone activity seems to be hardcoded somehow in the Homey firmware)
So @DaneedeKruyff : would it be possible for you to create listeners for Zigbee2MQTT devices with the following capabilities?:
- alarm_contact (I guess that is already supported by Heimdall)
- alarm_tamper (I guess that is already supported by Heimdall)
- alarm_generic.open_window
- and actually all subcapabilities of alarm_generic
- alarm_motion.vibration
- alarm_motion.occupancy
- alarm_motion.presence
- and actually all subcapabilities of alarm_motion
- garagedoor_closed
- locked
I hope that would work with Heimdall 
2 Likes
Thank you, so it’s not just about adding them as per Capabilities - Homey Apps SDK ? Hmm, that’s a bummer.
@Gruijter For zone activity, if i understand the documentation, this is an indirect trigger for alarm_motion and alarm_contact only. Maybe the option could be activated by default through some configuration of the z2m device for those properties when they exist. Just a guess.
Oh i see what you mean : you dont map dynamically the device capability in homey at discovery, but you have a generic static capability for all z2m devices per default. Is that what you mean ?
1 Like
Yeah, these probably work. But Z2M has many types of motion and contacts, so they are mapped to a subcabapility e.g ‘alarm_motion.presence’
And subcapabilities do not trigger zone activity. This is now hardcoded in the Homey firmware. So you could ask Athom if they are willing to change that…
1 Like
Would it be possible to only map alarm subcapabilities directly to “real” capabilities and have a “virtual” alarm capability which will be active if any subcapabilities are?
E.g. have
alarm_motion.motion
alarm_motion.presence
and if any one of those is active alarm_motion is as well.
Maybe with a device setting to enable/disable this behavior?
Too much work for me and messy architecture. Rather have Athom enable subcapability support out of the box.
1 Like
EDIT:
I haven’t had the time to read this thread properly before posting. So sorry if I wrote something before which was already completely answered. I just read the thread regarding motion and as far as I understand, it is not possible (??) to trigger a zone activity with Z2M motion devices. Does the same apply to the flow cards? Is there some workaround or is it just impossible to use motion devices with Z2M and this homey app?
Hey,
I just moved all my devices from Homey Pro back to Z2M, as the Zigbee implementation of Homey is missing a lot features (groups, bindings, proper reporting, support of devices etc) and used this App to get all my Zigbee devices to Homey. Everything worked very well and almost everything is working. However, I have one small issue with a presence sensor. It was added to Homey without any issues and also recognises the motion alarm - I can see the motion set to yes, when it detects motion. However when trying to use said motion detection in a flow. It does not work. 
I might have an idea:
Looking at the sensor in my devices it uses the word “motion” and in advances flows it uses the word “presence”, so I think there might be an incorrect mapping?
Or am I just stupid and use the flow cards incorrectly?
The Test buttons work for my flow, so I think the start card just doesn’t get triggered.
I have the same. Weird
I checked the thread again and it seems to have worked before. Just the Zone activation is not possible. But Flows have worked before. So I guess this is a bug?!?
Maybe. Will check. I hope it isnt caused by the latest Homey firmware release…
Edit: I checked the code for triggering alarm_motion.presence and alarm_motion.occupancy, and all looks good. In fact I havent changed that code in a long time. So that the flow cards don’t trigger anymore does seem related to a Homey firmware update. I have found that Homey has several issues with sub-capabilities. I already informed Athom about it. But I guess it is a matter of priorities.
1 Like
Thank you for checking and informing Athom 
Can you reproduce the issue or are you not having these issues?
No, cause I dont have zigbee devices for motion myself.
versions 2.3.2 and 2.3.3 were published as stable:
- Stability improvements.
- Added class icons for motion sensors and dimmers. (thx @Sre )
1 Like
@Gruijter hi Robin, I have an issue where devices that have simular names seem to react to events for example I have a light named “Office” and a blind named “Office blinds” and it looks like the office blinds also receive the office events, is includes/contains used to match events to devices resulting in “office blinds”.contains(“office”) reporting a false positive?
I think that is the case. Just rename your devices (or do a pull request) 
