Is there a way to schedule an Appdaemon restart every day, or every few hours?
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 
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 .
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