As suggested by the developer @kevin, I am starting this thread to track the work done to get his MQTT software working with MQTT Alarm Panel. I am very new to MQTT, so be gentle. The installation guide for the alarm panel states the following:
Supported Command and Publish States
Command topic: home/alarm/set
Command payloads: ARM_HOME, ARM_AWAY, DISARM
Publish topic: home/alarm
Publish payloads: disarmed, armed_away, armed_home, pending, triggered (armed_night not currently supported).
I was thinking that following step F to use an MQTT virtual switch would likely be the best route, but then again, I am noob. For reference, this is the Alarm Panel (AP) page:
I'm going to have a read of the information on that website and try and understand better the role of the app. It seems to extend quite a bit beyond just an alarm interface and was created to front end a software alarm solution like HA.
You're right in that the using virtual devices is likely the best way forward. I don't use the keypad/alarm devices in HE but they are supported in the MQTT app, although might need a bit of adaption.
In my case I have a standalone Ethernet connected alarm panel that communicates onto MQTT. It provides quite a lot of information including zone activations (armed and disarmed). It cannot be disarmed via MQTT however (my choice).So my goal is really to get this information into HE and HA. I wouldn't be using HE or HA as my 'alarm'. Do you use HA, just wondering what drew you to this app?
Are you hoping to use HE as an alarm solution - with sensors etc?
Also you could just map the reported alarm status into HE modes if that was useful. The MQTT app fully supports modes.
Node-RED may also become useful here adding some intelligence in the management of topic payloads between HE and MQTT. It interfaces directly to both.
I am using the Konnected alarm panel and use Hubitat Safety Monitor to interact with it....provides alerts, signaling sirens, etc. I had started out with Home Assistant, but was ultimately not able to get to a high comfort level with that platform.
I have a Fire Table mounted on my door and point that to a Sharptools dashboard, but I like the way that the MQTT Alarm Panel presents the keypad and how the UI acts in relation to arming and disarming the alarm.
Right....the alarm panel presents as the initial screen which can be swiped away to show Sharptools. I have been able to make the mqtt virtual switch update the home/alarm/set topic with a payload, but the alarm panel itself does not update in respond to the command. I am looking into this now....
OK - sounds like a plan .. What arms the panel from Hubitat currently - an inbuilt device - a Konnected driver device ? You could try publishing that to MQTT and see what it reveals.
I am not sure what 'direction' the app is running in. When the home/alarm/set command is issued is that payload not provided by the app onto MQTT ? If so the system (HE) monitors that topic and actions accordingly providing a status back on home/alarm.
In which case from HE you publish status to home/alarm and you receive commands from home/alarm/set which would trigger the virtual switch or the alarm set/unset command within the driver.
You I think are maybe publishing to home/alarm/set from HE.
Think of the app as just a user interface - you have to receive commands from it and publish status back to it. It can only control your alarm if you setup the method to do that (via the commands it issues).
I have now installed the app - the above behaviour is correct.
How many modes can your alarm be in ?
I tried to install the Konnected app and drivers but it crashes presumably because I don't have the hardware. Can you send me a scren grab of the device that you use to control (set/unset) the alarm so i can see the commands available and attributes.
When the home/alarm/set command is issued is that payload not provided by the app onto MQTT? It does, but right now I just want the mqtt virtual switch to be able to change the alarm panel app. I see the change on the broker, but this does not reflect on the app.
If I can use the MQTT switch, then I can just make a rule that arms the alarm when the swich is "on". This action also publishes to topic home/alarm/set = "ARM_HOME". The developer of the tablet app says that the panel is not seeing that change which doesn't make sense to me since I can change between disarm and armed on the panel and see this reflected on the broker.
Yes it is - or any other device that chose to control the alarm via MQTT
That is because the app gets and displays the alarm status from the home/alarm
MQTT topic and that needs to be maintained by HE to show the current state of the alarm. So the app knows the command was actioned. Currently I suspect you're not providing that status to MQTT ?
Are you seeing this in the home/alarm topic or home/alarm/set - the 'status' of the panel needs to be sent by HE to the home/alarm topic and is one of these: disarmed, armed_away, armed_home, pending, triggered (armed_night not currently supported)
The commands accepted are one of the following in the home/alarm/set ARM_HOME, ARM_AWAY, DISARM
You see armed as a payload on MQTT - where ? That's not a supported value that could be sent from the app.
Do you have MQTT Explorer installed - I really recommend that app ? I guess you have something as you see MQTT payloads
Can we just recap what you want to happen here. You want a switch in HE that turns on or off when the system is requested to arm/disarm from the Android app ?
There are two arm states though and one disarm.. Do you only use one armed state ?
I don't think i will need to use arm_home along with arm_away and disarm, but since the switch only has the two states, I would need to figure out how to handle three states. Thanks again for all the help! Have to take a break on this now, but will hopefully look at it again in a few hours.
almost .. it does not set the above - pressing arm or disarm in the Android app sets that - HE shouldn't set that as it can arm/disarm the system directly
I have created two virtual switches one is for the "Alarm Arm Request" (../set) from your Android app. In this your switch_Topic wants to be the home/alarm/set topic
The device will turn on when an arm_home is asked for and off when a disarm is requested (after entering your code) You need to pass the switch state of this device using RM into whatever arms your alarm on HE
There's a second virtual switch device I called "Alarm State" which must be updated (using RM) from your alarm to be on when the alarm is set and off when unset. This then updates the Android app with the current state.
In this when on or off it updates the home/alarm topic on MQTT and the Android app will instantly show this new state.
Now your task is just to link these two virtual switches using RM so that they control and get status from the Konnected drivers.
There are obvious improvements - we need a three state device rather than a virtual switch (two set modes & disarmed) and we may be able to interact with the Konnected driver directly depending on what it exposes when enabled on MQTT.
I have tested the above (in my case by linking the "Alarm Arm Request" device to the "Alarm State" device via a 5 second delay to simulate) and it works...
I do quite like the Android UI, obviously you can push other info like weather into it too via MQTT.
BTW The developer of this app is sending the .../set command payload to MQTT 'retained'. This is not advisable and should be changed to 'not retained'. Are you in contact with them ?
I only posted a bug on the github for the app and the developer replied back to explain how what I was seeing was not an issue with the app. I am sure I gave him a bit of frustration. Feel free to add an enhancement request.
I don't HSM but does your Konnected install use that at all?
Does Konnected link with the HE Mode?
I am thinking of adding HSM support to the MQTT app.
