auger66

Yep, that was it. Thank you! After all the sudo instructions, it upgraded the frontend, but the backend was still showing 3.0.19 and not connected. I did a factory reset. Same. Then while I was poking around, poof! Everything indicated 3.0.61 and connected. Plus, Polisy shows up on ISY Finder for the first time. Thanks again to everyone.

FreeBSD polisy 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 r369564 POLISY amd64

I didn't think to look at the version since I just installed it. I've also tried updating a couple of times. I showing I'm on an even older version of 3.0.19 I tried all three of these upgrade instructions in putty and a couple of restarts: sudo pkg update sudo pkg upgrade (will update all out-dated packaged) or sudo pkg upgrade pg3 (to update just PG3) sudo service pg3 restart I received no errors or updated files. It returns all repositories and packages up to date, zero candidates, and your packages are up to date. I'm still on version 3.0.19

Agreed. Sometimes it's just best to sit on your hands.

No, but I just installed PG3. PG2 works fine and is up to date. I did a sudo pkg update on PG3 a couple of days ago, but nothing changed that I could tell. I just tried a one-click update on the front recessed button. No change.

Yes, Hue shows it installed on the dashboard. I reinstalled the Sonos node server, too. They won't run, though. When I click restart, the node server restarts and almost immediately shuts down. Both have the same behavior, and both logs look the same to me. Full of same errors, but I don't know what the culprit is. They also both show up on the ISY-994 admin console under node servers. Before I installed PG3, I poked around the forum and saw both of these worked on PG3. I have a feeling I'm doing or not doing something stupid. Thanks Sonos log.txt Hue log.txt

OK, thanks for the help. I had uninstalled both node servers. I reinstalled the Hue node server. Same behavior. I attached the log. Thanks again. pg3_5-6-2022_13702_AM.txt

I have a Polisy running PG2, and an ISY-994 with a serial PLM. All working well. I was only running two node servers so I decided to delete them and use them only on PG3 instead. I'm keeping the ISY-994 going. Not planning on ISY on Polisy anytime soon. I thought I had read through everything, but I'm clearly missing something. PG3 sudo installed and started fine ISY found and ISY login information entered Went to the store and put my Portal information in Selected install for the Hue node server It installed fine and shows up on the dashboard and ISY admin node server list. But it won't stay running. When I restart, it starts and stops. It's status is disconnected. Can't add any Hue nodes When I go back to the store, it doesn't indicate the Hue Node server was installed, and I get "failed to get purchased node server" error flag. Sonos node server behaves the same way I'm guessing this isn't a node server problem, and is something more basic. ISY finder doesn't indicate Polyglot 2 or 3. I didn't know this was a thing until now. Polisy and PG2 have always worked fine. I can reboot the ISY from PG3. Any suggestions? What did I not do? I don't have to plug the PLM into the Polisy if I'm still using the 994, correct? I didn't with PG2.

FWIW https://staceyoniot.com/insteon-is-down-and-may-not-be-coming-back/

So this topic kept going so I dug out the actual programs I have running in a hangar. The idea is when it's warm and humid, the concrete floor gets wet. So I wanted a program to run when "wet floor" conditions were met and turn on a big floor shop fan. The values that mattered were 60% humidity and 60 degrees. If both of those conditions or above were met, then I wanted the fan on. Otherwise, off. So this is to set the humidity variable Set humidity variable - [ID 000B][Parent 0001][Run At Startup] If 'Thermostat' Humidity >= 60% Then $Thermostat_hum = 60 Else $Thermostat_hum = 59 This is to set the temperature variable Set temp variable - [ID 000A][Parent 0001][Run At Startup] If 'Thermostat' Temperature >= 60.0° Then $Thermostat_temp = 60 Else $Thermostat_temp = 59 And this is to control the fan based on the temperature and humidity conditions. The wait 30 minutes is to keep the fan from cycling on and off too often when the humidity drops. It's not unusual for the humidity to be near 60%. Humidity fan control - [ID 0002][Parent 0001] If $Thermostat_temp is 60 And $Thermostat_hum is 60 Then Wait 30 minutes Set 'Floor fan' On Else Set 'Floor fan' Off

I have something like this I programmed a few years ago with an Insteon thermostat to turn a shop fan on at a remote location. It's still running. Since the humidity changed constantly and restarted the program every few minutes, I made one program to set a variable if the humidity value was 60% or above, and else if below. There is also an above or below temperature value to the variable. The next program just looked at the variable. I also put a one hour wait on the "if" if the humidity cycled between 59 and 60, which it did surprisingly often since the fan would almost immediately drop the humidity. I didn't want the fan cycling on and off rapidly. However, I haven't put near the thought into this that @MrBillhas, nor do I have his ISY ability. The OP just reminded me of what I did to solve a similar problem back then. Works perfectly.

