evarsanyi

I'm sorry, I haven't had the cycles to work on this yet. My EZIO's are gathering dust at the moment.

No progress as far as I can tell. When I'm out from under some work I'll try to write a program to dump a working linked EZIO, hopefully that will give UDI a clue as to how SH changed the internal layout.

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

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

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.

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

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

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

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] 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.

OK, I tried the rename thing and it didn't change anything at the next boot. What's funny is the 2 devices its complaining about haven't even been queried yet when it puts up the message. I pull the PLM/ISY out of the wall, wait a bit and plug it back in. As soon as it starts to ping (ICMP) I go to the admin applet and immeditaely its got these 2 pops about the devices being unreachable. If I then turn on the event viewer and watch it churn through my configuration (for about 5 minutes) querying everything when it gets to each of those devices there is no problem at all querying it (no retries, no problem). Its like it remembered there was a problem with them once and feels it has to report it every time it boots.

Also, FWIW using the SmartHomeNet utliity, after a factory reset the EZIO comes up showing group 0 for input 0, group 1 for input 1, etc.

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

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

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.

Yes, if I "touch" the devices (faston or off or whatever) they start to act normally until the next reboot.

The same two units (in an installation with perhaps 70 units) get flagged as being unreachable every time I log into the admin UI after a reboot. The show up with an '!' as well, however if I go to either of them and query it always works but usually leaves the '!' up. If I turn either one off and back on (or fast on/fast off) the unit responds and the ! goes away until the next ISY99 reboot. Both of these units have been replaced in the past (though many others have as well). I've tried restoring the devices and that doesn't seem to help. If I watch the insteon traffic with a scope there's no unusual noise and a good strong signal at both locations (4.5-5V P2P after the first hop). I can read the link database (2-3 mins of continuous traffic) w/o a retry usually and it always compares correct. One of the units is a 2476D dimmer and very new (an RMA replacement from SH), the other unit is also a fairly new 3 pin lamplinc. This has been happening on 2.7.0 and now 2.7.7. Any ideas what I can do to clear the cobwebs on these?

Yeah, I think that's what I was up to here. The idea was this program would provide a condition to help detect (in another program) a double button press (2 L9 on's in a short time span). My plan was to have 2 other program that did things, one based on a second press within the 5 seconds and one that would occur if a 2nd press wasn't received in 5 seconds. I think I also wanted to use a program as a simple state variable (with a very long wait), it would start when I wanted to set the variable and would be stopped when I wanted to clear it. I never went down that path because there didn't seem to be a way to keep it stuck in a state I wanted easily (using wait, maybe there's another good way). My attempt here is clearly not using it the way it was intended, I'm happy enough to wait for a future release with actual state variables that can be set/cleared/tested and maybe some way to do edge triggering (events) rather than level triggering on states (the level triggering doesn't mesh well with some of the events, like time or X10 which are discreet).

The state gets updated immediately in the applet display when I click either unit on/off w/o issue. My PLM is v52, though the only X10 involved is from an RF transmitter sending the initial trigger (L9 ON) the devices are all insteon. The issue that this seems to be is one SHL and I went around about right after Insteon came out... I have 2 'slave' Switchlincs (no load) at the top of some stairs and its a popular activity to press both on or off with one hand at the same time. The switchlincs don't back off a 'random' interval when retransmitting, so if you get lucky enough to have both of them sync to the same 16ms powerline window (which is actually amazingly easy to do) they do their 5 retransmits on top of each other and the messages never get through. I'm fairly sure this is whats happening here except the loads are on the switches locally so they both go off, its just the ISY that doesn't hear about it. Is there a better PLM version out that doesn't hang when doing lots of reprogramming/setup? If so I'll see if I can get SHP to swap this out...

I was trying to use the program itself (its status) as a state variable that was true for 5 seconds (and could be tested from other programs).

I guess I've got more dialing to do. This setup replaced 60 or so of the older X10 smarthome xxxLincs and when I finally had that running well (with the right repeaters and filters) it was pretty reliable, if slow. I have all the same filters (though I shut off the X10 repeaters/bridge) as before. The filters should be wide enough to cover the slightly higher frequency that Insteon runs at (the are basically low pass filters tuned to pass 60hz well). Any suggestions on tweaking would be greatly appreciated. and in isolation any single operation is *much* more reliable (and fast). Taken as a system however they have some bugs to iron out ... keypad lincs crashing, unreliable PLM firmware, random startup states after power failure, a total joke of a protocol attempt in the PLC, implementation issues around retransmit collisions, and bad QA on the actual switchlinc paddles (I've had about 20% of them go bad mechanically -- the newer replacements are all much better I think I just got a bad run as an early adopter). SHP is a great company and replaces all the ones that have issues instantly, I have no complaints there. SHP did an amazing job making X10 "reliable" (though it was still a toy for early adopter types for the most part) so they had a high bar to make insteon as good or better. I'm sure they'll get it eventually. The reaction I got above is the kind of attitude that will cause them trouble crossing the chasm -- you're not going to get away with telling a luxury home buyer they can't push two switches too quickly after they spent $10K for an upgrade to Insteon in a new house. They'll kick the builder into the next county and that builder will think long and hard before offering Insteon in the next house (and he'll go back to selling hard wired lutron/etc). To the extent things like the ISY can wallpaper over the flakey implementation it will keep knowledgeable installers gainfully employed and the tech hopping (and hopefully get keep us all in new versions with fixes as time goes by). My totally offtopic .02 anyway.

