Qolsys IQ Panel 2 and 3rd party integration

Restarting AppDaemon on a schedule is a band-aid, and band-aids are rarely a good idea. If you pay attention to the issue at hand, you’d realize that will only continue their problem because the panel triggers iptables throttling after too many reconnects. Restarting AppDaemon on a schedule will guarantee this problem stays around forever!

superpaul, you should post your logs here, and get help that way. We can’t assist without some concrete information to look at. I think you may need to activate a higher logging level. Then, check the HA Core logs and post that too.

I also suggest you don’t try to go BACKWARDS in time and re-question territory that’s already been dealt with by much more knowledgeable people. The panel throttles connections after a while. Fact. They looked at the driver code. I think you need to re-read my previous post again, because you are experiencing TWO failures: one of them is then AppDaemon itself craps the bed, which can be solves by a restart. HOWEVER - from a totally separate angle, after too many of these, the panel will start to throttle. From your end-user perspective, it might be hard to tell the difference between these two events because they both result in “Unavailable” entities as far as you’re concerned. But if you want to solve this problem you will need to stop handwaving things like that away.

For me, restarting HA can trigger the AppDaemon freeze. Restarting AppDaemon usually fixes it. HOWEVER - after some time, those AppDaemon restarts stop working. THIS is when the panel is throttling, and when I have to reboot the panel. After a panel reboot, and one more AppDaemon reboot, I’m all good (because now the throttling has been reset).

And just to re-iterate, if it were the addon, I wouldn’t have had it working for so long :slight_smile:

There’s got to be some way around this - unless you think Control4 users are having these issues too with their native Qolsys integration

@amirite: With all due respect, I’m not handwaving things away. I’m working in order of things I know to be problematic. I don’t know (to your point) that I’m being rate limited, but I think it’s irrelevant because restarting AppDaemon fixes my problem. Logically, it doesn’t make sense that if the panel is rate limiting the Qolsys AppDaemon app, restarting AppDaemon would magically bypass/reset that rate limit. I’m happy to be corrected if somebody can explain that how such a thing would occur.

I respect that I could post logs and possibly get help that way. However, the main crux of my question: “is anybody running this reliably without issue”, seems to be a resounding “no”. Multiple people are more or less saying they leave it running, and it stops working. What are they going to help me with, that they couldn’t help themselves with?

It’s not my intent to be combative here; we all want the same goal, ultimately. I think there are a lot of potential variations with respect to how each person has their environment setup, which is going to make any support challenging. I’m not trying to re-litigate this entire thread. I’m merely asking if those issues are still present, and I have my answer. I appreciate your help and feedback.

That’s fair, but I don’t really think it’s the case that most people are having the hangs. I’m running this reliably without issue. Others are as well. You should still post your logs. There are always root causes to these problems and that would really help to find whatever you guys are experiencing. More heads are better than one, and there’s simply no way to help you without seeing what you’re seeing. Basic system specs would help as well.

I can only suggest that the best place to look would be with the differences between HassOS and a regular Docker install. If you know what you’re doing it theoretically shouldn’t be very different, but I’m guessing this difference is producing some kind of difference in your setup that’s causing the AppDaemon hang.

BTW I don’t think auto-restarting AppDaemon is the answer. I don’t assume Qolsys is the only thing running on AppDaemon and restarting the whole server can bonker other apps running.

1 Like

Looks like there is a pretty serious bug in the socket implementation. You can’t just use recv(8192) (or whatever number of bytes) and expect to get a complete and parsable JSON. recv() just returns the max number of bytes that you specify.

I’ve seen this issue in at least some of the logs that are posted in this thread (e.g @painkiller). It usually manifests itself when you see the “non json data” log message. This will prevent auto discovery from happened when the first INFO request is published. So when zone events come from the panel they will also fail and you’ll see that in the stack trace because there is an expectation that the Zone exists.

You need to continuously loop until you have the complete message. In this case there is a new line that can be used as a delimiter.

