apostolakisl

Polisy is a device that supports Insteon, it is not an Insteon device. Polisy will probably support every open source protocol that exists, so I wouldn't worry about Insteon when making a Polisy decision.

Of course the caveat to that is that you don't just buy one switch. You might want 100 of them.

Ahh, the good old days, when a tank of gas was $50. Unless you are taking your date to McDonalds, not sure your going to get by with $50 there either.

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.

After migrating to IoP, the following program style no longer works. It is supposed to be true only when you click the off paddle when the light is already off. But it is running true when you turn the light off from on. Curiously, does not run true when you click off the second time from 25%. Bath Night Lt. Can - [ID 0076][Parent 0083] If 'Master Bedroom / Master-Bath Cans L' Status is Off And 'Master Bedroom / Master-Bath Cans L' is switched Off And Program 'Dark Outside' is True Then Set 'Master Bedroom / Master-Bath Cans L' On 25% Else - No Actions - (To add one, press 'Action')

No, ud mobile does the same thing the http user interface does, it gives an error. You can't do anything with it.

Nope. Gives the same error "requires uuid" Also, doesn't let you enter a uuid

I have exactly the same problem.

Well this is not going well at all. The only thing that went to plan was getting Insteon working. The node servers are not working. PG3 is totally messed up and PG2 only works from PG2 to ISY. If I try to send a command from ISY to the node server, it says "busy" and then times out with an error. PG3 won't accept me changing settings. I try editing the ISY and it says "updateisyparameters invalid". I tried adding it as a second, and that sort of works, but just has all kinds of issues. Nodelink has the same problem. I can't send commands to it, it populates the admin console, but I can't send any commands to my DSC alarm without an error. PG3 images below when I edit current isy UPdate; I have discovered the nodelink is getting commands from ISY, however, ISY doesn't think it is working. ISY says busy and then gives an error, even though the command went through. Other polyglot does not do anything. Also tried restoring backup of pg3, and it doesn't do anything. No nodes, no configuration. The ISY setup page has no uuid and no way to enter a uuid. Only if I add a second ISY can I get a uuid, but the nodes I installed aren't there. UPdate: OK, figured out some of the issues. Upon moving to IoP, I moved polisy's IP address to the IP that used to be for my ISY. This of course moved the node servers as well. ISY however held onto the old IP address for polisy even though polisy from its side logged into ISY, ISY did not update that IP. However PG3 still is dead.

The technology works. It had some growing pains. Dual band and sourcing better electrical components fixed pretty much everything I ever had a complaint about. And they worked out little bugs like not using tapered screws to hold the paddles down (they cracked, presumably thermal stress). And for a while, they had so many niche products that just rounded out the protocol. Anyway, now that things seem to be all worked out, it is too late for them. Obviously, I think they made some big mistakes on the business side of things. They should have worked with other companies for one.

You still need something to get plc/insteon radio into ip based protocol. Unless you put ip based wifi into each device, but that would be a completely different device environment and incompatible with all current devices. I'm thinking basically a PLM that instead of output usb or serial, it outputs to ethernet or wifi. PLM plus ISY is more or less doing that as is.

Yeah, put some hardware in between that does the translations. It would, I assume, be a completely new piece of hardware.

The concept of node server on the device. Since the protocol is not over internet, how does that work?

Generally I agree, but above I do not. This is not emotional in the sense that I have some nostalgia. I have a gigantic system and I am happy with it because it functions perfectly. It is a lot of work, I mean a lot of work, to set it up. So I suppose in the sense that I have an emotional aversion to all the work of setting up a new system, then I guess it is emotional, plus it is expensive. There is a cost to multiple versions of the same product, I understand. I also think your current base of Insteon customers is your best asset, especially the hub people who will see UD as their savior. I started with about a dozen devices, I now have over 100. And I went on to install Insteon at my church with another ISY. I suspect there are lots of people who are at that dozen point, ready to grow. And, I started with a 99i, then a 994i, then a polisy. . . what is next? Gadget people buy more gadgets! It is a psychiatric illness my friend.

I suspect that this statement was at least somewhat related to the management of Smartlabs, which of course may now be a resolved issue.

I think the name polycon is already taken.