apostolakisl

OK, PG3 now opens without phantom ISY. It found the correct uuid for IoP and says it is connected. But there are no nodes listed, managed or otherwise. Before it listed all of my nodes as unmanaged, PG2 and ones I had previously set up on PG3. I am hoping to get my PG3 nodes back to "managed" on PG3. EDIT: and when I say "before it listed. . " I mean after moving to IoP and before the deletion I just did a few minutes ago. Everything was fine before IoP migration

I'm trying to remove PG3 from polisy and then start with a virgin install of it. I have tried sudo pkg delete pg3 But it does not delete the "user" and "group" and asks me to manually do so. I do not know how to do that and also have concern that perhaps pg2 is stored there. [admin@polisy ~]$ sudo pkg delete pg3 Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: pg3: 3.0.59 Number of packages to be removed: 1 The operation will free 62 MiB. Proceed with deinstalling packages? [y/N]: y [1/1] Deinstalling pg3-3.0.59... [1/1] Deleting files for pg3-3.0.59: 100% ==> You should manually remove the "polyglot" user. ==> You should manually remove the "polyglot" group

5.3.3 @Michel Kohanim

Looks like after doing a restore on every device, this problem is solved. Not sure how or why it got messed up. Because of the program that started this whole thread is one I use every day, I know that the problem started right after I switched to IoP.

I went through and right clicked every device and hit restore. Like 75 of them. Gonna take a while.

I added a brand new 2477D switch to the network and it worked correctly. So I tried restoring one of the already installed ones and now it works. I guess I'm going to need to restore all of them? I don't think this is a link issue but rather how ISY is processing info on the links.

I suppose, but the links aren't on IoP, they are on the PLM and device. And yes, I restored a backup. I was shocked at how the backup restored. It was basically instant.

It is every single 2477D, at least of the ones I tested and that is about a dozen. Plus, there is no mechanism to lose links by just pluggin the plm into a different controller. The links are all on the plm and devices, none of which have had any changes. I posted a screenshot of everything that happens when I click the "on" paddle. You get a DON. Also, all the other stuff you might do like dimming or clicking off produce status updates, and those aren't different links, they are just different responses to the same link.

I can duplicate it, I just don't know why it would only be my system. It happens like this every single time. IoP is receiving the DON signal as seen in the event log, in addition, it responds to the DON programatically. In other words the following program works: If 2477D is switched on Then do something. It is only the status that does not update.

The program isn't exactly the issue, it is just what immediately brought the problem to my attention. The problem is that ISY is not registering a status change with a press of the "on" paddle for that switch, local control in other words. So the light is still listed as off (or whatever it was) after I click it on, that causes the program to misbehave through no fault of its own. If the light is turned on by any other method, it does register as being not off. In other words, dim up, dim down, responding to a scene, and probably fast on but I haven't checked that one. If the admin console says the light is at 50% and I click "on", it still says 50%. If it says "off" and I click "on", it still says "off". If it is 100%, and I click dim up, it now says 100%. I the light is off, I click "on", it still says "off", but if I do a query, it then says "100%". Every single 2477D I have tested is behaving the same. The screen shot of the event viewer showing the "DON" comm and the admin console status showing "off" at the same time tells the story.

@Michel Kohanim Doesn't appear to be a problem with 2477S. Just 2477D.

OK, it works. A bit of a cludge, but whatever. If you have an old ISY 99i with IR. 1) Factory Reset 2) Boot it up with a plm plugged in 3) Open admin console http://your.isy.ip.address/admin.jnlp 4) Delete PLM 5) Go to the IR tab and load the default 40 codes 6) Setup network resources in your 99i to trigger your IoP pointing to the program/node/etc you desire the IR button to act on. https://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface 7) Write a program on 99i If IR 'IR_003' is Pressed Then Resource 'Name.1' Else - No Actions - (To add one, press 'Action')

