Feedback Please on a Strategy for Lock Management (Starbucks Card!)

[PLCGuy]

Hi 

Inspired by Javi's cool idea "Favorite Custom Toggle" in the UD Mobile Wiki, I started trying to develop a full-fledged lock management strategy for UDMobile and the EISY. In particular, the last comment in the sample logic "This is a simple example, a real installation should include checks for things like door open status" really seemed to throw down the gauntlet - it got me thinking about what a "Real Installation" should achieve. The following is my effort to date - I thought I'd throw it out to the UD community to critique and suggest improvements. 

First, what are the requirements for a "real" lock management system? Assuming the system is using Z-wave smart locks and an ELK alarm system for door status, these were the initial requirements that I came up with:

1. Users should only be able to lock a lock if the door is closed. 
2. Users should have full visibility of the lock's status in a single lock object on the Favourites tab. The typical user will only work from favorites and there should be no need to for them to click around to other screens or objects determine status - it is best if it is all visible in one "Lock Object".
3. At a minimum, users should be able to determine with a single look at UD Mobile Favorites if a door is one of the following states:
   1. closed and locked, 
   2. closed and unlocked, 
   3. open or 
   4. in a trouble/fail/dead battery state
4. The battery level should be displayed on the Lock Object, as that will impact the ability to lock
5. It should be efficient to program and operate. (I have quite few locks, so I don’t want something that requires ten programs for each lock.)

Q1: Did I miss anything?

Assuming I didn't, achieving Req #1 was easy. I just added an AND condition to the If statement in the Lock Toggle program to check if the door was closed (aka “Normal” in Elk Alarm speak). Here is the revised version of Jari's program:

Toggle KtchDr_Lock - [ID 00A9][Parent 0019][Not Enabled]

If
        'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Status is not Locked
    And 'Alarm / House Alarm System / Kitchen Dr' Logical Status is Normal
 
Then
        Set 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Lock
 
Else
        Set 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Unlock
 
// This program must be disabled or every time the KtchDr_Lock is unlocked (not Locked) the KtchDr_Lock will lock.
// The status is "not locked" as there are multiple status values such as "unlocked", "locked", "Jammed", and "unknown".
// Door open status must be Normal (aka closed) for the KtchDr_Lock to lock, otherwise it will unlock. 

Req #2 has been more of a challenge as displaying states that rely on more than one device requires using variables as flags. In this case I wanted to combine the door status from my Elk with the lock status from the Zwave lock. I'd hope to write a simple program that would mathematically combine the integer values coming from these two devices into a single door status variable. Maybe something like tghis:

0= Closed and Locked,
1= Closed and Unocked
2= Open
3= Trouble

Unfortunately I wasn't able to dream up a math function to generate such a status variable because the Elk reports door status as:

0= Normal (aka closed)
1= Trouble
2= Violated (aka open)
3= Bypassed

While the Yale lock report lock status as:

0= Unlocked
100= Locked
?= Jammed

Instead I wrote a program that mashes together boolean logic with math operations, which IMHO is rather inelegant. This program checks if the door is both closed and locked and if it is, runs the Then branch to set the Door_Flag to 0. Otherwise it sets the Door_Flag to 1 if the door is closed and adds door status - the lock status is ignored in this case (which is a bit ugly). The flag is interpreted as follows: 0= Closed and Locked, 1= Closed and Unlocked, 2= Trouble and 3= Open (lock status unknown).  Here is the program:

KtchDr_Door_Status - [ID 0022][Parent 0021]

If
        'Alarm / House Alarm System / Kitchen Dr' Logical Status is Normal
    And 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Status is Locked
 
Then
        $Ktch_Dr_Door_Flag  = 0
 
Else
        $Ktch_Dr_Door_Flag  = 1
        $Ktch_Dr_Door_Flag += 'Alarm / House Alarm System / Kitchen Dr' Logical Status 
 
