So I'm having a bit of trouble with logic conditions for a door lock (2.2.4.148). For example I want to write something like "If Door status- unlocked then lock door". On first glance it's a super simple logic expression.
With Hubitat I need to make the condition first , so I select the lock and select the lock state as "unlocked". the following condition is generated by Hubitat "Door unlocked FALSE". It should be creating "Door unlocked TRUE".
So I think, that is weird, but I'll play along and make the condition a "NOT", odd but whatever.
So I make the same condition but this time select the "NOT" flag. What I expect is "NOT door unlock FALSE" but what do I get from the software, I get "NOT* door unlocked TRUE. Which doesn't work for me either since the state is switched in addition to "NOT" added.
My only option is to make the condition, realize it will make the inverse, and then make my statement be "IF "Door unlocked FALSE" THEN ELSE Lock Door" It just seems really clunky to have to do this.
Thoughts?
The first thing I would suggest is that you probably want to use a door sensor so that this has something easy to trigger from, and also you aren't just going to be locking "into thin air" when the door might be open like when you are bringing groceries in from the car or whatever.
Next, community apps are very helpful. Here is one example (might be more) that can do what you want.
Lastly, there are lots of examples in this forum of this. Probably one of those would be a good example to start from.
Sorry I might not have been clear and my attempt to simplify the entire rule may not have been helpful. I already have a trigger event. When the rule is triggered I want it to check the locked status of a second door and lock that door if it is unlocked.
I shouldn't have extracted only part of the rule for my post I just didn't want to make it more confusing....
The entire design is that there is a HID reader by one door. This rfid reader and all the door security is handled by separate hardware. When the door controller grants access in the morning (correct keyfob, correct time/date, etc) it triggers a dry contact for a few seconds. This is wired to a zwave contact sensor (my interface between Hubitat and my door controller). Hubitat checks the door locked status, if the door is locked, it is unlocked and the lights turned on to the building. The door then remains unlocked. In the evening a wave of the correct RFID keyfob the unlocked door and it is locked and the lights turned off. It all works great. The problem is that I wanted to check the status on a second door (there are two doors to this very small building). I wanted to make sure the second door wasn't accidentally left unlocked and here is where I discovered that the conditional statements created by the Hubitat web interface get a bit goofy with respect to door status
-E
also i use the following app to check the state of doors and windows on mode change (away,night) and alert me if something is left open and auto lock the doors if one is still unlocked.
its also available through my apps on package manager ( I didnt write it i ported it from smartthings)
choose action type conditional
then choose if stmt
then choose new condition
then choose the device type ie lock
then then the specific lock , then the options ie unlocked/locked etc.
then your other actions whatever they may be ie unlock other lock, log, turn on switch etc.
then make sure you add another condition at the end the endif for your if
also under conditions
I believe that you may be misinterpreting the orange and green lettering.
That is the current evaluation of the condition based on the state of the system. It is the system trying to be helpful showing you how it would currently be evaluated.
Ahhhh,
Yes, that is it! It also explains some past issues with rule machine logic. I never thought that the actual state of the device would be shown in the conditions. Clearly a RTFM moment.
