This may be of interest.
Noonlight for Home Assistant
I saw it too. Looks like it would be a nice enhancement to Alarmo. Probably better to wait until it can report the type of alarm. Think that’s coming in V2.
Happy to see you can sign up for your own account and not through a third party.
5310
Yes, I do have Noonlight and Alarmo works very well with it. My Q was more along the line of a duress code, which would turn the Siren/Bell off and disarm the alarm, but notify of a duress situation. Seeing how quickly Noonlight responds (less than 10 seconds on alarm), and they first text and then call, all of the above in less than 30 seconds, I will check with them to see if they have the ability to have a duress code on file, which would solve this.
BTW, anyone out there in the US looking for a solid monitoring company, Noonlight are Rock Stars!
~TJ
1 Like
I’m using the Xfinity zigbee keypad to arm/disarm the system. I have setup a duress code 4357 (help) which will disarm the system and push notifications (and/or emails) to certain phones. But, I think the Noonlight option would be great!
I have this same error when casting the alarmo panel to my nest hub. Am I doing something wrong?
I was hoping that updating to v1.6.0 would resolve the caching issues.
Are you on the latest version?
Yes, but this is just when casting. It works fine on chrome on my desktop and phone. Even when on mobile data.
You need to clear cache of the app or/and your browser, then it should work.
Did that and no change.
I made the switch and it worked well
1 Like
I’ve just switched across to Alarmo, finally, from BWAlarm, however I have an issue with the MQTT implementation not working with my hard-wired Paradox alarm system. Hoping it’s just a matter of sorting out the MQTT details.
In the BWAlarm I had it set up as follows:
command_topic: paradoxdCTL/hassio/Arm
which would set the Home Assistant BWAlarm to either armed_away, disarmed or armed_home based on that topic being either armed_away, disarmed or armed_home coming from the Paradox alarm system.
There is also a topic for HA to control the Paradox system:
state_topic: paradoxdCTL/in
which requires a complete payload such as:
{"password":"1234","Command":"disarm","Subcommand":"0"}
so that HA can set the Paradox system accordingly.
I think I have most of it sorted in that when I arm_away and disarm the Paradox system (which is my primary way of controlling the alarm) HA responds by arming / disarming Alarmo. This is great because my automations to send status updates to our phones are working.
Trying to arm_home (Paradox calls this armed_sleep) is not working however which I don’t quite know why but it seems that the MQTT command sent to paradox is wrong. When I watch the topic I’m seeing {"event": "ARM_HOME", "delay": 0} being sent back from my Paradox system rather than simply armed_home as I would expect to see which seems to be due to the payload being sent to the Paradox being wrong… confusing to explain… Arming ‘sleep’/home from the Paradox system works to arm Alarmo, but Alarmo isn’t arming the Paradox system if I try it that way around.
I’ll keep playing with it but at least I have it mostly working. Long story short is that HA and Paradox are supposed to be in sync with each other, so if we arm or disarm from either HA or the Paradox system, the other will follow. I’m close, just not quite there.
Hi Dave,
Alarmo has no functionality for controlling (+ keep in sync with) an external alarm system. It is designed to be the alarm system rather than controlling an external one.
The event_topic in Alarmo is designed for GUI purposes, i.e. to show status feedback on a wall tablet (many users use MQTT Alarm Control Panel).
I don’t think it contains sufficient data to connect to your Paradox system (e.g. it does not share a code).
On the other hand, there is also no way of triggering Alarmo from Paradox, so I think it is not possible to keep both in sync.
The payload structure for controlling Paradox:
{"password":"1234","Command":"disarm","Subcommand":"0"}
Is very application specific, every system may require a different format (e.g. Subcommand is something that I have no idea about).
For that reason I don’t think it will be possible to add full support in Alarmo to control it.
I see the following options:
-
Set up Paradox support as separate integration (and separate alarm_control_panel entity) in HA. A possible procedure is described here.
To keep it in sync with Alarmo, new functionality has to be added. Such functionality is requested before here, here and here. -
Use node-red to receive the data on the
event_topicand convert them to the payload structure for Paradox. To be able to trigger Alarmo through MQTT, new functionality has to be added.
I think the way to go is option 1 since it seems more generic.
Alarmo can treat your alarm as an ‘external’ area, and keep them in sync using the master. See for example here.
Unfortunately both options require work to be done, so for now there is no complete solution I can offer you.
It actually doesn’t need that much work at all to get them to sync, as I say, I have it almost completely working already.
I have the above (and variations for arming modes) entered into the MQTT section of Alarmo and they do work for armed_away and disarm, just not armed_home for some strange reason.
Likewise, when I arm the Paradox system from it’s remote or touch screen, HA (Alarmo) follows suit and arms / disarms accordingly. That side works perfectly.
The reason for this sync setup is so that the two can act as one complete alarm, allowing me to monitor both the HA sensors and the Paradox sensors via Home Assistant, getting notifications etc for all of them. The other benefit is that the Paradox system is stand-alone with battery backup etc too, so if power is cut or HA is down, the Paradox alarm is still fully functional (other than notifications).
I’m SO close to having it working completely perfect. Just the one function not working: Alarmo to arm paradox in armed_home mode. I should be able to sort it out with some more testing.
Hi guys
I had setup an alarmo notification for using the ALARMO_FORCE_ARM function and everything worked fine until a few days back where stopped sending messages. When trying it from alarmo interface it works fine but when let it on its own it’s not doing anything. I run the latest version v1.6.0 and I cannot relate the problem with the recent upgrade. Any thoughts or work-arounds ? I tried to remove the ‘entity_id’ line from yaml but it doesn’t let me save it, instead, it throws a bug message.
Thank you all
Everything works fine after 1.6.1.
Awesome how far this project has come in not even a year !
I hit a bit of a problem configuring it for a specific use case. I have some roof windows that I sometimes leave open during the night now that days are hot, but never when I leave the house. So I’d like them to be be bypassed automatically when open in arm_home mode, but not in arm_away. Is that possible ?
Thanks !
I’m still having the issue casting the Alarmo card to my Nest Hub. I’ve updated to the current version, but that didn’t fix it.
Any suggestions?
Hi there, no not possible (yet?). I raised a feature request. Maybe you could +1 it on github to raise niels attention. @HeyImAlex
I’m just setting up Alarmo for the first time. I have configured Away, Night and Custom.
When I use the Alarmo card, I can only see Away and Night - custom does not show. When I use the regular HA alarm card, I can select ‘custom_bypass’ however it doesn’t actually work.
Am I missing something?
I just installed Alarmo and it has been fantastic !
I did have one question, would it be possible to add a pending delay if the alarm is triggered while in an armed_home state ?
I ask just in case one of us forgets to disarm the alarm and it would be good to have a 10 or 15 second window to properly disarm the alarm before it getting triggered.
Thanks !
1 Like
Entry delay is available for all states that I’m seeing in my config panel.
1 Like