Yes it should work.
Just follow his guide (Alarm setup section) and make all settings accordingly.
There are some weird restrictions in that app, so take care with the settings.
Just after I added device classes to everything 
Awesome, thanks ! Iām going to test the new version right away. This is a great integration, HA was missing something like this.
Hi,
When trying ti disarm the system, using th loveless alarm panel, I get this error in the log:
Logger: homeassistant.components.websocket_api.http.connection
Source: core.py:1405
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 8:27:22 PM (1 occurrences)
Last logged: 8:27:22 PM
[547901540576] extra keys not allowed @ data['data']
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 135, in handle_call_service
await hass.services.async_call(
File "/usr/src/homeassistant/homeassistant/core.py", line 1451, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1486, in _execute_service
await handler.job.target(service_call)
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 204, in handle_service
await self.hass.helpers.service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 499, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 664, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 536, in _handle_entity_call
await result
File "/config/custom_components/alarmo/alarm_control_panel.py", line 272, in async_alarm_disarm
await self.async_update_state(STATE_ALARM_DISARMED)
File "/config/custom_components/alarmo/alarm_control_panel.py", line 406, in async_update_state
await self.automations.async_handle_state_update(state=state, last_state=last_state)
File "/config/custom_components/alarmo/automations.py", line 71, in async_handle_state_update
await self.async_execute_automation(automation_id)
File "/config/custom_components/alarmo/automations.py", line 117, in async_execute_automation
await async_call_from_config(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 97, in async_call_from_config
await hass.services.async_call(*parms, blocking, context)
File "/usr/src/homeassistant/homeassistant/core.py", line 1405, in async_call
processed_data = handler.schema(service_data)
File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 272, in __call__
return self._compiled([], data)
File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 594, in validate_dict
return base_validate(path, iteritems(data), out)
File "/usr/local/lib/python3.8/site-packages/voluptuous/schema_builder.py", line 432, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: extra keys not allowed @ data['data']
Using default values in the alarm panel.
I have the 1.3.1 from HACS (p.s. tried to remove the integration, and the repo. and reinstalledā¦ same issue)
Looks like you have set up a notification to be sent when disarming, but the target (service) does not support sending a message.
Damm, you are good 
spot onā¦ (created that notification and tried to test it by enabling/disabling the alarm)ā¦ HINT: a test button would be nice on the notifikation tab
and a āfunction breakerā, if you have a bad notification, and try to disarm the alarm.
you need to disable the ābad notificationā and reload to get it working againā¦
1 Like
How Can WE have multiple action on notification without duplicating.
In the same notification sending a voice message and a telegram notification
Works great for arming now, thanks.
It seems the checkbox for āallow disarmā is not being respected though. Iāve set up a code with:
Allow arm = on
Allow disarm = off
Override code = on
But it will allow this code to disarm the alarm
Iāve migrated my Alarm setup to Alarmo, and Iām very happy with it. Great work.
I have a couple of questions:
- Is there any special reason, to not allow changing between armed modes? letās say, Iām armed_night and in the morning I would like to automate the transition to armed_home. Icant! I first need to disarm. and then arm again. The default alarm, allows this transitions.
- Are the notifications/actions run more than once, then triggered by a specific event? in some tests, I received multiple notifications.
You can select multiple targets in the notification editor.
If the telegram and voice integrations have the same format for their notify services that should be sufficient. If not, then you should switch to YAML editor and manually define the 2 actions.
I will take a look at this. This is not intended.
I think there are very few alarm systems that allow switching between modes.
At least the āgenericā HA alarm integrations donāt offer this.
Lucky for you I am planning to add such functionality.
My own use-case: I want to have the motion sensors temporarily disabled when my Roborock vacuum cleans up while the alarm is in armed_away.
I noticed that after restarting HA, the actions defined to the initial state would fire again.
I want to avoid this.
Additionally, Alarmo tries to turn off my siren every time the alarm is disarmed.
This would only be needed after the alarm was triggered.
I want to improve stuff here as well.
For example, by allowing actions to be defined on transitions from triggered ā disarmed.
In other circumstances, the actions should fire only once. If you see otherwise, let me know.
Be aware that this integration is brand new (literally a month old).
It needs some time to grow mature 
Itās already better than anything else HA has to offer.
Letās keep discussing on whatās missing 
1 Like
How do I setup the siren? is there a devive_class needed or ?
Is there any special reason, to not allow changing between armed modes?
Temporarily, you can comment out the below code starting at line 279 (v1.3.1) in the alarm_control_panel.py
# elif self._state != STATE_ALARM_DISARMED:
# _LOGGER.warning("Cannot go to state {} from state {}.".format(arm_mode, self._state))
# return
It seems like if one of my sensors is unnavailable and then becomes available again, even if itās a door and still locked, that will trigger the alarm. Is it just mine?
Set the siren up in the Actions section.
Unavailable is an indeterminate state, meaning that Alarmo cannot judge the situation.
This considered as an unsafe situation, hence it will trigger the alarm.
I would assume the triggering occurs as soon as the sensor is unavailable, not when it is reverting from unavailable ā available.
Why are your sensors becoming unavailable? You cannot really make a reliable security system with such glitchesā¦
Iām investigating why but suspect it is because of sonoff RF bridge.
Pretty happy so far with the integration. Iām running it in parallel to my old, fully automation based alarm, hopefully Iāll be able to completely switch over to Alarmo soon.
Iām currently thinking about how to integrate sensor tamper switches in a nice and consistent way. Basically all my sensors (door, window, motion) have some kind of tamper detection which runs separately to their main function. If a sensor detects tampering, the alarm should always be immediately triggered if armed, regardless of mode. So for example, if armed in home mode, a motion sensor doesnāt trigger the alarm on motion, but would still trigger the alarm when tampered with.
Right now I simply created an additional binary template sensor for each sensors tampering trigger and added them as additional immediate sensors to Alarmo. That works but feels a little convoluted. Would it be a good idea to integrate such functionality directly into the component or would that be out of scope feature creep ?
I wouldnāt really know a better way.
Perhaps we could make use of the device_class: opening, have Alarmo automatically recognize it as a tamper switch and do the settings accordingly.
Currently for motion/door/window/fire sensors similar things are in place.
IMO in HA the entities are a bit āconvolutedā anyway.
I rather would have users assign complete devices to Alarmo, where a device can have up to 10 entities in HA.
But such thing would only work if all integrations have the device_class set correctly.
These tamper switches you are refering to, how are they represented by your integration?
Or are they represented as attributes of the normal binary_sensor?
Or are separate entities created?
Typically they will be separate entities on the same device. It really depends on the device and integration. For the camera tampering, itās just another binary entity. For my Aeotec and Fibaro sensors itās more complicated. Besides a binary open/close (or motion/no motion) entity, they also expose a non-binary āburglarā entity, which encodes different states of the device as different numerical values. A typical zwave type encoding would be 8 = door open, 3 = tampering detected, 0 = all good. Iāve seen that encoding with several manufacturers now, but Iām not sure if it can be considered a defacto standard (probably not). And itās probably completely different again for Zigbee or even cloud based wifi sensors.
So itās not straightforward at all. Maybe the only practical way is to create binary template tamper sensors. But I agree with you, ideally you would just add entire devices to Alarmo and have the integration handle all security related aspects of the device.
I guess the real solution here is to have more uniformity in HA integrations.
As long as things are messy as they are now, all that we can implement here is just a workaround and not a real solution.
Regarding:
Currently Alarmo sensors only can be binary_sensor entities. But I donāt really have a good reason for it, it should work for any.
For me itās OK to allow more entity types, as long as users can provide a mapping to safe / unsafe states.
Ofcourse a consequence is that if your sensor will suddenly have an unlucky value ā13ā, the state would be flagged as undeterminate and you get this situation.
unfortunately unavailable sensors can happen. for example: I have a board ESP32 for managing my wired sensors and siren. and very occasionally it disconnects and reconnects to wifi, at that moment they are unavailable for HA. It would be bad if that triggers the alarm and siren for that.
Iām not sure whatās the correct solution. maybe make it configurable: trigger unavailable states Yes/No.
This way users with more robust systems can go with it. And the others may accept that risk.