apostolakisl

If a device write fails, you will also need to manually "write changes", so it is not just used for the pro version. If you make changes to a device that is not plugged in for example, or the com just fails for whatever reason. But "writing changes" only does anything at all if there are changes to write and you will know that by the presence of the green "0100" next to the device.

Write changes is mostly used for the pro version that allows you to make changes but not write them until a time of your choosing. Very helpful when making lots of changes to not have to wait for each change to write before moving on. Also if isy tried to write changes but had a com issue you can trigger another try.

You need to plug the plm into eisy or it will give you errors. The whole point of what I just wrote is that eisy won't change anything in the network unless you tell it to. Just plugging it in won't change your links.

Eisy won't change anything on any devices unless you tell it to. Scenes are all written on the plm and on the devices. ISY keeps track of what is supposed to be written in those links so you can restore the devices. But if you never tell it to restore a device/plm, it won't write anything and they will stay the same. In short, if you don't tell it to restore the plm or restore devices, your insteon network won't be changed.

I don't see where it would be a problem to have the 994 on and no plm attached in an insteon network that has an eisy running as well. I would shut down polyglot if you have that running on rpi and I would disable any programs using network resources and I would change the elk module credentials so it can't mess with your elk whilst you configure the eisy. Or you could isolate the 994 by plugging it into another network. Easy way would be if you have a spare router. Plug a computer and isy into it and nothing else and then it can't mess with anything.

I assume you could use "<name of location> fans <speed>" and create a routine that is not device specific. And the do "fans <speed>" that is device specific. Personally don't see myself controlling fans in a room I am not located in except for my shut down routine, and that is a single command that triggers an ISY program that then executes a shut down of all kinds of stuff.

This discussion got me playing with Alexa a bit. I discovered that you can have each device respond uniquely to a command. So for example, the Alexa on my back patio would respond to "fans high" by turning on the patio fans, and that same command in the exercise rm would turn on the fans there. To the point here, by isolating commands to the relevantly located Alexa, Each Alexa will have fewer commands to understand and thus lower the chance of it confusing commands.

The way I outlined above, it always works no matter how you control it. There are ways you could mess it up and get multiple buttons lit at the same time or off at the same time, but you would have to go out of your way to do that and it would never happen excepting that you did it on purpose. Like adding the buttons to other scenes as responders. But why would you do that except to sabotage yourself?

the hardest thing is remembering the exact words. Need to get a Grok assistant that can recognize what you want rather than requiring literal requests. And the real pisser is when you start to say what you want and halfway through realize you are saying the words in the wrong order and then Alexa gets all confused and you have to wait for it to clear out before you can go again.

I have this setup for several KPL, though I did 4 buttons, I use this to control fan speeds. Create 2 scenes. One For each button Add both buttons to each scene. - Button C is controller for Scene C, Button D Controller for Scene D Set the "on level" for D button to "off" in Scene C, and similarly, set the "on level" for button C to "off" for Scene D - remember to do this both for the primary scene, and for when the scene is controlled by the button (from the device tree on the left, click on the scene, set the on levels, then click on the other controller for each scene (button c in scened c) and set the on levels there as well. Note: In the device tree on the left, controllers in a scene will be in red letters. Main Scene Setting On levels Now for the controller, in this case, fan low. Finally click on the KPL in the tree on the left, and in the right pane at the bottom, click on "toggle mode", and set button C and D to be "toggle on" only. EDIT: I should also mention that you will want to add as responders to the scene whatever action you want. In my case a fan. Or, if the only thing these buttons are controlling are programs, then just put the status of the button in the "if" part of your program. We call these "radio buttons", like how old fashioned car radio buttons worked, push one in, the other pops out. This works when the buttons are controlled by direct press, and it works when the scenes are turned on by other methods, for example, a program, or Alexa, or even another Insteon device (you can add other insteon devices as controllers to the scene if you like, just remember to again set the "on levels" for that controller. With my fans, I can turn them on from Alexa (via a program) and it sets the buttons correctly. If I say "Alexa, fan high" for example, it will trigger the fan high scene and the high button turns on and whatever other button that was on turns off.

@bmercier @sjenkins I opened the Web UI at my office last week and haven't touched it over the weekend. I just clicked on that tab and can still see the status of items and control them without doing any refresh or logout/in. This connection is running over a router to router vpn which further complicates things, and yet, it is still up. I initiated the connection last week by going to the LAN IP address of my ISY which gets routed through the VPN.

maybe isy had a static ip address set and the new router is in a different subnet. When ISY works, you get a new router, and now ISY doesn't work, logic would say there is nothing wrong with ISY and that it is the router configuration. Put your new router on the same subnet as your old one and probably ISY will show up.

My condolences for buying a neo system. There is no linking that to anything, unless you live in Canada and then you can use their app and only their app. Back to your Elk. Were you using Elk to directly control Insteon devices or were you going through ISY? There is no reason for removal of Elk to have anything to do with Insteon traffic except perhaps if you had the Elk working directly with Insteon. I forget exactly how Elk direct control works to say for sure. Looking at your system, you don't have a whole lot of devices. You might just consider deleting everything and readding. Perhaps you some orphan links that are messing with things from the Elk removal. If you delete the devices one at a time and add them back in, any devices in programs will go right back into those programs. You will have to rebuild your scenes. After you do that, you either need to go into each program and hit any random item then "update" then "save" or the program won't work. I think rebooting ISY will also make the programs work again.

Troubles here. I can only assume it is related to this update, but not sure. I haven't done anything else. Things in my house weren't working. I Logged into admin console to see what was up, it had a pop error "loading nodes: retry". It said "linking" in the bottom left corner. Never seen this before. It kept doing it and doing it. I finally power cycled. Opening iox finder, listed was just a single ISY at https://mylocalip/desc After I did the upgrade yesterday, it listed multiple versions of ISY at different ports. Now just the one. I now had to use my portal user/pass to log in even when selectin "lan". OK, I think that was to be expected. But what is up with it stuck in "loading nodes" and not doing anything. @bmercier EDIT: One good thing seems to have happened now. My java admin console is now staying alive. Prior to this, the admin console would lose connection after just 10 or 15 minutes and I would have to re-login. It has now been up continuously for 19 hours.

@bmercier Is the eisy ui intended to only be a user interface or an administrative interface? As a user interface in my situation would get very limited use, but using it as administrative interface would be golden. Writing programs, creating/editing scenes, working on notifications, network resources, all that stuff. The java admin console is just always hanging up.