andrew67

Guys, I'm here to let you know that I completely disagree with that kind of thinking. The whole point of home automation is to simplify our interactions with the places we live, so we can have a better overall experience. That includes setup. So we are faced with a choice right now. We can have the limited automations that Philips, Google, and Amazon can make money on, can have zero support for anything else, or we can hire programmers every time someone wants to change what a wall switch does. Every time I need to do an update of anything... I have to re-learn the backward way ISY does things... and become a detective. It could be better... It could look for broken links. It could automatically find problems. It could have readable logs. It could have tool tips. Event viewer could have a decode mode...

Partial answers to questions 1 and 2 that I have been able to figure out: The hue bridge maintains the configuration of hue lights, rooms, groups, and scenes, as well as other items. This is all documented in the Hue SDK information, which users should NOT have to read to understand how to use ISY and the Node Server. When setting up your Hue system, you need to remember the following issues/items: a) Hue uses Zigbee, which is a multi-hop routed protocol. There is a "suggested" rate limit which is "recommended" to be no more than 10 requests per second, with groups perhaps not more than 1 request per second. No idea what this means in practice, but its definitely SLOW. Too slow to do any real dynamic effects. b) You apparently MUST put hue lights into rooms. This is enforced by the Hue app. Rooms do not really mean anything more than "group" but you must have each light in one and only one room. In addition there is the default "all lights" group. Zones are groups too, but zones can have whatever you want in them. c) Thus, because you must put each light in a room, its probably better to make the rooms "useful" and to get as much grouping done using rooms, even chopping rooms up into multiple pieces. There is some personal preference to this, but if you never send a command to a room, then you have wasted an entry, which will end up in your long list of hue stuff that you need to scroll through all the time. While nothing prevents you from hitting individual lights, which will also be in the list.... read on for more info. d) The Node server reads the configuration from the Hue Bridge. You really only want to do this ONCE, and only AFTER you have "named" everything in the Hue App. This is because the Node server and ISY do NOT actually communicate about the names of nodes. It is a tortured setup with multiple caches, which will go out of date. i) It appears that subsequently added new nodes can be added to ISY by clicking the "Re-Discover Bulbs" button which is visible in ISY when you click on "Hue Bridge." This only ADDS new nodes (lights, rooms, groups) to ISY. ii) If you remove lights, rooms, zones, etc. they DO NOT disappear from ISY, and cannot be deleted from ISY, you must delete them from the Node server. You do this by clicking on the nodes "button" in the lower left of the button array for this node server. This toggles on/off the list of your Hue devices, rooms, and zones. For each entry, to the right there is a "Delete" button. Deleted nodes do not show up in ISY with status percentages, etc... Its all blank. If the name has also been changed in the Hue App, you may need to search the Node server's list for the ADDRESS which is the part to the right of the NODE ID in ISY which is of the form n001_.... and is listed just under the friendly name when you click on the node name under "Hue Bridge" iii) if you have changed the names of lights, rooms, or zones, the Node server WILL get the new name, but the ISY WILL NOT, and there is NO WAY to update. I suppose you can manually change them in ISY. The node ID does not change unless you have deleted, and recreated the zone, so the connection still works, even though the name is stale in ISY. iv) together, this behavior makes it quite user unfriendly if you don't do it all perfectly first time. e) sending commands to individual lights works fine. The upside is you don't need groups, the downside is that ISY uses a "per controller" light command setup, which is painstaking to create. The alternatives are programs, and using "network resources" but both make the process even MORE obfuscated and complicated. It is NOT clear how paddle dimming is actually supposed to work, and these choices may interact with that. The commands are not instant, and you will see the popcorn effect.

