Paradox Alarm MQTT Hassio addon

alfredo · November 23, 2018, 9:32am

Hi Everybody,

I suspect there may be a small issue with the current release of the add-on. When the alarm is triggered, it seems the addon crashes, instead of working properly

Sadly, I can’t properly debug the application, because my alarm is connected to a third party, and hence I can’t trigger it freely. Is anyone willing to set up and help with the debugging?

First step would be to see if you can reproduce the issue. This is easy: trigger your alarm, and check whether the addon works properly going into the “in alarm” state, or if it becomes unavailable. If you can reproduce the issue, sharing the logs would be the first step, and I’d be happy to guide you further down road from there. Feel free to share the logs as private messages, if you’re concerned they may contain sensitive information.

Thank you in advance!

RKor · November 23, 2018, 10:25am

Give me a few days and I’ll try to set up my siren delay (if there is a way) and also test out the plugin.

Thanks for the advice @alfredo

xessiv · November 25, 2018, 2:32pm

You can probably set a delay with Babyware - http://www.paradox.com/Download/Babyware.asp?CATID=199
Let us know how you go, as I’m wanting to do something similar! I read in a manual somewhere that it was possible to set a delay on the alarm, and then what I was thinking was to have an automation go something like:

if alarm state is away and
if a sensor state goes to on then
play voice etc

And set the alarm delay so that it starts a little bit after your voice finishes. Would need some testing but should do the job

alfredo · November 27, 2018, 11:20pm

You may just want to turn this:

if alarm state is away and

if a sensor state goes to on then

into:

If alarm state is triggered

so that the logic that triggers the alarm would remain confined within the Paradox alarm itself (it may trigger with different sensors and delays according if it’s armed away/home, and you don’t want to duplicate that configuration across the paradox and home assistant)

RKor · November 28, 2018, 6:37am

Hi Alfredo,

I had a chance to trigger the alarm today.
Unfortunately the state of the sensor does not change to triggered, just stays as armed away. Nothing in the log.

Then I tried it again, weirdly what I could see in the logbooks was all automations and sensors started switching off and then Home Assistant Stopped after a few seconds Home Assistant Started
Again, nothing in the log

I have different issue, when trying to send alarm_control_panel.alarm_trigger I get this

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/homeassistant/helpers/service.py", line 224, in _handle_service_platform_call
    await getattr(entity, func)(**data)
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/homeassistant/components/alarm_control_panel/__init__.py", line 138, in alarm_trigger
    raise NotImplementedError()
NotImplementedError

I’m also getting [Errno 9] Bad file descriptor in addon logs

alfredo · November 28, 2018, 9:40pm

Hi RKor,

Sadly, my suspects of an issue seem to be confirmed. Lack of clear error messages is going to make debug more difficult, but I’ll give this a deeper look. I also got the

message from the addon. It seems related to the MQTT library I used in there – yet the culprit seems to be related to some other error happening earlier, when the alarm is triggered.

For completeness, the behavior of the

is expected: the Home Assistant MQTT control panel does not support triggering the alarm intentionally (hence the NotImplementedError() ). This is not a major issue, since to my knowledge the Paradox alarm also cannot be triggered by the IP150 web interface, so even if the Home Assistant panel did support that, I could not implement that functionality in my addon

I’ll be taking a deeper look at the alarm triggering issue, and possibly come back with further experiments. What would be definitely useful for me, would be for you to stop the addon, log into the Paraox IP150 web interface, and get a capture of the HTML and Javascript code that runs on your browser when the alarm is triggered. I basically need to know how that web page looks like when the alarm is triggered, so that I can instruct the addon to read that information, and pass it over to Home Assistant. Anyone that could help with that?

alfredo · November 28, 2018, 11:33pm

Hi @RKor , all,

I believe I’ve figured out the cause generating the issue when the alarm is triggered. I’ve released v0.4 of the addon, which hopefully fixes it. You can update to the latest version with the usual (and painful for now, I know) git pull approach, described above.

If any of you could trigger their alarms, and let me know if that works now, I’d be grateful.

For the curious out there, the issue was probably introduced in v0.2, when I added PIR sensor detection (per @MyCool use case). Previously, I only checked for the Open/Closed state of the alarm PIR sensors. However, it turns out that a Paradox PIR sensor can actually be in 10 different states! For example, if a PIR sensor triggered an alarm, it will be in a “In alarm” state, which is neither Open, nor Closed; similarly, PIRs can be temporarily ignored, which puts them in the “Bypass” state. Previously, such states were not supported, and the addon misbehaved when any PIR entered any such unsupported state – notably this was the case for the “In alarm” state when the alarm was triggered. Luckily, each of such PIR states can be reduced to an “on/off” information, which is what the addon does now: it’s expected to support all PIR possible states, and inform Home Assistant with a simple on/off information.

