DSC keypad

[agame]

a sanity check: is the DSC Keypad device implemented in the current version?
DSC Keypad devices do not appear in the menu of candidate devices in the configuration dialogue so I assume not? [The GitHub notes indicate it is though elsewhere you note security is still coming, so though i'd clarify].

[GlennNZ]

Security Systems:

Has recently been added supporting VSS, DSC plugin, and Paradox/SP6000/Magellan plugins - as HomeKit Security systems.

DSC Keypad….
Presume you mean a security system in HomeKit? and if that is the case - should select security system in show all options and see how goes….
Does seem a very old option - and only by default supported it because it was the only security option HomeBridge supported.
Untested though and you may find that VSS - which is action based for resulting security device in HomeKit is usable with a few Actions/Triggers.

Glenn


Sent from my iPad using Tapatalk

[agame]

DSC is an old plugin though actively maintained, and I find very useful. Especially in rental properties, I find a real-world alarm system with a traditional keypad/touchscreen continues to be relevant. And it works during a system update lol. I map non-DSC sensors on to the DSC via Indigo.

I did load the VSS and after some jigging around I successfully published to HomeKit though (as the acronym implies) it really is only a virtual device to hold alarm system states, leaving a hell of a lot to be managed through scripts or a plethora of triggers and actions, much of which the DSC plugin does under the hood. Worst case i could use it as a virtual proxy for the DSC states though native support would be much nicer..

It occurred to me there could be contention between plugins so i have disabled VSS and unpublished the device, even cloned the DSC keypad. However the keypad devices don't appear in the selection dropdown.

[GlennNZ]

DSC is an old plugin though actively maintained, and I find very useful. However the keypad devices don't appear in the selection dropdown.

Hi

I will have a look at DSC.

That aside - what is the issue? You mention keypad devices don’t appear in the indigo device selection?
Is that the problem?

Pretty sure that device selection pull-down lists every indigo device, plugin or otherwise. So if its an indigo device - it should be there, if it’s not an indigo device… then….

[agame]

Yes that is exactly the issue:I can see every other Indigo device listed in the plugin's device selection dropdown, many of which are never going to be suitable for HomeKit - but no DSC keypad devices.

Even if i create a new one it doesn't appear. Looking closer, none of the DSC plugin's devices are appearing in the dropdown (for instance, individual sensor devices).

Also as a check I confirmed other plugins can see these DSC plugin devices (Cynical Behaviours, the old HomeKit Plugin)

[GlennNZ]

OK.
Slightly odd - but I suspect they are probably all custom devices,
(Actually thought all devices would capture them - but I'll check, I'll try to install DSC plugin and see what I see)

DSC = custom devices
But checked code from afar and all custom devices still should be shown in the All Indigo Devices pulldown.
(Unless already published to a HomeKit Bridge... in which case will be listed at bottom)

Check that first.

Glenn

[agame]

This is really weird.
I just went to publish an (unrelated) new device, an voila, the keypad and motion sensors are now all present on the list.

One possibility is i missed the device in the list earlier: I'm noticing that the device list isn't in the usual alphabetic order (there's a full sequence of devices starting with a Capital letter, then another full sequence of lowercase. Double checked and equivalent lists in other plugins seem to be in conventional alphabetic order ignoring capitalisation... I did realise there was some strange ordering earlier and i thought i stepped through every device but possibly I missed it.

sorry to waste your time!

[GlennNZ]

Good to hear.

The ordering is a bit funky - I think its by device type, alphabetical and then repeats - but hasn’t got too far up the list to improve as once added no need to revisit.

See how you go with the security device - the DSC support is by necessity untested - did try but couldn’t setup without the hardware…


Sent from my iPad using Tapatalk

[agame]

ah that makes more sense then.
The Unifi plugin has generated hundreds of devices i need to clean out...makes it difficult to deal with unpredictable sequencing!

From a quick play it the plugin appears to be working well, with the exception of mapping armed states: stay-armed and away-armed states seem to be mapped in reverse.
Also, DSC doesn't differentiate night from home/stay and selecting this in HomeKit currently does nothing (would make more sense to map it onto stay?)

[GlennNZ]

ah that makes more sense then.
The Unifi plugin has generated hundreds of devices i need to clean out...makes it difficult to deal with unpredictable sequencing!

From a quick play it the plugin appears to be working well, with the exception of mapping armed states: stay-armed and away-armed states seem to be mapped in reverse.
Also, DSC doesn't differentiate night from home/stay and selecting this in HomeKit currently does nothing (would make more sense to map it onto stay?)

Happy to revisit DSC - but as can’t test you are going to have to be pretty specific!

Specific debug logging for the DSC Keypad device probably ideal (can select that in plugin Config). And indigo will warning log anytime device changes.. May still need other debug logs as well..

The ‘mapping’ seems find to me, code wise. But really not sure what direction you are referring to… I have copied plugins conversion below. Seems correct.

Code: Select all

DSC_TO_HOMEKIT_CURRENT = {
    "armed": HK_ALARM_STAY_ARMED,
    "armed_stay":HK_ALARM_STAY_ARMED,
    "armed_away": HK_ALARM_AWAY_ARMED,
    "exitDelay": HK_ALARM_DISARMED,
    "disarmed": HK_ALARM_DISARMED,
    "tripped": HK_ALARM_TRIGGERED,
}
DSC_TO_HOMEKIT_TARGET = {
    "armed": HK_ALARM_STAY_ARMED,
    "armed_stay":HK_ALARM_STAY_ARMED,
    "armed_away": HK_ALARM_AWAY_ARMED,
    "exitDelay": HK_ALARM_DISARMED,
    "disarmed": HK_ALARM_DISARMED,
}

But welcome to check further, turn on debug logging for the DSC device and let me know what it’s reporting/saying and what it should be.
Should be able to fine tune as you need.


Sent from my iPad using Tapatalk

[agame]

okay...I've run a whole lot of tests.

I think one issue is present:

- HomeKit displays an armed status of 'Home' when Indigo reports the DSC armed status 'Away'. Attached screenshot shows homekit, and and a print of DSC states.

further debugging is made more complex because a DSC configuration issue means the system will always arm to 'Away' regardless of whether 'Away' or 'Home' is requested (regardless of the interface used).

[GlennNZ]

Hi

To fix this I really need some logging from HomeKitLink Plugin. (as I mention above)
Set device to debug in pluginConfig and change state a few times. Should log before and after states which I can use to fix.

Edit:
Have updated to 0.3.5 including hopefully a fix for above
Don't worry about above it fixes


Thanks

[agame]

thx - I think armed states are now correctly requested from Homekit to Indigo but looks like this version introduced a small bug preventing Homekit syncing with the DSC states.

eg selecting 'arm-away' correctly arms the DSC but spawns this. similar error (not surprisingly) follows any state change in the DSC.

Code: Select all

  DSC Alarm                       Alarm Panel Armed in Away Mode. (Partition 1 'icy creek alarm keypad')
   Trigger                         alarm armed - lock mudroom
   HomeKitLink Siri Error          set from deviceUpdate exception
Traceback (most recent call last):
  File "/Library/Application Support/Perceptive Automation/Indigo 2022.1/Plugins/HomeKitLink-Siri.indigoPlugin/Contents/Server Plugin/HKSecuritySystem.py", line 192, in set_fromdeviceUpdate
    targetstate = targetstate + "_"+str(armstate)
NameError: name 'armstate' is not defined
   HomeKitLink Siri Error          set from deviceUpdate exception
Traceback (most recent call last):
  File "/Library/Application Support/Perceptive Automation/Indigo 2022.1/Plugins/HomeKitLink-Siri.indigoPlugin/Contents/Server Plugin/HKSecuritySystem.py", line 192, in set_fromdeviceUpdate
    targetstate = targetstate + "_"+str(armstate)
NameError: name 'armstate' is not defined
   HomeKitLink Siri Error          set from deviceUpdate exception
Traceback (most recent call last):
  File "/Library/Application Support/Perceptive Automation/Indigo 2022.1/Plugins/HomeKitLink-Siri.indigoPlugin/Contents/Server Plugin/HKSecuritySystem.py", line 192, in set_fromdeviceUpdate
    targetstate = targetstate + "_"+str(armstate)
NameError: name 'armstate' is not defined

edit:
I can see on further testing that both the arm-home/stay and arm-away are now generating the correct DSC arming requests. States in homekit I can't test with the above bug.
Requesting 'night' arm in HomeKit is not registered at all by the DSC plugin in any way [with full debugging on]. Homekitlink Siri reports

Code: Select all

   HomeKitLink Siri Debug          Plugin in Use: com.frightideas.indigoplugin.dscAlarm

..which is as it reports after any arm request [which is why i provided you the device states earlier rather than logs]. I don't believe the DSC Plugin supports night-arm however and given there is no state change at the DSC-end it appears the Homekit and DSC devices will be 'out of sync' if 'night arm' is requested (until something else triggers a state refresh).

[GlennNZ]

Sorry - that was a lazy typo - that should be easy to fix.
Try next commit version
0.3.6

Regarding Night - not sure I follow - there is no 'out of sync' if the mode doesn't exist in one. Shouldn't really change anything.
Option will be to map Night - to something else, but pending any strong interest in that - leaving it unmapped will be fine.
Selecting Night - won't change the any mode in DSC

[agame]

Yes that sorted it - arming now resulting in the correct states. So from my perspective now very usable.

Re the sync issue - the risk of not mapping the unsupported night mode is simply the end-user indication that the system is arming when in fact it isn't. However I see that after 3 or 4 minutes the HomeKit device will revert to the correct (Indigo DSC) state. I found it is also possible to get the the HomeKit device out of sync with the DSC plugin when switching between modes if DSC throws an error (for instance, too many commands in quick succession, or a zone not ready).

In testing this I did find a quirk of mapping 'exit delay' to 'disarmed' - a user cant toggle back to cancel the arming process during exit delay, and the indication 'Arming' on the Homekit device - which is presumably meant to indicate exit delay on a native device, only flashes up momentarily. And a failed arm attempt (eg zone not ready) will look like a normal exit delay process is underway, None of these critical, just slightly rough edges that might be worth considering if they aren't DSC-specific!