Hey guys, I'm setting up my hue system and have done ok so far, but I am now getting to the point where I need to make some decisions which will take a LOT of ISY programming time. So I want to try to understand how the hue connection actually works. Here's a few questions: 1) when the node server was setup, somehow the devices and names were populated in PG3 Hue (sort of) and moved into ISY as nodes. How/when/how often/etc does this happen? I will probably be adding/moving lights amongst hue rooms and zones (whats the difference?) and would hate to have to fix ISY code each time. 2) Very little from the hue made it into the ISY, specifically not the names of the lights, only the names of groups. Any way to fix this? would make programming easier. 3) The ISY connection involves more than just "triggers." There seems to be the concept of "levels" associated with ISY and specifically Insteon. How are these Levels mapped to Hue in the "Command" structure? i.e. what actually happens when I press paddle up on a scene which includes Hue nodes? Presumably the "level is carried through" somehow.... Note that this doesn't seem to work quite right. When I press and hold a paddle, the scene starts out dimmed, but DOES NOT continue to brighten. Is there a fix for this? 4) what do default and ignore mean in a scene? I can kind of guess about ignore, but it does not seem to actually work that way... i.e. If I have a scene and send it a turn off command, it still seems to go off, even if Ignore is selected for the hue. (This is useful for control of button state on Insteon, which itself is a nightmare). 5) One of the things I would like to do is to create some dynamic scenes. i.e. make the lights do chases. What would be the best way to do this? It appears that setting a light to a color and then turning on "Color loop" works ok. But there doesn't seem to be a more general way to create color changing effects. After turning on Color loop, when the lights are switched off and back on, they briefly flash to their previous colors before slowly fading to the commanded color... What causes/how to fix this? There does not seem to be a Hue reference of any kind other that the VERY helpful one on setup. Am I missing it? Can someone explain the limitations of the ISY/Hue setup? xking helpfully pointed out that the hue input devices have fast connections to the hub, but that the hub is only polled by the Node server... more information like this is extremely helpful, because it tells you what you can't do....

I would suggest most of you not wait for Insteon to revive. It appears unlikely that significant new product will become available. I'm sharing here the basic repair procedure for the keypads and switches which show the "dead" or "clicking" issue. There are other things which kill these, but 99% of mine needed this fix. I trained my GF to fix these too, as it get tiring, and smaller hands help. Helps to have someone share the work too. Eventually even this fix needs to be re-done, as the parts do NOT last forever. The design is commercial grade... even with proper parts its not a 20 year situation. The insides of these get HOT, and even doubling the size, plus putting in 5K hour 105C parts will not be forever. I've seen as little as 4 years out of switches which control big loads. The basic issue here is that there are two electrolytic capacitors in the power supply section, which dry out, and then the PSU cannot properly filter the DC, and the whole thing stops working. It is possible that poor filtering also kills signal integrity, but since signal integrity reporting was not included in insteon, you can't know without test equipment, and I'm not that motivated to do testing. I no longer "chase" dead switches. If I am taking the faceplate off of a bank I replace all of the capacitors, even the ones I've previously replaced. YMMV on this. You will need: small Philips screwdriver, soldering iron, small diagonal cutters, thin needle nose pliers, solder braid, solder, and replacement caps (see below). 1) Remove switch from wall, it may not be necessary to disconnect it from the wiring. I don't disconnect, but ensure power is off. 2) Remove the 4 faceplate screws, and remove faceplate or button array. Now is a good time to WASH these. 3) Remove the 4 outermost screws which hold the plastic transparent back on to the switch. 4) Carefully push back or twist the back cover. Do not push it back too much or you will break the wires which go to the buzzer. If you break them, they are extremely hard to re-solder, and you may need to just clip them, and not have a buzzer. 5) Note the two capacitors in the lower left corner of the picture. NOTE THE POLARITY The stripe goes AWAY FROM THE + SIGN on the PCB. Your unit may be similar, there were MANY versions. There are two capacitors there. While you have the unit open REPLACE BOTH. I already replaced the front one in the picture ONCE. This is the second time... Some units only had ONE capacitor, and used an SMT device for the other one. I replace the 10uF 35V big capacitor with a 22uF 35V unit. You can get a bag of 100 from digi-key for a few dollars. You need something with SUPER LONG LIFE. 5000hrs at 105C. Todays stock was Wurth 860240572002 and Nichicon UPV1V220MFD1TD I'm sure both are fine. For the 10uF there were more choices today, Rubycon 35ML10MEFCT54X7 and Wurth 860240572001 were near the top of the list. 6) To actually remove and replace the caps, I do the following. a) Using small cutting pliers cut through the middle of the cap, right through the barrel. This is close to where the terminals are inside. Push up the bottom part of the cap away from the pcb. It will be possible to pull this remaining part of the cap off of the leads, leaving to wires sticking up out of the pcb. b) using a soldering iron, heat each leg, one at a time, and using a pair of needle nose pliers remove each leg. c) using Solder braid, remove the solder from the holes. d) Find a suitable location to put the caps. As you can see from the picture, it does not have to be seated on the PCB. Bend the leads to make them fit the holes in the appropriate location, cut to length. e) insert and solder. 7) Reassemble.