Let me know your mileage, as always. And happy hacking with Home Assistant!

RKor · November 29, 2018, 12:19am

Hi @alfredo ,

I just tested the 0.4 and triggered the alarm but unfortunately the state still doesn’t change

I got a whole lot of these errors though. 2018-11-29 11:14:11 ERROR (MainThread) [homeassistant.core] Error doing job: Fatal error on transport TCPTransport (error status in uv_stream_t.read callback) TimeoutError: [Errno 110] Operation timed out
I’m hoping that’s related to the plugin and not some other crap on my setup

But I’m not getting [Errno 9] Bad file descriptor in addon logs anymore which is good

dav · December 4, 2018, 5:51pm

what is the problem it don’t work.

raise six.reraise(type(error), error, _stacktrace)
File “/usr/lib/python3.6/site-packages/urllib3/packages/six.py”, line 685, in reraise
raise value.with_traceback(tb)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 601, in urlopen
chunked=chunked)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 387, in _make_request
six.raise_from(e, None)
File “”, line 2, in raise_from
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 383, in _make_request
httplib_response = conn.getresponse()
File “/usr/lib/python3.6/http/client.py”, line 1331, in getresponse
response.begin()
File “/usr/lib/python3.6/http/client.py”, line 297, in begin
version, status, reason = self._read_status()
File “/usr/lib/python3.6/http/client.py”, line 266, in _read_status
raise RemoteDisconnected(“Remote end closed connection without”
urllib3.exceptions.ProtocolError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’,))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “ip150_mqtt.py”, line 137, in
ip_mqtt.loop_forever()
File “ip150_mqtt.py”, line 119, in loop_forever
self.ip.login(self._cfg[‘PANEL_CODE’], self._cfg[‘PANEL_PASSWORD’])
File “/ip150.py”, line 137, in login
‘{}/login_page.html’.format(self.ip150url), verify=False)
File “/usr/lib/python3.6/site-packages/requests/api.py”, line 72, in get
return request(‘get’, url, params=params, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/api.py”, line 58, in request
return session.request(method=method, url=url, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/sessions.py”, line 508, in request
resp = self.send(prep, **send_kwargs)
File “/usr/lib/python3.6/site-packages/requests/sessions.py”, line 618, in send
r = adapter.send(request, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/adapters.py”, line 490, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’,))
Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 601, in urlopen
chunked=chunked)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 387, in _make_request
six.raise_from(e, None)
File “”, line 2, in raise_from
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 383, in _make_request
httplib_response = conn.getresponse()
File “/usr/lib/python3.6/http/client.py”, line 1331, in getresponse
response.begin()
File “/usr/lib/python3.6/http/client.py”, line 297, in begin
version, status, reason = self._read_status()
File “/usr/lib/python3.6/http/client.py”, line 266, in _read_status
raise RemoteDisconnected(“Remote end closed connection without”
http.client.RemoteDisconnected: Remote end closed connection without response
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/lib/python3.6/site-packages/requests/adapters.py”, line 440, in send
timeout=timeout
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 639, in urlopen
_stacktrace=sys.exc_info()[2])
File “/usr/lib/python3.6/site-packages/urllib3/util/retry.py”, line 357, in increment
raise six.reraise(type(error), error, _stacktrace)
File “/usr/lib/python3.6/site-packages/urllib3/packages/six.py”, line 685, in reraise
raise value.with_traceback(tb)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 601, in urlopen
chunked=chunked)
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 387, in _make_request
six.raise_from(e, None)
File “”, line 2, in raise_from
File “/usr/lib/python3.6/site-packages/urllib3/connectionpool.py”, line 383, in _make_request
httplib_response = conn.getresponse()
File “/usr/lib/python3.6/http/client.py”, line 1331, in getresponse
response.begin()
File “/usr/lib/python3.6/http/client.py”, line 297, in begin
version, status, reason = self._read_status()
File “/usr/lib/python3.6/http/client.py”, line 266, in _read_status
raise RemoteDisconnected(“Remote end closed connection without”
urllib3.exceptions.ProtocolError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’,))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “ip150_mqtt.py”, line 137, in
ip_mqtt.loop_forever()
File “ip150_mqtt.py”, line 119, in loop_forever
self.ip.login(self._cfg[‘PANEL_CODE’], self._cfg[‘PANEL_PASSWORD’])
File “/ip150.py”, line 137, in login
‘{}/login_page.html’.format(self.ip150url), verify=False)
File “/usr/lib/python3.6/site-packages/requests/api.py”, line 72, in get
return request(‘get’, url, params=params, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/api.py”, line 58, in request
return session.request(method=method, url=url, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/sessions.py”, line 508, in request
resp = self.send(prep, **send_kwargs)
File “/usr/lib/python3.6/site-packages/requests/sessions.py”, line 618, in send
r = adapter.send(request, **kwargs)
File “/usr/lib/python3.6/site-packages/requests/adapters.py”, line 490, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’,))

