kzboray

@bpwwer A follow on question. Since the NS's are PG2 not PG3 does the same fix of installing a NS in an unused slot work to correct DB issues?

@PB11 I have a client with a Polisy that also has seven unmanaged PG2 node servers. I went so far as to remove the node severs manually from the Polisy. SSH and deleted all the node server directories from the PG2 directory. I also deleted them via AC, but they are still there. It's something I've been meaning to create a ticket for, but since it's not breaking anything atm, it's been a low priority. I believe it has something to do with the portal account used during login to the portal. Since I have multiple clients I support, it is not out of the question that I used the wrong portal account when updating their system and now the node servers are somehow linked to that other portal account. I'm reaching, but since the node servers are not actually on the Polisy anymore, it's all I can think of. It's just a theory, but I can't come up with another explanation as to why the node servers show up in PG2, but don't actually exist anywhere else. Please keep us updated on what you find.

My Polisy spontaneously rebooted. I was notified via the new portal status and ignored it until after dinner much to my dismay. As it turned out the entire system was non-functional. Even logging in via AC was weird. I have gotten back some function, but am still trying to determine what happened and how to fully correct it. Here is what my AC login looks like now. The first issue I had trying to access IoX was that the password had reverted to factory default causing not just frustration when trying to access IoX but also caused Polyglot to disconnect due to a mismatch in passwords. Once I corrected that I was then able to log into IoX but it wasn't communicating with Polyglot yet and all Insteon devices where showing they needed to be updated, however the update icon on the top menu wasn't there! After several PoliSy reboots I finally loaded up an IoX backup and all Insteon devices came back, setting the password in Polyglot got all the NS's back, but there is obviously still something wrong as the AC top menu is missing a couple of options, I cannot communicate via the could to my IoX and the Portal still shows my device off line. I'll have to open a ticket at this point to see if Michel and his band of merry men can sort out what's happened. I am simply sharing a pretty catastrophic event that I was mostly able to recover from because I keep up to date backups!

@TRI0N I would encourage you to take another look at UD Mobile, it's actually very powerful, but it requires you to do the configuration. After all how and what do you want control over from your phone? I certainly wouldn't want all 234 Insteon devices to try and populate my phone screen, not to mention network resources, programs, nodeservers and associated nodes, that's unworkable. UD Mobile is intentionally blank when you first start it. You have to read the manual or do what I did and play with it for an hour. I now have a great setup that is just the way I want it and when I had a problem one Saturday Javi spent the next 6 hours working with me on a resolution. It turned out to be a problem on my network, but he was there the entire way offering suggestions and diligently working to help.

@swnewman Have you verified that the portal has been approved in AC? It might be that simple. Open AC and go to <Configuration> <Portals> and verify that you have accepted the portal integration, it should look like this if it is setup and authorized.

@bpwwer, on my test polisy the password / user is admin / admin. That combination did not work. I typed it multiple times with caps without etc. nothing seemed to tickle the fancy of what ever system is checking the password / user name. I mention this only so you guys have a heads up. As I said not mission critical at all. Very low priority for me.

@JTsao I went ahead and made my backups and tried using the following URL. https://polisy.local:8443/rest/pg3x.enable I was first warned by my browser that here there be dragons (Problems with the cert) bypassing the warning I was then promoted for a user name and password. admin/admin did not work. I also tried polisy/admin with no luck. So unless we are first given the correct user name / password combo this is a non-starter. It was a flight of fancy for me and not mission critical. Having been stopped at first base I have lost interest in pursuing this for the moment.

@asbril Like all tech, z-wave has it's strengths and weaknesses. I'm glad z-wave is working well for you and I should have been more precise in my comments. Insteon is without a doubt the best solution for DIY lighting control. Outside of that z-wave and other technologies are better suited. Your comment about the stability of Insteon the company is also another important consideration and one I agree with. But until they either go away for good or another technology becomes available that is better suited to lighting control, I'll have to continue to use and recommend Insteon in combination with a UD controller for rock solid lighting control. Like you I have personally and in clients homes a combination of technologies. Without a doubt the homes that give me the least amount of support issues are the ones that use primarily Insteon. The homes that I used z-wave in are the most troublesome. From the more mundane issues like the pop-corn effect in lighting groups to the more complex when adding a new switch causes the whole system to need TLC because the manufacturer changed the firmware and now it's a series 700 on a 500 system that has no S2 support and the devices firmware now has a different feature set that causes it to be non-operational with other older switches from the same manufacturer. For door locks and relays z-wave is awesome, well maybe not awesome, but there are often multiple vendors with solutions for these needs. Insteon has none. I think there is a place for both Insteon and z-wave, as well as matter, zigbee, and even plain old wi-fi devices(my least favorite) in any automated home.

