Jump to content

EZIO6I


evarsanyi

Recommended Posts

I sent back the incompatible EZIO8SA and got an EZIO6I and an EZIO4O. Sadly the 4O was DOA so I'm waiting for another one now.

 

I can't get the EZIO6I to link up with the ISY99 (2.7.7) and produce any useful results. If I manually link the 6I to a switchlinc everything works fine, I activate the input and the device comes on, deactivate the input and it goes off.

 

I tried adding the device and it was detected as an EZIO 6I, however its inputs show no status and if I put an input in a group with the same switchlinc the device is not controlled.

 

The ezio and the isy's plm are in the same outlet.

 

I notice if I manually link it the group numbers for the inputs start at 1 (if I'm decoding the link table correctly) but if I let the ISY generate links it uses group 9 and up (just like on the EZIO8SA).

 

I can communicate with the SimpleHomeNet utility and the inputs show up correctly.

 

Any tips on how I should link with this thing? I just want one of the inputs to trigger a program and/or turn on and off an insteon scene.

 

What sort of debug info can I gather? The results of 'SCAN' on the EZIO seem almost random.

Link to comment

I tried to delete the ezio6i (which went OK), then re-add it by giving its address and allowing auto-discover. It churned for a while doing peeks and pokes then put up the dialog:

 

[-200000] Node not added - failed restoring device [1 70 B1 1]

[5006] UPnP Cancellation failed: SID not found [/CONF/ADR.CFG]

 

This was after it apparently added the 9-E groups for the device (they show up in the 'my lighting' list now).

Link to comment

Hi evarsanyi,

 

May I humbly ask if you followed the ISY instructions on the screen? There's a pause between pressing the set button and then linking. This is the time and EZIO initializes itself.

 

We use group 9 and above for all inputs in EZIO devices.

 

Unfortunately I really cannot provide any more input above and beyond our testing with EZIO6I here which works absolutely fine.

 

The reason for the error is that ISY cannot communicate with the device ( trying to write into a memory location).

 

With kind regards,

Michel

Link to comment

In another post someone recommended not using the manual linking method and rather just adding it by giving its address and type.

 

Can you give me a step by step that you know works with this thing?

 

Starting from the ISY not having it programmed (I just removed it and rebooted the ISY) and having plugged in the ezio6i with the button held down and held it down for 15 more seconds then released it:

 

1) ...?

 

Thanks,

-Eric

Link to comment

OK, I did the following (twice):

 

1) remove the EZIO from the ISY99 (right click, remove)

 

2) power cycle ISY+PLM (wait 5 minutes for it to query everything and go idle)

2a) open event viewer and select level 3

 

3) plug in ezio6i while holding down set button, hold it for 15 seconds

3a) while held the light was on bright

 

4) wait 60 seconds, light on ezio blinks a little and ends up dim

 

5) Under 'link management', select 'new insteon device'

5a) auto-discover, name and address both "01.70.b1"

5b) leave 'remove existing links' radio button set

 

6) This churned for a while and added 01.70.b1 -9 through -E; lots of errors in event viewer around i2 (it seemed to think it was i2 and used extended commands for a while then got an error and went back to i1); it failed at the same exact place both times in the i2 sequence

 

7) Finally ended up popping up a dialog:

 

The first time the error dialog was:

 

[-200000] Node not added - failed restoring device [1 70 B1]

[-5006] UPnP Cancellation failed: SID not found [/CONF/ADR.CFG]

 

The second time the error dialog was:

 

[-110022] Couldn't open file [/CONF/FYP.CFG]

[-200000] Node not added - failed restoring device [1 70 B1]

 

8) I created a scene and added the -9 device and a switchlink relay, activating the input does not result in any event log traffic nor the light changing state; the light on the side of the ezio blinks though

 

I've tried this sequence now with a lamp linc, a relay linc, a normal switch linc, and a relay linc -- same results every time. I did succeed in manually linking the switch linc to the ezio after a factory reset without the ISY99 involved.

 

Test conditions:

- 2.7.7

- New PLM (reports V.85)

- ISY's PLM and EZIO plugged into same outlet box (right next to each other)