I’m not a python developer and I no longer code day to day so rather than submit a pull request here’s the re-written listen function from the qolsys_socket.py that solves this problem for me. With that being said, all my binary sensors are showing up as “Unavailable” but not sure if it’s related to this fix or not. Restarting everything seems to have solved that Unavailable problem.

    def listen(self, cb: callable):
        #listening = True
        self.app.log("starting listen", level="INFO")
        data = ""
        #err = ""
        buffer = b''
        while not (self._wrappedSocket._connected):
            self.app.log("not connected yet", level="WARNING")
            self.app.log(self._wrappedSocket._connected, level="INFO")
            time.sleep(1)
        try:
            while self._wrappedSocket._connected and self.__listening__:
                while b'\n' not in buffer:
                    self.app.log("Buffer: %s", buffer, level="DEBUG")
                    received = self._wrappedSocket.recv(4096)
                    self.app.log("Received: %s", received, level="DEBUG")
                    buffer += received
                line,sep,buffer = buffer.partition(b'\n')
                self.app.log("Line: %s", line, level="DEBUG")
                data = line.decode()
                if len(data) > 0:
                    self.app.log("data received from qolsys panel: %s len(data): %s", data, len(data), level="DEBUG")
                    if is_json(data):
                        try:
                            cb(data)
                        except:
                            self.app.log("Error calling callback: %s", cb, sys.exc_info(), level="ERROR")
                    else:
                        if data != 'ACK\n':
                            pass
                        self.app.log("non json data: %s", data, level="DEBUG")
                else:
                    self.app.log("No data received.  Bad token?  Detatching.", level="ERROR")
                    self._wrappedSocket.detach()
                    raise NoDataError
            self.app.log("stopped listening on qolsys socket", level="INFO")
        except socket.timeout:
            self.app.log("socket timeout", level="WARNING")
        except NoDataError:
            self._reset_socket()
            # raise NoDataError
        except TimeoutError:
            self.app.log("qolsys socket TimeoutError: %s", sys.exc_info(), level="ERROR")
            self._reset_socket
            # raise NoDataError
        except:
            self.app.log("listen failed/stopped: %s", sys.exc_info()[2].extract_stack(), level="ERROR")
5 Likes

Hi,

I have an alarm system setup through Telus(Canadian provider) that uses QolSys hardware. For some reason the panel that I’m using does not have that "3rd Party Connections’ menu that would provide that token. I guess it’s been removed by Telus.

Is there anyway to still connect to the Qolsys panel without the token?

Are you using the dealer code ? What do you see when you go to the wifi devices menu ?

I stayed away from TELUS “Smart” Security for this reason. They lock the panel down and you have no access. I went with a local company out of Edmonton and was given the dealer code for full access to the panel and settings.

I’m using the master code. I’m not sure what the dealer code is. I supposed I could call Telus and see if they would be willing to give that to me.

There isnt any Wifi Devices option either. I see bluetooth devices, z wave devices, and iq remote devices.

You could try 1111, 1234, 0000. The dealer code (installer code) will be different from the master.

The default dealer code is 2222. So you could give that a try.

Ah 1111 ended up working. Thanks guys!

1 Like

Sorry if this has been asked before but is there anyway to also lock/unlock doors that are connected to the panel?

I have them showing up as binary sensors but it only lets me know if the door is open or closed.

No, you’ll have to pair those directly to Home Assistant with a Z-Wave stick or hub, or try your luck pairing a z-wave stick as a secondary hub to your panel once S2 support rolls into HASS from ZWaveJS (no idea if secondary hubs actually work properly in HASS)

My security company is replacing an HAI system (which is integrated with HA) with a qolsys 4. Is it going to be possible to replicate functionality (real-time status and control of devices) using HA? The panel will be talking to alarm.com but I also need a way to monitor and control locally. I have looked at this integration: https://github.com/roopesh/ad-qolsys but I am still not clear what is or is not doable.

@ihf1 I can’t speak to a Qolsys 4. This was written for a Qolsys IQ 2 Panel. It might work for a Qolsys 4 - you’d have to experiment it.

And please see above threads regarding concerns around stability. It’s working for most people but does have some occasional glitches and hang-ups. If you’re counting on it for your business… don’t blame me if you run into issues :slight_smile: .

Thanks. Yes the qolsys 4 is new and I haven’t even seen it yet. With regard to the Qolsys 2, will this code permit reall-time (local) monitoring and control of whatever the qolsys connects to?

Since you don’t want to submit a pull request, maybe it would be helpful to submit an issue? That way your fix doesn’t get buried in this long thread

1 Like

It would be assumed that if the software is the same on the Qolsys 4 as the 2, then yes it would work, but I don’t know of anyone that has a 4 yet to test it. I would assume it would work.

This script doesn’t do any other control of the alarm system other than allowing you to arm and disarm the system and to allow the sensor status to be passed to home assistant. You cannot control zwave through this script and currently it also doesn’t even have any information about zwave devices that are passed through the stream either. It is solely the sensors connected to the panel.