HomeKit Security System. Errors in log, seems to work though

Setup, Configuration and Use Beginners
, ,
1

Hi,

I’ve been experimenting with the HomeKit Security System.

Two items are created - A current state item, and a target state item.

My items are:
HouseAlarm_State
HouseAlarm_TargetState

HouseAlarm_State has the HomeKit Metadata tag CurrentSecuritySystemState
and HouseAlarm_TargetState has the HomeKit Metadata tag TargetSecuritySystemState
Both are Strings. And each have a state desciption to change the display label STAY_ARM to HOME etc and adding the Command Options required for interacting with the item -

  • STAY_ARM / AWAY_ARM / NIGHT_ARM / DISARMED / TRIGGERED for Current State item
  • STAY_ARM / AWAY_ARM / NIGHT_ARM / DISARM for Target State item

Although these are the only mandatory tags listed in the docs, I seemed to need to add the SecuritySystem.Name tag to the Equipment level item, HouseAlarm, to make the item show in Apple Home app on iOS.

Without this I was getting the following errors when I added all Metadata -

2022-02-15 20:11:21.085 [WARN ] [.accessories.HomekitAccessoryFactory] - Accessory of type SecuritySystem must have following characteristics [SECURITY_SYSTEM_CURRENT_STATE, SECURITY_SYSTEM_TARGET_STATE]. Found only [Item:HouseAlarm_State (Type=StringItem, State=NIGHT_ARM, Label=Mode, Category=alarm, Groups=[HouseAlarm, gSelection_ItemsToRestoreOnStartUp])  HomeKit type:SECURITY_SYSTEM HomeKit characteristic:SECURITY_SYSTEM_CURRENT_STATE]

and

2022-02-15 20:37:21.325 [WARN ] [.accessories.HomekitAccessoryFactory] - Accessory of type SecuritySystem must have following characteristics [SECURITY_SYSTEM_CURRENT_STATE, SECURITY_SYSTEM_TARGET_STATE]. Found only [Item:HouseAlarm_TargetState (Type=StringItem, State=DISARM, Label=Target Mode, Category=alarm, Tags=[Setpoint], Groups=[HouseAlarm])  HomeKit type:SECURITY_SYSTEM HomeKit characteristic:SECURITY_SYSTEM_TARGET_STATE]

Confusing at first to have two items (current and target), but the logic seems to be that timers can be added (for leaving the house before it arms etc), which makes the Apple Home app display things like “Arming…” and “Disarming…” during any time delays.
*HINT A rule must be created to update the Current state to be the same as the target state. Either immediately, or with an added delay.

This appears to be functionally working for me for the most part now. But I am still getting errors in the logs that make me think this isn’t setup correctly yet.
I am sending commands STAY_ARM, NIGHT_ARM, AWAY_ARM, etc, and even though the desired action happpens, I am getting these error messages -

2022-02-16 11:42:33.778 [WARN ] [ssories.AbstractHomekitAccessoryImpl] - Wrong value STAY_ARM for CurrentSecuritySystemState characteristic of the item HouseAlarm_State. Expected one of following [HOME, AWAY, NIGHT, DISARMED, TRIGGERED]. Returning DISARMED.

This log doesn’t make sense. The rule I wrote sent STAY_ARM to Current State when Target state changed to STAY_ARM. Current State shouldn’t be expecting HOME, AWAY, NIGHT. It should be expecting STAY_ARM, AWAY_ARM, NIGHT_ARM etc Despite all of this, all items update as expected.

2022-02-15 20:36:35.816 [WARN ] [ssories.AbstractHomekitAccessoryImpl] - Wrong value DISARM for CurrentSecuritySystemState characteristic of the item HouseAlarm_TargetState. Expected one of following [STAY_ARM, AWAY_ARM, NIGHT_ARM, DISARMED, TRIGGERED]. Returning DISARMED.

This also doesn’t make any sense. The item HouseAlarm_TargetState was sent DISARMED, not DISARM. And it shouldn’t be expecting these commands that include DISARMED and TRIGGERED as these are the commands the item tagged with TargetSecuritySystemState, not CurrentSecuritySystemState. Again, despite these errors, the items appear to behave correctly by updating and sending states back and forth to the iOS Home app.

