Maybe it was intentional, but it looks like there is an extra underscore in the notification value. I got the lock to report jammed by only partially locking it. And I don’t recall ever getting a Forced Entry alarm to show up (pounded on the door)! But it also then set alarm_number to 2, which I had been using as an unlock. Hmmm… time for a rewrite.

Maybe it was intentional, but it looks like there is an extra underscore in the notification value.

Yes - this was the intention. It breaks up the notification and the event (ie notification type is ACCESS, and the event is MANUAL_LOCK).

It is true that this makes is slightly different than the type in the “type” field which is a bit annoying and I might revisit this. When I defined these event types a few months back I wanted to avoid making them reeeaaaalllyyyy long so truncated things like ACCESS_CONTROL down to ACCESS

I keep seeing a number of these exceptions running snapshot #1025 and version 2.1.0.201708272249 of your new binding. Causing message is quoted at the top of the log.network_xxxxxxxx__node_42.xml (2.4 KB)jsondb-excerpt-node42.xml (5.7 KB, not really XML but the node 42 definition in jsondb)

Ok, thanks … now since it’s a pretty standard node (Fibaro FGMS) that has been working well for a long time (IIRC, it’s producing errors with the standard binding, too, but the message is different) , and short of the possibility to obtain a firmware update, is there anything I can do except to ignore it ? Does the message give you a hint w.r.t. an invalid parameter setting or some such ?

I had replied to your post, but still had not yet played with the alarms from the lock , or I may have spotted this sooner. With my previous rules, when the Forced Entry alarm went off, the door would unlock! I need to check on the other alarms yet, but my rules are now changed to use alarm_raw instead of alarm_number. The core of the issue for my rules was that alarm_number and notification_access_control display the number for any type of alarm, not just ACCESS_CONTROL. So, this is probably something that should be changed in the binding.

Why? The purpose of the alarm_raw was to provide raw alarm information. Are you now suggesting to reduce this to only access_control? Why not just filter this in your rule - you have all the information you need - right?

I must have not been clear in my explanation. I’m quite happy using alarm_raw as is! TY! I suggest a change to alarm_number and notification_access_control for those NOT using alarm_raw, and interpreting alarm_number=2 as a manual lock when it was actually a burglar, as I had been.