alfredo · December 4, 2018, 11:35pm

Hi @RKor,

This is bad news. It seems I’ll need a bit more of your help to have this properly fixed. I’d need to get a copy of your statuslive.html page generated from the IP150 when your alarm is triggered, so that I can see where the issue with my addon is. It shouldn’t contain any sensitive information, but please feel free to share it via private message if you so wish.

To get a copy of that page, if you’re familiar with the Chrome developer tools, you can:

Stop the paradox hassio add-on (otherwise you won’t be able to connect to the IP150 web interface)
Open Chrome and put the IP address of your IP150 module in the address bar; login with the same credentials you currently use for the add-on
Turn the Chrome developer tools on
Arm your alarm, and trigger it. Make sure the IP150 web page displays the alarm as triggered.
From the Chrome developer tools, use the debugger icons to pause the execution of the website
Then, under the Sources tab, navigate to the top -> liveframe -> statuslive.html page, and dump its contents.

If you could also share the firmware version of th Panel and the IP module, that would be useful. It’s under the System Info page on the web interface.

The above should give me something to chew!

The TimeoutError you’re reporting may be unrelated, as I see on this post that you were having this issue three days before I posted the 0.4 update?

hybrix · December 7, 2018, 5:53pm

Ciao,

First of all, thanks to the code developer!!

I’ve been able to configure mqtt, homeassistant (without hassio) and ip150_mqtt so that Homeassistant gets the status of the alarm with a sensor or with alarmpanel. My issue is that I find impossible to make my ip150 to get orders from homeassistant for arming/disarming the alarm. Could you help me? Which logs am i supposed to share?

Thanks

cesareino · December 8, 2018, 11:53pm

Hi Alfredo,
great code, thank you very much for your work.
PIR sensors, Availability and Area status work nice when configured as mqtt sensors.

I found a strange behaviour but it seems to be related to alarm_control_panel platform.
When i use it with mqtt platform, the buttons to arm/disarm are missing

This is my configuration
alarm_control_panel:

platform: mqtt
qos: 0
state_topic: paradox/alarm/state/1
command_topic: paradox/alarm/cmnd/1
name: Paradox
availability_topic: paradox/ctrl/state
payload_disarm: ‘DISARM’
payload_arm_home: ‘ARM_HOME’
payload_arm_away: ‘ARM_AWAY’
code: ‘xxxx’

When using the same configuration with platform manual_mqtt controls are shown but I cannot arm my alarm.
The payload ARM_AWAY/ARM_HOME is never published to the command_topic (I used MQTT.fx to subscribe to the topic).

Conversely when publishing the payload on the command topic with MQTT.fx, the alarm is armed.

Thanks for any suggestion to solve this.

alfredo · December 9, 2018, 6:28pm

Hi Cesareino,

It seems your mqtt alarm panel says the alarm is unavailable (“non disponibile”). Hence the arm buttons are disabled.

You should probably set the “payload_available” and “payload_not_available” parameters in config.yaml to match the availability value sent out by the ip150_mqtt.py software. The full documentation is at Mqtt alarm control panel

MQTT.fx should allow you.to learn what such values are.

By the way, be aware there seem to be an issue with my piece of software when the alarm is triggered. The home assistant status is not updated, and I’m not sure what’s wrong there. Unfortunately, I can’t debug this as I can’t freely trigger my own alarm.

I need some volunteer helping with debug. I’ve shared some instructions above. Also, if you could let me know what mqtt messages are sent, or any error message issued by the ip150_mqtt.py, when the alarm is triggered, that would help me big time in fixing this once and for all.

Hopefully this will help!

Cheers,
Alfrefo

alfredo · December 9, 2018, 6:32pm

Hi hybrid,

This looks mostly like a mismatch between topics and payload, between what is sent by home-assistant and what is expected by ip150_mqtt.py. My first guess would be double checking the config.yaml and set all values for topics and payloads.

cesareino · December 9, 2018, 8:00pm

The issue is related to the state_topic that is not correctly updated.
I noticed that when restarting Hassio the state is ‘unavailable’.
When the alarm is armed from the Paradox mobile app, the state is updated to ‘pending’ then to ‘armed away’ and the button to disarm became active (see picture).
When disarming from the Paradox app, the status on hassio is not updated and nothing is published on the state_topic so hassio thinks that the alarm is still armed. If I try to disarm anyway, the state keeps being ‘armed away’.

I’ll try doing the test ASAP and send you the statuslive.html page dump.

Cheers

tdgroote · December 10, 2018, 9:11pm

First of all: thanks a lot for the development of this addon.