I can't believe I'm the only one with this issue. I have rebooted polisy and that didn't fix it. If a switch is the responder to a scene and you turn the scene on, the status properly updates. But the below program runs correctly. tes - [ID 008E][Parent 0093] tes - [ID 008E][Parent 0093] If 'Kitchen / Kitchen Intercom-Island L' is switched On Then Wait 3 seconds Set 'Kitchen Puck S' On Else Set 'Kitchen Puck S' Off So ISY does recognizes that it is receiving the on command from the switch, it just isn't updating the status.

Well this isn't going anywhere. I'm going to hook up my old isy99i and use it as an IR to Rest converter and get my 40 isy codes back.

You can check the event viewer and set it to device communication mode (3). When you click on paddles you should see things pop up with the device addresses. If not, you have communication issues. In my case, I am having issues where the communications are showing up in event viewer, but Polisy isn't updating device status'.

The program is working correctly based on its understanding of the state of the device. The problem is the program is being told the incorrect state of the device. The program thinks the light is off even though it is on. The reason it thinks it is off is because IoP seems to be ignoring "DON" communications. It is receiving the DON, but it is not updating the device state. EDIT: And this is the case for every device I have tested so far.

I have narrowed the problem down to IoP processing error. I watch event viewer, click "on" paddle, I get a "DON" along with the correct Insteon address, but no change to lights status in the admin console. @Michel Kohanim EDIT: Here is a query result. It does register 100% after a query.

Don't see how this could be a link issue. Links are between Insteon devices. Nothing was changed between Insteon devices. The PLM is just another Insteon device. In addition, I have seen no Insteon to Insteon comm failures. All scenes are working as expected at all switches. I also tried doing a query of the one representative switch. I clicked "on", the light turned on, but ISY control panel still shows off. I do a query, and it still shows off with no errors reported on the query. I then click and hold a dim up on the switch that is already 100%, and now IoP shows "100%". Something weird here.

This is an issue not of ISY program processing but rather ISY (IoP) acknowledging the correct state of the device. Based on the displayed status of devices, IoP programs are behaving correctly. As it is, this is a much bigger problem than that program type. It is just the very first program type I found to have the issue and I jumped to the wrong conclusion about the cause based on the fact that I have seen that style go wonky twice before over the past 10 years or so. I tried doing a restore on that one device, but no dice, same thing. IoP still not showing an "on" command. But reports other commands. Dim up, dim down, off, etc. This is not a comm issue. I have tested about a dozen devices now and all have issues. There were zero issues prior to the IoP update. My comm has been rock solid for years. I made no changes to the PLM or devices, just switched serial cables and plugged into IoP instead of 994i. Perhaps a "restore plm" will help, but I don't know why it would.

I looked into this further. The program is working correctly. But IoP is not registering the status of the light correctly. I have tested many switches and the are all having issues. For example, my bedroom closet. ISY seems to always register an "off" command as well as dim and and dim down. But never recognizes on "on". So the light is off, I turn it on, but IoP still says it is off. So when I shut if off, the program incorrectly triggers. Something like this or similar is true for just about every switch in my house I have tested. This problem started after IoP was installed. I had virtually perfect correlation between ISY status and actual status prior to the switch and it has been that way for years through many ISY firmware updates.

Possible. I don't recall that when it happened with previous firmware that it only happened from higher starting levels. I think at those times the only way to get the light off was to do a fast off.

That works, but I'm not a huge fan of the Insteon double click. Often times you don't get the click rate right, especially if you are kind of moving quickly or have stuff in your hands.

I could, but I have a bunch of these. This problem has happened with other firmware versions and UD has always been able to fix it.

Curious. How "on" was the light. I have found it works correctly when the light starts off at 25%. But when it is closer to 100%, it does not. It is one of my favorite programs. At night, you might get up to go to the bathroom. Instead of pushing and holding to get the light to just turn on a bit, you just click "off" and you get a nice dim night light. Also the WAF on this program is very high. (wife acceptance factor).

I tried that last night, no dice. This has happened with past firmware updates which they have corrected.