Another similar error was -

2022-02-15 22:21:27.986 [WARN ] [ssories.AbstractHomekitAccessoryImpl] - Wrong value DISARMED for TargetSecuritySystemState characteristic of the item HouseAlarm_TargetState. Expected one of following [STAY_ARM, AWAY_ARM, NIGHT_ARM, DISARM]. Returning DISARM.

Anyone have any thoughts on any of this?

2

it looks like it mixing current and target items, i.e. HouseAlarm_State and HouseAlarm_TargetState.
can you share homekit metadata for these items as well as the rule?

3

Guessing these are String type Items, and in this usage Item state may not reflect commands sent … like a dimmer commanded INCREASE for state 75%

Try disabling autoupdate on these Items (autoupdate just blindly copies commands to state for Strings)

This doesn’t sound right. At an abstract level, you could command ARM, the system beeps and burps, and eventually announces ARMED. Or maybe a window is still open, it can’t do it, responds STILL DISARMED. Don’t think you should be forcing current state by rule, you cannot know what it actually is?

4

Yes, this is exactly what it looks like to me too. *sometimes
I’ve double checked 100 times though. Definitely set correctly.

image
image691×493 14 KB

and
image

5

Yes they are Strings, but I don’t think the commands sent are of the wrong type. I am only sending the default string values of STAY_ARM, AWAY_ARM etc.

I’ll try the autoupdate thing later this afternoon. Thanks.

Regarding having to force Current state with a rule - After going through the process, it does feel ike a feature, not a bug. Otherwise there would be no purpose in having two items. A single one would do. I’m happy to be proven wrong about this.
I’m using it to add a delay to the AWAY_ARM mode to let me leave the house before arming, but it might also be used for systems using PINs or other more complicated systems.

6

Rephrasing what I said, there needs to be separation between “instruction” and “status”. Instructions may fail, or be in progress, or otherwise not directly correspond to status.

In a conventional Things/channels binding that is easy - we treat commands and state as separate business. Roller command UP - roller state 50% - later, roller state 40% etc.
Alarm command SET - alarm status ARMING - later ARMED, or maybe DISARMED, WINDOW OPEN.
(This imaginary process is one that autoupdate would mess up, by copying command SET to the Item state, this is why I mentioned it)

But Homekit is not a conventional binding, it interacts with Items in a different way that I don’t pretend to understand. It seems reasonable to have a path for “instructions” and a path for “status reports”.

7

i think the issue is the mapping of values.

Wrong value STAY_ARM for CurrentSecuritySystemState characteristic of the item HouseAlarm_State. Expected one of following [HOME, AWAY, NIGHT, DISARMED, TRIGGERED].

so, binding got the mapping from standard values NIGHT_ARM, AWAY_ARM, etc to HOME, AWAY, etc. so, it expects command with custom value like HOME and not the standard one.

also the targetState has for some reason values of currentState.

i assume both items, HouseAlarm_State and HouseAlarm_TargetState are part of a group.
where you did the mapping, at item or group level?
how the metadata for mapping look like?

8

does anybody know if there is a possibility to hide unwanted alarm states like in thermostats or i need to use all of them ?

9

the same approach as for thermostat should work for security system. add mapping only to the states you need.

10 

Group gSecuritySystem            "Security System Group"                                   {homekit="SecuritySystem"}
			String          security_current_state     "Security Current State"             (gSecuritySystem)    {homekit="SecuritySystem.CurrentSecuritySystemState" [AWAY_ARM="AWAY", NIGHT_ARM="NIGHT" ]} 
			String          security_target_state      "Security Target State"              (gSecuritySystem)    {homekit="SecuritySystem.TargetSecuritySystemState" [AWAY_ARM="AWAY", NIGHT_ARM="NIGHT" ]}

Wrong value AWAY for TargetSecuritySystemState characteristic of the item security_target_state. Expected one of following [STAY_ARM, AWAY_ARM, NIGHT_ARM, DISARM]. Returning DISARM.

