I am not sure what happened overnight but I uninstalled the Alarmo custom card, then clear my browser cache again and now it is working.
Weird but I am thankful it’s working.
I am not sure what happened overnight but I uninstalled the Alarmo custom card, then clear my browser cache again and now it is working.
Weird but I am thankful it’s working.
Guys i have a question about Alarmo presence detection. How does it know if everyone is at home or not?
In my set up, i am using the companion app to share location to home assistant but i have found out that it is sometimes unreliable as it updates every 15 min. I know that i can set it up for every minute but it kills my battery. In order to mitigate that, i have set up sensors via Yaml in the configuration file that show as home in case we are connected to the home SSID. Finally, i created a group from the device trackers and the sensors based on the SSID.
How can i ensure that alarmo is taking into consideration the group and not the sensors individually?
Thanks
Kind Regards
M
It doesn’t, you need to use an automation to manage the alarm state depending on presence.
You can have multiple trackers linked to a person, and then check if zone.home is 0 (meaning no one is home) or >0 for someone home.
I see, I thought that this happens automatically without building an automation… Thanks, in that case I will include it in my home status automation that monitors the group…
I have made my own panel ( because I am anal about visual consistency with the rest of my homepage) and so far all works exactly as I want. The keypad buttons are not implemented yet (last week I had never heard of YAML) and I have no idea where to start. So, any pointers as to how to implement the keypad? Happy to upload the paper-buttons-row card.
The removal of the delay property from Alarmo entities in v1.9 is a bit problematic for me. I do not use the Alarmo card but I did use the delay attribute to trigger my own arming/pending timers (mainly for the UI). I don’t see any way to do this now. Any chance the removal of the delay attribute can be reconsidered?
This is already reconsidered and reverted. Version 1.9.1 is made just for that.
I got plenty of complaints, thought that alarmo-card was the only user of this
It looks pretty sleek, did you make it in HTML/CSS or just a graphical mockup?
In the first case, you can turn it into your own custom card by using the boilerplate-card as a template.
The code of the original HA alarm panel card can be found here (I think its more straight-forward than the code of alarmo-card).
What behaviour are you planning for the panic button? Missing something for this in Alarmo?
Its fully functional as a paper-buttons-row card (exept for the keypad) so, just YAML. The animation for the buttons (arming/triggered) are CSS. The panic button triggers the alarm and sends notifications to relatives/security gate. The spacing looks much better on the iPad mounted to the wall rather than the screen-grab from my PC. As I have never coded anything before, I am not sure how to get the keypad to enter the pin code, at the moment, the pin is part of the YAML and sent by default.
Ah clear, that’s very creative (and it seems quite simple to set up).
One way I could think of to implement the keypad, is to create an input_text
entity to store the entered pin code.
On each button press you could have a digit added behind the existing value of the input_text
, such that 4 presses make up a complete pincode.
There is no service in HA to have a letter/digit added to the current value of an input_text, but I made a quick test using a script and this seems to work:
script:
input_text_append:
variables:
current_value: "{{ states('input_text.keypad_code') }}"
fields:
value:
description: Value to append
example: "0"
sequence:
- service: input_text.set_value
data_template:
entity_id: input_text.keypad_code
value: "{{current_value}}{{value}}"
For the button click action you could add:
service: script.input_text_append
data:
value: "1" # or whichever number
Of course you will also need to clear the pin code, but for this you could call the input_text.set_value
service directly.
When clicking the arm buttons, you can call the service alarmo.arm
with a template for the code, e.g. code: "{{ states('input_text.keypad_code') }}"
.
Be aware that this way the pincode becomes visible in the input_text
entity.
You might want to automatically clear the entered pin after certain time of inactivity (alarmo-card does so as well), but still the history of the entity will reveal what has been entered.
For better security you could consider to not use a HA entity to store the entered pin, but for example use MQTT towards node-red or ApoDaemon which has the capability of holding variables in memory.
Hope this is useful for you
I think I love you!!!
Thanks very much.
type: entities
entities:
Hi there. I hope that posting the YAML here is ok, if not, I will remove it. I have added your sript example and now have input_text_append under entities. I have added the tap action to button 1 as a test. I have yet to figure out how to replace the code entry (code: ‘4948’) and where to find where the input_text_append stores the code input via the keypad. My apologies for the basic level of questions, and sinscere thanks for your response.
Hi, is it possible to disable a sensor using a command/automation, rather than manually turning off the ‘Enabled’ switch under ‘Sensors’ in the ‘Alarm panel’?
I’d like to create an automation to disable the motion sensor while my robot vacuum is vacuuming, to avoid it triggering the alarm, and then re-enable the sensor once the vacuum is docked.
I did already consider temporarily switching to custom_bypass mode which doesn’t include the motion sensor, but there are too many possible states/scenarios where it could end up not going back to the correct alarm state afterwards. I thought it would be much simpler to just temporarily disable the sensor instead of switching modes.
No this is not supported. There is only the option to bypass a sensor when it is active during arming, you cannot remove/bypass a sensor when armed.
I also use the custom_bypass mode when my vacuum is busy, it works fine.
Which scenarios are you afraid of? Effectively it works the same as disabling sensors, only while switching between the modes it is checked whether all sensors allow this (which I think is a good thing).
When leaving the house, I press an Aqara button to set the alarm to away, in node-red it then has to check if the vacuum is cleaning and then set it to custom_bypass instead, wait until the vacuum is docked, then set to away.
But what if I cancel arming during this time, it’s still waiting for the vacuum to be docked and then would set it to away anyway.
Someone breaks in through the front door while it’s cleaning and in custom_bypass, triggering the alarm. Cleaning is then finished and then the alarm is set to away when it should still be triggered.
I set the alarm and leave the house during the exit delay time, Someone then starts vacuuming remotely from a phone, the alarm will be triggered by the vacuum once the exit delay finishes and motion is detected.
The alarm is armed and I’m out, then decide to start vacuuming. The automation could detect the vacuum state change, check the armed state (away or vacation), set it to custom and wait for the vacuum to dock before changing it back to whatever it was before, away or vacation. But what if someone comes home while it’s waiting and disarms the alarm. When cleaning completes, the alarm will be armed again. I guess I could check if the alarm is still in custom_bypass or not before arming for this one.
This automation is triggered when the aqara button is pressed to arm the alarm, but what if I set the alarm from HA on my phone instead. I’d have to use a state changed node for alarmo and then check if cleaning is in progress before doing the rest, but then this would also get triggered when I press the aqara button and conflict with the first flow.
These are just a few that came to mind, I’m sure there are more that I’d have to try and account for in the flow. I just thought disabling the motion sensor while the vacuum is cleaning would be much simpler than changing the alarm mode and running into issues in different scenarios such as those above.
@datbilling
I would say cases 1,2,3,4 can be solved with an automation which sets the alarm to the custom_bypassed mode in case the current state is armed_away and cleaning is in progress.
For the last case you would indeed need to check whether the vacuum is busy and depending on that go to either armed_away or custom_bypass mode. Perhaps the automation for 1-4 can cover it too, if it acts immediately upon entering the armed_away mode.
If you really want to mask the sensors directly, you could define some template binary sensors which combine the state of actual motion sensor with some input_boolean to determine whether the sensor should be masked, and use the template sensors in Alarmo.
I am not opening the bug because probably it is me, who does not know how to - I am trying to use MQTT to arm/disarm, but it is not even responding to my commands - please have a look:
what am I doing wrongly? the code is 1234 and it works from the HA
thank you
another example: