Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
M1 alarm triggered info
#1
Is there a way to get what triggered an alarm on an M1.

At the moment I get an SMS indicating that the alarm has gone off, but I dont know why. I want to add the ability to know which zone triggered the alarm.

C ould do it long hand by uaing a lot of IF statements and testing each alarm zone one by one but that seems pointless for a smart system. We should be able to get it easily from the panel.

Mick
Mykel Koblenz
Illawarra Smart Home
Reply
#2
The field name is the source of the event trigger, and you can get the source value out. So you could send that info along.
Dean Roddey
Explorans limites defectum
Reply
#3
If you don't happen to be using the zone alarm event triggers, you can also get the list of violated zones in these handy fields:

AlarmZoneCount
AlarmZoneList

The list is sorted such that the first zone to go into alarm appears first.

I assume Dean has moved the Dev driver into the main build because he said he was doing some initial changes to the security drivers, but if not, it is available in the Beta Drivers section.

--Bob
Reply
#4
I haven't yet. I did the Omni first, and I'm going to take on the Elk next. There are various other things being done at the same time, wrt to configuratoin and the client side interface and such, so it's a fair bit of work. I'm doing some other things for a bit before I come back to the Elk for a final hit before the next release.
Dean Roddey
Explorans limites defectum
Reply
#5
I'm not using the Dev driver and I am just triggering off the AreaAlarm1 field. I'll have to look into the event triggers.

Thanks guys

Mick
Mykel Koblenz
Illawarra Smart Home
Reply
#6
What I'm probably going to do, once I get the Elk driver updated, is add the zone name to the event trigger data. Currently it's just a number, which isn't very meaningful and if I weren't worried it would break stuff I'd toss it out in the same process. But once zones, units, etc... are nameable, having the name would be much more useful. Ultimately the field names would still include the names of the things they are related to. But for more readability, or speakability, having just the name part available would be useful.

For now, you can always just cap it at the underline, and what's left should be the basic name part.
Dean Roddey
Explorans limites defectum
Reply
#7
Yeah, using names is a good thing. Of course, the Elk Zones are all nameable (and voiceable). The Dev Elk driver has all the names queried from the control so they are easy to get at. You could allow users to press a button on the config client and populate all the Log and Phys zone with their proper names.

For now, the Elk Dev driver makes the Elk names available via QueryTextVal ZoneName number.

If you are really feeling ambitious, you could write a program to replace all LogZone001 references with LogZoneFrontDoor. Of course, you'd still miss a few references, but you could take the opportunity to fix the Log/Phys mixup!

--Bob

P.S. Outputs have names also...
Reply
#8
I will do it like the others, where you do the naming at the CQC level, since it can enforce field name constraints and you may not want to use all of the things defined in the Elk/Omni at the CQC level, and you may not want to name them necessarily the same thing. So, though it's a bit more work, providing the naming at the driver config level has a lot of advantages, and is consistent with the way the Omni, RA2, etc... drivers work. A one time query could be provided perhaps to provide an initial population or something.

What's the log/phys mixup again? It may not be possible to fix it without breaking things, depending on what it is.
Dean Roddey
Explorans limites defectum
Reply
#9
The current driver provides two fields for every zone:

LogZoneXXX has the physical properties of the zone (Open, EOL, Short) and
PhysZoneXXX has the logical properties of the zone (Normal, Trouble, Violated, Bypassed)

I'm fine with allowing CQC to use alternative names from Elk, but I think you should have a button to get the Elk name for each zone and possibly for all zones at once. Outputs should definitely get names (Elk has names for the first 30 I think). Voltages, Themocouples, and Thermostats name optional.

Unfortunately I've used the default names in so many places I don't dare take advantage of your new naming ability without some proper tools for updating (or at least searching) my Templates, and Events.

Of course Areas have names too, so instead of AreaArm1 you could have HouseArm. Getting rid of the seven areas that aren't used and all their associated fields might be nice also... By my count, there are 6 fields per area, so that would be 42 fields eliminated for most users anyway.

--Bob
Reply
#10
rbroders Wrote:The current driver provides two fields for every zone:

LogZoneXXX has the physical properties of the zone (Open, EOL, Short) and
PhysZoneXXX has the logical properties of the zone (Normal, Trouble, Violated, Bypassed)

I'm fine with allowing CQC to use alternative names from Elk, but I think you should have a button to get the Elk name for each zone and possibly for all zones at once. Outputs should definitely get names (Elk has names for the first 30 I think). Voltages, Themocouples, and Thermostats name optional.

Unfortunately I've used the default names in so many places I don't dare take advantage of your new naming ability without some proper tools for updating (or at least searching) my Templates, and Events.

Of course Areas have names too, so instead of AreaArm1 you could have HouseArm. Getting rid of the seven areas that aren't used and all their associated fields might be nice also... By my count, there are 6 fields per area, so that would be 42 fields eliminated for most users anyway.

--Bob

+1
Have to fill my 10 character limit.
Thanks
George M
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Triggered Event w/ Elk AreaArm EST 18 5,835 12-04-2020, 05:37 PM
Last Post: gReatAutomation
  Triggered Event only works every second time znelbok 2 988 10-27-2020, 12:05 PM
Last Post: znelbok
  What is everyone using for weather info? ghurty 11 2,377 04-23-2020, 08:00 AM
Last Post: Dean Roddey
  Triggered Event on Timer Question znelbok 7 3,345 12-09-2019, 02:10 PM
Last Post: znelbok
  Editing Triggered Events Possibly Causing Kernel Panic/Crash gReatAutomation 6 2,693 11-08-2019, 01:10 PM
Last Post: Dean Roddey
  Pause / Resume Triggered or Scheduled Actions from the Interface Viewer gReatAutomation 2 1,878 10-30-2019, 01:38 PM
Last Post: gReatAutomation
  NetworkMonitor / Presence Info trigger? gReatAutomation 17 5,726 09-24-2019, 01:08 PM
Last Post: gReatAutomation
  Possible Bug with Triggered Events gReatAutomation 3 1,566 09-19-2019, 02:41 PM
Last Post: gReatAutomation
  Triggered Event and Standard Triggers gReatAutomation 5 1,999 08-23-2019, 12:38 PM
Last Post: Dean Roddey
  LogicServer Elapsed Time and Triggered Event gReatAutomation 6 2,327 08-17-2019, 07:53 AM
Last Post: gReatAutomation

Forum Jump:


Users browsing this thread: 1 Guest(s)