Restore PLM seems to have fixed this issue. I don't know how a system can lose its PLM links, in only one direction, but apparently that is what happened. I do not know if this is a part of the upgrade procedure, or just random.

I have a system with both hue and insteon parts. I recently migrated to PG3, IOP, and am running all the latest versions. Everything seems OK, and connected. I have created some groups of hue lights in the hue app app, which show properly in PG3, and in the Navigation pane of IOP. one example is "kitchen hue" which the hue hub has controlling about 8 lights. If I click on "kitchen hue," change a setting, and press the appropriate button, the lights respond as expected. I also have Kitchen hue as part of a scene called Kitchen Main. Each controller in Kitchen Main has "kitchen hue" set at my desired levels and commands. For example for Keypad E1.B "kitchen hue" has "Color temperature 2400K, Brightness 32 in 100ms, as link type "Command" However, when I press the button, only the insteon lights are affected. The Hue do not change their intensity or color. This all worked prior to a couple of power failures we had (before the upgrades top IOP and PG3), and I'm confused as to what could be going on.... I compared the device links tables (which I could read, so communication with the PLM is OK...) and found one record mismatch, the 00 was 1F on the ISY's table. I have two additional questions, -Is this the correct way to operate hue lights with insteon controllers? Is there a better way to trigger hue lights to a particular mode? I have not tried doing anything complex with them yet since this seems super basic, and I can't really see how to send multiple commands, I'd like to make color loops work across a series of lights, but can't seem to figure out how that would be done with this type of interface. Thoughts?

Has a series of power outages. It appears my Polisy is now only partially functional. My system was last modified about 2 years ago. I am running a ISY994i/IR PRO V5.3.0 The Polisy boots, shows up in my DHCP list and I can SSH into it. It reports FreeBSD polisy 12.2-RELEASE-p6 r369564 So apparently I should be upgrading, but the question is why did it stop working? My ISY reports that the Hue Bridge (which is why I got the Polisy) is Connected=True, whatever that means. Any attempt to connect to the Polisy from a browser results in Connection Refused the ISY launcher shows no Polisy, and does not have any Polyglot options on it. trying to add it fails. Any idea what happened here, and how to fix it so I can actually turn the lights in my kitchen on? the Polisy apprears to still have polyglot running... none of the log files seem to show anything interesting. Polyglot continues to show some execution going on.

I took the keypads off of my network, and put them on battery powered inverter. The result is the same. The keypad ignores the setting. Note that these are old, and not dual band, so there is no RF connection. I have a new keypad coming to try out.

OK, So I simplified it to ONE Controller, and ONE Responder button. On the controller keypad..... Pressing the button turns on the responder's button when it gets lit. The setting on the Responder in ISY can be On or Off, it doesn't matter. The buttons always are in sync On at the controller is On at the responder. I went in and looked at what is going on in the devices... here's the controller table. You can see link #7 is telling it to talk to the responder Here's the responder's link table when the setting is On Here's the table when its set to Off As you can see Byte 6 in Link 7 changes. The Keypad ignores the setting apparently

