landolfi

That was the recommendation of support, to upgrade to 5.5. I could swear I read here or somewhere that they had issues with Zooz ZWave after a 5.5 upgrade, so I'm hesitant to do it. I don't plan to cut over to ZMatter until the migration path is well established, and I'm primarily using ZWave with the Zooz stick. It's been very reliable until these periods of unavailability started. Interesting idea to just query devices of interest. I have a query all running at 3 am and the periods of unresponsiveness have always occurred between the night before and when I get up, so the query all is suspect.

I had several Yolink programs that weren't running properly, and when I went to test why the Then didn't fire I noticed the node references in the program were gone and the Yolink node server and nodes were gone from the ISY on Polisy node server and node lists. I added the Yolink NS back but was the disappearance expected or is this a different issue?

More trouble with Polisy disappearing/becoming unresponsive. I've opened a ticket, today the IoX couldn't find Polisy. Found it using IP address, then AC started with 4 minutes of System Busy. Now anytime the AC is the active window it goes busy again. Eventually solved it (with luck permanently) by unplugging the Polisy. The problem is that Polisy is unresponsive to commands and has failed to run programs during these periods. I've made no attempt to update beyond 5.4.5 nor made any other changes other than Zmatter board to what was a solidly performing system with the Zooz stick and Insteon PLM.

Yes, does sound similar. I was about to say all my Zwave devices have been working reliably during this time but then I remembered a few lights that should have been turned off at 23:35 that were still on. I can't remember now whether the issues started with 5.4.5 or with the ZMatter board install, I went to 5.4.5 when it became available but only installed the board last weekend.

Similar situation here on a regular Polisy with the new board installed running 5.4.5 and I also have Insteon. I was planning to wait for the process to stabilize to upgrade, but I have noticed in the week since I installed the board that while most things have worked fine, there have been at least 2 days when Insteon behaved erratically (devices not responding to commands, and then when I go into admin console to see what's going on, there's a long period of System Busy at startup, toward the end of which the Insteon devices do respond to the previous commands all at once. I can't tell what the System Busy is about other than I can see it seems to be querying Zwave devices. So my question is whether there might be a known issue with the combination of Zmatter board, Insteon, and 5.4.5 that 5.5 will fix?

I had a similar (not exactly the same) experience. Did you try the paperclip reset on the front of the Polisy (paperclip in front hole, hold for a second or two)? That's what solved it for me.

Just a heads up that in my case the package update to 5.4.5 caused a "System Busy" updating loop that I eventually had to reset my way out of. I waited for 4 consecutive cycles of System Busy that lasted about 10 minutes each before deciding to reset, but everything seems to be working OK now. The only way I noticed anything was up after the update was none of my sunset programs ran and I noticed during the busy cycle that my sunset and sunrise times were both 00:00.

Thanks, @MrBill for a very helpful post.

I have also posted in the IoP forum today about a similar issue running IoP 5.4.4 yesterday where two scheduled programs failed to run after the time change. My time is correct right now, and I checked sunrise and sunset for today and they are correct for my timezone, but maybe they weren't (and maybe the time wasn't) when the automations were supposed to run yesterday.

Yes, time zone and time are correct in AC. The thing that's puzzling to me about all this is that not just one but two schedule-based automations failed to run, as if Polisy was confused about the time. Regardless, I just ran a scheduled test program and it worked. I noticed the grace period for missed schedules, what is that for? Is that in case of a brownout? Just noticed this thread about time zone issues yesterday, I am also running IoP on 5.4.4:

Two scheduled IoP programs failed to run last night (11/6), one scheduled for 23:35 to turn off several Zwave plugs and an Insteon light that generally works flawlessly, and the other program set for the range 21:00 to 05:00 (next day) that should have run at 23:58. The time on the Polisy is correct and was last night too because I noticed at 23:42 that the 23:35 program hadn't run yet, so I started it manually by running Then. I know the 2100-0500 didn't run because the trigger event occurred and shows in the log at 23:58. It is supposed to send an email notification that I never got and play an audio clip that it never played. Any idea how this could happen? I was a bit suspicious about a connection to the 11/5-6 time change back to standard time, but the dusk program ran successfully on schedule earlier the same day. In the past I've noticed that ISY seems to be very prompt in executing the 2335 right on schedule and also executing the one using the time range reliably. One other complication is that I installed Home Assistant on 11/5 and it is using the HA ISY integration to report status of devices but not running any automations of its own. I hesitated to add HA into the mix but from reading other posts here about HA integration with ISY it sounds like others have HA and ISY coexisting without issues. But maybe not HA and IoP?

I have this same problem and thought it was something I was doing.

Is version 5.21 the one that incorporates the new way of handling the disconnects?

I was just about to do something similar. Rather than buy the pricey Ecobee temp sensors, I want to use the various Zwave temp sensors I have around the house. Is changing the setpoint the way to handle a temporary change to accommodate a too cold/too warm part of the house? I just have a single zone and thermostat but want to be able to temporarily warm/cool my living room which tends to be much cooler than the area where the thermostat is.

That update seems to have broken something for me. I am sending the log via PM.

Thanks very much, Mr. Bill! Under Condition, I click Control. I see now that what I have been calling the door sensor device, ZW043_Barrier, is not in the Control list, but the control list includes an overlooked device called Access Control Alarm, which I apparently should have been using all along since it reports Window/Door Is Open in ISY. So I'll go with control from now on.

$sDoorSensorOpen = 1 $sDoorSensorOpen Init To $sDoorSensorOpen Question about this: If i only care whether it's closed, should I flip this to =1 for $sDoorSensorClosed and then 0 means either it's open or unknown. Or is this variable functioning to say to ISY yes, it's really open?

Thanks, Mr. Bill! Your first suggestion sounds ideal, but unfortunately it's an open/close sensor and doesn't appear in the list when I choose "Control".

I started to say that my other wireless door sensors accurately report their state after reboot without intervention, but then I realized those sensors are on Smartthings. But more importantly, is closed the same as empty/no status as far as programming is concerned? My objective is to get the door going from open to closed status to trigger an event, which it won't do without intervention if it needs an open or close inbetween. Which maybe we are saying it does require intervention and that's the nature of an open/close sensor.

I have a door sensor whose status is always empty in the AC after an ISY reboot, even if I query it. I have to physically go to the door, close and open it to get ISY to recognize it's open. The problem I have is that a program with an If condition of status=closed is executing the Then even when the status is empty. Is empty supposed to be the equivalent of closed for programming purposes?

I have 2FA enabled, but the only effect of that is that it is required to make changes within the app. I tried requesting a code from within the app and then entering that for AUTH KEY without success.

I looked in the app and don't see anywhere it mentions Auth Key.

I added the Node server but I only see Blink Setup, no nodes underneath it. Do I need to provide AUTH_KEY, and if so, where do I find it? Are SYNC_UNITS the individual cameras or the Sync Module, and it looks like specifying that is optional?

Thanks for this explanation. So is it a best practice to give the Polisy a static IP and use that in the node server slot configuration? And for IoP, should we tell PG3 that the ISY is at 127.0.0.1?

I just went back and forth with Michel on this topic. He was telling me the node slot config in IoP should be localhost or 127.0.0.1, but then said leave it if it's working. I changed the ISY IP on PG3 (on PG3 ISYs/Edit ISY) to 127.0.0.1. So far things seem to be working and the node slot has the actual address of the Polisy, so I'll leave it at that unless you know that won't work for some reason.