need help with WHENEVER zone BECOMES NOT SECURE - SHORTED

[dBeau]

I have a zone defined "non-alarm/EOL supervised" and an automation rule that should trigger whenever the zone becomes shorted. I can fire a rule on the transition from NOT SECURE - OPEN --> SECURE, but the transition from NOT SECURE - OPEN --> NOT SECURE - SHORTED doesnt trigger the WHENEVER BECOMES NOT SECURE - SHORTED rule. Is this a bug or am I missing something?

I am trying to use a momentary rocker switch and just one zone to fire two different rules. Normally, the zone is NOT SECURE - OPEN. Pushing the top of the rocker shorts zone and puts into NOT SECURE - SHORTED while pushing the bottom of the rocker adds an EOL resistor to circuit and makes it NORMAL.

When I watch the status of the zone the state of the zone follows the state of the wires as expected, so I know there is no problem there.

 

[Sandpiper]

I have a zone defined "non-alarm/EOL supervised" and an automation rule that should trigger whenever the zone becomes shorted. I can fire a rule on the transition from NOT SECURE - OPEN --> SECURE, but the transition from NOT SECURE - OPEN --> NOT SECURE - SHORTED doesnt trigger the WHENEVER BECOMES NOT SECURE - SHORTED rule. Is this a bug or am I missing something?

I am trying to use a momentary rocker switch and just one zone to fire two different rules. Normally, the zone is NOT SECURE - OPEN. Pushing the top of the rocker shorts zone and puts into NOT SECURE - SHORTED while pushing the bottom of the rocker adds an EOL resistor to circuit and makes it NORMAL.

When I watch the status of the zone the state of the zone follows the state of the wires as expected, so I know there is no problem there.

Only a guess......perhaps the ELK rules are designed to detect a change from secure to non-secure or non-secure to secure but not from one non-secure state to another non-secure state.

If this is true, you may have to make the neutral button position the "normal" state, and the other two position the non-secure states. I cant think of an easy way to do this with a rocker switch, but with two separate pushbuttons (one NC and the other NO) this would be easy.

Another solution would be to use a relay to do the necessary switching.

 

[dBeau]

Only a guess......perhaps the ELK rules are designed to detect a change from secure to non-secure or non-secure to secure but not from one non-secure state to another non-secure state.

I was thinking the same thing. I was hoping someone would confirm it though. It sure sounds like a bug in that a transition is happening.

If this is true, you may have to make the neutral button position the "normal" state, and the other two position the non-secure states. I cant think of an easy way to do this with a rocker switch, but with two separate pushbuttons (one NC and the other NO) this would be easy.

I was hoping to keep it simple.

Another solution would be to use a relay to do the necessary switching.

And yet another is to use a second zone for each switch. If it was just one switch I'd consider it, but have three of these toggles already. Three more zones would hurt.

Of course the best solution would be if somebody came along and called me an idiot and told me the right way to do it Short of that, a firmware upgrade from Elk would do the trick!

I had been using non-momentary rockers and just checking for SECURE vs NON SECURE. It worked great but was a bit non-intuitive. If you wanted to hit the top of the rocker but it was already up, you had to push it down first, then up. Sounds like I might have to go back to that.

 

[Neurorad]

dBeau - I've spent some time going through this thread, and I don't understand why you're doing what you're doing.

I don't own an Elk (yet), but I've been trying to learn how to use it.

I following everything that's been discussed - I just don't know why you'd be doing it. Just testing the circuit?

 

[dBeau]

dBeau - I've spent some time going through this thread, and I don't understand why you're doing what you're doing.

I don't own an Elk (yet), but I've been trying to learn how to use it.

I following everything that's been discussed - I just don't know why you'd be doing it. Just testing the circuit?

It's an attempt to save on wires and input zones. The most straight forward approach would be to connect each momentary rocker to two different zones. One zone would keep an eye on the top of the rocker while the other would monitor the bottom. Rules could then be defined to activate on the transistions of those two zones (WHENEVER zone BECOMES NOT SECURE). Doing this for my three rocker switches would require 6 zones.

Turns out that zones are a bit smarter than just SECURE/NOT SECURE. There are three physical states that a zone can be in: EOL, OPEN, SHORT. The zone type specifies (among other things) how these physical states map to a zone status. It happens that my momentary rockers also have three physical states: normal, top pressed, and botton pressed. By wiring an EOL resistor in line with one side of the rocker and causing a short with the other side of rocker, the switch can convey its three physical states to the elk while using only one zone per switch.

The problem is that to be useful rules need to be triggered when a zone changes state. In my case I need rules triggered whenever the zone goes from OPEN to SHORT and OPEN to EOL. The latter works fine. The former doesnt... at least not for a supervised non-alarm zone.

...or were you curious about how I get my garage doors to go up an down?

 

[dutchyn]

Turns out that zones are a bit smarter than just SECURE/NOT SECURE. There are three physical states that a zone can be in: EOL, OPEN, SHORT. The zone type specifies (among other things) how these physical states map to a zone status. It happens that my momentary rockers also have three physical states: normal, top pressed, and botton pressed. By wiring an EOL resistor in line with one side of the rocker and causing a short with the other side of rocker, the switch can convey its three physical states to the elk while using only one zone per switch.

You can decide to use voltage levels instead of SECURE/NOT SECURE. If you put a 2200 ohm resistor inline with one switch, and two 2200 ohm resistors inline with the other, you get access to four voltage levels, just like the 4-state wiring. Then you can program the control to respond to each voltage level. Others use this technique to identify which car is parked in which garage bay, based on ultrasonic measurements of vehicle height.

 

