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

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?