MQTT Alarm Control Panel for Raspberry Pi and Android

The client ID is only important in that is has to be unique. Other than that, it can be pretty much anything you want. I’ll try and see what happens I allow anonymous access to the MQTT broker like you do but I’m not expecting anything from that since I’ve already determined that the username/password combination works and has sufficient read/write access on the required topics.

I’ve connected the panel to the WiFi both via the GUI Manager and the ADB tool. Both ways connect the panel to the WiFi successfully and I can see the connection on the router. The Wifi Router is about 2 meters away from the panel so it can’t be a signal-strength problem either. I’m not using an ethernet connection since I can’t run a cable to the panel.

I’ve been using the alarm panel throughout the different versions now. v1.4.8 was the last version that worked as expected. When v1.4.9 build 1 came out, I burned a new SD card and installed it and immediately ran into some problems. You came out with v1.4.9 build 9 relatively quickly after that. I didn’t have any problems for a couple of days but when I visited my parents again after a week, I saw that the problem had returned.

I’ll try the Android App version in the weekend. I’ll also re-install the 1.4.9 build 9 on the SD card since now it was OTA’d from build 1. Maybe that does something for it.

I just burned and tested v1.4.9 build 9 and I don’t see any connection issues that you describe. I will continue testing, but it makes no sense to work for a few days then stop working. Version 1.4.9 also uses the official Android Things 1.0 release, the things I changed involved screen dimming, I didn’t change the MQTT setup.

If you do see an error message that there is a connection issue popup sometimes this most likely means there must be some intermittent connection issue between the alarm panel and the MQTT broker. It may not have anything to do with your MQTT setup, it could be a network connection issue. Until I see the issue for myself, there isn’t much I can do to help. You may need to revert to v1.4.8 as an option, it will not OTA to v1.4.9.

My other recommendations are to connect with the Android App to test it or build a version of the Alarm Panel for your home and test v1.4.9 build 9 on that device. That would rule out the network in your parents home. I wish I could offer more help.

Don’t worry, you’ve already been a great help in attempting to troubleshoot this issue. I’ll try some more things this weekend and hopefully pinpoint the issue. Thanks again!

After I setup the DarkSky weather and bounced around between the log screen and the home screen, I began to see two popup messages. One was the network was disconnected and the other (as a result of the first) was that the MQTT broker could not be reached.

I need to investigate the issue further and if I find the cause, will issue an OTA update. Hopefully by time you arrive at your parents, the issue will be resolved. I use a development version at home which doesn’t seem to display the issue, but when I make the production version and install it, the issue appears depending on my actions.

Hey, its for los padres… it’s important to fix it!!

1 Like

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 :slight_smile: 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: http://thanksmister.com/android-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!!