Thank you for this. I have six different ISY/Insteon installations that have been running for awhile now. I've never had a PLM failure, but I just ordered a defensive USB PLM. Cheap insurance. Kind of like if you take an umbrella with you, it will never rain.

I started over with Polisy after Polyglot crashed on a RPi after an upgrade. The Nest node server never worked again. FYI . . .

Well, I can't replicate the issue, either, now. They are all reporting status just fine. Sorry for the bother. It seems like it had more to do with the location rather than Android vs iOS, but I still don't know what the issue was yesterday. Thanks

Javi, thank you for your reply. No errors during sync. Yes, the admin console shows the last status. Not talking about the blue dot--just on or off. I selected status when creating the favorite like the other devices and scenes I added. After I made the previous post, I went out and had a couple of beverages. I then realized I slightly misstated my issue. I realize battery sensors don't state their current status. What I meant to say is the app is not reflecting the last reported status or any status at all. For instance, the admin console will show the last status the leak detector sent--as dry on, or wet off, or heartbeat, etc. The app just shows a couple of -- always. This is the first time I've ever I'm handing off an ISY system to a pending new owner, and I'm trying to simplify the system with favorites and clean up details like this for the wall-mounted iPad I'm leaving. It's a lot to digest for someone that isn't familiar. I won't meet the new buyer until after we close, but I hear she's not "techie." I don't have any favorites on my separate, personal setup, but I just checked the same type of water leak detectors on my Android phone app. They reflect status accurately and immediately so the issue must be specific to the iOS app. Water leaks are a big, big issue in my high-rise building lately. I have programs that alert you to leaks, but it would be nice to see that the leak detector is showing dry on, as in, if the button on the detector was clicked to show it is "armed" again to trigger the program for a new leak. Thanks again for your effort on this native UD app.

I just put UD Mobile on an iPad. Leak sensor status doesn't show. Is there a way to directly show sensor status as a device like other devices do? I'm trying to avoid setting up a variable just look at sensor status. I'm assuming a variable would work. Thanks

I loaded the other five ISYs with only the Portal connections (no local) tonight. I can't believe how fast the app Portal interface is. Well done. One small suggestion . . . Consider making the favorites tab specific to the ISY you selected. I can see arguments either way. I'm all in Android, but the iOS app can't come soon enough for my users. So how's that going? Thanks again.

That's a great idea. Wish I had thought of it when I set up new place. I wanted to do the same thing but didn't know how to do it.

I would just like to say thank you for this. I put it on my Pixel 4. I haven't customized it yet; but it works, including the RPi. ? I support five ISYs for people that all have iPhones. I look forward to the iOS version for them. Thanks again . . .

Thanks for the input. I'll be putting my commands in programs so I should be able to control the overlapping commands. Plus, there are only two. That condo is small, and the motors are in separate rooms but pretty close together. Hopefully, close enough. I have seven Somfy roller shades and curtains in my condo. The roller shade motors have better range. I'm running Polyglot on a RPi in my place. It's not nearly reliable enough to put in someone else's place. I have to go in and restart the Hue nodeserver often. Same thing with DarkSky, but I removed DarkSky as I don't need it anymore. I put a RPi restart command to run every day at 4am, but I still have to restart the Hue nodeserver once a week or so. The Sonos nodeserver seems to always work. We'll see what happens when S2 comes out in a week. The ISY is rock solid so I'll be sending the Somfy tcp commands from the ISY directly. We'll see how it works out. I was going to buy a Zwave module for the ISY and use the Somfy Zwave interface, but many here didn't think that would work.

Many thanks. I'm looking for the best super robust way forward for some new Somfy roller shades in a rental unit. All of the Somfy solutions get poor reviews (myLink, ZRTSi, URTSi II, etc.,) mostly due to range issues. I'll try myLink and network resources first and cross my fingers. And how 'bout Elon yesterday?!!! ? Well done!

Would you mind sharing the MyLink tcp commands you use for network resources? Thanks

Well, this is probably the best thing I've learned all week. I tried it, and you're right. I wish I had known this a year ago.

Yes

I have a variable to control an Alexa routine. It still works; however, . . . It has always had variable timing on the execution. It can be anywhere from 1 second, 3-6 seconds, or occasionally not at all. It's not the ISY. The variable changes instantaneously.