Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
TrigEvent::GetZoneAlarmInfo
#1
TrigEvent::GetZoneAlarmInfo now has a new parameter and the upgrade defaults it to Name. This needs to be LVar:Name, or you will get the following error when you execute the trigger:

Seq#230 - 06/24 13:00:39-HARTFORD,CQCEventSrv,CQCEventWorkerThread3
{
CQCKit,CQCKit_StdCmdTargets.cpp.4829,Failed/Data Format,Error:773/0/0
Variable names must start with 'LVar:' or 'GVar:'
}


--Bob
Reply
#2
I found this in the .925 release info:

Automatically update any of the triggered event commands that read out the event info for the above affected event types, to add another target variable for the name value. This new parameter is optional, so it will just update them to have an empty value for that parameter, for backwards compatibility.

Apparently it didn't make it empty but rather had the word Name there, which obviously doesn't work because it needs an LVar: or GVar:

My code which uses this doesn't fire unless my alarm goes off. Today while I was at lunch a mylar balloon in my kids room set off the alarm. I didn't get a SMS from CQC (via IFTT.com) and the police were called. Ooops. Also I ignored the call from my monitoring system (ooops) - hey its a 1-800 number and was trying to enjoy my lunch.

--Bob
Reply
#3
Okay, one more question - also from .925 release notes:

Though I hate to make such changes late in the process, one of the long standing shortcomings in some of the event triggers is the lack of the name of the zone, motion sensor, or load in the triggers. Originally it wasn't an issue since few drivers allowed for naming of things. Now, moving forward into V2, it will be much more common. So update the Load, Motion, and Zone triggers to also take a name. Add new '2' versions of the CML base driver class' methods that allow drivers to queue up those trigger types, so that a name can be passed as well. I'm not going to try to add new filter types for filtering by these names, but at least they are there to use in various ways.

Can you point me to the signature for the new SendZoneEvent2 method? Maybe I'll add to the dev elk driver (though that would make it .925 dependent)

--Bob
Reply
#4
Oops, yeh, apparently it didn't default the wrong value. I'll fix that.

The SendZoneEvent2 is the same except it has one more parameter at the end, which is the name of the zone. Same for the Motion and Load ones.

I've updated the docs but haven't uploaded the last batch of changes yet.
Dean Roddey
Explorans limites defectum
Reply
#5
Okay, failed again!

I modified my trigger's GetZoneAlarmInfo call to use LVar:ZoneName as the 3rd parameter (instead of the bogus "Name" which was inserted by the upgrade). However, I have not yet modified my driver to use the 2 version of the function to send a name. I figured the variable would just get an empty string, and the next line of my trigger overwrites it by querying the driver to convert ZoneNumber to ZoneName.

Code:
07/03 09:03:17-HARTFORD, CQCEventSrv, CQCEventWorkerThread0
{
    CQCEventSrv, CQCEventSrv_ThisFacility.cpp.2017, Info/App Status
    Started processing triggered event 'Alarm -> EMAIL -> SMS'
}
07/03 09:03:17-HARTFORD, CQCEventSrv, CQCEventWorkerThread0
{
    CQCKit, CQCKit_Event.cpp.1388, Failed/Not Found, Error: 1000/0/0
    Value '/cqsl.zoneinfo/name' was not found in this event
}
07/03 09:03:17-HARTFORD, CQCEventSrv, CQCEventWorkerThread0
{
    CQCEventSrv, CQCEventSrv_ThisFacility.cpp.2079, Status/App Status
    Scheduled/Triggered event 'Alarm -> EMAIL -> SMS' failed
}

Unfortunately this is not the case and one cannot even ASK for the name parameter if the source of the event didn't set it. This seems a little rude, but I can fix the problem locally by simply omitting the 3rd parameter (I hope).

--Bob

P.S. I wish I could test this without actually setting of the alarm in my house!
Reply
#6
Oops, I guess it's not getting put into the trigger data if not provided. I'll update the query command to be tolerant of that. Sorry.
Dean Roddey
Explorans limites defectum
Reply
#7
OK, this will finally work in .933. Sorry about that.
Dean Roddey
Explorans limites defectum
Reply
#8
Thanks. I don't know if this helps you or not but I was thinking of a new utility: CQCEventSender which could send events into the system which are otherwise difficult to generate. It could take an input file from event dumper output and this would enable me to test my trigger without annoying the neighbors.

Anyway while thinking of this I turned on the dumper, and here is the output from a zonealarm event. Note the name==. Normal?

Code:
EvID=186613CEC7E71530-DF6BCF273FFF757E
cqsl.header
{
    v=1
    sysid=747AB624337F73FA-2FC92546E3382BF8
    class=cqsl.zonealarm
    source=cqsl.field:Security.PhysZone182
}
cqsl.zoneinfo
{
    state=secure
    zonenum=182
        name==
}

--Bob
Reply
#9
Some sort of little utility like that would be useful for sure.

On the name== thing, no that's not correct and it's one of the things I just fixed, since I noticed it as I was testing out the sending of these triggers without without the name so that I could test the GetXXXInfo() commands. So that will be fixed as well.
Dean Roddey
Explorans limites defectum
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)