apostolakisl

You can tell if the links are writing by watching the pop up window. Unfortunately, ISY doesn't make it obvious, but if you watch the small print writing in the bottom left corner of the pop up window, it will show you the traffic that is going on. It will show you all kinds of random traffic, but if you watch it will show link numbers. If every few seconds you see a that number has gone up (ignoring other random other messages in between), that is a good sign. If you keep seeing it stuck on the same number, not good. Also, the devices on the left window will start returning one by one to their normal appearance without any 1011, exclamation points, or other.

I went through and manually added every one of the 40 buttons twice. Mostly this works. However, 3 pairs of buttons appear to share codes at least as far as flirc is concerned. This was not the case when 994i was receiving the signals using the same Harmony remote. I installed the ISY codes on that Harmony from the Harmony library which had the ISY codes in it already (did this like a decade ago). I deleted and readded these buttons several times without any success in fixing the issue. Matching ISY IR codes according to flirc are 10/13 11/14 12/16

Not sure what gives here. I have the flirc installed and loaded in the default ISY 40 commands found in this thread. They showed up as I pressed the buttons. But it only works on every other time I hit the button. I tried deleting the whole thing and started over teaching the flirc manually the 40 commands. Same story. I confirmed every other button press by watching the "pressed" vs "idle" reported in the admin console as well as creating a program that runs on the button press. It is like it is a toggle or something, but there is no option to make these things a toggle. I tested it with a bunch of the buttons. I am using my Harmony remote, the same remote that worked flawlessly with 994ir. EDIT: I think I found the answer here in the forum. I'll need to play with this, not sure how to get the same button to respond to two different commands in flirc.

So if indeed you had amazing amount of noise in your network that you have now removed. You should be able to restore you plm and you made need to do a restore devices as well. If you have a backup of isy that is current, you could start from scratch. 1) Restore backup 2) Plug in PLM (if not already) and reboot 3)Confirm PLM attached via tools/diagnostics/plm info, 4) Factory Reset PLM (shouldn't be needed, but why not) 5) Restore PLM - note if you are restoring the plm and it is not the same plm as you were using when you made the backup, then it will need to write to all of your devices. I would set the isy to not do wireless devices at this time if you have any by clicking off that icon, also, disable any devices that are not currently plugged in/working so as to not slow down the restore. 3) Restore Devices if needed (same stuff in the note section applies here)

It sounds like your plm isn't working or your connection between eisy and plm is no good. Regardless of how screwed up your links may or not be, when you write to devices, eisy will write the links assuming you are able to communicate with the devices. And you are not communicating. Check under tools/diagnostics/plm info Make sure it lists your plm and says connected. I suppose it is also possible that something is so awful in your network that even though the plm is connected and working, there is so much noise that it can't talk to a single device. unlikely to say the least, but I suppose possible.

Yes, reinstall of node after development package install fixed it.

I did that. Rebooted eisy, still have the same error.

Dev packages? Where/how do I do that? Thx. Lou

I have had plenty of instances where a node looks good, but doesn't function. Reboots typically fix it. Just yesterday I had to reboot blue iris node. Blue iris said connected, but wasn't. The heartbeat system in nodelink never fails me. I actually went through some hoops to get nodelink back because it was so stable.

My emporia vue was offline. Restarting did nothing. I then deleted it and reinstalled it. Still says disconnected. Double checked my username/password and it is correct. The Android app and the web app both access the unit and display the current data. The log is as follows. A bunch of errors there at the end and no further log develops. These same errors were there before I uninstalled and reinstalled. I know it has worked quite recently, but can't recall if that was before or after I switched to eisy from polisy. I made that switch 2 weeks ago. I also, I recently updated eisy to the new firmware that supports the web ui. 2025-08-07 14:57:09.773 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2025-08-07 14:57:09.773 MainThread udi_interface INFO __init__:<module>: UDI interface initializing 2025-08-07 14:57:09.773 MainThread udi_interface INFO __init__:<module>: User=None 2025-08-07 14:57:09.774 MainThread udi_interface INFO __init__:<module>: Home=/var/polyglot/pg3/ns/0021b9027119_23 2025-08-07 14:57:09.774 MainThread udi_interface INFO __init__:<module>: Node Server Path=/var/polyglot/pg3/ns/0021b9027119_23 2025-08-07 14:57:09.774 MainThread udi_interface INFO __init__:<module>: PG3INIT=eyJ1dWlkIjoiMDA6MjE6Yjk6MDI6NzE6MTkiLCJwcm9maWxlTnVtIjoyMywibG9nTGV2ZWwiOiJERUJVRyIsInRva2VuIjoidkRVQk9kQlE5QkctYksvaCIsIm1xdHRIb3N0IjoibG9jYWxob3N0IiwibXF0dFBvcnQiOjg4ODMsInNlY3VyZSI6MSwiaXNQRzN4Ijp0cnVlLCJwZzNWZXJzaW9uIjoiMy4zLjIxIiwiaXN5VmVyc2lvbiI6IjUuOS4xIiwiZWRpdGlvbiI6IkZyZWUifQ== 2025-08-07 14:57:09.774 MainThread udi_interface INFO __init__:<module>: Loading interface module 2025-08-07 14:57:09.817 MainThread udi_interface INFO interface:<module>: Loading MQTT module 2025-08-07 14:57:10.336 MainThread udi_interface INFO interface:<module>: MQTT module loaded 2025-08-07 14:57:10.560 MainThread udi_interface INFO __init__:<module>: Loading udi_interface module 2025-08-07 14:57:10.560 MainThread udi_interface INFO __init__:<module>: Loading node module 2025-08-07 14:57:10.560 MainThread udi_interface INFO __init__:<module>: Loading custom module 2025-08-07 14:57:10.560 MainThread udi_interface INFO __init__:<module>: Loading isy module 2025-08-07 14:57:10.560 MainThread udi_interface INFO __init__:<module>: Loading OAuth module 2025-08-07 14:57:10.561 MainThread udi_interface INFO __init__:<module>: UDI interface initialized 2025-08-07 14:57:10.561 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.3.18 Starting... 2025-08-07 14:57:10.562 MainThread udi_interface ERROR udi_interface:write: Traceback (most recent call last): 2025-08-07 14:57:10.562 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b9027119_23/vue.py", line 10, in <module> 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: import pyemvue 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b9027119_23/pyemvue/__init__.py", line 2, in <module> 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: from pyemvue.pyemvue import PyEmVue 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: File "/var/polyglot/pg3/ns/0021b9027119_23/pyemvue/pyemvue.py", line 8, in <module> 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: import boto3 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: ModuleNotFoundError 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: : 2025-08-07 14:57:10.563 MainThread udi_interface ERROR udi_interface:write: No module named 'boto3' @bpwwer

Don't delete ISY Portal or you will lose your portal access. Unless you are getting rid of using ISY portal. I assume you are intending on using the portal. Without portal you will have to open ports on your router to access from offsite and you won't be able to use Alexa/Google and all of that stuff. And what you did to delete those orphan plugins is correct. However, you need to make sure you didn't have any of that stuff referenced in programs. Any program that referenced any of the deleted plugins will now be broken and won't run at all even if the rest of it makes sense. ISY program icons turn yellow when the program is broken.

With Polisy and 994i, there was a "pro" version, but with Eisy, I don't see that. Only the standard and ADR version. So I suppose that all Eisy units are "pro".

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.