paulbates

In many cases a failing PLM will act the way it does because the link table data is bad. What the ISY does is keep the master copy of links in a file as you add devices and scenes. Sometimes when PLMs fail the links table in the PLM becomes corrupt and/or incomplete. This is a link to an older manual, but the procedure is the same. Go to page 60 to 3.10.3 and forward and follow those steps. This type of failure usually comes with older PLMs, but its a place to start and something to eliminate as a cause.

Re-iterating what was said: Homeseer, Insteon, UDI and yes, Home Assistant, as comparatively smaller integrators, aren't fully there yet. None of them have a "we'll be ready here" date. Matter/Thread require significant resources for smaller integrators to complete the work, compared to Apple, google, Amazon. From Home Assistant's current Matter web page: "Realize that you are an early adopter, both on the hardware side and on the software (controller) side so you may run into compatibility issues or features that are still missing. Report any issues you may find and help out others if you find a workaround or tested a device." All due credit to Home Assistant's advanced state of integration, they are not saying "we're there". There's not a date. They are the lead horse in the race. Not all integration companies have the necessary resources to deliver the Matter plumbing .You've chosen an early adopter standard above automating functions in your house and will need the patience to see it through.. or make the necessary platform choices based on the direction you want to go.

I use a doorbell camera. A suggestion is to write an iox program that detects the motion. Then let it call a second program to turn the light on, use a wait statement ,and then shut the light off. By detecting only "on", the effects of the light won't effect operation. Here's my first program that detects motion. It calls a second program that turns various lights on, waits (randomly) and shuts them off. The point is, once motion is detected, the second program runs regardless of the motion sensor going back off: Front Motion Detected-1 - [ID 0027][Parent 0002] If 'Lighting Premise / Front Door (Motion)' is switched Motion And From 9:30:00PM To Sunrise - 30 minutes (next day) And 'Lighting Premise / Seasonal Lights-Entry Closet' Status is Off Then Run Program 'Front Motion Detected-2' (Then Path) Else - No Actions - (To add one, press 'Action')

A couple of efficiency comments: My belief is that it would be better for the If to use Control instead of status. When you turn an Insteon device on or off, there are multiple message exchanges between the PLM and the device. I'm counting 14 separate devices being addressed in a row. The way the ISY works.... it doesn't wait between each of the on or off commands. So your Insteon network is flooded with traffic and the next on or off is colliding with the previous. Is individual device reliability a reason for repeating it 150 times? To be candid that is really extreme. Put the individual devices into one or more scenes (one should be fine), and turn that one scene on or off... One time.... no repeat statement. They'll all go on/off appropriately at the same time I know this approach is different than you're asking, but the chain of separate devices coupled with the loop 150 times is going to give you unreliable results.

What is the house code / unit code... Not J is it? I would temporarily shift the house code to something else, and wait and see if it repeats. If it does not, modify your programs to the new house code

Read here: My guess is the the plugin needs to login into the eISY, so use that login info. Here's the developer notes on the parameters for each host you want to WOL Custom Parameters": Key = Host Name Value = Mac Address (xx:xx:xx:xx:xx:xx) / IP Address For example: MyComputer = 10:0c:b9:8e:3a:24/192.168.1.12

Sometimes things go astray in replacing a PLM I would try right-clicking on each of the 2 devices, one at a time, and select "Restore device" If that doesn't do it, delete and rebuild the scene.

You've just done it. Typically a community developer will already be an owner of the product. *Sometimes* community developers will consider creating a plug-in for something they don't own, if the appropriate hubs and devices are loaned and shipped to them for development; if you offered that that it might help. I saw that wiz supports Google home, Alexa, and IFTTT.. All three of those are supported by eisy... Google and Alexa via the isy portal, and IFTTT by a plug-in.

Something else to know about "Switched on" in Insteon devices which is a factor too. "Switched on" messages are only sent to the PLM/ISY when you physically flip the switch at the device.... not when you turn it on with a program. "If Status" is the right way to go for this use case

In your case status is probably more appropriate... the case being the power goes out when the pump is running and the ISY restarts. When the power comes back up, the smartenIT switch is likely still on, its last state, so it won't "switch on" and the program doesn't execute. Power is restored and it continues powering the pump. When the ISY restarts it interrogates every Insteon device for its state, and it will see that the pump is on, so "If Status" will be true. It won't "switch on" during that time and explains what you are seeing

Me too, and PC is wifi connected. Can't remember the specifics, but after many days, certain things in the interface stop working and makes the windows "bling" sound. It is handy for tinkering. I "tinker" too, especially tuning programs with variables.. when something unexpected does (or doesn't) happen.. I go see all of the variables on one page, last change time, etc However, its not designed for that and to answer the OP, there's no setting to control that

