Yale Lock Convert Alarm (raw) To Human Readable Text

I have a Yale “YRD110 Yale button deadbolt without keyway”.
It reports actions using Alarm (raw) strings like:
"Alarm_Raw changed from {“type”:“24”,“value”:“1”} to {“type”:“25”,“value”:“1”}
"
I would like to convert these codes to text. I found a conversion table to convert the number codes to text. It has about 18 entries for this lock.
I have seen methods to do this using rules and jsonpath transformation and a lot of “case” statments. I am hoping for an easier (less mistake prone) method.
I am thinking something like my other lock, a “914TRL Touchpad Electronic Deadbolt”. In addition to the channel “Alarm (raw)” it also has a channel “Alarm [Deprecated]” which provides a number. I use a MAP file to transform these numbers to text. Simple and straight forward.
Is there a similar way to do the conversion using a table?

If they are set values with a fixed meaning (e.g. {"type":"24", "value":"1"} always means foo) you can apply the Map transformation to convert the full JSON string to an easier to read value.

Note, the [Deprecated] part of the channel you have on that other deadbolt means “no longer supported, will go away at some point in the future”. You will want to switch both deadbolts over to using the raw Channel.

(1) Yes they are fixed.
(2) I tried a number of variations like the following:

String Porch_Alarm_Raw “P Alarm Raw type [%s] [MAP(DoorLock.map):%s” {channel=“zwave:device:fe40ab17:node26:alarm_raw”}

Which is sort of bruit force and unsuccessful. All I get is
{“type”:“25”,“value”:“1”}.
I don’t know how to parse {“type”:“25”,“value”:“1”} to pick out “25” which is what I need to map.

(3) I am aware of the depreciated tag which is why I need to use the channel Alarm_raw.

You don’t need to parse it out, use the {whole content} in your MAP lookup.
You’ll probably need to escape the quotes, not sure.

EDIT - now I think you do not need to escape quotes, but do for the colons.

Well, I’m almost there buttttt…
To the map file I added:
{"type"\:\"24","value"\:\"1"}=Lock Secured by Controller

{"type"\:\"25","value"\:\"1"}=Lock Un-Secured by Controller

For the lock with both Alarms (raw and number) I got them to display the same but it took a few fits and starts to get the raw one to display correctly in Habpanel. After a lock change the habpanel would display the {“type”:“25”,“value”:“1”} string. But if I refreshed using the curly arrows at the top of the window, it would correct itself. I did a few things like editing the widget and restarting the habpanel and, Boink, that lock is displaying correctly every time.

So I updated the Yale lock (Alarm_raw channel only) and it always displays {“type”:“25”,“value”:“1”} until I click the curly arrows. I tried all kinds of restarts, edits, and refreshes. Interestingly, I created a basicUI and it updates correctly but the habpanel needs the curly arrows to correct for the Yale lock but the other lock displays correctly.

I’ll find some way to untangle this and post my solution here for others. Rossko57, thanks a heap. You nailed it right off.

I think you are looking for code fences. :wink:

How to use code fences - Tutorials & Examples - openHAB Community

Bruce,
Thanks, I edited my post as instructed.

1 Like

You only need the one before colon.
I don’t think escaping the following quotemark interferes with function, but it’s not needed and harder to read.

People seem to struggle with getting transformed states displayed in HABpanel, I have little idea about it but understand there’s a tickbox to select “use server supplied format” or something.

Note you must use %s in your Item label [state presentation]

I don’t know what clicking curly arrows is about, definitely HABpanel ju-ju. :wink:

Great, I removed the trailing backslash and things still work.
The curly arrows are a symbol on the top of the HABpanel page that cause a refresh of the page. So I would click to change the lock state and the alarm_raw would display the {"type"\:"25","value"\:"1"} format. Then a refresh (curly arrows) would change it to “Lock Un-Secured by Controller”`

So I did some more experimenting. My android phone worked fine. no curly needed. My Windows desktop also worked fine. Only the Raspberry Pi required the curly. All three are using the browser FireFox.
Then as I experimented, sometimes the curly was not needed. The more I played (lock and unlock with each of the computers) and restarted the browser on the RPi I noticed that more and more, I didn’t need the curly every time. Right now all three computers are controlling the locks and the the text is displayed. It seems to have healed.
I am sure it will come back sometime.

@chris please clarify if this is accurate. I am confused.

Yes, the statement I see here from @rlkoshak is correct. Deprecated channels are ones that should not generally be used as they could one day disappear. Instead of immediately removing channels that people are using, they are marked as deprecated.

Examples of channels that are deprecated are some of these alarm channels where there is a new/better way to do things, and maybe where channels like switches have been removed where there is both a switch and dimmer channel on a device as we only want the dimmer.

1 Like

Both locks seem to be reporting correctly. While I was doing some cleanup I discovered some channels were linked to two places. One like:
zwave:device:fe40ab17:node26:alarm_access
And the other to a line in the items file. I suppose the first one might not know which map file to use. But refreshing seemed to get it to the right place.

Anyway, I created a map file for others that may have this lock (and many other Yale locks I suspect)…Finally I have a chance to contribute to his wonderful community.
The map file is from:
Source For Alarm Reports
I uploaded it here
Yale_YRD110.txt (1.6 KB)
(Change the “txt” to “map”. I was not allowed to upload a “map” file.)
There is a Note 2 in that file that explains that I don’t know how to pick out the “value” field so the information will be correct only for the master user. If I figure out

Thanks everyone.