EZeye & EZIO6I

[Anonymous]

#43423

Bob,

The UDI ISY links all the Inputs back to the ISY/PLM as part of adding the device to the ISY so it does not matter what the Broadcast Status Chg option is set to. The existence of a link for a particular Input overrides the Broadcast option for that Input. If you are thinking about an ISY you want to be on 2.8.0 firmware level. That is in Alpha status right now but I have tested the SHN device support and found it working fine. You have to send an email to the UDI support id and they will send you a link to access the 2.8.0 level. UDI is adding some additional support for the MorningLinc, GarageHawk and maybe ELK which is preventing them from moving 2.8.0 into Beta. The SHN device support looks solid. Although I have been using Insteon almost from its beginning I’ve had my ISY for only a few months. It has been rock solid so far. The device has a good reputation and great support.

Not all but many UPS and some PC power supplies attenuate Insteon signals. The devices are so good at clamping down noise they also affect the Insteon signal. I have all my PC/UPS equipment on FilterLincs. Just have to make sure the PLM does not wind up on a filtered or surge suppressed outlet. I did that by accident once and it sure played heck with Insteon communication.

Oh, yes there are nights where sleep is hard to come by. Rather than fight it I just find something to do on the computer or something on the TV.

I may have been wrong about using the Continuous AD conversion option. That may be necessary for the Analog inputs to work with trip points. Because my test had the EZEye digital output on Input 1 and the analog output on Input 5, whenever the analog changed the digital also changed. Any time the analog values are queried they are updated so that the query returns the most recent AD conversion value. I think the same thing happens whenever a digital state change happens so when Input 1 changed state the analog value of Input 5 would have been updated and it also triggered a state change because of the trip points defined. I have to do some testing where only the analog output is connected and see if the trip point works without the Continuous AD option. That option might be needed for the trip points to work. The query of the analog values should return the most recent conversion regardless of the AD conversion option. If you find the trip points are not working try turning on the Continuous AD conversion option.

Lee

[Anonymous]

#43424

I just got this reply from Perceptive Automation”

Re: EZeye & EZIO6I
SimpleHomeNet wrote:
Are the Inputs linked to the Indigo PLM or are you using the Broadcast Status Chg option to report state changes. Also if using the Broadcast Status Chg option when not using Analog 1 in Analog mode, when the Enable Analog Inputs option is set is the Broadcast Status Chg option also being set.

Indigo always enables the Broadcast Status Change option. It does not link the individual inputs back to the PowerLinc, but instead relies on the broadcasts occurring.
SimpleHomeNet wrote:
The full Configuration Register is set when any option is set so it is necessary for Indigo to set all the options that are desired when any one option is changed.

Indigo does do this. Here is an example showing the raw commands sent when the analog input option is disabled:

CODE: SELECT ALL
Debug SENT: insteon 0F.9D.D7 05.06.2E 00 4D 40
Debug RCVD: insteon 05.06.2E 0F.9D.D7 21 4D 40
Debug RCVD: ack from 05.06.2E for command 4D 40
Sent INSTEON “_ezio8sa_” write configuration flags (received: 40)

Debug SENT: insteon 0F.9D.D7 05.06.2E 00 4F 01
Debug RCVD: insteon 05.06.2E 0F.9D.D7 21 4F 01
Debug RCVD: ack from 05.06.2E for command 4F 01
Sent INSTEON “_ezio8sa_” finalize i/o device EEPROM changes

And here is an example with analog inputs enabled:

CODE: SELECT ALL
Debug SENT: insteon 0F.9D.D7 05.06.2E 00 4D 41
Debug RCVD: insteon 05.06.2E 0F.9D.D7 21 4D 41
Debug RCVD: ack from 05.06.2E for command 4D 41
Sent INSTEON “_ezio8sa_” set analog input trip values
Sent INSTEON “_ezio8sa_” write configuration flags (received: 41)

Debug SENT: insteon 0F.9D.D7 05.06.2E 00 4F 01
Debug RCVD: insteon 05.06.2E 0F.9D.D7 21 4F 01
Debug RCVD: ack from 05.06.2E for command 4F 01
Sent INSTEON “_ezio8sa_” finalize i/o device EEPROM changes

Note in both cases bit 6 is set (0x40 and 0x41). I also re-verified that my old EZIO8SA sends out the status change broadcasts regardless of the state of the “enable analog inputs” option.

I replied with this:

Re: EZeye & EZIO6I
Simplehomenet says they can’t reproduce my problem and basically you say it should work as the Broadcast Status Change is enabled.