Ya, so if we know anything about Insteon, its pretty obvious that controller vs responder is not the issue. The issue is that the protocol is brain damaged, INTENTIONALLY, to reduce traffic at the expense of of [debug, weird use cases, anything more than a 3 way circuit], the issue I have is that UD and Insteon are hiding the disaster that is now the Insteon protocol, which needs to be taken out back and shot. Sadly Zwave is apparently trying to be just as bad. They needed to go to V3 protocol at 100x the bandwidth, and own the industry 5-10 years ago, but instead we have ISY built on code from 1985, and then we are adding a Polisy of mediocrity which cant even deal with 1 update per second, when CK [www.colorkinetics.com] were doing 44 updates per second acroos 800 lights in 2000. [actual numbers]. [COMMENT I don't usually do this, and the last time I was on this forum I was more polite: Ive been doing this a long time... TOO LONG actually, and I'm fucking tired of the BS that home AutoNOTMation is dishing out. Its bad at every price level. So I try to pay less for the same amount of BS. I thought UD had some great people.... in 2012. Michael... I salute you. But fucking shoot this thing now, and get the VC to fund something better. /COMMENT]

First, I want to thank you MrBill, Its at least clear what you did, and I wanted to show you what happens when I do it. I DO NOT GET THE SAME RESULT. And I think I can now (after days of working on this) explain WHY. Its NOT pretty what is going on. My procedure (I had to do this several times to really understand how ISY works BTW. It took HOURS to do this): I took a spare keypad 12.BD.0D I had laying around, factory reset it, and hooked it up with an extension cord to an outlet shared with my PLM, to be near my computer. Its a 2486D, v.36. I have a few v.39's too, but mostly v.36 in my system. I linked it. I checked Buttons Grouping (Nothing was checked) I checked Buttons Toggle Mode (All were set to Toggle) I then created a scene named Test I then added buttons A B and C from it to that scene. At this point it looks like this: I then went through and changed all of the Actions to Off. So now each of the three buttons looks like this: At this point I tried the keypad. It works as YOU expected it to... i.e. the buttons are indeed mutually exclusive. The last one pushed stays lit. You would think the problem is solved. The key to understanding what is going on is available at this point, but you would never know to go looking for it. On my fourth time through I stopped at this step and did diagnostics... but I won't spoil it for you now. I then linked in another keypad. This time it was 12.B8.1E, also a V.36. Now all of my button scenes look like this: At this point the keypads are hopelessly out of sync, and DO NOT do the right thing. What happens is: Pushing ANY button on either keypad lights up ALL buttons on the OTHER keypad, and just the one pushed on its own keypad. Pushing ANY of the LIT buttons on either keypad turns off ALL buttons. Pushing ANY of the NOT-LIT buttons turns off the LIT button on its own keypad, lights up itself, and doesn't affect the LIT buttons on the other keypad. Here's the video to demonstrate: You can imagine how frustrating that could be when you can't see them side by side to understand, but the hint's are there. WHAT IS ACTUALLY GOING ON, is that ISY is creating an old style Mutually Excusive Button Group on EACH KEYPAD. If we go back to step 12, and look at the device's Buttons Grouping page, you see this: The second keypad's Buttons grouping page looks the same, with its address. However, clearly Mutually Exclusive Button groups can't be made between separate keypads, as there is no way to add them in. The third line of text in the box above is indeed correct, reset deletes the button group and destroys the Mutual Exclusivity within a keypad. However, the two lines above are FALSE. a) The ISY does not know the true status of the buttons on the second keypad when a button is pressed on the first. b) You cannot set a button to Off from an Off-On transition of a button, even though the ISY gives you the option to do so. This is either a bug in 5.3 which you have not experienced, or a limitation of my keypads. Your keypads are much newer than mine, new model number even, and maybe they understand and properly interpret the ISY's intent, But it seems QUITE BUGGY. ANY COMMENTS GUYS? 1935742627_2021-03-1817_50_33.mp4