I have a similar problem as mentioned above: the state of the alarm is not always reflected correctly in the MQTT. When I turned the alarm on, it correctly changed states to alarm_away. After turning it off with the app (on iOS) it did not change the MQTT state. When turning off the alarm with the control panel it changed it to “pending”.

Any idea where I should look to help you debug it?

hybrix · December 14, 2018, 10:24am

With below configuration, I’m able to get the status of the alarm correctly updated in homeassistant when I arm/unarm, but I’m unable to ARM the alarm from Homeassistant:

CONFIGURATION.YAML:
mqtt:
broker: 127.0.0.1
port: 1883
username: XXXXXXX
password: XXXXXX
discovery: True
sensor:

platform: mqtt
state_topic: “paradox/alarm/state/1”
name: “Alarm”
alarm_control_panel:
platform: mqtt
name: Paradox
state_topic: “paradox/alarm/state/1”
command_topic: “paradox/alarm/cmnd/1”
payload_disarm: “DISARM”
payload_arm_home: “ARM_HOME”
payload_arm_away: “ARM_AWAY”

OPTIONS.JSON
{
“IP150_ADDRESS” : “http://192.168.1.170:8047”,
“PANEL_CODE” : “XXXXXXX”,
“PANEL_PASSWORD” : “XXXXXXX”,

"MQTT_ADDRESS" : "mqtt://127.0.0.1",
"MQTT_USERNAME" : "XXXXX",
"MQTT_PASSWORD" : "XXXXXXX",

"ALARM_PUBLISH_TOPIC"   : "paradox/alarm/state",
"ALARM_SUBSCRIBE_TOPIC" : "paradox/alarm/cmnd",
"CTRL_PUBLISH_TOPIC"    : "paradox/ctrl/state",
"CTRL_PUBLISH_TOPIC"    : "paradox/zone/state",
"CTRL_SUBSCRIBE_TOPIC"  : "paradox/ctrl/cmnd"

}

Thanks!

xessiv · December 14, 2018, 11:02am

I have two different zones that I arm/disarm. If you only have one, then you just need the first one of each section.
Place the following in your configuration.yaml

alarm_control_panel:
  - platform: mqtt
    state_topic: "paradox/alarm/state/1"
    command_topic: "paradox/alarm/cmnd/1"
    payload_disarm: "DISARM"
    payload_arm_home: "ARM_HOME"
    payload_arm_away: "ARM_AWAY"
    qos: 1
    name: "Control State Home"
  - platform: mqtt
    state_topic: "paradox/alarm/state/2"
    command_topic: "paradox/alarm/cmnd/2"
    payload_disarm: "DISARM"
    payload_arm_home: "ARM_HOME"
    payload_arm_away: "ARM_AWAY"
    qos: 1
    name: "Control State Garage"

and then this is what I have in my groups.yaml for the arm/disam ‘sensor’

Alarm:
  name: Alarm
  icon: mdi:alarm-light
  view: yes
  entities:
  - alarm_control_panel.control_state_home <---- This one arms/disarms
  - alarm_control_panel.control_state_garage <---- This one arms/disarms
  - sensor.alarm_state_home
  - sensor.alarm_state_garage
  - sensor.master_br
  - sensor.bedroom_2
  - sensor.bedroom_3
etc

It took me a while to understand it as well, but this is what is working for me. See how you go

hybrix · December 14, 2018, 6:00pm

Hi Xessiv, just tried your config without sucess with the issue that I can’t arm/disarm from homeassistant:

Groups.yaml:
Alarm:
name: Alarm
icon: mdi:alarm-light
view: yes
entities:

alarm_control_panel.paradox

configuration.yaml:
alarm_control_panel:

platform: mqtt
name: Paradox
state_topic: “paradox/alarm/state/1”
command_topic: “paradox/alarm/cmnd/1”
payload_disarm: “DISARM”
payload_arm_home: “ARM_HOME”
payload_arm_away: “ARM_AWAY”
qos: 1

I feel completely lost on how to fix arming/disarming issue
Thanks

alfredo · January 3, 2019, 3:04pm

Hi All,

I’ve recently released version 0.5 of the add-on. It fixes several issues with the add-on not informing home-assistant when the alarm was triggered, or disarmed under certain circumstances. A few corner-cases remain uncovered, and a new version may be released once they are fully addressed, if necessary. In the meantime, you can update with the usual (still painful!) process, described above.

Many kudos go to @cesareino for proactively helping with debugging. This release wouldn’t have been possible without his continued support (and patience!).

I believe, in the future, this add-on should actually turn into an home-assistant component. All the code, required factoring and logic is there, it only needs to be ported to the home-assistant code-base. Unfortunately, I lack time and home-assistant specific development experience to make this happen. So, let me call for volunteers that would like to help on this! I’ll be happy to provide advice and support on the current code-base, and share the experience I’ve gathered so far!

Cheers, and happy new year!