I don't believe there is a time out, per se. It's not designed to be left running, when you're done working, close it down. Having said that, I forgot to shut it down sometimes and it will run for days before I notice. But I try to remember to shut it down

You need to clear java cache with all 3 boxes checked, then visit https://isy.universal-devices.com/start.jnlp and download the iox finder. At first execution of the java app, the icon (for that version of iox) is added to your desktop

ISY Cookbook Scroll down to pg 120. Your programs have variables, so you've used them. Make a State variable call it Pool Cycle Counter, and then add this iox variable statement: $Pool_Cycle_Counter += 1 ... every time a cycle happens Use that variable, either to send that a notification, or take an action in an iox program If $Pool_Cycle_Counter = > (some hard integer number) Then Send notifications, shut things off, $Pool_Cycle_Counter = 0

This one may not run after startup, it's a key control and should be set to "run at startup" so you know it's right. All of the programs that use a hard time of day: if those started, and then the ISY restarted from a power outage later, what happens (maybe that's where this began)? Based on how the ISY is set to "catch up" on programs when it restarts in the config tab, different things may, or may not happen. I think the randomness of power outage time will make this hard to be bullet proof. It's probably better to get a notification that the ISY restarted, have it shut everything off so you can manually intervene later and not accidentally over chlorinate the pool

It would be the same approach as your other servers and Rpis. SSH in to the eisy, create python or other method to detect the UPS's mode and issue command line to shut it down. I google searched "shut down freebsd" and specific command line examples were returned.

I suggest one of these approaches I described above: Maintaining variable state. Right now, when your isy restarts, they''re all being reset to 0. Every where you assign a value to a state variable in a "Then" or else, put an "Init to" statement right under itfor that variable for the same value so the ISY remembers when it resets. Have a program that you set under the programs tab to run at start up and make sure the valves are off (or whatever startup state should be). Different inston / smartenit devices can come back up in different states on a reset. You might have to bench test the program by unplugging the ISY. If you create a deadman program as I described in my first response, you'll want to set that to run at startup too Approach 1 can be a slippery slope and would need more validation testing. A final thought is to have the ISY run a program when it starts up to shut valves off and send you a notification, so it can't over-run and you can be aware and deal with it

Without seeing your programs there's some guessing on my part. If power goes out, the pump loses power too (?) Variables that haven't been saved with "init to" statements in your iox programs will reset to 0 It will help to see the programs here

1) create a separate "dead man" switch program. If status pump is on wait xx minutes. (Something longer than it should run) Set pump off Send yourself a dead man program notification else 2) you can mark programs to run at startup. You may want a program that establishes startup conditions (pump off?) sends a notification, and has no "If" statements. Set it to run at startup

While there is an iox restart program statement (and it's not recommended) there is not a shutdown statement. It's run on BSD Linux, so it's technically possible. Having said that, I went through more power outs on my 994i and raspberry Pi original node servers than I can remember and they came back up. Only a couple outages at my new house on eisy, same thing, came up. What was important was "init" variables in iox programs so particular monitor and control functions stayed whole.

I had insteon in my last house for > 15 years, and sold the ISY and everything with it. I started over here last summer, and went with i3 paddles... slowly built up to 14. UDI is offering a 10% off promotion for Insteon now, and Insteon offered multiple discounts to those that joined their 2 year celebration call last month... I have 10 more coming to go in. They have a softer look and sound in the house, less clicky and distracting. Nice package, smaller footprint and operate well... They did better than I expected in the WAF department. I believe the core package is still more embedded device and not an SOC.. meaning it likely will never support a linux type operating system or IPV6 stack... so, no Matter coming directly to the switch. If I choose to go matter in the future, I'm counting on implementing it as described in the post above.

Well said. AFAIK, matter is simply a pathway between devices and not "smarts". eisy will be powerful matter product as its logic is brand (Apple, Google, Amazon, et al) agnostic. Eisy is also the best native Insteon controller, we get the best of all worlds.

They want to as well; all HA integrators want to. I attended their 2nd Anniversary celebration zoom call a month ago and this exact topic came up. Like UDI, they're not the size of apple, google, amazon, et. al, don't have the resources to deal with the giant ball of matter code and they are struggling to get to the finish line as well. They said they're targeting January. Having said that, I'm fairly confident that they mean that as it applies to their hub and director products, not matter on their embedded devices; switchlincs, etc.

The 2 bought in the last 10ish months started with 70.7x.xx

While I understand where indymike is coming from, there a pluses for it being directly integrated with my Insteon network if the Insteon network is strong. Like you I've used them for long periods at my last house. I have them monitoring my sump pump run time and depth alarm at this house and it works well for that purpose. To follow the diagnostic path you've been on, I would plug it back in, but disconnect the input wires to the iolinc and retry. If it reappears, its the iolinc... if it doesn't, its potentially the alarm system or wiring.