Can anyone tell me why this simple rule isn't working?

[George M]

It seems like a simple rule, but it is not working.

I am trying to get info about who was the last to unarm the alarm into my HA program (CQC).

I have a series of this rule (one for each user)

WHENEVER Home (area 1) ARM STATE BECOMES DISARMED
AND LAST USER WAS George (user 1)
THEN SET Code (counter 10) TO 2


and so on up to setting counter 10 to 8

However no matter who disarms the system, the counter is not changed to the appropriate #.

 

[jpmargis]

How are you determining that the counter is not changing? Any possibility you mixed up the counter names? More than one with the same name? The rule looks good. You can add a THEN to display a text string on the keypads just to verify that the rule is actually firing.

 

[George M]

I have a widget in my screen from my automation program. When the counter changes to 1 it will show "George", when it is 2 it will show "Mark" etc. If I change the counter manually the changes occur correctly on my screen.

 

[drvnbysound]

I use the same setup to get text messages when certain people arm/disarm my panel. The only thing I have different is the THEN statement.

 

[wuench]

I agree, try some local feedback. It may be that the CQC driver is not polling/updating the counters correctly. I think it was counters that were a PITA to deal with over the ASCII protocol, there is a long delay when polling them for some reason on the Elk. And there are several versions of the CQC Elk driver floating around, I think one didn't poll automatically. I am not sure what made it into the official release.

So you may want to rule out the CQC driver first, by doing something like Drvn said above and do text on the keypad, etc in the rule. If that works, then it is a CQC driver issue.

 

[video321]

Did you power cycle the panel?
I had a last user issue too until I cycled the power.

 

[George M]

[quote name=Wench' timestamp='1357484400' post='186086']
I agree, try some local feedback. It may be that the CQC driver is not polling/updating the counters correctly. I think it was counters that were a PITA to deal with over the ASCII protocol, there is a long delay when polling them for some reason on the Elk. And there are several versions of the CQC Elk driver floating around, I think one didn't poll automatically. I am not sure what made it into the official release.

So you may want to rule out the CQC driver first, by doing something like Drvn said above and do text on the keypad, etc in the rule. If that works, then it is a CQC driver issue.
[/quote]
Good point. Ill try that out.

 

[Dean Roddey]

The shipped Elk driver expects to get async notifications for counters, so they should be updated quckly, though you do have to insure that the correct optoins are set in the Elk to have it send them. You have to indicate during driver install how many you want the driver to care about. It queries them during connect but then depends on asyncs.

 

[George M]

The shipped Elk driver expects to get async notifications for counters, so they should be updated quckly, though you do have to insure that the correct optoins are set in the Elk to have it send them. You have to indicate during driver install how many you want the driver to care about. It queries them during connect but then depends on asyncs.

Dean,
I just posted on the CQC forum about this. On the client side of the driver I do have certain counters to be updated from Elk. I believe I have 1 through 40 set up that way. When you say "you do have to insure that the correct optoins are set in the Elk" do you mean in the Elk itself or in the CQC Elk driver as I mentioned above?

EDIT. I just checked my Elk setup. On the global / misc page all items are checked to be updated.

 

[Dean Roddey]

First thing to do is to just change a counter outside of CQC in some way you know it works and see if it shows up. If so, then all is well there and the problem has to be elsewhere.

 

[George M]

Well I have confirmed that Elk is working properly. A change to value of a counter is recognized and acted upon in Elk. I have changed the Counter value in multiple ways (via rules, tasks and the turning on of a light switch). All actions resulted in a rule that will send a text message to the keypad and chirp an interior siren. This happened in all cases.

So I am moving this to the CQC forum, because it is a case of the Counter value change not being synced with the Elk driver in CQC.

 

[Dean Roddey]

It sounds like the Elk isn't sending out the async notification as it should, or at least as the docs imply it does If you hook up a serial terminal to the serial port and change counters, do you see notifications being spit out for those changes? I would test it but my Elk is hosed right now and I need to send it in for a replacement.

 

[electron]

It has been a while since I did any ELK driver work, but I was under the impression that you had to poll the values, the ELK does not transmit whenever a counter changes (that could potentially DoS the system).

 

[George M]

It has been a while since I did any ELK driver work, but I was under the impression that you had to poll the values, the ELK does not transmit whenever a counter changes (that could potentially DoS the system).

I think you are correct since they are not listed under the Globals / Special page where you check mark what you want reported through Serial Port 0. Those items listed are: Event Log, Tasks, Zone Changed, Lighting, Output Changes, and Keypad Keys.

 

[Dean Roddey]

Hmmm... the driver is assuming they are transmitted for some reason. Not sure why that is, since it's lost in the depths of time now. That's really going to be sub-optimal. You can have a fairly large number of them and they have to be queried one at a time. If you define, say, 60 of them, at best we wouldn't want to try to poll more than a couple per second on the kind of constantly ongoing basis it would require, which would mean a 30 second latency worst case before we'd see a change. If we tried to get the latency down to what you'd normally expect for async reporting changes, we'd have the serial port locked up constantly just with counter polling.

They really need to provide some means for async notifcation. A Dos issue is easily avoided by only bother to check if they need to send any once every couple seconds. Either that or provide for a 'read all counters changed since the last time I checked' type of call or something. Otherwise it's going to be pretty impractical if you need any signifcant number of them.