I did a few builds and tests with production and I think I have it in a stable place. I pushed out v1.4.9 build 9 today which I am also using on my on RPi3. I think you want to be sure you have a valid WiFi connection even if you have to use the command line to setup the WiFi connection. Also be sure that you are only entering the IP address for your MQTT broker (192.168.86.xxx) and not http/https as you would with CloudMQTT. However, I don’t expect you to spend more time testing. So skip this build if you are happing with v1.4.8 and its stable for you. Thanks!
Thanks! I’ll test it out over the weekend 
Seems to be working now for a few days. I consider the matter fixed
Anybody get this to work with smartthings smart home monitor through the smartthings mqtt addon on hass.io?
Unfortunately, the problem came back after a couple of days. I’ve done more investigating and this is what I noticed so far:
The alarmpanel (running on a RPi3) is connected to the WiFi successfully (done both via GUI and ADB).
Dark weather API works, NTP works and the connection to the MQTT broker works. I verified this by manually connecting to the local MQTT broker. I’m not using SSL and/or certificates to keep it simple.
Here’s what I do, it goes wrong at step 7:
- The alarm is disarmed and I use the alarmpanel to set it to armed_home.
- I see the armed_home message pop up on the MQTT broker in the home/alarm topic.
- Home assistant picks up the message and changes the alarm state to “armed home”.
- I try to disarm the alarm again via the alarmpanel by entering the code
- I see the disarmed message pop up on the MQTT broker in the home/alarm topic
- Home assistant disarms the alarm
- the alarmpanel still shows the “armed home” state. It doesn’t go back to disarmed!
- I enter the settings menu and then go back. I see a quick flash of an error saying it could not subscribe to the MQTT topics. the errors disappears so quickly I had to do a burst shot photo just to capture it.
- Now if I powercycle the panel, it comes back up in the disarmed state.
Configuration on the alarmpanel and Home assistant are identical. State topic is set to home/alarm and command topic is home/alarm/set. Any idea what could be causing this?
Edit: I was running Home assistant 0.63 because I was still running Python 3.4. I’ve upgraded from Jessie to Stretch, upgraded to Python 3.5.3, created a new venv and installed home assistant 0.72.1 and upgraded mosquitto MQTT to stretch as well but I still have the same problem 
I enter the settings menu and then go back. I see a quick flash of an error saying it could not subscribe to the MQTT topics. the errors disappears so quickly I had to do a burst shot photo just to capture it.
That is just a connection error when it sees inits the MQTT client after returning from the settings.
I am running the same exact version as you and haven’t encountered the issue. I looks as though from the steps when Home Assistant receives the “disarmed” message, its not sending back out the “disarmed” message to the Alarm Panel.
Can you possibly test this by sending out the disarmed command from HASS using the MQTT developer tool to send back the disarmed message when it gets into the “armed_home” stuck state? It’s mqtt.publish for the service and the packet looks like this:
{
"payload": "disarmed",
"retain": true,
"topic": "home/alarm"
}
If its not received then the connection to the HASS MQTT service is somehow broken. If it works then HASS isn’t sending out the disarmed topic when it is disarmed.
This is the issue point:
the alarmpanel still shows the “armed home” state. It doesn’t go back to disarmed!
HASS must send back the disarmed message and the device must have a network connection and receive the disarmed message in order to change the state of the alarm to “disarmed”. So since it worked for about a week, we seem to have an intermittent network issue or some issue in HASS that is not sending the information.
I am for now ruling out an issue with the Alarm Panel because a) it worked for a week then stopped working and b) I have the same setup and never experienced this issue. It’s also impossible for me to duplicate your setup with network and HASS in order to duplicate the issue, especially if it appears after a week.
Your suggestion to manually send the disarm payload gave me an idea. I subscribed to both the home/alarm and /home/alarm/set topic to see what happens. So I powercycled the panel again to get it back to disarmed and started from there.
I run two terminals to subscribe to the topics:
mosquitto_sub -t home/alarm -u mqtt -P mqtt -h 192.168.1.130 -p 1883
and
mosquitto_sub -t home/alarm/set -u mqtt -P mqtt -h 192.168.1.130 -p 1883
- I tap the alarmpanel and set to to armed home.
- The home/alarm/set topic publishes ARM_HOME (from the panel)
- The home/alarm topic publishes armed_home (from home assistant)
- The alarm state in home assistant changes to “armed home”
- the alarm panel changes to the yellow icon, “armed home”
- I tap the alarmpanel and input the disarm code
- The home/alarm/set topic publishes DISARM (from the panel)
- The home/alarm topic publishes disarmed (from home assistant)
- The alarm state in home assistant changes to “disarmed”
- The alarm panel stays on the yellow “armed home” icon
So the messages get published but the alarmpanel doesn’t seem to read/see/react to them. So I tested this as well:
- powercycled the panel and verified that the alarm is currently disabled
- Changed the alarm state from home assistant from disarmed to armed home
- The home/alarm state topic publishes disarmed (from home assistant)
- Nothing on the home/alarm/set topic
- The alarm panel stays on the green “disarmed” icon
- Home assistant shows the alarm has changed to “armed home”
From the alarmpanel I’ve configured the following settings:
MQTT broker: 192.168.1.130
unchecked SSL/TLS
Service Port: 1883
Username: mqtt
password: mqtt
Client ID: alarmpanel-1
Alarm Command: home/alarm/set
Alarm Topic: home/alarm
On Home assistant I’ve configured the MQTT connection as follows:
broker: 192.168.1.130
port: 1883
client_id: hassbian-1
keepalive: 60
username: mqtt
password: mqtt
My mosquitto.conf file is this:
pid_file /var/run/mosquitto.pid
user mosquitto
port 1883
listener 9001
protocol websockets
persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto/
allow_anonymous false
password_file /etc/mosquitto/pwfile
Anything different from your side on this?
I am not using a custom Client ID.
I don’t know where you are getting access to your mosquitto.pid file, I use hass.io and don’t see it. Here is my hass.io setup for mqtt:
{
"plain": true,
"ssl": false,
"anonymous": true,
"logins": [],
"customize": {
"active": false,
"folder": "mosquitto"
},
"certfile": "fullchain.pem",
"keyfile": "privkey.pem"
}
I am using the component Manual MQTT Alarm control panel - Home Assistant which I think is required for the alarm if you want to publish the states from changing the alarm mode in the component from the HASS front end.
Here is my setup:
# Manual Alarm
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
I can’t help debug your MQTT setup unfortunately without duplicating everything. But something is either never connecting the panel to the alarm or breaking the communication. I don’t have enough experience to know with setting up MQTT to see if there is some issue with login or client id’s or something else. How did this work for week then?
Are you publishing the states as retained? I still am confused what you are using in HASS as the alarm control panel if you are not using the Manual MQTT Alarm Control Panel component? It doesn’t work with just the MQTT Alarm Control Panel. What HASS component are you using?
If you have an Android device, you might also want to try the Alarm Panel Android application to see if you get the same results. That has 1000’s of users and no reported issues. You can grab it from Google Play search for MQTT Alarm Control Panel. Give’s you another sanity test.
I used to run this setup at home but I’ve sold that house and bought a new one. That one is still being built and my current, temporary house has an alarm system already. My parents still use your alarmpanel in combination with Home assistant and its their setup i’m trying to debug here. I got there twice a week to help them build out their smarthome setup, including the alarm.
I’m using the same Manual alarm MQTT component as you but since I’m using Hassbian, I also have to configure the MQTT broker connection itself. This has all worked flawlessly up until 1.4.8. It wasn’t until 1.4.9 that I started seeing these issues. The home/alarm topic retains the last state as it should and I can see it does when I subscribe to the topic as it shows me the last state of the topic.
The Android App is a good tip. I’ll connect it and see if that does work as expected. I’ll get around to that on Saturday hopefully.
Well, try with the basic setup. You have changed the client ids from the defaults and you have a username/password set for your MQTT setup. Try it without a username/password (its behind a firewall anyways right?) and remove any dashes or strange characters from the client id. Not sure if there needs to be a specific client id set for the MQTT broker. That’s the only thing different that I can see with my MQTT. But first try using the Android application with your current setup and see if it works. I am still confused why you thought it worked for a couple weeks then stopped after the v1.4.9.9 release.
Something else also changed with v1.4.9. There is now a WiFi manager setup in the settings. Can you check that the WiFi settings are correct in settings. This may be some issue with disconnecting from the network. Also, Android Things doesn’t support using both WiFi and Ethernet connections. I am doing a fresh install of the latest v1.4.9 to look for any issues.
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!