paulbates

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.

@hart2hart is correct. The motion sensor is returning to a "no motion detected" or "system alarm off" state before the 3 minute wait in the program completes. The "if" statement evaluates as false, and the program cancels at that moment during the 3 minute wait. A way around this is to make 2 programs: copy the program and call the copy "JP's closet detector 2" Remove the "if" from program 2, leaving it blank remove the "then" statements from program 1 add a single statement to program 1 that is a program statement that calls program 2.. Run program JPs closet detector 2 Because program 2 has no "if", it can't be evaluated as false, and it will run through without the sensor stopping it. If the closet sensor trips again in program 1, that will restart program 2 so the light will stay on if you are in the closet for a while. If you post the program steps as text instead of a graphic, i could copy that and show both programs

I set up my ecobee last year following the instructions... but as it was that long ago I don't remember exactly where I saw the pin. My guess is that it showed up first time on the plugin configuration page after first install and setup. The config page and node page are dynamic when they discover things like new nodes. (I recently added an ecobee sensor that showed up under nodes) @Jimbo.Automates will be able to help

Based on Jimbo's comments in the install docs, it says not to proceed until you have the pin, which is presented at first startup. I would uninstall the plugin, restart the eisy and try again.

That looks like the node pg3 uses for keep alive between it and the plug-in, which can be separate and have just the controller. There should be other nodes that sometimes only appear after reboot or 2 after installing the plugin. Have you rebooted it?

It's a guess; I can't think of a busier time on the insteon network than during a plm replacement. A number of messages to each device to reconfigure them. Sometimes messages don't make it, in either direction, and then they are repeated. My guess is that as iox stepped through each device to reconfigure it, collisions sometimes happened, but the iox code is also retrying what it couldn't finish until it was complete..... and you got a message each time it happened.

Open a support ticket. I'm sure you'll get going soon. https://www.universal-devices.com/my-tickets/

My initial eisy experience was similar. Did you try the other USB port, restart?

Np Mike.. that comment was responding to hoosierdaddy, who was asking about scenes vs ISY programs with multiple Insteon commands back-to-back

My comment was sending multiple device commands back to back created Insteon colllsion problems, not scenes. In fact that's why I recommended scenes.

YW. If you do a number of insteon device commands back-to-back in an isy program, there should be a several (3?) second wait between each command to allow the command to reach the device from isy/plm plus the return acknowledgement from the device to isy/plm

Yes, I'm suggesting putting them all in another scene. Elegant is s matter of definition.. a single scene that shuts all devices off simultaneously with very little insteon traffic and no time used up involving the plm or program. A program would not be needed if the scene also included an insteon switch as the controller, which I believe was the op's requirement: Hit a switch at an exit door when he's leaving the house and have multiple inside lights go off at the same time. I had 25 insteon devices in a similar scene arrangement in my last house

If you choose to @Jimbo.Automates, I am interested in the smarthose timer if that could be supported. I went from a 15 zone rainmachine system at my last house to very simple 1, possibly 2 smarthose setup at my current house.

With udm, the occupancy setup on the portal is no longer needed. You create geo fences with the app and they'll appear a nodes on the isy. You do need an active portal subscription.

Sending that many insteon commands back-to-back will create collisions on the insteon network, doing it 5 times will be worse. If they are all insteon devices, you can create an insteon scene for this and no program will be necessary