@gduprey I encourage you to try other platforms, but I will warn you they all have the same or similar issues with z-wave. z-wave is the problem, not the controller. Unlike Insteon combined with a ISY994i on which we all got spoiled because UD spent the time to reverse engineer the protocol on each and every Insteon device released; z-wave is a nightmare. Even z-wave manufactures of which there are many don't follow their own standards from device to device, making the word standards an oxymoron. UD has already sorted out a few of the issues with z-wave on their eisy platform and from experience I can say with 150% confidence that over time the eisy will become a rock soil platform for most z-wave devices. In the mean time like I said, try a few others out and let us know what you find. Maybe there is a better mouse trap, I personally haven't found it yet and with Matter coming on the scene it's only going to make what is already a crazy space even more convoluted.

I have an issue with the PG3 LifX NS in that anytime the Polisy is rebooted or updated, the LifX NS always restarts with zero bulbs found. Yes I have the correct bitstring installed. Often I have to reboot my router and the Polisy and restart the NS multiple times before I find a combination of reboots and restarts that works to restore the NS's ability to find the LifX bulbs. Maybe it's just time and I'm impatient, but I've tried just waiting and after hours the NS still won't find the LifX bulbs that it found with no difficulty before the reboot / restart of the Polisy. This problem also used to happen with PG2 so I believe it to be a local issue or something with the NS itself. Yesterday none of the normal gyrations worked to restore function after the 5.5.9 upgrade. So, I ended up deleting the LifX NS and started from scratch. Eureka! That worked. I don't understand why this happens, but the simple solution is to use the devlist parameter; if I could figure out how to make it work. Is anyone using this with PG3? I tired to set it up yesterday and couldn't find a workable name in the parameters section of the configuration. I tried, Key Value devlist.yaml devlist.yaml 1 /var/polyglot/pg3/ns/000db9560fac_3/devlist.yaml (with a value of 1 and blank) Nothing seems to work. Here's my test devlist.yaml, maybe I have the formatting wrong. I changed the names to protect the innocent, ignore the xx:xx:xx. Let me know what's working for you! Tagging @xKing and @bpwwer as one of you obi wan's might have some insight as to why the LifX NS causes so many problems and how to use the devlist parameter. bulbs: - ip: 10.0.0.225 mac: 'D0:73:D5:xx:xx:xx' name: Chand-1 type: bulb - ip: 10.0.0.226 mac: 'D0:73:D5:xx:xx:xx' name: Chand-2 type: bulb - ip: 10.0.0.227 mac: 'D0:73:D5:xx:xx:xx' name: Chand-3 type: bulb - ip: 10.0.0.228 mac: 'D0:73:D5:xx:xx:xx' name: Chand-4 type: bulb - ip: 10.0.0.229 mac: 'D0:73:D5:xx:xx:xx' name: Chand-5 type: bulb - ip: 10.0.0.230 mac: 'D0:73:D5:xx:xx:xx' name: Vanity-1 type: bulb - ip: 10.0.1.231 mac: 'D0:73:D5:xx:xx:xx' name: Vanity-2 type: bulb - ip: 10.0.1.232 mac: 'D0:73:D5:xx:xx:xx' name: Vanity-3 type: bulb - ip: 10.0.0.233 mac: 'D0:73:D5:xx:xx:xx' name: Vanity-4 type: bulb - ip: 10.0.1.234 mac: 'D0:73:D5:xx:xx:xx' name: Vanity-5 type: bulb - ip: 10.0.0.235 mac: 'D0:73:D5:xx:xx:xx' name: Bedroom-1 type: bulb - ip: 10.0.1.236 mac: 'D0:73:D5:xx:xx:xx' name: Bedroom-2 type: bulb - ip: 10.0.0.237 mac: 'D0:73:D5:xx:xx:xx' name: DiningRm-1 type: bulb - ip: 10.0.1.238 mac: 'D0:73:D5:xx:xx:xx' name: DiningRm-2 type: bulb groups: - address: grp000 members: [Vanity-1, Vanity-2, Vanity-3, Vanity-4, Vanity-5] name: Vanity - address: grp001 members: [Bedroom-1, Bedroom-2] name: Bedroom - address: grp002 members: [DiningRm-1, DiningRm-2] name: DiningRoom - address: grp003 members: [Chand-1, Chand-2, Chand-3, Chand-4, Chand-5] name: Chandelier

