Install MQTT Explorer
1/ Select paradox
2/ Click on the trash
Thanks, that did it (easier for me)
I kept what @AhmadK suggested
Listen to a topic
Listening to
#
Message 2 received on paradox/alarm_status/2 at 9:50 PM:
disarmed
QoS: 0 - Retain: true
Message 1 received on paradox/alarm_status/1 at 9:50 PM:
stopped
QoS: 0 - Retain: true
Message 0 received on paradox/status at 9:50 PM:
offline
that’s cool, your alarm publishes its status as far as I can see so it’s possible to configure the MQTT alarm.
you should see messages about zones but they should not have retained flag.
I had hard time trying to figure out what code you’re using as you kept switching between two of them.
I presume you’re using this Paradox Controller
The reason why your alarm is in Unknown state lack of messages in paradox/status topic - normally it’s a retained message like online when it’s online and offline otherwise but if there is no such message at all , HA shows it as unavailable until is sees something in that topic.
So until you make your Wemos publish its status in availability topic, nothing will work. (Update - I can see it now, see below)
Did you see the note at the bottom of the Github page?
There are also several reasons why it;s not working for you - different alarm firmware version, errors in Paradox Controller code, configuration of your physical alarm and so on.
Let see how it works on Tuesday but my advice is to try getting messages in availability_topic.
Actually, if you commit/remove that availability_topic string, HA will always assume it’s available and therefore it’ll pick up and display its status like Disarmed/Armed_away/Triggered. (but don’t do it if you can see valid messages in the availability_topic
By the way, looks like you have 2 partitions so when you’re done with sorting out partition 1, don’t forget to add the 2nd one as well as per Github.
OK, from your MQTT messages I can see that at 9:50 PM you disarmed the 2nd partition, siren in the 1st partition was switched off and then your Controller disconnected from the broker (but for some reason it’s the other way round…) Looks like alarm_status es are retained (as it should be) but status is not (but I think it should for HA to consider it as available and therefore enable its functionality) or you just didi not include it when copied/pasted as I can see its retain: true in your previous posts.
I have to say that generally you chose one of the most unreliable ways (WiFi) of connecting the alarm to HA. You’ll get all sorts of issues here and therefore it’s very difficult to troubleshoot - for example, I can only guess why exactly it disconnected (and you yourself would have hard time figuring that out, too).
So my advice is to find a way of wired connection between tour HA and the physical alarm - search this forum as many people integrate their alarms with HA (I cannot help here as I have only HA-based alarm).
And if you wish to stick with it - well, looks like now you can see the status of your alarm and set/disarm it and you just need to sort out that zones problem. Not bad… 
Thanks a lot for your help and suggestions. I will have a carefull look in the morning. Right now I am running HA in rp3+ but after the installation of the alarm combined with other devices I added lately I am noticing that it takes for ever to restart so I just started to look for a mini pc like nuc. After the setup of the alarm I am going to read and learn about linux I guess.
About the wired connection which I would prefer also Its just not possible.The alarm is far away from the rp3 hidden in a closet
me @ RPi3+, too. Not a beast for sure bot not forever. SD card failure is your main enemy, especially with a lot of sensors and recorder enabled so be warned.
NUC/laptop is a good idea but it’s advanced, not sure you need it right now… but who knows.
O M G NO! 
yeah, shit happens :\
You are right I am using Paradox Controller
As I said right now everything is disconnected. Yesterday I changed my configuration like below but I am not able to test it. I only have one partition so I don’t yet why it is reporting for the second partition
I will check it again as soon as I reconnect it.
This is my config yaml. I added availability (as I thought I should be) . does it look ok?
alarm_control_panel:
- platform: mqtt
name: paradox_alarm_partition_1
unique_id: paradox_alarm_partition_1
state_topic: "paradox/alarm_status/1" ## The MQTT topic subscribed to receive state updates.
command_topic: "paradox/action/1" ### The MQTT topic to publish commands to change the alarm state.
availability_topic: "paradox/status" ### The MQTT topic subscribed to receive availability (online/offline) updates.
payload_available: "online"
payload_not_available: "offline"
payload_arm_away: "armed_away"
payload_disarm: "disarmed"
retain: false
One more advice if you know.
In the zones setup I have movement sensors which I set them as (device class) “motion”
I set the covers as" window"’ (is it ok?)
and I set the siren as “vibration” which seemed logical at the time but I am not sure right now…
yes, unless your alarm is unable to indicate its availability I believe it’s a good idea to know when it’s connected.
well… it won’t work based on messages you posted before. check it out what’s posted in paradox/alarm_status/1 and guess what HA should show you?
And the last string of your config… did you read the docs? What’s that?
I don’t know what other options are available. Door/window is ‘open’/‘close’ so if it suits you and your cover can report its state as ‘open’/‘closed’ then it’s ok I presume.
Well, until you sorted your setup out there is no need to use sired and you can rely upon alarm’s status MQTT messages but don’t leave your house like that for a year
I added the last string because of the following and based on another configuration I I found in the forums. I think that it is needed - (It was set on true yesterday)
if not please tell me to completely remove it
“” The mqtt alarm panel platform enables the possibility to control MQTT capable alarm panels. The Alarm icon will change state after receiving a new state from state_topic . If these messages are published with RETAIN flag, the MQTT alarm panel will receive an instant state update after subscription and will start with the correct state. Otherwise, the initial state will be unknown “”
you need to understand what you’re doing, not to believe someone else as it’s not a religion.
- there is no
retainconfiguration variable for MQTT Alarm Panel so what do you expect by adding that? -
retainis a parameter of a message so the sender should set that (Paradox Controller) and as far as I can see in your previous posts messages inparadox/statusdo have it set totrue(don’t they?)
I see, you are right. delete it 
So, before a while the technician left.
The good news: The alarm is integrated to HA and everything is reported as it should be.
The bad news: I needed to add to the alarm system GPRS capability. (in case the wifi/phone goes down to be able to report to the security center). The gprs module is connected to the one port that it’s available and is the same with wemos d1… 
Unless we find a way to connect them simultaneously I will have to choose which one should be connected and which is not… shit happens I guess
what was the problem in connecting them both to that port? did you ask?
Well, the technician didn’t know for sure. We did try to merge the wires in the exit of the pins but both modules went offline. He said he we will ask the local paradox company to set if there is a way, but he is not so optimistic. We added a universal gprs module “trikdis g16” which comes with it’s own app so I can control it ooh but I really like to insert it in HA
I’d recommend to ask for help at forums discussing the Arduino sketch on your Wemos - looks like you need to find a way of splitting the port’s signals… so it has nothing to do with MQTT anymore, it’s a hardware problem.
1 Like
Yes, I already looking for a solution about it.
Meanwhile, I added only the wemos in the alarm and I just noticed that although all the zones are reporting fine there is a problem with the alarm panel in fronted.
When I manually arm the alarm in sleep mode for example it shows in status away and I can not disarm it. When I am trying to arm the alarm from fronted it doesn’t respond.
I have kept the original configuration yaml as per example of the github. (which worked 2 days ago)
alarm_control_panel:
- platform: mqtt
name: paradox_alarm_partition_1
unique_id: paradox_alarm_partition_1
state_topic: "paradox/alarm_status/1"
command_topic: "paradox/action/1"
availability_topic: "paradox/status"
and this is the log file from MQTT
Any ideas how to debug it?
Listen to a topic
Listening to
#
Message 13 received on paradox/event/trigger_zone at 8:42 AM:
0
QoS: 0 - Retain: true
Message 12 received on paradox/event/zone/8 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 11 received on paradox/event/zone/6 at 8:42 AM:
1
QoS: 0 - Retain: true
Message 10 received on paradox/event/zone/11 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 9 received on paradox/event/zone/10 at 8:42 AM:
1
QoS: 0 - Retain: true
Message 8 received on paradox/event/zone/9 at 8:42 AM:
1
QoS: 0 - Retain: true
Message 7 received on paradox/event/zone/2 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 6 received on paradox/event/zone/3 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 5 received on paradox/event/zone/5 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 4 received on paradox/event/zone/4 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 3 received on paradox/event/zone/1 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 2 received on paradox/event/zone/7 at 8:42 AM:
0
QoS: 0 - Retain: true
Message 1 received on paradox/alarm_status/1 at 8:42 AM:
disarmed
QoS: 0 - Retain: true
Message 0 received on paradox/status at 8:42 AM:
online
QoS: 0 - Retain: true
I don’t get it because you use unknown terminology. Could you elaborate?
And is the MQTT log relevant to it (I presume it isn’t)?
Sorry, english is not my native language.
I mean that the alarm card in the fronted isn’t responding (almost at all) I can not arm or disarm the alarm from fronted. see picture below. The alarm is armed but I can not disarm it with the disarm button. With the same setup and configuration I could (2 days before)
what happens exactly? can you see any MQTT messages when you’re trying?
I disarm it with keyboard. alarm panel receive the message
I just tried to arm it. Mqqt has the commands but it didn’t arm the alarm
Listen to a topic
Topic to subscribe to
#
Message 21 received on paradox/event/zone/3 at 9:03 PM:
0
QoS: 0 - Retain: false
Message 20 received on paradox/action/1 at 9:03 PM:
ARM_NIGHT
QoS: 0 - Retain: false
Message 19 received on paradox/action/1 at 9:03 PM:
ARM_NIGHT
QoS: 0 - Retain: false
Message 18 received on paradox/action/1 at 9:03 PM:
ARM_AWAY
QoS: 0 - Retain: false
Message 17 received on paradox/action/1 at 9:03 PM:
ARM_HOME
QoS: 0 - Retain: false
Message 16 received on paradox/event/zone/3 at 9:03 PM:
1
QoS: 0 - Retain: false
Message 15 received on paradox/event/zone/3 at 9:03 PM:
0
QoS: 0 - Retain: false