Mac Home Automation

The Hubitat is a fantastic hub but makes some changes to the way things used to work that might cause confusion. Specifically the state of a door lock can be more than just locked and unlocked. It used to be that turning the lock unit in XTension on would unlock such a device, and turning it off would lock the door. The hubitat uses an enumerated list of values for the state of the lock and by default XTension will send the enumeration at value 0 for the off command and the enumeration at value 1 for the on command.

The enumerations as set by the Hubitat for my lock are this, yours may vary:

0: locked
1: unlocked with timeout
2: unlocked
3: unknown

Sending an OFF command to the lock unit will send the 0 enumeration and the door will lock. Sending the on command will NOT send the unlock command, but rather the “unlocked with timeout” command. My door locks either dont support this command or it doesn’t mean quite what it appears to. It does nothing to my locks. I think it may be a feedback letting you know that the door has had the re-lock itself setting turned on in the lock itself and is going to lock again shortly rather than a command you can send to tell it to handle re-locking itself in some amount of time. I’m not sure exactly, but it does not unlock my doors.

XTension solves such problems that many devices have by offering enumerations as a popup menu instead of just a toggle switch showing on or off. The full web remote and all interfaces inside XTension support this automatically and will show you the popup menu of selections so you can always unlock the door properly. The mobile web remote plugin however has not yet been updated yet to support the popup for enumerations and so you can lock the door from a toggle control on it, but you cannot reliably unlock the door from it. You may also wish to implement the simple on and off commands for scripting or you may have already had locks setup this way previous to the hubitat and dont wish to change how you’re scripting them.

If thats the case it is easy to create a “pseudo” unit to use instead of the real lock unit that will handle this for you and provide a simple on and off interface for the mobile web remote or for scripting.

For this example I’m going to create a Pseudo unit named “CONTROL Back Door Lock” and assuming that your lock unit from the Hubitat is called “Back Door Lock” adjust those names as needed for your system.

Since we treat lock units like alarm units the On state is the alarm state, in this case unlocked. And the off state is the clear state which is locked.

Create an ON script for your new pseudo unit and add some code something like this:

set value of “Back Door Lock” to “unlocked"

and create an OFF script of the pseudo unit with code something like this:

set value of “Back Door Lock” to “locked"

This uses the ability of the Set Value verb to accept enumerations as strings where in olden days it would accept only numbers. Since the adoption of the hubitat plugin it was necessary to support their enumerations and if you have the enumerated values setup in the unit, which XTension will do for you automatically when creating units from the Hubitat but you may setup for any other unit you wish, then you may use the name of the value instead.

The last thing to do is add some scripting to the actual LOCK Unit from the hubitat to keep the pseudo control unit in sync with it when changes come from elsewhere or manually.

In the ON script of the real lock unit add a line of code something like this:

turnon “CONTROL Back Door Lock” with no script

And in the OFF Script for the real lock unit add a line of code something like this:

turnoff “CONTROL Back Door Lock” with no script

the “with no script” is necessary and keeps the on or off script of the pseudo control unit from running when the state changes. If we didn’t do that we would be controlling the lock unit, which would control the control lock unit, which would control the lock unit and so on and so forth until the script stack was exceeded and it would throw some errors to your log without actually working to keep the lock control unit in sync. This way the visible state of the control unit will remain in sync with the real lock so that you can hit a simple toggle in the mobile or other interfaces to the unit.

In my case since the Locked state is at 0 and any of the other states should probably show as unlocked I can just use the on/off scripts to set the same on/off value in the pseudo. If your door lock has things in a different order or has other states and is more complicated you may need to use some logic based on the potential values. For example something like this in the ON and OFF script of the real lock unit.

if enumerated value of (thisUnit) for (future value) is in {“locked”, “really locked”, “some other thing that means locked”} then
  turnoff “CONTROL Back Door Lock” with no script
else
  turnon “CONTROL Back Door Lock” with no script
end if

This gets the enumerated value from this unit but not the current one, as the values are not updated until after the on or off script is run, so you must also use the “for” switch and pass it the future value to discover what the NEW state will with. Without that it will return the current state which has not yet been updated for the new value.

Now make sure to add the control pseudo unit to any lists or interfaces, particularly mobile web interfaces, that you wish to more easily control the lock from. If you have other scripts that are using the on and off commands to control the lock make sure they are now pointing to the new pseudo control unit and not still to the old lock unit.

• Created 12/11/2024 by James