That just does not work for me at all. No matter what I do, or how many times I try it or on which keypad, I cannot get an on command from a button to turn off the backlight of another button. Its 100% consistent. I've reduced this down to a single scene, with the 3 buttons of a single keypad in it. Everything is set to Off in each of the controllers. There is no external control, and no load or other responders. Perhaps your program does the Off and you don't realize it?

I don't understand... Are you saying that the scenes with the other kpls buttons in the off state still need programs to turn off the backlights? i.e. that the "Off" doesn't do anything by itself?

I've wiped everything out several times.... Usually I just pull the air gap, and push it back in for 30 seconds, and then go do a "restore device." Then I go get a Gin and tonic, and wait. I have 3 keypads in that room, so I do all 3, takes about 1.5 Gin and Tonics.... Note that my kitchen ones are all relatively old (V.36). I have some newer ones in the house (V.39) and (V.43) but they are not involved in this area.

All of the Keypads have been reset multiple times since I started this process, and I have not tried to turn on Mutually Exclusive Buttons... I would prefer not to, since ISY won't know whats going on. I'm trying to use your method to do mutually exclusive buttons. But my keypads don't seem to behave like yours.... The On/Off setting for the keys does not change their behavior. Did you try your method to create links on a 5.x system? I can't imagine its all been broken in 5.x and nobody noticed, but I have seen that again and again in other software... There are no available diagnostics, not even a "verify device", and once again the whole process keeps exposing to me how excessively complicated the ISY UI is to understand. Every time it looks "Obvious" what something does, it doesn't.

I'm running V5.3.0. Ya, so I did that. I'm as confused as ever about what I can, and cannot do via Insteon, and I am not being helped by the UI. 1) When I have all of the buttons in Toggle mode, and everything is off, and I Push A, All 3 of the A's light up, and don't go out, even though they are programmed as Off in each other's responder lists. Pushing the button itself again causes the Off command to be sent, with both the lights and all A-buttons going off, so the buttons indeed got changed into Toggle mode. It "works" the same way regardless which keypad I use for the first or second press, so... it appears that what is happening is that regardless of what I put into the responder link (On or Off), the net result is that On gets sent if the transition is Off->On. Not sure if this is a bug in 5.3.0, or a limitation of the protocol, but the UI should know and inform, and eliminate the idea that you can do this if you can't. 2) I can't change a keypad's self responder link, its set to default, which I guess means its going to do the same thing as in #1, and you can't change it. I think thats because its a limitation of Insteon, but of course no real info on this is available. This would be one of those places where being able to tell why and exactly what is going to happen would be fine, and a link to how to make it behave differently would be even better. Bug: default is sometimes Default, Command is sometimes Command Insteon is however always Insteon Haven't tried Ignore yet... 3) Is the purpose of the "Command" option to allow an arbitrary command to be sent to the device? How come that option isn't available if that is indeed how its supposed to work? [Could "Send additional command after delay" be another option?] 4) Now I went back and turned the buttons to Non-Toggle[on]. Bug: Note that the Buttons Toggle Mode Dialog box immediately writes to the devices, but has a "Cancel" button, which of course does nothing.... It also has an OK button, it really should have a Close button, and neither of the other two, or it should cache the data and write later. The buttons indeed now are non-toggle. Its impossible to turn off the LED.. its always on. (note this is regardless if a scene is connected to the button or not).The buttons do indeed trigger the scenes On is sent each time they are pressed, however there is now no control over the backlight, its always on. 5) In addition, there is now confusion about Led Brightness, which seems to have been hastily renamed to the "Backlight" button and dropdown. They seem to set the same thing, but.... a) It seems that all of the buttons must have the same brightness [which is fine, except you can't change some buttons to never light up, which would have been an OK fix for what I want to do], so leaving the ability to change it everywhere is adding to the confusion. There should only be ONE place to change the backlight if its not changeable for each button individually. b) the "Backlight" button and dropdown do not reflect the current state written into the device. The LED brightness box seems to be correct, but the backlight dropdown holds whatever value you set it to, and never queries the device. When you switch to a different device and switch back, it keeps the old value, suggesting that that is what is written into the device. So at this point I am once again asking HOW IS IT SUPPOSED TO WORK?

