Syslog

[ptzmeyster]

Hello taligentx,

First off, thank you for creating such a cool project, this was exactly what I was looking for! And, it works just as the Readme says. (I am using the 5516 control panel with a 1608 board with a zone expander.)

For troubleshooting purposes, do you think it would be possible to add a syslog functionality? That way everyone doesn't have to drag a laptop to the place where the alarm is installed? (Perhaps having a dsc/Set command that enables or disables syslog and sets the syslog server IP). I know with the IRQs, it could be an issue pushing to a syslog server. Perhaps it can be done as a MQTT topic, publishing latest log message to a topic.

Also, I have seen the sonoff switches flashed with tasmota firmware publishing a status update message periodically with some useful health stats to mqtt and syslog, that can also help with troubleshooting in this project.

Once again, thank you for writing, working on and creating such a comprehensive project.

[taligentx]

Hi @ptzmeyster - good to hear it's working out for you! It shouldn't be a problem to add syslog to a sketch - I haven't tried it, but something like the arcao/Syslog library should work. You'd just need to include the library in your sketch and then print whichever status you'd like to syslog.

Is there a status you'd like to see that isn't currently being tracked by the library? In a troubleshooting context, it'd be useful to know if the interface is receiving data from the DSC panel, I'll look into adding that.

[taligentx]

Added checking the Keybus data status to the develop branch. Feel free to re-open the issue if you run into any issues using this library with the Syslog library or if there are useful troubleshooting/status states that are missing.

[ptzmeyster]

Hello,
Thank you for that, it will help!
In response to your initial question, the data status would assist in a troubleshooting context.

From a functionality perspective, considering the following features might be useful:

The ability to bypass zones before arming and remove bypass after arming
Ability to publish to mqtt bypassed zones
Ability to publish to mqtt alarm trigger zones (zones that caused the alarm to trip)
A mqtt topic that can be used to send numeric keys to the alarm in sequence. - Think remote programming, using virtual keypad. (Perhaps this can tie into the bypassing of zones)
OTA upgrading might be tremendously useful as well :) (With failback of os in the case of a failed upgrade)

[sj-louw]

@ptzmeyster Agree. This would be great if we can get these features.

[ptzmeyster]

Another Feature that might add value, is a MQTT topic to show when the system is ready to be armed for stay and when the system is ready for away arming. (When all the doors are closed and no motion is detected)

[taligentx]

@ptzmeyster Thanks for the feedback! Notes below:

The ability to bypass zones before arming and remove bypass after arming

This is already possible using virtual keypad dsc.write(). You can enter a key or key sequence - I've successfully tested writing *1 + access code + zone number + # + arming code to bypass a zone and arm. You do need to wait after *1 for the access code prompt before entering additional keys, see the MQTT examples on how to check for the access code prompt.

Ability to publish to mqtt bypassed zones

I'll add tracking bypassed zones to the todo list - I've already decoded this in the protocol but for now the library hasn't tracked it because I didn't see any software that would use the information and it would use more memory. The MQTT portion can be handled by the user's sketch once the library can provide the bypassed zone data. Which software is able to use this information?

Ability to publish to mqtt alarm trigger zones (zones that caused the alarm to trip)

This already possible - the library provides the zone alarm status in dsc.alarmZones[], see the Status example sketch to see how to check which zones are in alarm. You can then replace the Serial printing with MQTT publishing. Which software is able to use this information?

A mqtt topic that can be used to send numeric keys to the alarm in sequence. - Think remote programming, using virtual keypad.

This is already possible: the dsc.write() method can accept either a single char or an array of multiple keys as char[]. For example, you can pass the payload of the MQTT client to dsc.write() including multiple keys in a sequence. You just need to watch out for cases where you have to wait for the panel to respond before sending more keys (like when an access/master/installer code is needed).

OTA upgrading might be tremendously useful as well :) (With failback of os in the case of a failed upgrade)

This is already possible by adding the ArduinoOTAlibrary to the user's sketch.

a MQTT topic to show when the system is ready to be armed for stay and when the system is ready for away arming.

I'll add this to the todo list, the current dsc.ready[] status does not differentiate between ready with all zones closed and ready with stay/away zones open - this matches the behavior of the DSC keypads but it is possible to be more specific. Again the library would provide the data and then it would be up to the user's sketch to handle it as desired, through MQTT or otherwise. Same question as before, is there software that can take advantage of this information? For the HomeKit and HomeAssistant integrations, the example sketches send the ready status as being disarmed - neither of these software platforms are able to distinguish between ready for stay or ready for away arming.

As far as how this should all work, the library's job is to make the most useful DSC data available, while the user's sketch handles what to do with the data. Ideally, the example sketches should show how to use the data in a way that can be adapted to each individual need - hence the distinction I've been drawing between issues that can be addressed in the library itself and issues that can be addressed in the sketch.

Now that quite a bit of the Keybus protocol has been decoded, the next focus is on integrating with other software - feedback is critical to understand the various ways this interface can be useful and what needs to change in the library itself.

[taligentx]

@ptzmeyster Thoughts on use cases for tracking the bypassed zones? Memory is always on a budget so there should be a way to actually use that information before increasing memory usage.

[ptzmeyster]

Hello taligentx,

Must say, awesome write-up, really gives a lot to think about. I will have some capacity available in the very near future to play with this on a much deeper level. {Thinking of implementing some of the capabilities, will obviously share ;) }

I am quite excited about what else can be done with the events from the alarm. Currently I use the status of each sensor to trigger events in "HA" I also use python as a basis to apply some logic to my day to day activities. From turning off the tv when everyone goes to bed (using PIR's) to enhancing my morning routine with triggers for lighting on the outside, when the beams are triggered.
Currently I am looking at auto arming when conditions are met, feeding presence, DoW and other triggers in. At the moment, so happy that I can work with all these inputs to come up with creative solutions.

Bypassed zones:
So as far as I can tell, you don't have to store the statuses in memory. When you do a *1 query on the keypad, the panel actually shows you the bypassed zones. In my case, bypassed zones are removed on every disarm of the alarm.
My suggestion would be to not worry about storing the values. The suggestion would be, that on every change of the bypassed zones, a *1 output would make available all the currently bypassed zones, which can just be passed on to a MQTT topic. - But then again the *1 component can be done with the dsc.write() function. The return the actual information, I don't yet know how to do. What would be nice is to handle events when a new zone is bypassed and then do the *1 to get all bypassed zones which can be subsequently passed on to MQTT or wherever.
Use case would be to use this information as validation on the arm status of the alarm, making sure the correct zones are bypassed. Remotely bypassing and re-arming. (Currently we have a garden service that comes on specific days, and we need to verify that they won't trigger the alarm. My family sometimes forget to bypass the zones and then I invariably get a call from the security company stating that there has been intruders found in my yard)