Another datapoint here: I recently discovered you have to wait many seconds to reliably make the ISY see the state of 2 co-located devices changing. Initially I thought I had to hit them pretty close together in time (16ms or so) but it turns out the switchlinc's I've got (rev 1.5 I think?) get confused if one starts transmitting any time the the other is already sending (so maybe seconds if retries are required). I keep coming home to the bathroom fans running (turning them off is gated by the lights being off in the bathroom), checking the status on the ISY and finding it thinks both lights are still on. Maybe I'll try to make a 5 minute poll that just checks the status of these two (and 2 others in a similar situation) over and over. This insteon stuff is really turning into pretty much the same set of headaches as X10 had (flakey) -- which in no way reflects on UD's most excellent ISY.

No word. I haven't really been able to build any sort of state machines with this thing yet unless I use device state as a variable. I'm not keen on buying a bunch of LampLinc's to use as program variables so I gave on this tack for now.

In most other locations where I need to control N lights in the same room I use a KPL or Controlinc -- now that events work well I will also use fast on/off in a couple of new places. Its a great new way to get extra control. The WAF of having to learn to turn off 2 lights on 2 switches that used to work fine on the old Switchlinc X10 system (and before that mechanical Decora paddles) in a new way is *very very* low. It would be like trying to explain to someone you're loaning your car to how you reversed the gas and brake but its *much* better this way. Other problem is turning them on, TW usually holds the 'on' of both paddles down until the lights get bright enough then lets them go (at different times). Yes, scenes could do this if you're willing to imagine what modes you want to have for the room -- when I've tried this no one can remember the events needed to get a given scene unless its a well labeled KPL (and even then the general populace seems to be happier just adjusting each light manually where there's only 2 of them).

In this spot one switch controls the lights on a bathroom vanity and the other switch controls the can lights in the rooms ceiling. When leaving the room we usually press the bottom of the paddles on the way out. This happens frequently in another location at the head of a stairwell. One switch controls the lights in the stairwell ceiling and the other a chandelier at the top of the stairs. Same use case, someone's coming up stairs and wants to shut the lights off behind them, however in that case its worse because both switches are controllers for switchlincs elsewhere that drive the loads -- so you get to the top of the stairs and hit both switches to shut off the lights and nothing happens. It happens to my wife all the time, its not just me being picky.

I realize this doesn't make any sense short term, but... It would be much more flexible if the programming facilities could be used to directly build state machines which could hold internal state (ie: variables) and were passed events directly. All the current functionality could be implemented in terms of these. It would allow one to write code at the level the actual network runs. You don't know that unit X is 'on', you get an event saying it 'went on' (or maybe you don't even though it did); you don't know that the time is XX:XX right now (by definition that's false), you do know that XX:XX has passed from the future to the past. I'm very happy with the functionality provided in 2.5! I have found that implementing solutions in a real world means understanding the ugliness of the real world and trying to wallpaper over it means either you lose flexibility or things can't be made to work reliably. Again, really happy with this stuff, just some input for the next spin.