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.