Interface on 5.3.0 is now more confusing than ever.... Some part of this is missing prompts, explanations and visual elements. Some is just confusion in how the UI is structured. For example: a) The buttons really don't look like buttons at all. When selecting a device, the buttons across the bottom send commands, and because of their grouping, they kind of suggest they are buttons, but have no decoration to let you know that. they are just grey squares, and don't look "pushable" b) the "buttons" in the middle of the screen look like labels. I couldn't figure out why my ramp rates were not changing, and reverting back to previous values. The box labeled "backlight" for example carries no hint that you should push it to write the new value to the device. c) why are there "right arrows" on "On" and "Beep"? what does "NLS-null[CMD-I_BEEP_255:level" mean? d) when selecting a scene from the navigation pane, you are nominally modifying a scene, but its totally not clear that there are multiple "scene's within a scene", NOR that the ISY is a controller for the scene, and that thats what you are changing when you click on the scene. Here the update button at least has a feeble attempt at making it look clickable, but its to the left and above the things you are changing. At this point some sort of 2-D setup here of controllers vs responders would REALLY improve the ability to see what is going on. when you click on a controller it gives you a list of responders, but when you click on a responder you get the device itself, and no indication that you are not changing the scene, or the devices's ON level in the scene, or again, that you even can push any of the "buttons" which look like labels... e) There's no label or explanation of the dropdown box with "Insteon" in it, or how one might actually use it. Wouldn't it it better for it to say something like" Send Insteon Command" or "Don't send anything to this device" Others have complained that its not clear what the options do as well. Is it not possible to load a more visually helpful set of primitives into the UI? Maybe some tooltips?

Yes, I finally remembered that confusing issue late last night, and changed that, but the buttons backlights still don't turn off, ever. I tried setting them to non-toggle[on], and it didn't help either. Also I seem to remember there was a way to push all of the ISY scene's levels to the other controllers, but I could not find that either.... Does that still exist?

I'm fighting this right now too... And the entire concept that this question needs to be asked 15 years after these things were first sold is INSANE. I first programmed my system in 2011, and it was clear as mud back then. Its not any better now. I actually gave up and only ended up using a total of 9 buttons in my whole house out of 31 keypads I installed because it was impossible to get them to work right, and even harder to figure out why. I just tried to create scenes using lilyoyo1's method, and now tried switching back to the Non-Toggle method, and BOTH fail miserably. And because its Insteon, and communication is slower than typing it in manually, you can't ask any questions. I just factory reset my 3 keypad links and am trying again to restore them since I am out of things to try other than "gee idon't know have you re-installed your operating system yet today?" We need the ISY to show the movie of a burning log during device writes instead of that little progress bar. I usually go grab a gin and tonic while it works, and if this keeps up I'll have a drinking problem. I still don't know exactly what happens when I press a button marked Non-toggle[on], and how to effectively use that in a scene..... The entire idea that buttons can't be used without programs to fixup their states is CRAZY.

