No, there is no setting for that.
You could lower the volume when starting the countdown when enabling Partially Armed and raising it when the countdown is done.
1 Like
This might be a solution, thanks.
Hi Dandee, I canât see any of my vibration sensors inside the app. Iâm using Xiaomi Aqara sensors, but they seem to be ignored. I think itâs being ignored because I added them trough the DeConz/Homey app:
I had troubles adding more than 20 Zigbee devices so I eventually chose this route to solve all my problems⌠until now 
Other Aqara sensors trough DeConz seem to work fine (motion and door)
Is it possible to implement these vibration sensors? They just act like the direct connection to Homey:
Hi @Satoer,
The official Xiaomi app by @TedTolboom maps the vibration to Homeys alarm_vibration capability which I use in Heimdall
Can you run the Homey.devices.getDevices({ online: true }); command on https://developer.athom.com/tools/api-playground and see what itâs mapped to when using deCONZ? (Screenshot like below please)
For me it looks like this:
Thanks for looking into it. Itâs quite a list:
and (did not fit in one screenshot):
and the last bitâŚ
Is this the preferred way? I can also ask the Deconz developer to implement this.
Yes, this is a relevant snippet from your screenshot (compare this to the last part of my screenshot):
As you can see the capability names differ from the âoriginalâ from the Xiaomi app by Ted. The names Ted chose in the form of alarm_xxxxx are more in line with the original capability names that Athom uses for the more well known capabilities such as alarm_motion, alarm_contact, alarm_battery etc.
Also, I think Ted proposed these capabilities to be added to Homeyâs core but Iâm not sure (maybe @TedTolboom can comment on this)
So, in the end it would be best to ask the deCONZ app developer (@MadMonkey) to change the capability names. (Otherwise all other apps that use these capabilities would have to be changed, the ones I can think of are Homeykit, Groups app, Homeydash and Heimdall and maybe more)
No, these capabilities are not standardized yet.
Will push Athom once more.
But indeed, preference would be to use the default capability naming; alarm_ and measure_ so they will be also compatible with other apps over the API. Too bad Athom doesnât check on this during certificationâŚ
Hi
I havenât followed the entire discussion but I can mention a few points here:
- first of all it is not possible to rename the capabilities as it would break all existing installations and as there is no migration path offered by Athom
- the problem lies deeper in my opinion. There are a few official capabilities offered which is fine. There is also the option to create custom capanilities which is great, but the downside is that these are different capabilities from a technical point of view, even if everything is very similar. I had this problem to with two air quality sensor which measure VOC, but as this are technically different capabilities you cannot properly use them together (i.e groups).
In my opinion there is only one proper solution (propably wonât happen: athom needs to define more official capabilities and needs to provide a migration path.
As long as this does not happen I see no other solution that you look at this as follows: you can use custom capabilities from other apps, but you need the consider them as app specific. Even if it would work by the same name some capabilities still might be different, i.e use a different measurement.
What I donât really see is why is should be a problem to check for different names, i.e alarm_vibration or vibration_alarm?
@MadMonkey Migration paths for capabilities and classes, without breaking functionality, are available, actively used and described in the documentation:
https://developer.athom.com/docs/apps/Device.html#addCapability
https://developer.athom.com/docs/apps/Device.html#removeCapability
If you need help with these functions, please contact me on slack.
As mentioned before, Iâll push to get these capabilities standardized: Add alarm_{drop, tilt, vibration} and measure_tilt capabilities by TedTolboom ¡ Pull Request #135 ¡ athombv/node-homey-lib ¡ GitHub
2 Likes
I see the dilemma here. But since the DeConz app user base isnât that large yet (because itâs quite recent released in the Homey App store) isnât it best practice to ârip the bandageâ before it becomes a way bigger obstacle to change it? Besides, where is this specific sensor mainly used for. I think in security situations and there are already multiple applications with a large user base based on the capabilities from @TedTolboom 's âStandardsâ.
I see that Ted mentioned migrating options. But even without them, I think current Deconz-vibration sensor users wonât be that sad if they need to remove and re-add the vibration sensors with a firmware update, if this means that the sensors will be compliant with standards using the other apps.
1 Like
Hey @TedTolboom
This works but is only a partial solution as it wonât migrate insights data for example (I guess it might also break some flows). Great PR btw, but why not add a few more capabilities such as side & rotation (aqara cube), VOC, PM10, PM1.0?
@Satoer The deconz is larger than you might think, also because many used already the inofficial app and migrated to the one in the store. I really do not wanât any update to break existing installations! As I regard it, the current implementation is perfectly fine according to documentation. The only reason to change this is when there is an new, official vibration capability as proposed by @TedTolboom.
What I still donât get: Heimdall is checking a custom capability defined by the aqara app. So why can it not do the same for the deconz app? It is one line of code! When depending on custom capabilities, you always have to regard them as app specific!
@MadMonkey I donât want to put any energy in arguing on what is wrong, who did it and why, I only ask you to listen to the users of your app.
Fixing it in Heimdall is not one line of code, and more importantly it would mean moving away from the whole philosophy on how Homey works; providing an abstraction layer that enables the use of any device of any brand without Homey or an app knowing anything specific about it other than using the standard capabilities.
Sure, Athom is lacking on the number of capabilities and standards, that doesnât mean developers should lower their standard to their level, please show the users of your app you havenât and do the sensibly thing.
The abstraction simply does not work for custom capabilities and it also is not just a small change in my app either. All I try is to protect the app users from a broken setupâŚ
@Satoer, Iâm sorry, it seems your problem will not be resolved. I suggest moving your vibration sensors from the deCONZ app and re-add them using the Xiaomi app.
Letâs pray the long awaited Zigbee rewrite will be here soon and make the deCONZ app obsolete.
No, Iâm Dutch, brutally honest, not beating around the bush. Or as we say it in Holland, âIk ben geen Zwitserlandâ 
5 Likes
Glad to hear, nice sayingđ!
Question, when i change the surveillance mode to enabled, I have an option in the settings that it will tell me which devices havenât given a reaction for the last 24 hours. But this is every time when I enable my surveillance mode. I would like to make a flow that tells me every day at 1900 oâclock witch devices havenât reacted the last 24 hours. But when I disable the option in de settings, the flow also doesnât work anymore.
There are 2 separate checks, there is the Pre-Arming Check and the Communication Check.
The Pre-Arming Check is run, as the name says, when Arming Heimdall and is configurable with these settings:
The Pre-Arming Check can be run manually by using the Check status of all sensors action card in a flow.
The Communication Check is also run when Arming Heimdall but canât be disabled. You can also start the Communication Check by using the Check Last Communication action card in a flow.
Can you please post a screenshot of the flow you use and your settings?
(Also, thereâs still a bug in Homey that will cause the Last Communication Date not to be refreshed when a sensor does communicate)
1 Like
Itâs what you said. The communication check gives the messages of the devices that not respond for the last 24 hours. I have scheduled it for 1900 hour. I think it would be nice to not receive these messages when arming. Thatâs also when leaving home and that could be 5 times a day. But you said thatâs not possible. Thnx for your answer.
