paulbates

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.

A couple of thoughts. I'm guessing you did a factory reset and a restore device. Try just factory resetting it, watch and see what happens. If it's the bulb, I've solved a "kind of" related problem, the "Led Christmas light glow" to deal with the residual voltage from lamp modules. What I did was plug a low voltage device, an old phone charger, at the end of the string. I don't understand the electrical principles involved and I could be off base, but it has worked me on LED strings. Plug one into the extension cord behind the lamp module and watch the logs

The 994i is an end-of-life product No more software updates / fixes for it. No growth. Newer node servers, integrations won't work. IIRC, the new Insteon i3 switch products don't work, or not all features work with the 994i. I moved last summer from my house that I had my 994i at. I had finished automation around 2016, so I probably would have replaced it with a 994i if it died as my automation wasn't going anywhere. Now I'm at that point with the house I moved to, I've pretty much finished other than a few Insteon n-ways which won't need the eisy once set up. But I plan to be here ~10 years. The point is I'm looking for this eisy to get me through that time and not go through another system rebuild, supported and updated for most of it.

Relatively. You'll need a backup to restore on the me isy. And then complete the move to the new plm. The cable is a likely culprit and needs to be proven out

It's best for scenes/groups to be created and managed by the isy.. You can do this after the fact by adding them to the isy, the default is for the isy to remove any existing links when adding. A couple of points: Make a spreadsheet of devices with their insteon addresses and locations. If you can, wait until you have the eisy to do any programming of n-way switches and insteon devices. Use the spreadsheet data then This approach applies to inline modules, you can add them to the isy by insteon address

I don't think you're screwed. Submit a ticket and udi will help you resuscitate it. You might have to pay something as the 994i end-of-life product wise. https://www.universal-devices.com/my-tickets/ The alternative is to consider moving to the eisy.... As you've had 8 years of use which is a very long time for most electronic things

Another root cause to unpredictable, flaky behavior in an older ISY is the SIM card going bad. This potentially is a cause. I didn't scroll back through this thread to see if this was covered or not... but *it is* something that will eventually happen. If you search the forum for SIM Card, or the wiki the procedure is covered. The problems you are having still seem systemic to me based on their random nature.. ed corrupt PLM or/and corrupt SIM, and not a program suddenly going bad

Unusual symptoms, but a factory reset and restore is easy to do and should be eliminated as a possible cause

EDIT: My recollection is that it was one device per hub, but that was wrong, here is yolink supports page. Can I use multiple YoLink hubs within the same network? Yes, you can set up multiple hubs within the same network, and it is recommended doing so. Having two or more hubs increases system reliability. If hub A is offline, devices will automatically connect to hub B. Additionally, placing hubs in various locations throughout your home will expand their communication range Wrong: Yolink devices can only be associated with one hub, so the answer is no from a practical point of view. However, the range and reliability of yolink devices allows you a lot of flexibility in the hub's placement; like right next to your router. My announcement capable, Wi-Fi only hub 2 is near my router. It talks to all my yolink sensors, even fridge/freezer seniors across the house in the garage. I have no Wi-Fi connectivity issues either

Right, the suggestion was to move that down a level.. set all but one of the program folders (assuming you have your programs in folders) methodically let each folder run for whatever time you think is right and have no problems, the uncheck another... rinse and repeat (after removing 1=0 from the top level) However, your other answer convinces me that the problem is not programs and barking up the wrong tree Can you get to all of the MS easily? You'll want to, one at a time, press and hold the set button and then check the options for each especially the timers... looking for 52 minutes or any value that looks suspicious. A factor reset and restore device is in order... but hold on to that thought.... +1 to what @IndyMike said. PLMs can suffer a long and agonizing death. Continuing to refresh the PLM's link table is a road to nowhere and likely explains the continued degreadation of ISY functioning. Here's my suggestion: Order/receive a new PLM Find an iox backup from before the most recent events happened Restore that backup Swap the old PLM with new, following the PLM replacement procedure Except... skip step 1, backup, that list, my guess is that the current state PLM/Links table is too far gone This will take a while and you have to individually do each wireless only device by placing it in set mode Look for any devices with the green "io" next to them and do a "restore device" until they're all clear. Test as best you can to address individual device problems. Factory resetting / restore device may be in order for some with corrupt data tables. Check all of the settings of each MS. My guess is the MS are ok, but have corrupt tables... hard to say

You're on the right track with this approach. To optimize it it, I would set that same 1=0 logic on all your top level program folders. Then step through turning them on from the top down, either Folders with many programs... or Folders with time based programs in it The PLM could be partially to blame, when flaky Insteon light activity happens out of the blue, it can be the sign of a failing PLM. How old is the PLM? However, the PLM and most Insteon devices do not have timers/clocks in them so it doesn't fit the 52 minute problem. The only Insteon device with a timer that I'm aware of is the timer key pad, where the buttons had different count down times on them... you don't have one of those do you? They're long out of production. EDIT. MS's have timers too, they are suspect as well

The network service that the finder uses to find the ISY is (initially) not part part of the TCP/IP protocol.. it's a discovery/magic frame. It's good because it doesn't care what the IP address of the ISY is... it will ask it to identify itself. What's not good is that because it's not TCP/IP packet, it won't pass through the router/gateway in the EERO. Many access points offer "Bridge Mode" where it uses the host (AT&T) as the router. If the EERO has "Bridge Mode" this gets around the problem. Yes. It's possible through your ISY portal account. It's a little tricky to setup, but once setup works really well.