Once again, I am re-programming my kitchen after my flood and rebuild. My system has about 100 Insteon devices, and generally works fine. The new Kitchen has some different lighting in it though, so I need to change the programming. Its been a few years though, and I forgot all of the f***ed up decisions and limitations of Insteon, so once again relatively simple things are working in weird ways. Maybe one of you can help. I have 3 keypads and 3 paddles, one each at the 3 entrances. None of the keypads have any physical load connected, the main lights will be Hue running off of a Polisy, but I have not even tried to get to that yet.... I'd like the ON, A, and B buttons to be in a "mutually exclusive group" on all 3 keypads, and lets just say for the moment that we wanted 100%, 50% , and 33% on my counter and island lights to be all that they control. The counter and island lights are each wired to one of the paddles. The third paddle is for a chandelier which isn't installed yet, and we are not worried about yet. Obviously we want the buttons to activate each respective scene. I don't care much if they stay lit or not when that happens, but it makes most sense if only max of 1 stays lit, i.e. the last one, or none stay lit. SO I programmed up the scenes, added all of the devices and buttons to each scene, factory reset all of the devices, and wrote all the links. (Took almost 5 hours, which is insane, but thats a different set of posts that I have written before) Each scene has both paddles, and all 3 buttons from all three keypads as responders, except obviously that one I want to trigger that scene is a controller... In other words I setup this: Now for the Weirdness.... Regardless of which button I push, every button lights up and the lights go to 100%. In the past I used to use mutually exclusive button groups, and Non-Toggles to do various things, but apparently they are frowned upon now... and I understand that. What I don't understand is why this does not work. Note that it is not communications issues, noise or any of those other excuses. All 3 keypads work exactly the same way 100% of the time. Any ideas?

If you replace "claims" with "as the user expects given the claims" then I think we agree. The reality is that insteon is terrible from many perspectives, and I probably would not have installed it if I had known just how bad it was. However, I am stuck with 150 devices, and re-wiring is not an option... next time I'm not buying anything without a 10 year warranty. I've replaced (parts inside of) 150 of 150 devices.... i.e. 100% failure rate at 4 years, so I'm sorry if I'm a little jaded. Whats PyHue? ANd how does that relate to the portal and controlling ISY?

Actually, Insteon is very badly broken, and was from the day it was conceived, which is partially why the ISY exists in the first place. The basic problem is that the insteon protocol was never intended for true home automation, and is about 20x to 100x too slow to actually perform its desired function. Hence the "commands" are deliberately shortened to the point where there isn't even a set scene to value command as an "operating" command. Using live re-programming of devices to add functionality would take minutes per command, and even routing commands through the isy and leaving all devices as linked only to the modem and not part of a scene (which theoretically is the right way for a HA system to work) is much too slow as well. This leaves the ISY to try to clean up the mess. Its function seems to be best left as link management, but that leaves lots of dumb Insteon stuff, like: a 3 way light switch setup is a scene, and not a device, and can't be set to 50%. So now everyone is trying to get their echo to do cool things, and the workaround for setting a scene to 50% is to create a 50% scene and then mess up the echo's grammar to fix it. Now we are fixing the original problem with not one but two counter programmed hacks. Perhaps there would be a way to have the isy interpret a set scene to 50% command as a series of device commands rather than a scene command, or have access to multiple scene commands. It has the information, and it would work, but be slow. However that "program" can't be written because: 1) programs can't be set to a value 2) a generalized program can't traverse the tree of devices so you would have to write them manually 3) you would be programming scenes for a decade for any non-trivial system at an even reasonable scene density If #1 can be fixed, then #2 and #3 could be done with "helper apps" on the ISY.

Did this ever get fixed? It seems it partially got fixed... I can dim a scene now from the echo, so obviously something got fixed, and I can turn a scene on and off right now, but I can't set it to a percentage???

That must have been a browser incompatilbility... It was all filled out when I pressed submit.

LeeG: Ya. I think I'm getting a sense that there are 2 different databases involved, and that there is no actual enforced consistency between them. Just a set of routines that make changes to both at the same time... Unfortunately this creates the "black art" kind of structure where you have to do certain things in a certain order if there is a problem or else you have no idea what ends up happening. I'm very wary of just taking your suggestion and making more mods to my system because my experience with corrupted databases suggests that thats a bad idea until I get an answer from someone who knows how all of the interactions work... Do I need to submit a bug report? This does explain however the lack of a menu option for "check all of my device links" Wouldn't actually make the scene list and links match...