Zone Trigger (zt) Command

[Jay Basen]

I’m trying to use the zone trigger command as described in the API documentation to trigger an alarm state on a zone using code running on a Crestron smart home processor.  To trigger zone 55 I am sending the following command – “09zt05500AF”.  For testing, I just have zone 55 configured as Type 16 – Non-Alarm.  I was expecting that if I sent the command that I could watch the zone status of zone 55 change from normal to violated.  Am I incorrect in this assumption?  Is there a way to test the command without triggering the alarm system to sound the siren, etc?

Thanks in advance for the help

[Brad Weeks]

The “zone trigger” ASCII command only causes a momentary open state and violated status of the zone. Having a zone definition of “non-alarm” will not cause an alarm. The ‘non-alarm” zone can be used in an automation rule to trigger an event.

 

In order to verify that the “zone trigger” ASCII command actually triggered, an example automation rule like this could be used:

Whenever Zone (non-alarm)  (Zn 55) Becomes Not Secure

Then turn Relay (Out 3) On for 10 seconds.

[Jay Basen]

Thanks so much!

[Jay Basen]

Hi,

Well I tried the suggested test of turning on an output with an automation and it didn’t work.  As a starting point for my debugging, could you please validate that the command 09zt05500AF to trigger zone 55 has the correct checksum.  If my checksum calculation has an error that is certainly going to keep this from working.

Thanks

[Jay Basen]

Never mind.  I used the example in the API documentation to validate that the checksum calculation is correct.  I need to look at other reasons this isn’t working.

Thanks

[Jay Basen]

Hi

I configured Zone 58 to be a water alarm (I also tried several other zone alarm types).  Then I sent the following string to the Elk system to trigger zone 58:

09zt05800AC\x0D\x0A

The keypad did start beeping and the keypad display said there was a water alarm.  However, there is an automation that runs whenever there is a water alarm to trigger an output that is connected to a Watercop motorized valve to turn off water to the home.  This didn’t execute.  In addition, the Crestron Elk M1 Zone Control Module reported that the Zone Status was normal.  It didn’t report that the zone was violated.

It seems that there are significant limitations to the zone trigger command and that the only workable solution is to wire outputs on the M1 system to zone inputs and use the outputs to trigger the zones to an alarm state.

Thoughts?

Thanks again for the help

[Martin Banks]

Hello OP and other contributors.

We’re having a similar issue.  We’re trying to trigger an automation based on the Zone Trigger command sent via RS232 from a control system (Crestron in this case).  Broader picture:  We want to use the Crestron motion sensors (PIRs) on a site to trigger events / automations / actions (call them whatever you like) on the Elk M1.

We’ve used the Ness SDK software to generate ASCII serial strings.  (Ness is the re-badged Elk brand in Australia.).   We’ve cross-checked the strings with the RS232 Protocol document, and checked the checksums with a checksum calculator.  All look correct.

We have been able to successfully use generated strings to trigger outputs and check input voltages.  Happy days.  Furthermore, the M1 is already doing a heap of integration things via RS232 from the Crestron.  Therefore, it’s not an issue with the RS232 setup.

However, the problem we have:  The Zone Trigger (ZT) command simply does not work.  In fact, it doesn’t even prompt a serial response (rx$) from the M1.  We’ve tried several combinations of configuration on the RP software to program our M1 Gold for a ‘virtual’ or ‘phantom’ input.  None of them work.  Including:

– Zone Definitions: Non-Alarm, Burglar Entry/Exit, Burglar Interior

– Type: EOL (with a 2k2 resistor), Closed (with a jumper) and Open.

The documentation suggests ‘many’ zone types will function.  It also suggests a momentary Open command is issued, from which my limited brain deduces the zone should be configured with Normally Closed with a jumper in order for a change of state to be recognised.

I’m home from site now and looking at this forum so I can’t do further testing until I get back to site.  I see the previous replies about using a Non-Alarm definition to trigger an automation response, and I’ll try this tomorrow.  But… I’m not confident, because the ZT command doesn’t even get a rx$ response from the M1.  Seeing as other commands work fine (Outputs, Voltage query), it seems to me the serial syntax is wrong for the ZT command.  But the documentation marries up with the SDK code generator.  Therefore if I trust the documentation, the problem must be with the zone setup on the M1.

I’ll try the above method (i.e. make an Automation rule) tomorrow.  In the meantime, if anyone on this forum happens to read this and knows the solution, I’ll buy you a drink if you ever come to Queensland.

Lots of love.

[Jay Basen]

I was never able to get the zone trigger command to work for me.  I ended up wiring an output on the Elk alarm panel to the zone I wanted to trigger and then using the command to open/close the output.  Hope this helps

 

[Martin Banks]

Thanks Jay.

I just tried your method (physically wire an Output relay to an Input, then use the Output Pulse command (cn) to simulate an Input violation) and it indeed works.  So thank you!

Would be great to properly implement the zt instead though.  I’ve reached out to Elk and to Ness in Australia today.  Let’s see what they come back with.

Cheers

[Jay Basen]

Glad it worked for you.  It is a rock solid solution even if it does waste an output.

[Martin Banks]

Hi Jay, Brad et al.

I’ve had some success today with zt.  Here’s what worked:

– Brad sent me a firmware update overnight to 5.2.39.  Was previously running 5.3.10.

– I ran a series of tests across various vacant Inputs, with combinations of physical jumpers and open circuits, then tested by pulsing the zt command using the approved syntax.  I used the Ness SDK software to generate the strings.  I assume there is an Elk branded version of this software too.  The generated strings agreed with the Protocol document and I checked the checksums with an Online Checksum Calculator.  For example for Input 48, I used the string:  09zt04800AD\r.

– Command has no effect on inputs without a physical jumper.

– Command only worked for me on Zone Type “1 = Normally Closed”.  Therefore has no effect on Zone Definition “00 = Disabled”.

– On pulsing the command, the Input would stay Open/Violated for different times according to the Zone Definition.

– “01 = Burglar Entry/Exit 1” stayed violated for roughly 32s

– “04 = Burglar Interior” stayed violated for roughly 32s

– “16 = Non-alarm” stayed violated for roughly 46s

 

So, we have success and can use the command going forward for M1 responses triggered by Crestron, such as Crestron PIRs and digital triggers from security cameras.

Thanks Brad and Jay for your help.

[Jay Basen]

That is great news Martin.  Thanks for letting me know

Jay

[William Turner]

I am also interested in using the zone triggers from Home Assistant https://www.home-assistant.io/integrations/elkm1/   Uses the function SERVICE ELKM1.SENSOR_ZONE_TRIGGER
Cause a zone on the panel to trigger. This command creates a virtual momentary open condition on the zone as if the EOL hardwired loop had been physically opened.

I didn’t have it working, but if I understand from your testing above, the Input must have a physical jumper, so additional MXIN cards would be needed for jumpered inputs rather than a virtual input.

Does the input jumper require a terminating resistor?    And needs as the normally closed wiring examples?

Any indication if a firmware roll-back is required for 5.3.18?

Best regards,

Bill Turner

[Jay Basen]

Hi Brad,

Martin was able to get it working without wiring the zone to relay.  Since I have it working using a relay I haven’t gone down the path of trying to make it work through software.  That will wait until I need to trigger a zone again for something else.

To answer your question, whether you need a resistor is dependent on how you have defined the zone.  If you just define it as normally open or closed then you don’t need a resistor.  If you define it as EOL Hardware / Wireless then you will need a resistor.

Hope this helps

Jay

[Author]

Posts