If the EZIO6I input #1 updates OK if ENABLE ANALOG INPUTS is not selected and then if the ENABLE ANALOG INPUTS IS ENABLED and this causes neither the #1 or #5 input or the Analog input to automatically update nor show any action in the Events Log can it be a problem with the EZIO6I?

Is there no way to manually link the EZIO6I to the PLM using the buttons on the sides of the units? If so how?

Also when I upgraded to 2414U I was never prompted for the driver. Everything other than this problem with the EZIO6I is working OK. Could the driver be the problem?

I’ve asked PA again if I can manually link the EZIO6I to the PLM 2413U. I would of thought if the Broadcast Status Change was working I would of had something in the Events Log.Can it be the EZIO6I is failing when asked to send Broadcast Status Change messages for both Analog & Binary?

Other than your utility is there anyway to link the EZIO6I to the PLM?

thanks,

bob

[Anonymous]

#43425

The example posted for writing the configuration register was for what looks like an EZIO8SA. Can you run the same trace using your EZIO6I?

Many PC based products write links to PLMs. PowerHome2, HouseLinc2, the SHN Utility will but it cannot write link records to the same device it is using to communicate with the powerline. You would have to use the PLC as the powerline device for the SHN Utility for it to be able to write link records in the PLM. Also it seems like Indigo is dependent on the Broadcast message. If you have active links with the EZIO6I Inputs it will send Group messages rather than Broadcast messages.

They must be writing at least one link record in the PLM with the EZIO6I address as the PLM will not pass the Broadcast message back without it. The PLC might have but the PLM will not.

The only thing I can say is that my EZIO6I sends Broadcast messages for Input 1 and Input 5 when the Enable Analog Inputs and Broadcast Status Chg options are set in the Configuration Register. Have you double checked the wiring of the EZEye to be sure all 4 wires are connected to the correct EZIO6I pins. Not sure how bad wiring would cause the result but just trying to cover all bases.

[Anonymous]

#43426

The example posted was from Matt at Perceptive Automation, I don’t think I can extract that info. I’m going to ask.

I have the information to link the EXIO6I to the PL2413U. I’m going to give it a try and see what happens.

Matt thinks the fact that the EZIO6I is not broadcasting both the Analog and Binary inputs is a failure in the EZIO6I. See his post

http://www.perceptiveautomation.com/userforum/viewtopic.php?f=7&t=5988&p=35874#p35874

Can your EZserve be used to write link to the PLM? Since Indigo does not do it I am looking for some way (other than your windows based utility) to write links.

I’ll get back to you on the linking the EZIO6I to the 2413U.

thanks once again for your help.

[Anonymous]

#43427

There is a device type listed for the SmartlabsPLM on EZSrve. I’ve not tried using that device as a Responder so cannot answer that with direct knowledge. Do you have an EZSrve and if so what firmware level is installed. I have a new EZIO6I being mailed to me. Should be here by Friday afternoon. I will be able to verify that the latest firmware does (or does not) generate Broadcast messages. If it does perhaps you can return the EZIO6I and have it flashed to the latest firmware level. I don’t think it is a firmware issue but have no direct way to prove that at this point. Indigo is correct that if an active link exists it suppresses the Broadcast message for that particular Input. Since it looks like Indigo has to see a Broadcast message linking will likely not prove anything. Even if Group messages are sent it would be concluded that Group messages work but that does not prove Broadcast messages work. I can see that they have confidence in Indigo setting the Broadcast Status Chg bit. I would like to see a trace that shows it being written to the EZIO6I device type or have the SHN Utility read the Configuration Register and find both bits On. It is not a generic problem with the firmware as much of the code is common across all the EZIOxx devices and it is working with their 8SA. It is also working with my EZIO6I. That leaves Indigo setting the bit as an open question, perhaps the firmware in your EZIO6I is not sending the Broadcast message. Seems a strange symptom that turning on the Analog option would affect a digital Input broadcast message. I have no way to prove it is not however. At this point all the things that are necessary to have it happen need to be verified which includes knowing for sure the Broadcast Status Chg flag is actually on. The absence of that bit would explain the lack of Broadcast messages from both Inputs. That does not mean the bit is not On, only that it is one way to produce the symptom you have.

[Anonymous]

#43428

Matt has me running some tests now. I’ll post the results.

bob

[Anonymous]

#43429

Bob,

