v1.5.0 build 2 is rolling out to devices now. Hopefully this offers a fix for the issues. I am not seeing the issue on the production builds yet. What was happening is the WiFi network was reconnecting when it wasn’t needed, this caused intermittent connection issues. Now the WiFi is established once in the settings or manually if you set it up from the command line.
V1.5.0 Build 2 been running for 3 days now. No sign of the intermittent disconnects!
Outstanding work @thanksmister!
I updated to 1.5.0 build 2 and no issues so far. I’m keeping my fingers crossed 
thanks again!
so I have the alarm working but i’ve been trying to get telegram to send me a photo when disarmed. The correct api token was entered, correct chat id, they’re the same as I use in my hassio install to send myself messages over telegram and i’ve rechecked them several times. The camera permission is checked for the Alarm panel on my phone in app permissions so that shouldn’t be an issue either.
I have a OnePlus3t with android oreo. I’m not sure what to do here.
Check in previous posts on this topic within this thread. I think that there was an issue with some people using the same telegram for both HASS and other applications. I use the same for both, so I don’t know where the hitch is, it could be your chat id or some other typo. But the feature definitely works.
I have created a new beta version of the application due to the large number of changes. I have integrated some of the features from the WallPanel application. Here is a list of some of the changes:
- Added Google Vision API for detecting faces, motion, and QR codes
- MJPEG streaming of the camera that can be integrated into HASS or viewed from webpage
- Added ability to send remote commands to alarm panel using MQTT (wake, capture image, speak, notify, play audio)
- Added ability to publish device sensor data using MQTT (light, temperature, humidity, pressure)
Wake the device screen when motion or a face is detected
Instructions for using the new features can be found on the Github Project page: Android MQTT Alarm Panel for Home Automation Platforms | MQTT Alarm Panel
You can join the beta program if you wish to test the next version before it’s released to production here: https://play.google.com/apps/testing/com.thanksmister.iot.mqtt.alarmpanel. It contains this feature similar to WallPanel. You may leave the beta program whenever you wish and return to the production version. Once this version is fully tested, I will roll it out to production.
1 Like
These changes are awesome thanks for your hard work. I installed this in a custom case for raspberry with 7" touchscreen set into my wall. Thinking I’d never have to access it but due to your awesome updates it would seem that is going to happen. Do you have OTA as part of the road map at ALL if not I would like to feature request it.
These changes are not yet for the RPi 3 version, they are only for the Android devices. I don’t know when they will arrive on the Android Things version, depends on my available time. But they will eventually come.
1 Like
I think I found a glitch in the app. It looks like the app settings for “Disarm home delay” and “Disarm away delay” are flip-flopped
My app alarm settings are:
Pending time = 0
Disarm Delay Time = 0
Arm Home Pending Time = 5
Arm Away Pending Time = 60
Disarm home delay time = 20 seconds
Disarm Away Delay Time = 5
My configuration.yaml is:
alarm_control_panel:
- platform: manual_mqtt
state_topic: home/alarm
command_topic: home/alarm/set
pending_time: 0
delay_time: 0
trigger_time: 4
disarmed:
trigger_time: 0
armed_home:
pending_time: 5
delay_time: 5
armed_away:
pending_time: 60
delay_time: 20
When I set the alarm to armed_home it pends for 5 seconds then arms. When I open a door it delays for 5 seconds then changes to triggered. If I set the alarm to armed_away it pends for 60 seconds before arming. When I open the door it delays for 20 seconds then changes to triggered.
As you can see from my app settings, the delay time on armed_home and armed_away are flip-flopped. Or am I just going crazy?
App version - 0.8.1 build 0
Hassio version 0.75.2
The mqtt manual control panel is driving the modes of the application, so your setup is what’s causing the confusion. The pending time is the time before the alarm is armed and they delay time is the time before the alarm is triggered. From the settings you have and the behavior you described they seem correct.
For arm away you have pending 60 and triggered 20. You said that it gives you 60 seconds before arming and when entering gives you 20 seconds before going to triggered, isn’t that what you’d expect?
Correct, I’m getting what I expect based on my MQTT Alarm Control Panel settings in configuration.yaml. But the “Disarm away delay” and the “disarm home delay” settings in the app are flip-flopped from the MQTT alarm control panel config. I’ve changed the app settings so the countdowns on the app match what the MQTT Alarm control panel are doing. My app settings have to be like this in order for it to work as expected
Ok, I will investigate.
I think you are experiencing a bug that I reported some time ago and the response was that the documentation is incorrect. Here is what I have for my configuration file for example:
alarm_control_panel:
- platform: manual_mqtt
state_topic: home/alarm
command_topic: home/alarm/set
pending_time: 60
trigger_time: 1800
disarm_after_trigger: false
delay_time: 30
disarmed:
trigger_time: 0
armed_home:
pending_time: 0
delay_time: 0
armed_away:
pending_time: 60
delay_time: 30
You would expect that when I have “armed_home” set with pending 0 and delay 0 the alarm would be triggered immediately when I open my door, but it follows the same delay_time as I have setup in the defaults. The issue I have reported is here: https://github.com/home-assistant/home-assistant/issues/14268 as well as the “solution”, which is better documentation.
My issue is similar, but slightly different. In the issues linked above the confusion is between pending time and delay time. My issue is between armed_home delay and armed_away delay.
Examples:
Delay time to disarm from Armed_Away (time from door opening to alarm triggering)
Config file setting: 20 seconds
Disarm Away Delay Time app setting: 5 seconds
Experience: The alarm will trigger after 20 seconds unless I enter a code. The app counts down from 20 seconds
Delay time to disarm from Armed_Home (time from door opening to alarm triggering)
Config file setting: 5 seconds
Disarm Away Delay Time app setting: 20 seconds
Experience: The alarm will trigger after 5 seconds unless I enter a code. The app counts down from 5 seconds
So, I have to trick the app by flip-flopping the disarm delay times. I enter 20 seconds for Disarm Home Delay time in order to see a 20 second countdown for Disarm Away Delay and vice-versa.
Ok, I found where the logic is reversed. I am glad to have another pair of eyes because I would have never discovered this issue. Currently the fix will be in the next beta version but will not be available for production until the beta program is complete. If you can’t wait for production, you are welcome to join the beta program to get the fix earlier. You can join the beta program here https://play.google.com/apps/testing/com.thanksmister.iot.mqtt.alarmpanel.
Awesome! I’m glad I wasn’t just going crazy. I have it working with the settings flip-flopped so I’ll just wait for the production update.
Thanks for the help and the awesome app!!
Has there been any thought to having separate “pending” states for the armed-away and armed_home?
Currently, If I set the alarm to armed-away the alarm goes from disarmed>pending>armed_away. And if I change to armed-home it goes from disarmed>pending>armed_home. Similarly, if it is in armed_away state and a door is opened it goes from armed_away>pending>disarmed or triggered. The multiple uses of the “pending” state seems to somewhat limit the automation that can be done using the alarm states.
For example, if I want HA to turn the lights on when I get home and turn the alarm off I could set a trigger for the automation based on the alarm. But when I open the door and enter my code the alarm goes from armed_away>pending>disarmed. So, if I set my light trigger based on the alarm going from pending>disarmed the automation would work when I get home and disarm the alarm, but it would also run if the armed_home was on, a door was opened (putting it in pending state for 5 seconds), and then the alarm was disarmed.
Or, if I want to get a notification anytime the alarm is triggered while I’m away. I could set it to send a notify if the alarm state went from pending>triggered. But then I would get notifications even if the alarm was in armed_home, a door was opened (putting it in pending for 5 seconds) and then triggered.
I know these are first world problems. I’m just curious if this has been thought about or if there is another way to accomplish these automatons.
The application adheres to the pending, delay, and trigger times of the HASS MQTT Manual Alarm Control component. So take a look at that documentation to see the different pending times you can set between armed home, armed away, and triggered.
You can adjust the pending time as you like. But obviously you would like to have a pending time when you open your door so you have enough time to enter the code. The alarm actually goes from away to pending (enter code time) to disarmed (after entering correct code) then to triggered if the code is not entered on time.
If you think the behavior of the component needs to be improved or more features added, those change would need to be addressed in the HASS component. Think of the application as just a pretty interface for the HASS alarm control panel but with some extras added.
Why not just turn your lights on when you go from alarm away to pending, or when you open the door if the alarm is in away mode. Obviously you could build your automation to be as complex as you like but you would have to do more work in the HASS such as remember you are coming from away or home mode to pending.
I’d prefer not to have the light trigger be from armed_away to pending because it would turn on all the lights for anyone that broke into my house. Although, I suppose I could add an “all lights off” automation if the alarm goes from pending to triggered.
I’ll look more into the capability of the HASS alarm component.
Thanks!