Can you get HSM Status over Maker API / EventStream?

[jvm33]

@bravenel

Not sure what you're talking about. It won't offer Arm Night unless and until you have intrusions configured for Night.

To clarify. . .

• In a prior post, I suggested that it would be helpful if HSM could create a "child device" that could be used to arm / disarm HSM Intrusion sensor and would have an attribute showing when HSM was triggered

• I suggested that this child device could have attributes and controls like those shown for Security Keypad, particularly the "securityKeypad" attribute (https://docs.hubitat.com/index.php?title=Driver_Capability_List#SecurityKeypad)

• But I pointed out that this Security Keypad Capability was missing the "armed night" state and command.

• If the SecurityKeypad capability had the "armed night" status and an armedNight() command, I figured I could implement a device myself that interfaced with HSM to control it and get its status.

• So I created a simple device driver and found that if I had a simple device driver with "SecurityKeypad" as a capability, it turns out that if you are writing a trigger in rule machine, Rule Machine does indicate that there is an "armed night" state.

• Thus, even though the capability list says that the securityEnum has the states

securityKeypad - ENUM ["disarmed", "armed home", "armed away", "unknown"]

It looks like Hubitat actually did implement part of the armed-night state, and the actual states implemented are more like:

securityKeypad - ENUM ["disarmed", "armed home", "armed away", "armed night", "unknown"]

Thus, it seems that the SecurityKeypad driver capability has mostly implemented the "armed night" state and that has been carried through into Rule Machine. But it looks like the "armNight()" command wasn't defined and that command doesn't appear on a device's web page when you use the capability.

Thus, what I was suggesting is that this SecurityKeypad capability looks like someone implemented most of the "armed night" state, but there's a little missing and I was hoping that could be completed. At least it appears to be the case that there's just a little bit missing here.

[bravenel]

@jvm33

Thus, it seems that the SecurityKeypad driver capability has mostly implemented the "armed night" state and that has been carried through into Rule Machine.

I'll put this into the hopper for capability review. If you're using a custom driver for SecurityKeypad, just add armNight() command as a custom command in the interim.

[jvm33]

@bravenel

I'll put this into the hopper for capability review. If you're using a custom driver for SecurityKeypad, just add armNight() command as a custom command in the interim.

Thanks. Greatly appreciate that this will get a review (and FYI - though you can trigger on SecurityKeypad in rule machine, I just noticed you can't activate the arming commands from Rule Machine). Anyway, thanks for the quick response.

[bravenel]

@jvm33

I just noticed you can't activate the arming commands from Rule Machine)

Say what?

[jvm33]

I mean for a device that has a driver using the "SecurityKeypad" Capability you can't call the "arm" commands of the SecurityKeypad capability directly from Rule Machine -- unless I somehow overlooked it (though, as you point out, if its HSM you're controlling directly, that you can do from Rule Machine).

[bravenel]

Security Keypad is not a capability supported by RM. We can add that pretty easily. Then you could do that with a custom action.

I take that back, it is supported. But there may be a bug preventing its selection... Checking.

The capability was missing from the list. Added now, next release.

[jvm33]

@bravenel

The capability was missing from the list. Added now, next release.

Thanks for taking care of this so quickly! And I noticed in the list of commands that "armNight" is already there in rule machine too, which is great (so I presume Rule Machine is already set up to execute an armNight() method if that method is in a driver that declares the SecurityKeypad capability). Looking forward to the next release!

[bravenel]

@jvm33

I noticed in the list of commands that "armNight" is already there in rule machine too

No, RM gets the available commands from the device used in the custom action. Those commands may be ones defined in the capabilities, or as custom commands of the driver. In this particular device, Iris Keypad V3, armNight() is a custom command defined in the driver.

[bravenel]

Assuming the driver you are using has some other capability besides Security Keypad, you can select it in RM custom action with any of its capabilities (try Actuator). Then, all of the device's commands are exposed.

[jvm33]

@bravenel

Then, all of the device's commands are exposed.

Thanks for the tip.

[jvm33]

@bravenel Sorry to keep coming back to you on these issues, but I think there may be a bug in HSM's status reporting on the EventStream interface. Specifically, the "displayName" and/or "descriptionText" portions of the report, which identifies the mode of HSM, always shows "Home" and "null"

More specifically:

If I send a status request to HSM using MakerAPI in the form:

http://192.168.1.168/apps/api/773/hsm/armedStatus?access_token=6a5553ef-046a-469c-985e-4551268356c1

Then, on the EventStream interface I get back a report in the form:

{"source":"LOCATION","name":"hsmSetArm","displayName":"Home","value":"armedStatus","unit":"null","deviceId":0,"hubId":0,"installedAppId":0,"descriptionText":"null"}

Notice that the displayName says "Home" and "descriptionText" is set to 'null'. These fields always have those values regardless of whether in armedNight, armedAway, or armedHome modes. I think one or the other of these should indicate the armedStatus.

Note that the HTTP interface does seem to return correct values, just the EventStream interface doesn't seem to return complete/correct information.