// The program checks if the door is both closed and locked and if it is, sets the Door_Flag to 0. Otherwise it sets the Dr_Flag to 1 if the door is closed (0) but unlocked (1+0) and 3 if the door is open (1+2) - the loock status is ignored.. 
// The flag is interpreted as follows: 0= Closed and Locked, 1= Closed and Unocked 2= Trouble and 3= Open (lock status unknown)
// FYI Door Status values from the Elk are 0=Normal, 1=Trouble 2= Violated and 3=Bypassed. 

Then I headed into UD Mobile to build the Lock Object in Favorites. It took Javi's configuration design and pointed it to the Door_Flag, rather than the lock. I also had to adjust the Advanced Configuration Status to display the Flag. This is the configuration and the end result:

 

It works pretty well and my family is happy with it. However it has some serious limitations:

1. It doesn't display the battery level of the lock. 
2. It neglects all the other door and lock status info, which I'm sure will cause me trouble one day.
3. The icon doesn't change because I couldn't find a representative icon for a smart lock that might indicate the various states. Yes I tried using the open and closed padlock symbol, but it just confused everyone. @Javi - please add more door icons or let us load our own. For example, sliding door icons in an open and close state would be very nice. 

I'd really appreciate any feedback and improvements to this design. If anyone can solve the missing features in an elegant way or come up with a clean math function I'll send you the $10 Starbucks gift card sitting beside me on my desk 😀

[Javi]

Nice work!  This is one of the more difficult automations.

Variable Math functions:

This is a little more involved and very dependent on the devices.  The best solution I can think of is to use variables similar to bitwise.  This would allow you to combine status from multiple nodes into a single variable.

Yale lock values as Y:

0= Unlocked
100 = Locked
101 = Jammed

Elk Values as E:

0 = Normal (aka closed)
1 = Trouble
2 = Violated (aka open)
3 = Bypassed

The variable will be represented as YYYEE or E.  So Locked and Bypass would be YYYEE or 10003 (100-03). Note that the multiplication value (i.e * 100 below) is dependent on the number of places occupied by the next variable, in this example it could have been * 10 as Elk values only have the "ones" place, if the Elk values had a "tens" place then * 100, if the Elk values had a "hundreds" place then *1000.

Advanced: This could be expanded with the battery property (B) represented as YYYEEBBB. However the Zero values may cause an issue for the third value, so +1 may be required for all variables which have zero values

Variable values:

Yale Unlocked

0 = Y0 * 100 + E0

1 = Y0 * 100 + E1

2 = Y0 * 100+ E2

3 = Y0 * 100+ E3

Yale Locked

10000 = Y100  * 100 + E0

10001 = Y100 * 100+ E1

10002 = Y100 * 100+ E2

10003 = Y100 * 100+ E3

Yale Jammed

10100 = Y101 * 100+ E0

10101 = Y101 * 100+ E1

10102 = Y101 * 100+ E2

10103 = Y101 * 100+ E3

Now you have a unique value for each combination of states.

Example Calculation:

Note that this is an example which combines the current temperature (T) with the heat setpoint (H) TTTHHH with multiplication accounting for the hundredths place (*1000)

The variable is 74069 or TTHHH Temperature = 74 and Heat Setpoint is 069 (69)

 

 

Display Battery Level:

Currently the standard favorites tiles only shows the state of a single node/var/etc (i.e. display node). So displaying both the status of the variable and battery level is not possible.   This is possible with custom tiles but requires some HTML. However the current instructions are only for developer testing and will be changed soon. I'll be releasing new instructions when everything is ready in the app.  

This is similar to the Thermostat tile which shows multiple properties, but could also show properties from multiple nodes.

Node Server (Plugin):

When the new instructions are released we will be adding instructions for developers to have Custom Tiles attached to Node Servers.  This may work in this situation by creating a node server which observes properties for both the door and lock nodes then combining them into a single node with a custom tile.  Developers can charge for their Node Servers, so if this is built for yourself it can be shared with others, and possibly generate income.

[PLCGuy]

Hi Javi

Thanks for such a detailed reply. For some reason the forum didn’t inform me of your reply but now that I’ve seen it I’m going to try it out, especially your idea for the variables.