- I have scope traces (can post the pictures) showing there is nothing significant going on at ~130Khz and no noise > a couple of millivolts. The insteon signals are very strong (as you'd expect), around 6V P2P measured in the same j-box.

 

I'm thinking of trying this isolated on a power strip behind an industrial strength (ACT) filter linc, but given how relaiably it repeats this it doesn't seem like random noise or a weak signal issue.

 

I saved the event logs and will try to figure out how to post them here.

Link to comment

OK, here are some logs, these are all at level 3. During the first attempted add I had also logged into the console and done a 'DBG 2' (I don't remember if that did anything useful). After that failed I power cycled again and didn't do the DBG 2 for the next attempted add of the EZIO.

 

After first power cycle of ISY (after removing the EZIO), this has mostly the query traffic chugging along for 5 minutes:

http://eljv.com/pub/ISY-Events-Log.2009-12-08.19.49.33.post_reboot.txt

 

First attempt at adding ezio resulting in the UPNP error:

http://eljv.com/pub/ISY-Events-Log.2009-12-08.19.58.45.attemped_ezio_add.txt

 

Second attempt at adding ezio resuling in the FSY error:

http://eljv.com/pub/ISY-Events-Log.2009-12-08.20.23.47.add_ezio.txt

 

Trying to add EZIO to a scene with 1 other device (EZIO -9 first, then the device):

http://eljv.com/pub/ISY-Events-Log.2009-12-08.20.26.32.add_to_scene.txt

 

Finally, here are some pics of the powerline I took while trying to debug the EZIO8 a week or two ago. I'm using an ACT high pass filter meant for debugging X10 issues with a scope, it basically blocks everything below 100Hz or so so you can crank the channel gain up and see millivolt signals at 130ish Khz.

 

There's the usual triac switching noise but not much else going on. There's nothing in this network aside from the lighting and a few proven non trouble making devices (fridge, etc) that isn't behind one of many filter lincs (several commercial grade ones from ACT). There are now 6 signal bridges in the network (2 of the new lamplinc hybrids and 4 of the rev 2 gateways). Signal is blazing strong every place I connect the scope (at least compared to what it looked like with X10).

 

Idle line showing some triac noise but nothing else going on:

http://eljv.com/pub/IMG_0003.JPG

 

Close up of the switching noise spike, even X10 can deal with this:

http://eljv.com/pub/IMG_0004.JPG

 

Some insteon traffic starting at distant device (the lower amplitude bursts) then getting repeated closer to the power box where I was monitoring. The 2nd hop is 6V+ peak to peak and well away from the switching noise.

http://eljv.com/pub/IMG_0009.JPG

 

A broader view of an insteon conversation, the signal strength varies a lot depending on the luck of the draw on who gets the first hop and how far they are (thus how much cancelletion occurs). That's my guess as to why its so flakey. These tests were all reading a link database on a device about 30 wire feet from the main panel where I was monitoring.

http://eljv.com/pub/IMG_0012.JPG

 

Looking for the worst case signal strength, just above a volt was the weakest I caught at the panel:

http://eljv.com/pub/IMG_0013.JPG

 

-Eric

Link to comment

Hi Eric,

 

WOW ... this is amazing and I must say one of the most comprehensive set of diagnostic aids I have ever seen.

 

First of all, I wanted to make sure you knew that you can disable Query at startup while you are testing. This feature is on the Configuration/System tab.

 

Secondly, based on all the logs and your explanations, the problem is definitely not noise related. The problem is how we should program EZIO such that it would work. From what I gather, the problem is that we are using groups 9 and up for inputs where as EZIO (itself) uses groups 1 and up for input. This was not a problem in their previous firmware releases but apparently now has become a problem.

 

I am going to contact them again and see if we can find a resolution or at least some help in programming the latest version of EZIO.

 

I am truly sorry for all the trouble you've been going through ...

 

With kind regards,

Michel

Link to comment

I'm happy to get more diagnostic data if that would help.

 

What is the 'best' way to download the link database in a random device? I was thinking I could manually link it and snapshot the DB then try it with the ISY and do the same, but when I use the link dumper in the diag tools it doesn't always return the same data twice in a row (with no changes happening).

 

What's up with the EZIO looking like an I2 device then failing to work as one?

 

My network has been acting a bit strange since I added more signal bridges trying to make the silly EZIO8SA work. A table top controlinc that I use to shut off everything in the house is now plugged into the same outlet with a new hybrid repeater lamplinc and instead of making things better several devices don't see the 'all off' message reliably now. Again with the scope the signal strength is there and there is no obvious noise, I'm wondering if there's a compatibility issue between new and old insteon devices. The older stuff is certainly buggy a bunch of ways (can't turn off 2 lights manually at the same time too close together in time, extended messaging wildly broken, loads throb during insteon traffic).

 

If you think its worth it I can try the EZIO testing again behind an isolating filter (with just the isy's PLM and the ezio), maybe some other device is interfering at the protocol level (?).

 

I do know about turning off the query at startup. It leaves the ISY in such a wacky state that I hate leaving it off (I thought the ISY stored the 'ON' level for devices, but I guess it doesn't, without the query most devices come up in the ISY as 0% and when i hit 'ON' it does nothing -- until I query it and it shows the correct default on level, then 'ON' works OK; fast on always works of course).

 

I'll trade you my EZIO6I for your working one if it comes to that :)

 

-Eric

Link to comment

Hi Eric,

 

Thanks so very much. I seriously doubt the problem to be signal related. It's how we program the EZIO to use different groups for input. We do this to make a distinction between the inputs and outputs and since EZIO does not let us change the group numbers for output, that's why we have to change the group numbers for input.

 

If we use the same group numbers, then ISY would not know if a relay was turned on or if the input was shorted. So, we have to figure out a way to allow for different group numbers to be used.

 

I am still awaiting a response from SH.

 

Thanks again and with kind regards,

Michel

Link to comment

Is there any chance this will work?

 

I'm happy to do additional debug/testing if it helps narrow things down.

 

If this is going to be a black hole politically please let me know so I can just return these EZIO things; I'll build my own using a USB IO dongle and an NSLU2 :)

 

I really do like the 'instant on' aspect when its manually linked and working (I have one alarm input attached to it so when you open the door into the garage the lights come on, that's pretty nice with a short delay). I'm willing to put in some hours to help straighten this out any way I can.

 

Thanks,

-Eric

Link to comment
  • 3 weeks later...

It was recently thought that EZIO8SA wouldn't work at all and the EZIO6I would, but it turns out a recently purchased EZIO6I doesn't work either. To be clear the EZIO in both cases works if you manually link them with the button pushing method, but if you try to use their utility or the ISY to program the link table over the network they lose in various spectacular and subtle ways.

 

I have gotten an EZIO4O to work without issue as an ISY99 device FWIW.

Link to comment

Hi evarsanyi,

 

I am SO very sorry for not getting back to you. I had completely forgotten. This said, however, have you tried our latest 2.7.8?

 

The very ironic thing is that now EZFlora does not work and exhibits the same issues as EZIOxxx. The good news is that SHN customer support person is looking into it and hopefully we'll find a resolution to all of this.

 

With kind regards,

Michel

Link to comment

I saw the 2.7.8 alpha annoucement but there was no mention of the EZIO in the release notes so I haven't tried it. Did you make some changes to compensate for their link database/i2 issues? If so I'll give it a try...

 

I'm optimistic that USI and SH will eventually make this work :)

 

One possibility: if SH and/or SimpleHomeNet are sending out units with differing memory layouts and there's no automated way to tell it would be 1000% better than now if you could just pick a 'revA' or 'revB' manually when adding the EZIO and experimentally figure out which one works. Its telling that their own (SimpleHomeNet's) utility can't program the link database on these devices either, I think maybe SH changed something and didn't tell them.

 

If the issue is the new layout is "secret" and they won't tell you what it is for whatever reason then never mind :)

 

-Eric

Link to comment

Hi Eric,

 

We did remove the analog inputs and broadcast from EZIO configuration. That might actually have an impact but, the again, I cannot be certain since mine works fine either way.

 

The problem is that we do NOT know what the problem is. If we knew why this is happening, then we would surely fix it. SHN is looking into it and I do hope we'll figure it out one way or another.

 

With kind regards,

Michel

Link to comment

Is there a way with the ISY to just (painfully slowly) dump all the config RAM and link memory for a device w/o otherwise configuring it? I have some old code that did this from my pre-ISY attempt at writing a protocol stack that worked through the PLC (which was a fools errand given the bugs in the PLC interface) so I know its certainly possible.

 

Another option would be to use the XML interface Jeff H is using in his config tool (or the REST interface) if either of those provide a way to send/receive raw PEEK and POKE commands.

 

If we had a way to dump a device I could use the button pushing method to link the EZIO with a unit then dump the whole thing out and we could compare what it did internally to what the ISY is attempting to do (which we can reconstruct from the event log if there's no easier way).

 

?

 

-Eric

Link to comment

Hi Eric,

 

There's a way of doing that through JSDK. If you are interested, please send an email to tech@universal-devices.com and I'll give you the information. Please note that this interface may break everything you have!

 

With kind regards,

Michel

 

Is there a way with the ISY to just (painfully slowly) dump all the config RAM and link memory for a device w/o otherwise configuring it? I have some old code that did this from my pre-ISY attempt at writing a protocol stack that worked through the PLC (which was a fools errand given the bugs in the PLC interface) so I know its certainly possible.

 

Another option would be to use the XML interface Jeff H is using in his config tool (or the REST interface) if either of those provide a way to send/receive raw PEEK and POKE commands.

 

If we had a way to dump a device I could use the button pushing method to link the EZIO with a unit then dump the whole thing out and we could compare what it did internally to what the ISY is attempting to do (which we can reconstruct from the event log if there's no easier way).

 

?

 

-Eric

Link to comment
  • 2 weeks later...
  • 3 months later...

As with many here, I use the EZIO6I to monitor the status of my alarm panel. Also, like many I am frustrated by the inability of the ISY99i to successfully query the EZIO6I. My EZIO6I was purchased after 1-Jan-2010, so I assume it is one of the new models.

 

Where we live, we lose power several times a year--sometimes several times a month depending on the season. Most of the time, its a brief flicker, but it is enough to cause us to have to reset a bunch things. The problem for the ISY99i when this happens is that it can't tell if the alarm is armed or not. Thus, it frequently doesn't run the "away from home" programs that it should. Or conversely, we come home and get involved in something, and the lights start changing automatically, because the ISY99i thinks we're still away. This kind of thing makes home automation extremely frustrating.

 

This frustration led me to dig a little into what is going wrong. I am a complete newbie to the Insteon protocol, and started with these documents:

  • [*:s2vvxfe6]Ref 1:
ISY-99i/ISY-26 INSTEON:Using the Event Viewer
[*:s2vvxfe6]Ref 2: Insteon - The Details
[*:s2vvxfe6]Ref 3: EZIOxx Advanced Details and Command Set

I was unable to locate any form of message sequence charts for the Insteon protocol. Without them, the protocol spec is incomplete, as it leaves much of the semantic interpretation up to each reader.

 

First, let me start with my configuration, which i believe is typical:

alarmpanel.jpg

      • Figure 1. Tree view of the EZIO6I

As you can see from the image, the ISY99i has been unable to ascertain the status of any of the EZIO6I inputs (via a query). In this picture, the status of the Fire Alarm is known, because my spouse accidentally triggered it, thus causing the status to be explicitly sent to the ISY99i (e.g., not obtained by a 'query' operation.)

 

So to delve into what is going on, we selected the "AP-9:Disarmed/Armed" item in the tree view, and selected the "Query" option. The result of this action yielded the following in the log file:

 

logf.jpg

      • Figure 2. Log file for an ISY99i 'Query' command against the EZIO6I.

Using the references listed above, I attempted to parse what is happening. Let me start by saying that I've no clue as to the meaning of the first two bytes immediately after the [action-code] in each logfile entry.


  • Mon 05/03/2010 11:21:05 AM : [iNST-ACK ] 02 62 01.70.F0 0F 4F 02 06 (02)
    (this is a response from the PLM to the ISY99i indicating that it received a query command--4F 02--from the ISY99i, and has forwarded the request to the Insteon network. For reference, the EZIO6I address is 01.70.F0, and our PLM address is 12.9D.12.)
     
    Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 4F 02 (02)
    Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2
    (this is the reply from the EZIO6I, it appears to be the EZIO6I's Direct Acknowledgment of the query command. Bit5 in the 2B value indicates this is an Acknowledgment command, and the command values simply reflect the original query command of 4F 02.
     
    I agree this is not a normal 'acknowledgment' to a query command if you compare it to say a SwitchLinc. However, I could find no place in the protocol specification that indicated this was an -invalid- response. The EZIO6I is simply saying "I'm here and listening" to the query command. Apparently, SimpleHome felt the status that the EZIO did not fit well with the 'normal' query status return (e.g., ST, OL, RR et al). I assume because of this they elected to leave it at "I'm here", and expected the controller to issue subsequent commands for particular pieces of information.
     
    I will also admit to being a little confused as to why the ISY99i is identifying this as "Group 0". The issued request from the ISY99i was a direct point-to-point request, and the response was the same.)
     
    Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 4F 02 (02): Process Message: failed
    Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2
    (this appears to be the ISY99i telling us it doesn't know what to do with the acknowledgment.)
     
     
     
    Mon 05/03/2010 11:21:05 AM : [iNST-ACK ] 02 62 01.70.F0 0F 49 00 06 (00)
    (this is a response from the PLM to the ISY99i indicating that it received a Read Input Port command--49 00--from the ISY99i, and has forwarded the request to the Insteon network. This is exactly what the SimpleHomeNet utility also does to query the status of the EZIO6I.)
     
    Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 49 01 (01)
    Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2
    (this is the acknowledgement and response from the EZIO6I. In the returned commands--49 01--with the 01, the EZIO is telling us that Input 1 is turned 'on', Input 2 and the rest are 'off'. This is precisely right for the state of the EZIO6I at time I ran the query command.)
     
    Mon 05/03/2010 11:21:05 AM : [iNST-SRX ] 02 50 01.70.F0 12.9D.12 2B 49 01 (01): Process Message: failed
    Mon 05/03/2010 11:21:05 AM : [standard-Direct Ack][01.70.F0-->ISY/PLM Group=0] Max Hops=3, Hops Left=2
    (this appears to be the ISY99i telling us it doesn't know what to do with the information returned.
     
    If we go back to examine the state of the EZIO6I as the ISY99i understands it, the information in Figure 1 hasn't changed--the Fire alarm is Off (correct), and the rest of the inputs are unknown (incorrect, since the EZIO6I returned its state.)

For comparison purposes, I loaded the SimpleHomeNet utility and looked at the EZIO6I...

ezio6iinputs.jpg

      • Figure 3. EZIO6I input state after hitting the "Read Inputs" button on the SimpleHomeNet utility.

The state shown is what was expected--Input 1 is On, and the rest are Off. And for comparison purposes, we were curious as to the input traffic that generated:

ezio6ilog.jpg

      • Figure 4. Insteon messages sent & received by the SimpleHomeNet utility for EZIO6I "Read Inputs".

We note that these are the same commands that the ISY99i issued to obtain the status of the EZIO6I inputs.

 

I love my ISY99i. We also appreciate all the hard work the development team puts into the product, and their diligence on the forums in answering questions.

 

With that said, I hold in my hand two products that claim to be Insteon compatible--the ISY99i and the EZIO6I. Both claim to adhere to the Insteon protocol, yet they only partially talk to each other. I am certain this is due to poor specification in the protocol. But from these tests, it looks like the EZIO6I is performing according to the documentation provided, yet the ISY99i is not processing the information correctly.

 

Could you please put the EZIO6I query option somewhere on the priority list to address? I will be glad to help in any way possible. Just keep in mind that I'm very new to Insteon. I'll even go so far as to make an offer to ship you my EZIO6I if it will help solve the problem for all of us.

 

Thanks again for all your hard work!

 

cheers

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...