paulbates

It's best to make the IP settings in the ISY automatic... that will 'future proof' your ISY and computer if/when network changes are made again.

This is a good catch... if the ISY is physically plugged into the EERO, and the laptop connecting to the ATT... the NAT firewall in the EERO (assuming its on), would give these exact symptoms. If possible, plug the ISY into the ATT router instead of the EERO (laptop and EERO need to both be connected to one or the other)

The correct terminology should be: responder, or, controller/responder. It's always a responder. For example, if the button is responder only, it would light or "un-light" in response to another controller turning the scene on and off. If it's a controller/responder, it will do the above and be a switch that activates the scene for other responders.

There's 4 things on the list, I take it you recognize what .240 and .73 are and they are not the ISY? Do you know what the other 2 are? If no Click the add button on the finder, and one at a time try http://192.168.1.241/desc Try the same thing with .71

Have you tried unplugging, wait 10 seconds, replugging the ISY? Give that a few minutes and then try launching the finder.

No.... My suggestion was not to upgrade the ISY to eisy as a solution to what is likely a java or local network problem. I have an eisy, it's great, but the migration is a lot of work, for likely no immediate benefit to you. I bought an eisy because I sold my last house in Dearborn with the 994i and "things" last summer and started new here. The 994i is a solid device that should continue serving you as is; you'll still get help with it here on the forums.

Also, is the ISY functioning; your programs and lights etc are working, but you can't get to it?

If you're happy with your current home automation functionality, I would simply subscribe to another one or two years of the portal , and set a reminder in your calendar around the time of the next subscription renewal to avoid it happening again

Thank you. I don't have a lot of rules, but one of them is: No ports open on my router.

The typical way to fix this is to put the 'Then' statements in a second program with no 'If'. Have the first program (with the if) only have program 'run then' statement that calls the second program. That will solve the problem with the living kodi clean program.. The second program, with no 'if', will run uninterrupted to conclusion The office bath the program works because you physically double-tap the switch for fast off to trigger the program. The only thing that could change that during the wait is another fast-off.... which would restart the program.

Go to the summary tab and right-click on "Run at Startup"

Go to the My Programs folder and right-click on it. Pick Find/Replace near the bottom and select the device to find instances of it.

This may help a little. Go to the My Programs folder and right-click on it. Pick Find/Replace near the bottom and use Raw Text to find instances of "vText". There's other options besides Raw Text like devices and variables.. I don't think that will help in this case but take a look

No, it requires some "sawing and banging", eg manual work, but can be done. This example is based on a raspberry pi, but guessing the method could be modified for other platforms. Take a look here, especially down around post 4: There is an older node server, pre-polyglot called Nodelink. It was many products integrated into one application, and it included a data logger that could write to syslog. I used it, but it was many years ago.

Are there multiple conditions for the program to execute? The last run time and finish time will match when one of the conditions is true and iox evaluates...even if all the conditions are not true and it doesn't run. You may be seeing the results of that. As an example, I have the ring plugin and have an iox program that uses the doorbell motion sensor to report movement at night after a certain time. I just came home around 1pm and the program shows it ran and finished around that time, even though the "Then" of the program did not execute.

There's a lot of symptoms and great analysis in this post... but if it is a flaky Insteon MS, I've found that letting the battery run down can confuse the MS (at least the MS1) and cause unpredictable behavior. I made it a practice when I had them to factory reset and "restore device" when replacing a low/depleted battery. I got many years with them when staying ahead of the battery replacements, in fact sold them with the house.

Elk is a closed, supervised system and directly adding Insteon sensors isn't possible. The closest you could get, from what I know, is adding an Insteon 2450 IO linc as open/close contacts to the elk's dry contacts input (if you have that). However, the 2450 dry contacts output continue to be vulnerable to the dreaded Insteon "All on", and would not be recommended for an important alarm system function. You could write iox programs on eisy to evaluate insteon sensors and elk activity from the plugin and take action, depending what you want to accomplish.

You can proceed... The network trip for this connection is inside of your house, from the computer to the eisy. You're good either if you're on a wired connection... or, if you're using wifi with wpa 1,2 or 3, then its encrypted over the air. The communication from the eisy pg3x server in your eisy to the store is encrypted.

Your best bet will be submit a ticket to UDI with the email addresses for both portal accounts and which one you would ultimately like to be functional. Include a link to this post for background https://www.universal-devices.com/my-tickets/

If you have a voltmeter, the quick proof would be measuring the output of the power supply. The other evidence is the power supply light out and a related power event. https://www.amazon.com/Digipartspower-Adapter-Universal-Devices-Universal-ISY-994i/dp/B08YXMWL42 The only alternative to the ISY I'm aware of for Insteon is Insteon's own hub. It will be matching the definition of simple to its capabilities, you could ask questions on the Insteon forums about that.

You're looking at a rebuild of the keypad functionality, etc scenes from scratch. You don't need the old ones any longer. I would factory reset both new keypads, connect them to power however you do it (wall or bench with cable) begin building the scenes from scratch (or modifying existing)... and check that option are right depending how the old keypads were configed toggle, non-toggle,etc) Make sure that the keypad buttons are controllers, not responders or the scene won't trigger

If the keypad is in a folder in the device list, it must be removed from any folder(s) that its in and be at the root level before the "replace with" function appears.

The newer Insteon I3 Paddles can be configured at the switch to be a dimmer or relay (on/off). The body of the switch is definitely smaller than the older model Insteon switches, To add to @IndyMike's suggestions on managing space; You can cut the leads down on the Insteon switches wires to fit and also use "push in" connectors vs wire nuts to get space back in the j-box

Hi @Guy Lavoie, I do remember you from my ADI Ocelot days! It's part of my ha lineage and a lot of hair ago. I believe udi and the isy will resonate with your Ocelot experience... Powerful yet relatively easy to do and maintain

Integrators like udi, insteon and home assistant are not there yet with matter. Udi has mentioned their struggles with thread. Despite their other successes touted at their 2 year celebration zoom call last week, insteon kicked the thread discussion down the road till next January for their hub and director products. While home assistant has some thread capabilities, their last blog post that I could find is from this past January, where they consider it a beta capability. They ask users not to move away from working zigbee or zwave installations at this time. They also suggest using brand affiliated gateways with the devices selected. To me, the matter standard has a lot of practical barriers to it's own success as something that can actually be implemented to the promised vision of seamless cross manufacturer integration, and we remain in the "bleeding edge" phase. It's on the big manufacturers (Google, etc) and the matter standard committee to get it together. Udi is rightly stubborn about not implementing something that doesn't work and can't be supported... yet.