Paradox Alarm MQTT Hassio addon

@wojcior1 @ddppddpp …and I’m also experiencing the stability issues you’re describing, and I’ve indeed mapped them back to the hassOS 8.1 update. See the history below: the red circle indicates the moment I updated to hassOS 8.1. Prior to that, the sensor is fully stable. After the update, you can see small grey ‘unavailable’ moments, which indicate the instability.

I’ve looked at the add-on logs, and they show some “operation timeout” errors:

Exception in thread Thread-1:
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/urllib3/connection.py”, line 156, in _new_conn
conn = connection.create_connection(
File “/usr/lib/python3.8/site-packages/urllib3/util/connection.py”, line 84, in create_connection
raise err
File “/usr/lib/python3.8/site-packages/urllib3/util/connection.py”, line 74, in create_connection
sock.connect(sa)
TimeoutError: [Errno 110] Operation timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 665, in urlopen
httplib_response = self._make_request(
File “/usr/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 387, in _make_request
conn.request(method, url, **httplib_request_kw)
File “/usr/lib/python3.8/http/client.py”, line 1255, in request
self._send_request(method, url, body, headers, encode_chunked)
File “/usr/lib/python3.8/http/client.py”, line 1301, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File “/usr/lib/python3.8/http/client.py”, line 1250, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File “/usr/lib/python3.8/http/client.py”, line 1010, in _send_output
self.send(msg)
File “/usr/lib/python3.8/http/client.py”, line 950, in send
self.connect()
File “/usr/lib/python3.8/site-packages/urllib3/connection.py”, line 184, in connect
conn = self._new_conn()
File “/usr/lib/python3.8/site-packages/urllib3/connection.py”, line 168, in _new_conn
raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7fb5f6b50940>: Failed to establish a new connection: [Errno 110] Operation timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/lib/python3.8/site-packages/requests/adapters.py”, line 439, in send
resp = conn.urlopen(
File “/usr/lib/python3.8/site-packages/urllib3/connectionpool.py”, line 719, in urlopen
retries = retries.increment(
File “/usr/lib/python3.8/site-packages/urllib3/util/retry.py”, line 436, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host=‘10.0.100.20’, port=80): Max retries exceeded with url: /keep_alive.html?msgid=1 (Caused by NewConnectionError(‘<urllib3.connection.HTTPConnection object at 0x7fb5f6b50940>: Failed to establish a new connection: [Errno 110] Operation timed out’))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/usr/lib/python3.8/threading.py”, line 932, in _bootstrap_inner
self.run()
File “/ip150.py”, line 29, in run
self._one_keepalive()
File “/ip150.py”, line 24, in _one_keepalive
requests.get(‘{}/keep_alive.html’.format(
File “/usr/lib/python3.8/site-packages/requests/api.py”, line 75, in get
return request(‘get’, url, params=params, **kwargs)
File “/usr/lib/python3.8/site-packages/requests/api.py”, line 60, in request
return session.request(method=method, url=url, **kwargs)
File “/usr/lib/python3.8/site-packages/requests/sessions.py”, line 533, in request
resp = self.send(prep, **send_kwargs)

I tried to reinstall both the add-on, and the MQTT broker (and MQTT integration), to no avail.

I currently have little idea why the OS update would make HTTP connections timeout. I’m sure that if some rate-limit was introduced, this would 1) have been advertised in the changelog and 2) it would be creating way more issues than for just this add-on. Also, it’s strange the “unavailability” moments seem to not have a pattern, and rather being random.

If anyone has ideas to test or to get to the culprit of the issues, I’m happy to hear.

I’m not sure where to start here, but python3.8?
Sorry if this is completely unrelated.

Ah! One would hope that Docker could save you from this kind of pain, but hey :slight_smile: Since we’re clueless about other possible causes, and I haven’t been refreshing the add-on in a while, I’ll give it a go.

Thus far, in a local testing environment, I’ve bumped all the python library dependencies with success. I also noticed that the way you build an HA add-on infrastructure has changed a bit recently, so I’m working on refreshing that, too. I’m currently running the fully refreshed add-on in the local test setup. If it will look stable enough, I’ll release a new version to see how it copes with reliability for a broader audience. :crossed_fingers:

…and I’ve released v1.2 of the add-on, hoping this may improve the recent reliability issues. This release does not change anything about the add-on functionality (I literally didn’t touch a line of its python code). It just updates python dependencies to their latest version, and also uses the latest Home Assistant add-on framework.

The add-on was working perfectly in the local test environment – but crucially in such test environment Home Assistant may not actually run on HassIO 8.1 (as Home Assistant runs on top of the local OS).

Please let me know if you see any improvements with the erratic behavior that was observed recently. In case you still see it, any further information you could provide to pinpoint the issue will be extremely useful. Thanks, and good luck!

I’ve tested v1.2 briefly… without going into the logs there seems to be some improvement but the issue persists- the available/unavailable state change for all Alarm related entities now is manifested every ~ 20mins. With v1.1 it was every minute or so. I’ll let it run for a couple of days to see some trends and maybe look at the logs.

It’s confirmed the add-on changes in 1.2 (were much due but) don’t solve the erratic behavior.

I’ve confirmed the hassOS 8.0 → 8.1 update seems to be causing it. By downgrading back to hassOS 8.0 (ha os update --version 8.0) the problems goes away.

I’ve been looking at the differences between 8.0 and 8.1. Some seem unrelated (like adding support for more wireless dongles). One seemed possibly relevant: the OVA guest agent version has been bumped. But I tried to run hassOS 8.1 without the agent support on the host (so the guest agent would not start at all) and the erratic behavior persisted. I also noticed the kernel has been updated, but I’d be shocked if that had such an effect (and only for this add-on, since the rest of Home Assistant seems to be doing fine!)

For the time being, the workaround is to stick (or downgrade) to hassOS 8.0, while the root cause can be identified and solved.

@ddppddpp @wojcior1 what’s the value if you go to Settings → System → Hardware? (Are you both running on an OVA VM?)

I’ve opened a github issue to see if we can get help nailing this down.

I’m on a odroid-n2 falsely reported as ‘Home Assistant Blue / ODROID-N2’ :slight_smile: so probably not related to the OVA.

Settings → System → Hardware:
“Virtual Machine
ova”
I am using windows 10 and Oracle VirtualBox 6.1.34

Anyone willing to help me connect my Home Assistant to my Paradox IP150, via Anydesk? I tried multiple times, I have read the whole topic and I still get requests.exceptions.ConnectionError: (‘Connection aborted.’, RemoteDisconnected(‘Remote end closed connection without response’))

I’m not sure how the Anydesk component would come into play? For the add-on to work, your Home Assistant installation needs to be able to talk directly to the IP150 module. Typically, they need to be in the same network subnet (other more exotic setups are possible, but usually not recommended.)

hello sorry if I answer you now but aevo lost authentication data… yes I changed raposito using pai-alarm-interface and it worked immediately

I am running supervised on Debian 11 and am also having the unavailable issue with the latest versions of hass. So it doesn’t look like an OS level issue.

I’ve been wanting to have this plugin working for a long time and I’ve never been able to do it, I’ve tried several times for several years without success, and today I’ve decided to make it work even if it costs me my life, well, I’ve managed to make it work, all my problem was where I had copied and pasted the example from the info page, and it turns out that the quotes you used in the example are not valid, in the example you use

“xxxxx” instead of "xxxxx"

big LOL for me :man_facepalming::man_facepalming::man_facepalming:

Having problems with the Paradox IP150 MQTT adapter and HAOS 9.0 (HW Rpi4, Mosquitto broker)?
I have problems with repeated connection drops with the IP150. I found out that drops out are related to OS version, not to HA core of Home assistant. I had no problems on HAOS 8.7 and earlier. Have you any other findings?

1 Like

I’m having this problem too. In the issue on github they are trying to blame it on the version of HassOS, but I’m not even running HassOS, but rather Debian. I never changed anything on the OS version and this issue started happening after some homeassistant upgrades. It definitely has nothing to do with the OS, but despite me repeating this, they continue to act as if it does. It’s starting to look like this just will never get fixed.

1 Like

I have same isue after last updates…

Hi @scstraus I understand your frustration, which is mine, as I’m also affected daily by the issue.

You’re right the problem is present outside of HassOS installations. Since I can only reproduce on HassOS (and the problem consistently appeared updating from 8.0 to 8.1), I’m having a very hard time debugging this, except scrutinizing the HassOS changelog, which is admittedly small.

Have you got a chance of pinpointing the exact update that broke the add-on in your environment? E.g. was it a kernel upgrade, was it a Debian software package? Is there any specific component that you can upgrade/downgrade that makes the issue consistently appear/disappear? That may shed new light on the culprit of the bug, and hopefully allow progress in its fix. Thanks!

Hi Alfredo. I can tell you that it definitely wasn’t a debian software upgrade as I haven’t done one at any time near the appearance of this issue. It was one of the hass upgrades (or perhaps a supervisor upgrade), but I’m not sure which one (I skipped a bunch of versions and did upgraded through about 4 versions rather quickly). It started happening at a similar time to all the other complaints in the forums and github issues, though. And no, I haven’t found any upgrade/downgrady which fixes it. It’s possible it was an MQTT upgrade too, as I pretty much always upgrade my addons soon after a hass upgrade.

After many test the problem is debian 11 supervised, i restore a backup HA (ProxMox) with debian 10 and i make full update at latest ver of HA 2022.9.7. Problem solved, timeout at paradox disappear.

Mosquitto version is 6.3.1.

ha info
arch: amd64
channel: stable
docker: 20.10.18
features:

  • reboot
  • shutdown
  • services
  • network
  • hostname
  • timedate
  • os_agent
    hassos: null
    homeassistant: 2022.9.7
    hostname: knxserver
    logging: info
    machine: qemux86-64
    operating_system: Debian GNU/Linux 10 (buster)
    state: startup
    supervisor: 2022.09.1
    supported: false
    supported_arch:
  • amd64
  • i386
    timezone: Europe/Athens