Upgraded two Polisy's today one starting from 5.4.4 and the other from 5.5.7. Both system's upgraded without issue. The 5.4.4 took about five minutes. Don't rush these box's when they are upgrading, let them beep at you when they are done, don't start poking at them until then. The 5.5.7 took less than a minute. Neither system uses any z-wave, strictly Insteon, with five and twelve NS's respectively.

@PapaBear I agree with @apostolakisl ISY 994's don't fail, its the SD card that will wear out over time. Replace it and run a restore from your last known good backup. That should clear up your issues. It might also be a bad power supply. If the PSU is starting to deliver low or fluctuating voltage it could corrupt the ISY config, but given your symptoms, I'd start with the SD card.

@rstotts After you check the the firmware and UI versions match I'd suggest you factory default the 2334-2. Factory Reset Factory Reset clears all user settings from Keypad including INSTEON scenes, on-levels, ramp rates, X10 addresses, etc. 1) With a small screwdriver or your fingernail, pull out Set button to create an air gap 2) Wait 10 seconds 3) Push in Set button and hold. Do not let go Keypad will begin to emit a long beep 4) When the beep stops, release the Set button. Device’s embedded software will rewrite all settings to factory defaults A couple of seconds will pass Keypad will double-beep and its LEDs will return to normal brightness The connected load will turn on and Keypad will return to ready mode

@TRI0N Thank you! I'll have to read through the entire post, appreciate the info!

@TRI0N Just to clarify...Using one of the 4 smaller buttons you were able to add them to a scene, or just the top larger button?

@TRI0NThere are multiple discussions about the Zen32, but simply put Zooz will not program the necessary changes to allow the 4 smaller buttons to function in scenes, they give reasons for this that sound mostly like excuses. The real reason is probably due to their inability to make the changes; not enough memory available, lack of skill in house, etc, take your pick. So you have to use programs to maintain the button lights on the 4 smaller buttons.

@brians I couldn't agree more. I've gone a couple of rounds with their support pleading for scene support for the Zen32 to no avail. I also had a recent mediocre service experience with them. I had a Zen32 fail. It would no longer join/leave a z-wave network and wouldn't factory reset. After my first email they wanted more testing which I provided, then the same after the second and third emails, finely they wanted a video of my testing and I said, "No." I further started that I was going to buy a new one from Amazon and then return the bad one in the new ones box and they could deal with Amazon. At which point they sent me a new one, that works perfectly, but I wasted an hour dealing with a very nice person who made me jump through too many hoops and left me feeling reluctant to deal with them again.

@brians is right. The Zen32 is advertised as a scene controller but it's really not. I've even tried using it as a scene controller with Home Assistant and you still have to navigate the lack of scene functionality on the four smaller buttons. It's a 5 button PITA, but once you learn how to deal with the indicators on the smaller buttons it's one of the better options for multi- button controllers available atm.

Update from AC. Took about 3minutes for the 4+1 beeps. Rebooted Polisy from AC. ISY started fine, PG3 was DOA. Ran the update script via SSH as documented by @brians in the post above this one and PG3 updated to 3.1.17_1 as expected. Tried PG3 again and it works, however this update once again killed the LifX NS. I will open a ticket about it this time. Here's the LifX NS fix for both Polysi and eisy Polisy sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/.local bitstring pip3 install --prefix /var/polyglot/.local bitstring==3.1.9 eisy sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring pip3 install --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring==3.1.9

On a Polisy 5.5.4 to 5.5.5 upgrade I encountered one very minor issue that was easily resolved. Programs that changed Insteon scene settings I had to click on each program and do an update followed by a save. I did not change any parameters, simply a click and update to refresh the values. I do not know if this is isolated to my Polisy or if others might encounter this so I wanted to share with the community.

Upgraded Polisy no issues, took about 3 minutes from start to finish.

@bgrubb1 Bitstring is updated to version 4.x in 5.5.4 OS update. This disables LifX from working as it requires version 3.1.9. If you install the 5.5.4 update it will remove the 3.1.9 version and install the 4.x version. The solution for both the eisy and Polisy are listed in the first post.

@stevesreed Don't worry about "Bad" It's been that way since the dawn of time or at least the first Polisy. It doesn't seem to effect operation.

@asbril Sorry mate. Keep us updated on the solution.

@Bumbershoot Great idea, but it won't work for this problem. The issue is one of the NS's dependencies is missing. More specifically the correct version is missing. The LifX NS hasn't been maintained and is becoming out of date in regards to the API and dependencies. The NS won't even start correctly unless you replace Bitstring 4.x with the expected 3.1.9 version. It shows up immediately upon starting the NS when you will see errors in the log file indicating it couldn't find the Bitstring dependency, and then when discovery tries to start, it won't be able to find any devices.