EZeye & EZIO6I

Matt,

What do you think of SHN's reply

Re: EZeye & EZIO6I
by grif091 on Tue Jul 27, 2010 12:11 am

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.

bob

Matt,

I just linked the #1 & 5 input to the PLC. The log shows the inputs switch ON and OFF but there is no State change display in the State column or in the Binary Inputs display at the bottom of the window. I unlinked them and I'm back to where I started in that I have to select the Get Input/Output Status button to get the status.

I followed the 4 step procedure below and and it's working OK again but why is there no display when linked?

1) Re-do the Define and Sync
2) Totally close the device dialog and re-open it
3) Inside the EZIO settings sheet, press the Upload Settings button.
4) Turn on the Analog Inputs checkbox, press the Upload Settings button again

regards,

bob

[matt (support)]

What do you think of SHN's reply

I find it a big confusing, because the EDIT section seems to contradict the first paragraph. The first paragraph says 4F 09 doesn't apply to INPUT broadcasts, but the second paragraph says it does for the EZIO8SA and furthermore the command should be sent for all EZIOxx modules even though it doesn't appear to work for non-EZIO8SAs.

Regardless, the build of Indigo you have now does both. It sends both 4F 09 and it sets the flag in the "port configuration" register to also enable input and output broadcasting.

I just linked the #1 & 5 input to the PLC. The log shows the inputs switch ON and OFF but there is no State change display in the State column or in the Binary Inputs display at the bottom of the window. I unlinked them and I'm back to where I started in that I have to select the Get Input/Output Status button to get the status.

I'd like to see an Event Log snippet showing: the broadcasting working (after you do the Define and Sync again), the input linking, and the inputs changing to show the linked input ON/OFF commands coming in but not the broadcasts (that is, the broken state). I'd like to see all of that together in a continuous log so I can check to see if Indigo is inadvertently sending any commands that would disable the input broadcasting.

Question though: if the input broadcasting is working, then why are you trying to manually link the inputs now?

Matt,

I'll do the testing as you ask and send you a copy of the Events Log. I'll probably get to it tonight.

As for why I tried linking when the Broadcast Status Change is working is because of what SHN mentioned in reply to one of my posts. They said that the Broadcast Status Change was the least reliable Insteon communication. They saw that I had a lot of problems in the past with my EZIO8SA and replied with this;

I have not seen that behaviour with any of my EZIO2X4s (have 3 installed) or my EZIO8SA. Were you using the Broadcast Status Chg? That is about the least reliable Insteon communication you can use. Not that the SHN family is missing an Input change but the Broadcast command is a single message sent in the blind. That is, it is not sent to any specific device. It is like to old X10 messages. One message goes on the powerline and if the powerline is very good things work fine but usually the powerline is not all that clean and a Broadcast message is lost sometimes. Insteon deals with that with Group command processing by following up a Group Broadcast with Group Cleanup Direct commands to each device in the Group. This command is ACK by the responder and repeated up to three times by the Controller if an ACK is not received. Group protocol is used when there are links between the Controller and the Responder. I never use the Broadcast Status Chg option for that reason. Also why I had some trouble setting that test case up as I don’t use it on a day to day basis. Linking is much more reliable because linking forces the Group command protocol with all the associated ACKs and retries.

bob

Matt,

I did the linking. If I link input #1 only then you can see from the log that (button 1) one effects both inputs #1 & #5/ I cover the EZeye (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).

If select the Get Input/Output Status 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 await further instructions

bob

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)

[matt (support)]

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):

Code: Select all

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.

It is like to old X10 messages. One message goes on the powerline and if the powerline is very good things work fine but usually the powerline is not all that clean and a Broadcast message is lost sometimes

Comparing an INSTEON broadcast command to an X10 command, IMO, is like comparing apples to oranges. There are several reasons the INSTEON command will be much more reliable: INSTEON uses BPSK encoding, the messages are hopped/repeated several times, all modules in the network act as repeaters, etc. Note that Group Cleanup commands do help reliability, but they aren't foolproof either if there are underlying signal problems or heavy INSTEON traffic on the power line.

Matt,

These are the posts regarding my last post about the manual linking failing once I link the second input. I don't see an answer here do you?

bob

Re: EZeye & EZIO6I
by grif091 on Thu Jul 29, 2010 10:57 am

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

Re: EZeye & EZIO6I
by grif091 on Thu Jul 29, 2010 11:45 am

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.

[matt (support)]

Actually, I think this does explain the behavior you are seeing:

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.

If you link only 1 of the groups, then the EZIO is still sending the broadcast status change command because the other input is changing. Whenever it broadcasts, it includes the binary state for all of the inputs so they both update. But once you link the other input as well, then broadcasting is disabled for both inputs (per their reply above) and it stops sending the broadcast status change command.

So, you need to either use only linking and patch into the INSTEON Group commands coming in, or you need to not link and just use the broadcast status change functionality. If you do the former, then you'll likely want to track the state of the inputs in separate Indigo variables (using Trigger Actions) since the internal binary input states of Indigo won't be automatically updated. That is, Indigo doesn't update its internal EZIO states based on the incoming Group/Button linked commands. This is because Indigo is currently designed to work with the EZIOs using the broadcast information, or via status polling.

Matt,

OK now I think I understand; I could create a third input just to keep the Broadcast Status Change working or I could use linking and have trigger update a variable if there is a change.

Is it a lot of work to make Indigo work with the linking even if the linking is done manually? Like in my case if both inputs are linked then Indigo uses the linking rather than the Broadcast Status Change?

thanks for your help, I hope others find this useful too.

bob

[matt (support)]

OK now I think I understand; I could create a third input just to keep the Broadcast Status Change working or I could use linking and have trigger update a variable if there is a change.

I'm not sure. I think it is only working because your 2 inputs are related (both are hooked up to the EZEye and changing about the same time). I guess if you wired the digital EZEye input to both I1 and I2 of the EZIO, but only defined the links on I1 and I5, then it would work but I'm not positive.

Is it a lot of work to make Indigo work with the linking even if the linking is done manually? Like in my case if both inputs are linked then Indigo uses the linking rather than the Broadcast Status Change?

I'll add it to the list, but to be honest this type of change won't likely make it into any 4.1.x release. We are focusing our development time on the big 5.0 features currently, while still of course doing critical fixes (and really trivial changes, which this would not be) to 4.1.x. But I'll definitely make sure it makes it to our (rather large) feature ToDo list.

Matt,

Can you tell me why I get so many of the "Received INSTEON "EZIO6I" inputs status changed: 1, 0, 0, 0, 1, 0" at the same time?

thanks,

bob

2-Aug-10 6:37:19 AM
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: 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: 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: 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: 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: 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: 1, 0, 0, 0, 1, 0
Received INSTEON "EZIO6I" inputs status changed: 1, 0, 0, 0, 1, 0

[matt (support)]

I'm not sure. Maybe a floating inputs problem, or your analog trip points are spaced too closely together? It is odd the values themselves are changing, but maybe the values are bouncing back below (or above) the threshold before the status broadcast is sent out. Seems unlikely though....

I'm not sure. Maybe a floating inputs problem, or your analog trip points are spaced too closely together? It is odd the values themselves are changing, but maybe the values are bouncing back below (or above) the threshold before the status broadcast is sent out. Seems unlikely though....

It needs pull ups to work correctly...

Mike

What are pull ups? Can you explain what and how to do?

thanks,

bob