I'm using Surety. Nice people. Wish they had a different logo 
Wow. Very helpful information in all of the responses. Sincere thanks to everyone for the input!
Yes. You can probably ignore this as there aren't likely any events generated by the remote.
In the logs, there should be an entry that starts out like this:
{"event":"INFO","info_type":"SUMMARY", ...
There may be several of these entries if you have a lot of sensors and the entire list is too big for a single network packet.
Send the one closest to the "Summary info received" info message and I'll add it to the list of recognized devices. But as I said, there probably aren't any useful events generated by the IQ remote so there may not be any child device created, but at least it can be ignored without creating an error message.
Thanks! I'd imagine that the events for this IQ remote would be tamper, AC power interruption, PowerG connectivity etc. It doesn't have glass break sensors as far as I know.
Would this bit be enough?
QolSys IQ Alarm Panel: json: [event:INFO, info_type:SUMMARY, nonce:, partition_list:[[name:Panel, partition_id:0, secure_arm:false, status:DISARM, zone_list:[[group:fixedintrusion, id:380-2838, name:Master Bedroom Keypad, partition_id:0, state:0, status:Closed, type:Keypad, zone_alarm_type:0, zone_id:1, zone_physical_type:4, zone_type:104],
I also saw a few of these in the logs. The IQ Remote was the first thing I added to the IQP4 so I assume it got the ID of 1. Looks like maybe we have this because the keypad isn't recognized.
(redacted)
Not likely. Unfortunately, tamper events are never reported on the C4 interface. Nor are power events, or anything else except open/closed, active/inactive, etc. The child drivers in HE do have the TamperAlert capability; I never removed that after I realized that tamper events were not sent by the panel. At least, not at the time I wrote the drivers. I probably ought to check again to see if that's changed.
You could power down the keypad for a while and see if any event shows up in the HE log, but I doubt it.
Yes. There's no code to handle type:Keypad at present. I can add some code to suppress the error message, but unless the panel sends events for that device there wouldn't be any point in creating a child device in HE.
I have a hardwire device and it has sent a contact closed event. Is that the tamper on the device?
I noticed I'm getting these socket errors, but oddly the event log for the device is not keeping a full history so I don't know how far back it goes. Seems like it's only keeping an hour. I did upgrade the HE firmware yesterday. Let me know how I can help sort out what's happening.
for me, this indicated that the two systems were no longer connected. The only solution I found for it was to reboot the Qolsys panel.
Don't know. If you remove and replace the cover do you get open and closed events? At the time I wrote the drivers, things that raised a tamper alert on the panel did not send a corresponding event out the C4 interface. That may have changed since.
Yes, I just tested it. If I remove the cover I get an open event and then get a close event when I close the cover.
Any idea how those socketReceiveError's are happening? I scanned your code and I can't tell how these are getting generated every 30 seconds or so. They are super weird because if I look at the event stream for the alarm system the lower half is alarm mode events and the top half are these errors. This is the case hour after hour. These errors never push down the events that have the "Alarm System" in the produced by column. For example in the below images the green highlight is the same timestamp in both shots. The pink in the last visible socket error in the event stream. I waited to snap the screen shot of the second one until after lines disappeared.
Are these events generated by your driver code are are they somehow generated by the system?
Must be the tamper switch then. How does that register on the panel? As an alarm contact or a tamper switch?
By the system. The driver uses the "raw socket interface" which is very poorly documented. As soon as you open the socket it seems to do an asynchronous read, which times out after 30 seconds. There is no explicit read() method, at least not documented.
You can ignore them. The alarm panel sends periodic status information for each connected alarm sensor; the more sensors you have the more messages it will send but I never figured out how often they would be sent. If the alarm panel doesn't send anything for 30 seconds, HE's rawSocket code complains. It doesn't hurt anything and an internal read operation begins again, so it's harmless if not annoying. I couldn't get a lot of assistance from HE at the time; I was happy enough when they added SSL to rawSocket, so I just let it go. Without a SSL-capable raw socket, this driver would not be possible.
The driver itself does monitor communications from the alarm panel, and if nothing has been received for 10 minutes, it closes and reestablishes a connection. With a panel that has few alarm sensors, there might not be any events sent on the C4 interface for 10 minutes or more. But there's no way to know if that's the case vs. the connection just being hosed. 10 minutes seemed to be a reasonable compromise between detecting dead connections and closing/reopening the connection to a panel with few devices.
Yes. The cover has a foam padded protrusion that meets an on board momentary switch on the circuit board. It registers on the panel as a tamper event for the hardwire.
I understand this... Pretty much my daily life and 3rd party platforms for my primary job. Grateful we have the option.
Yes, I looked to update the docs, but they don't make that something the community can help maintain. They have some bits in release notes for rawSocket that didn't make it to the developer pages. Wondered if readDelay or the eol options might help.
@gopher.ny sorry for pinging you, but do you have any insight into rawSocket and understanding events that are coming from the system when using rawSocket? If there is something we can do to make the events go away or even just understand better why they are happening would be useful.
Do you see any entry in the alarm driver logs when this happens? I think you would need to have debug logging enabled.
I tampered it again to check the log on the Alarm System. I have these entries for the hardwire that correlate to the events on the hardwire.
Thanks. Just open/closed events, like any other sensor. You'd think it would show up as a tamper.
It does on the panel, obviously. Maybe tamper is relative to the device type and group. A takeover device with open/close may only be a tamper. In a perfect world I'd get all events like power loss etc. Even better would be ability to send events from rules...
Thanks for taking a look. I have not yet tampered the panel or the IQ Remote to see if it's any different. Since I don't have the IQ remote showing anyway I'm not sure there is value on that one yet.
Yes, I can take a look at the source code.
The timeouts above can likely be fixed by adding a timeout parameter, like
interfaces.rawSocket.connect([ timeout: 300_000 ], ip, port)
Other relevant parameters are readDelay (milliseconds), which is how long the socket sleeps before checking for incoming data again, and bufferSize (bytes, between 1024 and 1048576).
The developer documentation needs work. I hope to get to it one day...
1 Like
Wasn't aware of that param. Is that a typo? What is the correct format for the delay? And the max delay value?
No, you can have an underscore in an integer for ease of reading.
The delay is in milliseconds. Default is 30_000, and the disconnects in the logs above come every 30s, so it seems that timeout causes them. The parameter gets passed to socket's setSoTimeout() function, so any positive integer (up to Integer.MAX_VALUE) will work.
1 Like