Indigo must have the ability to trace the PLM activity. Can you trace the activity when Input 1 does signal a state change. Perhaps seeing what the Broadcast message looks like from the EZIO6I Input 1 will show something useful.

Lee

EDIT: i’ll be away from the house tomorrow until about 3 PM EDT.

[Anonymous]

#43430

Matt found the problem. Can I send you my EZIO6I to be updated if that in fact will fix the problem?

Re: EZeye & EZIO6I
CODE: SELECT ALL
PowerLinc Linking – . enabling: status change broadcasting
PowerLinc Linking – . reading: configuration settings, input trip points, and output timer durations
PowerLinc Linking – . . . read: configuration settings 00

Well, this shows what is going wrong, and explains why SimpleHomeNet couldn’t reproduce the problem.

The first line above Indigo is telling the module to always broadcast changes. To do so, it sends the command bytes:
CODE: SELECT ALL
0x4F 0x09

Next, Indigo reads all of the settings from the EZIO. Included in this is the configuration flag byte, which includes the broadcast change bit along with other flags:
CODE: SELECT ALL
0x4E 0x00

The EZIO returns, as a result of that command, 0. But it should return that bit 6 is set because of the first command which enabled the broadcasting. I believe that is likely the firmware bug that you have uncovered.

Indigo then stores off that entire flags byte (as returned by EZIO) and modifies its bits as you make changes in the sheet (but never changing the broadcast bit, which is assumed to now be correct), and then eventually sends that byte back to the EZIO when you press the Upload Settings button.

So the problem is the EZIO is telling Indigo the broadcasting is disabled even though the command immediately before it should have enabled it. Indigo presumes the EZIO returned a good value, and then uses that value later. So it might really be enabled after the first command, but because the EZIO later tells Indigo it isn’t enabled Indigo fails to pass the correct bit value later.

I think I will change Indigo to always force the value of that flag to ON regardless of what the EZIO returns as the status of that flag. That will probably short circuit the problem.

[Anonymous]

#43431

Unfortunately the 4F 09 does not enable the Broadcast Status Change message for Input changes. It enables the Broadcast Status Change message for Output changes. The Configuration Register controls the generation of Input Status Change messages. Have him consult the EZIOxx Advanced Details document. It describes the 4F 09 as setting “Enables Output Port status change broadcast messages”. What they need to do is enable the Input Port status change broadcast message.

EDIT: the command sequence Indigo is doing for the EZIO8SA is the correct sequence and should be done for all EZIOxx devices where they want to generate Input Status Change messages. That is why the EZIO8SA produced the correct results. The command set is common across the entire EZIOxx family of devices.

[Anonymous]

#43432

There seems to be some confusion in the document the way Matt at PA reads it but never the less he made some changes to Indigo and gave me an advance copy and the EZeye/EZIO6I is now working in Broadcast Status Change mode. Now that I have it working I tried to manually link the digital & analog inputs I’m using but I’m having a problem.

If I first link input #1 only then you can see from the log that (button 1) one effects both inputs #1 & #5 ( I’m covering the EZeye to simulate dark) both #1 & #5 go to 0. If I then link #5 as well, there is no status change when I cover the EZeye (dark) so linking input #5 stops the automatic sending of the input status.

If select the Get Input/Output Status in Indigo it will update the Inputs. Which puts me back where I was originally except now there is no automatic updating with linking, before there was no automatic updating with Broadcast Status Change.

I sent this info to Matt and he replied;

I’m afraid this one might be a question for SimpleHomeNet. As shown in your Event Log Indigo is setting the broadcast input/output bit flag (4*) multiple times (it never clears it):

PowerLinc Linking – . updating: configuration settings 40
…
Sent INSTEON “EZIO6I” write configuration flags (received: 40)
…
Sent INSTEON “EZIO6I” write configuration flags (received: 41)

Doing the manual linking process shouldn’t clear the broadcast flag in the EZIO. Try doing a Re-Sync or Define and Sync of the module. That should not affect links you created and will force Indigo to send the command to set the broadcast flag again, just in case it got cleared.

Personally, I wouldn’t bother with the manual linking at all — I would just use the broadcasting. Although SimpleHomeNet is correct in that the broadcasting isn’t ACK’d, the broadcast command is sent out with the maximum hop/repeat count for an INSTEON message so it will be re-broadcasted multiple times by the entire INSTEON mesh network. Presuming you don’t have any egregious signal problems, it is very likely that Indigo will get the message.

This is the Event Log when I was trying the manual linking. Matt’s response is based on this log.