==> /var/log/openhab/events.log <==
2022-06-26 21:35:01.603 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'security_target_state' changed from NIGHT to AWAY

==> /var/log/openhab/openhab.log <==
2022-06-26 21:35:01.607 [WARN ] [ssories.AbstractHomekitAccessoryImpl] - Wrong value AWAY for TargetSecuritySystemState characteristic of the item security_target_state. Expected one of following [STAY_ARM, AWAY_ARM, NIGHT_ARM, DISARM]. Returning DISARM.
11

and icon is freezing at “Arming…” message

12

just copy&pasted your config and it works fine on my side. i see only 2 status (basically switch) in home app, no mapping errors in the logs. it is on oh3.3 but should the same on 3.2. i have not changed anything on security system since a while.

regarding “arming…” it will say this as long the current state will not become equal to target state.

here are the screenshot from my tests (ignore the icon “OFF” on the home screen. it looks like an IOS bug. if you open the room view or the accessory you will see the correct status)

image
image1920×1230 220 KB

13

indeed, what i discovered recently (and i don’t know how to reproduce this error) that homekit metadata is not refreshing correctly. I think it is connected with both textual and gui configuration at the same time. Don’t know if this is a homekit addon problem, or a “thing/item” configuration problem. What i noticed making a GUI configuration of metadata"

1/ GUI homekit item as a group → configuration made from group item in the metadata config (:8080/settings/items/gMotion1/metadata/homekit. Didn’t sticked to the items after saving configuration (“Save”) → don’t now exactly if i should use “Update group members”

then sudenly the motion sensor started to work :slight_smile:

I think the same happens with this security alarm, but i am doing this only by text config. I will try to reboot /clear cache of openhab and run it again.

14

ok current state need to by updated by a rule to stop “Arming” message. I add a simple rule converting target to current command.

15

Hej,

Group gSecuritySystem            "Security System Group"                                   {homekit="SecuritySystem"}
			String          security_current_state     "Security Current State"             (gSecuritySystem)    {homekit="SecuritySystem.CurrentSecuritySystemState" [AWAY_ARM="AWAY", DISARMED="OFF", AWAY_ARM="ON"]} // STAY_ARM / AWAY_ARM / NIGHT_ARM / DISARMED / TRIGGERED[STAY_ARM="pozostan", AAWY_ARM="poza"]
			String          security_target_state      "Security Target State"              (gSecuritySystem)    {homekit="SecuritySystem.TargetSecuritySystemState" [AWAY_ARM="AWAY",DISARMED="OFF", AWAY_ARM="ON"]}

Which this setup, the icon does not show any states it shows only details of accessory not the switch. What i am doing wrong ?

16

not sure i understood what you see. usually there are 2 different things: control and settings. what happens if you just click on the security icon in home app?
can you share the screenshots?
please also make sure you have deactivated homekit bridge on apple tv/homepod for time being. you can activate once your configuration is working as expected

17

Zrzut ekranu 2022-06-28 o 08.56.05 (1)
Zrzut ekranu 2022-06-28 o 08.56.05 (1)828×1792 148 KB 

metada config looks ok and 
08:59:24.500 [WARN ] [essories.AbstractHomekitAccessoryImpl] - Wrong value AWAY_ARM for TargetSecuritySystemState characteristic of the item security_target_state. Expected one of following [STAY_ARM, ON, NIGHT_ARM, DISARM]. Returning DISARM.
08:59:24.503 [WARN ] [essories.AbstractHomekitAccessoryImpl] - Wrong value AWAY_ARM for CurrentSecuritySystemState characteristic of the item security_current_state. Expected one of following [STAY_ARM, ON, NIGHT_ARM, OFF, TRIGGERED]. Returning DISARMED.

i see an error with the mapping here, gona correct it and try again

18

I’ve dabbled in the HomeKit Security System, too, and those error messages can be a puzzle. Your setup logic seems spot-on, so those warnings are a head-scratcher. I faced similar quirks, but as long as everything’s functioning as expected in the Apple Home app, you’re golden. Maybe change to Vivint security; they don’t have such hiccups. Good luck!