[dBeau]

You can decide to use voltage levels instead of SECURE/NOT SECURE.

Voltage levels sound like a great idea for applications like presence detection where the response time of the system is not important. In my case, when a user presses the button, they expect a response right away. In the Elk there are two ways to trigger a rule in response to a zone change. One is to periodically check the state of the zone, the other is to let the Elk do that for you and trigger a WHENEVER/BECOMES rule. The former is either slow (1 sec minimum) or slows the elk down in other ways (if there are too many of these). The later is perfect but the Elk doesnt trigger rules on voltage levels changes (or apparently transitions between non-secure states).

Now if we knew when to check the voltage level in response to a button press, we'd have something. It turns out that the switches I am using are DPDT. I just wired them up so that the previously unused side of each switch will short out a fouth zone. This is the trigger. Then I modified the rules to all read "WHENEVER trigger BECOMES SECURE AND switchX is SECURE or SHORTED". This works great at the cost of another zone and more complex rules.

It occurs to me now that with only two zones, one for the trigger and one for voltage level, the Elk could probably handle 8 or so switches. The switches would have to be double pole with one side all connected in parallel to the trigger zone and the other side side tapping into a resistor based voltage divider connected to the other zone. The rules would all trigger from the trigger zone but would check that the voltage of the value zone is within a range determined by the number of resistors in the circuit. Since the ELK doesnt support an "if within range" condition for analog zones, programming would be a pain, but it would work.

 

[Lagerhead]

It occurs to me now that with only two zones, one for the trigger and one for voltage level, the Elk could probably handle 8 or so switches.

Clever solution. I wonder why you limit the application to 8 switches (16 poles) -- is this just a conservative design point? Twelve volts over sixteen divisions gives 0.7-0.8 volts per division. If you push this to 30 or so divisions (15 switches), you still have 0.4 volts per division. Much beyond that would probably start to test the practical limits of the solution.

Since the ELK doesnt support an "if within range" condition for analog zones, programming would be a pain, but it would work.

I think this can be done with one rule per division. WHENEVER trigger AND voltage<x AND voltage >y THEN. . .

 

[dBeau]

Clever solution. I wonder why you limit the application to 8 switches (16 poles) -- is this just a conservative design point? Twelve volts over sixteen divisions gives 0.7-0.8 volts per division. If you push this to 30 or so divisions (15 switches), you still have 0.4 volts per division. Much beyond that would probably start to test the practical limits of the solution.

I was just being conservative. If you were to use 1% or better precision resistors you could probably push it further. I havent played with the A/D conversion in the Elk so I dont know how much slop there is there. Things could change based on temperature or battery vs AC power. Either way, I think you'd have to build the resistor network and observe the results to try to find the center point for each position. With only a few points, you could probably just get away with doing the math and using the results for the rules.

Since the ELK doesnt support an "if within range" condition for analog zones, programming would be a pain, but it would work.

I think this can be done with one rule per division. WHENEVER trigger AND voltage<x AND voltage >y THEN. . .

The way the Elk counts it, I think that's three rules. But you are right, that's about how it would look.

The solution that I settled on (one zone per switch, plus a trigger zone) has the advantage that rules can be written to deal with simultaneous button presses as unique events (button1 up with button 3 down --> turn on hot tub). Might be useful for some applications. The two zone divider approach will always report as if only the switch with the lowest resistance was being pressed.

I'm going to leave things as they are, but if I find myself in need of a couple of more zones, I know where to find them.

 

[Lagerhead]

I have a zone defined "non-alarm/EOL supervised" and an automation rule that should trigger whenever the zone becomes shorted. I can fire a rule on the transition from NOT SECURE - OPEN --> SECURE, but the transition from NOT SECURE - OPEN --> NOT SECURE - SHORTED doesnt trigger the WHENEVER BECOMES NOT SECURE - SHORTED rule. Is this a bug or am I missing something?

The M1 behavior is even stranger than dBeau discovered. Besides this odd omission for Zone Type 0, the behavior for Zone Type 3 rules differs, and the ASCII messages generated are different still.

Recently when installing some new door-state and deadbolt-position detection I encountered the same problem. Out of frustration I documented the behavior for all of the transition conditions. Here is the result.

[codebox] Type 0 Type 3 Type 3
Transition Rule? Rule? ASCII? Indication
-------------- ------ ------ ------ -----------
Short -> Open no yes no door opened
Short -> EOL yes no yes bolted
Open -> Short no yes no door closed
Open -> EOL yes yes no (N/A)
EOL -> Short yes yes yes unbolted
EOL -> Open yes yes no tamper

Type 0 = EOL Supervised
Type 3 = EOL Supervised on Short

Rule? = Is a Rule triggered on this transition?
ASCII? = Is an ASCII message sent on this transition?
[/codebox]

As dBeau found, no rule is triggered on the Short-Open or Open-Short transitions for Type 0. OTOH, these transitions *DO* trigger rules for Type 3, while Type 3 puzzlingly omits triggering for the Short-EOL transition. Yet more inconsistent (and frankly too sparse) is the behavior of the ASCII messages generated on these zones.

FWIW, the solution for me is Zone Type 3 with a hack -- a couple of rules that send the missing ASCII strings. But I am not happy to sacrifice the text storage space in the M1 and had to make some other compromises to do so.

Bugs, or is there some rationale for this behavior?