28-Jul-10 11:40:21 PM
PowerLinc Linking – entered discovery linking mode (240 seconds)
PowerLinc Linking – sending id request for device information
PowerLinc Linking – received module button pressed from 0C.B1.75
PowerLinc Linking – sending id request for device information
PowerLinc Linking – received id request response from 0C.B1.75
PowerLinc Linking – retrieving firmware version
PowerLinc Linking – initializing remote device “EZIO6I” (address 0C.B1.75, firmware version 25)
PowerLinc Linking – . enabling: status change broadcasting
PowerLinc Linking – . reading: configuration settings, input trip points, and output timer durations
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
PowerLinc Linking – . . . read: configuration settings 00
PowerLinc Linking – . updating: configuration settings 40
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 1
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 1
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 1
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 1
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 1
PowerLinc Linking – . . . read: analog1 raw trip points 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 1
PowerLinc Linking – . . . read: analog2 raw trip points 0, 0
PowerLinc Linking – . . . read: output timer durations
PowerLinc Linking – initialize complete
PowerLinc Linking – device “EZIO6I” properties updated
PowerLinc Linking – syncing remote device “EZIO6I” (address 0C.B1.75, firmware version 25)
PowerLinc Linking – syncing of this device not possible remotely (skipping)
PowerLinc Linking – sync complete

28-Jul-10 11:41:09 PM
PowerLinc Linking – exited linking mode
Sent INSTEON “EZIO6I” input binary states request (received: 1, 0, 0, 0, 1, 1)
Trigger Action _EZeyeBinary
Sent INSTEON “EZIO6I” input analog value request (received: 0, 0)
Trigger Action _EZeyeAnalog
Sent INSTEON “EZIO6I” write configuration flags (received: 40)
Sent INSTEON “EZIO6I” finalize i/o device EEPROM changes
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 1

28-Jul-10 11:41:49 PM
PowerLinc setting analog1 OFF to ON trip point raw value to 45
PowerLinc setting analog1 ON to OFF trip point raw value to 40
PowerLinc setting analog2 OFF to ON trip point raw value to 1
PowerLinc setting analog2 ON to OFF trip point raw value to 0
Sent INSTEON “EZIO6I” set analog input trip values
Sent INSTEON “EZIO6I” write configuration flags (received: 41)
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Sent INSTEON “EZIO6I” finalize i/o device EEPROM changes
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 1, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 1, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 0, 0
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 0, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0

28-Jul-10 11:43:02 PM
Sent INSTEON broadcast set button down

28-Jul-10 11:43:48 PM
Received INSTEON “EZIO6I” off (button 1)
Received RF security command sensor normal (min delay) (ID 85)
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 0, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” on (button 1)
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” off (button 1)
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 0, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” on (button 1)
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” off (button 1)
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 0, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” on (button 1)
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” off (button 1)
Received INSTEON “EZIO6I” inputs status changed: 0, 0, 0, 0, 0, 0
Trigger Action _EZeyeBinary
Received INSTEON “EZIO6I” on (button 1)
Received INSTEON “EZIO6I” inputs status changed: 1, 0, 0, 0, 1, 0
Trigger Action _EZeyeBinary

28-Jul-10 11:45:23 PM
Sent INSTEON broadcast set button down

28-Jul-10 11:46:19 PM
Received INSTEON “EZIO6I” off (button 1)
Received INSTEON “EZIO6I” off (button 5)
Received INSTEON “EZIO6I” on (button 1)
Received INSTEON “EZIO6I” on (button 5)
Received INSTEON “EZIO6I” off (button 1)
Received INSTEON “EZIO6I” off (button 5)
Received INSTEON “EZIO6I” on (button 1)
Received INSTEON “EZIO6I” on (button 5)

Thanks! I think we are getting closer.

bob

[Anonymous]

#43433

A command that is not ACKed by architecture cannot be retried. It is the ACK, or lack of one from the Responder, which controls whether a Controller will retry a command. A Broadcast command has no To: Insteon device address value (To: address contains Group number) so no device on the powerline knows to ACK a Broadcast command. Therefore no retry for Broadcast command. This is Insteon in general, not unique to SHN devices.

Linking an Input does not affect the Configuration Register bit but it does override the Broadcast function for that Input. When an Input is linked it no longer generates a Broadcast message for that Input. An input state change for a linked Input will generate a Group ON/OFF command sequence for the Group number that has been assigned to the particular Input.

Unless the Indigo trace is reversing the order of the received bits on the Input status change Broadcast message the bits are in this order from left to right, 6,5,4,3,2,1. The Analog trip points for Analog 2 should be set something well away from the 0/1 values that the trace shows. A floating Analog Input hovers near the 0/1 value and will generate meaningless state change messages. Set the unused Analog 2 trip points to 400 for Off to On and 200 for On to Off. That does not guarantee that a floating Analog input will not generate a state change but those values should keep them to a minimum.

Glad to hear progress is being made. I should receive my new EZIO6I tomorrow. I will verify that it generates Broadcast commands as expected in case you do want to order a firmware upgrade. I don’t think that is necessary to achieve correct Broadcast command generation but will verify on the latest firmware in case you do want to go that way.

[Anonymous]

#43434

The Hop count and message retransmission has to do with Insteon devices rebroadcasting (repeating) messages. It has nothing to do with Insteon retrying a command three times. When an Insteon device receives a message on the powerline that is not sent to it specifically it rebroadcasts (repeats) the message at full powerline signal strength based on Max and Remaining Hop count. The Hop count insures that messages are not rebroadcast forever which I think Insteon refers to as a message storm. This is an important aspect of Insteon reliability as it insures that messages are moved down the powerline at maximum amplitude. This is not command ACK and retry that is associated with Group command processing used when an Input is linked to a responder. There is an insteondetails.pdf document in public space accessible from a link from the Smartlabs web site if you are interested in learning more about Hop counts and message rebroadcast. The document is old but it has a good explanation on message Hops and rebroadcast which still applies today. HouseLinc2 has a good powerline diagnostic that allows a user specify the Hop count number to be used during powerline evaluation. The larger the Hop count on received messages the better the quality of the powerline. Conversely the more ACKs received for messages with original small Hop counts the more reliable the powerline.

[Anonymous]

#43435

Lee,

Not sure if there is an answer in your last posts to my question or not. I have the Broadcast Change Status working fine thanks to a change by Matt. Now I want to use linking instead of the Broadcast Change Status so I tried the linking process in the EZIO6I Quick-Start Guide. After successfully linking EZIO6I input I1 I can cover the EZeye and see the #1 input (button 1) change OK in the Indigo Event Log and on the Indigo Binary Input display. The problem is once I link the EXIO6I I5/AN1 then the linking is not working at all. When I cover the EZeye there is no input change again as seen in the Event Log. Why is is once I link the second input they stop working?

thanks,

bob

[Anonymous]

#43436

The links records are not correct or the Group numbers assigned to the Inputs are not correct. Something occurred when creating the second link record that overlaid the information used by the first set of link records or the link records themselves were overlaid.

Describe in detail what you did to create the links. Did Indigo create the links, did you use the Set button technique on both devices (cover the exact Set button sequence, how long held, how many times pressed to select the Input, etc), was indigo involved in creating either end of the links. If you run the SHN Utility it will show both the Group numbers assigned to the Inputs and the link records in the EZIO6I. It cannot display the link records in the PLM assuming you would be using the PLM as the powerline interface device for the SHN Utility.

[Anonymous]

#43437

Bob,

Where Broadcast setup and processing is more the exception, Group definition (linking) and Group messages are the norm. Whenever devices are linked together Insteon uses Group command protocol exclusively. In most houses I would guess that 95% of Insteon traffic is Group related, device controlling device. I say that only to put Group processing in perspective. It is the most tested most exercised aspect of Insteon. If Group processing is not working something in the setup or definition is amiss.

After a Factory Reset all EZIOxx Inputs have no Group numbers assigned and no link records in the link database. In the simplest definition when using the Set button to link an EZIOxx device as a Controller to a Responder the Input is identified by the number of times the Set button is tapped. When done with the Set button Input 1 is assigned Group 1, Input 2 is assigned Group 2, etc so Group number to Input number is predictable. If software/firmware is defining the linkage any Group number convention can be established. For example, the ISY assigns Group 9 to the first Input, incrementing the Group number by one for each subsequent Input. So long as the Controller device and the Responder device use the same Group number in related link records any Group number can be used. Just so someone does not jump in and correct that statement there are some limitations. Group 0 cannot be used, Group 255 cannot be used as that is reserved for All On/All Off but in general any Group number between 1 and 254 is okay so long as the same Group number is used in the “Controller of” link record in the Controller and the “Responder to” link record in the Responder and that Group number has been assigned to the respective Input.

If you are thinking about using the SHN Utility to verify what information has been stored in an EZIOxx device I can guide you through the process.

Lee

[Author]

Posts