larryllix

Send me a PM. I am just on my way out.

Wow! What a text mess. Strange I didn't see that one. Nice attempt to belittle the complaints. Read the thread title. The point was, nobody reads the webpage manual instructions to click the update button, and the instructions are given to the user via the code installed in the IoX, same source as the code that beeps the polISY and eISY, not from some website page. When the code changed to beep six times, the code to tell the user it should beep only 4 times could have been corrected to match. Now this error has been reported a few times for the last few years and yet nothing has been done to correct it. This should have taken less than 5 minutes to correct a piece of text inside IoX and appears to be an error reported many times that has caused a lot of confusion for users attempting to upgrade. If you are going to report errors via a beep count system it needs to be accurate or at least tended to, when bugs are reported. Otherwise, remove the beep system and stop confusing the users and possibly causing more problems. I don't expect a perfect ISY but it gets a little tiring when bugs persist for 20 and 30 releases that are so easily corrected. Cripes, many of the bugs still exist from the upgrade to V5, from V4 (remember 5 years ago?). I have already dumped my polisy once due to so many operational bugs and went back to my ISY994. Looking forward, I have given polisy another chance (code conversion was a bitch) but it may have been a mistake again after many years of "debugging" something that is still less reliable than ISY994 was.

The instruction is in the code and it disagrees with the actual code. It may cause people factory reset their ISYs when it doesn't report as stated in the code. For the 5 .inured it takes to correct this it may avoid days of co fusion from supporting users. This has become quite usual lately as UDI travels down do many new ventures. The trail of poop is starting to become hurdles. Sent from my SM-G781W using Tapatalk

Yup..very iriitating

Update went fine, however none fo the existing non-Zwave bugs have been fixed for the last three years. Previous report Previous previous report

Separate lines with waits between them is more secure and more reliable than scenes. Scenes have no confirmation of signals and therefore no Insteon retries if no response is received. I use a combination of the techniques. For most groupings I use scenes to turn them off, but for middle of the night "if all else fails" I use individual Off lines as you demonstrated. You do need Waits between every second or third line to be 99.99999% successful though. However, having said that, I only have two Insteon controlled lights left. The rest are all WiFi bulbs now so I have very little need for any Insteon scenes any more. My WiFi NRbridge software creates it's own scene control appearance with very little delay between bulb operations. IOW: when I used a lot of Insteon lighting, I used Insteon scenes for human appearance (less popcorn effect) , and individual program lines for all other operations, giving better reliability.

Notifications still do not indicate properly and modulus arithmetic was never implemented properly since decimals were introduced in v5.0.1

Yes. If your devices were set up by any other method be sure to factory reset each device, and start fresh with linking them to your ISY. Then build your scenes from there. ISY will then install the links correctly and be able to manage them later .....and quite well also. Sent from my SM-G781W using Tapatalk

Thanks for your illuminating comments but it seems like my bulbs are all screwed.

lol WiFi bulbs get 1% brightness in any colour. Sent from my SM-G781W using Tapatalk

I use WiFi controlled LED RGBCW bulbs throughout using the MagicHome/LEDenet protocol. I have only two LED lamps that use Insteon LampLincs in my bedroom and they dim fine down to about 12% with better brands of bulbs. I have about 15 more LampLincs in my junk box currently. After I downsized I have never installed any SwitchLincs back into service as I use Alexa vocal control mostly now. If that fails they are all fully operable from a wall switch or a WiFi mobile app. No cloud required, just a router. If that also failed they will operate via BT on a similar app. I was going to implement Zwave also but after testing a few devices I decided against full Zwave expansion. They seem poorly implemented after Insteon experience. RGBCW bulbs run about $8 each now and come in various sizes up to 10W each. I have many RGBW 5m strips that are compatible, as well as two floor lamps that only do whites from 2500K to 6500K from the same apps and ISY software.

is your am and pm set correctly ? I've been fooled many times with that on other clocks. Sent from my SM-G781W using Tapatalk

How old is your router ? I had an ASUS router AC92u? that was short of memory and it started doing really strange things around the 51 devices mark. Unknown to me, ASUS doubled the NVRAM in the later released model. I spent a few years fighting with it before buying four new ones that all had bugs in them also. All my MH protocol bulbs and strips work 99% now. However I use my own software bridge. Sent from my SM-G781W using Tapatalk

...and variables can be cloned and synced together between ISYs/ polisys, and eISYs, easily with NRs triggered by variable value changes. If both devices can hear WiFi or Ethernet signals it's easy and it can be bidirectional also.

I think the local vs online is just inside the app. IIRC When the "online" bit is set in the request packet sent, the bulb doesn't respond with a confirmation, . This makes it faster for animations also. IIRC a long click on the device in some apps will get you the device settings. Some of the apps will not allow local control. I always had to use the fluxnet app to achieve no cloud connection.

Port 80 is always assumed by drivers when you do not specify, so maybe the drivers see the 80 and don't specify a port to conflict with the 8080 that they didn't know wasn't part of the IP address???

v5.5.5 installed and runs fine on my polisy AFAICT. Haven't seen any problems yet but no Zmatter or Zwave usage yet.

Flag @bmercier to see if he is aware or knows something about that. He may have a fix or at least want to know.

..and UDI likes to see, firsthand, some of the quirks that happen. It helps them improve things.

Did you try restarting the NSs in polisy? I had to do that every time in the past. My ecobee NS seems to have fixed that and heals like a trained dog now.

Add the port number to the IP address like this. 192.168.0.165:8080 I do not have a WC8 board anymore so I cannot verify this.

Put an AND pair of parentheses arround all your OR logic lines. It is in the upper edit box. If [ Time is 1:00:00AM Or Time is 2:00:00AM Or Time is 3:00:00AM Or Time is 4:00:00AM Or Time is 5:00:00AM Or Time is 6:00:00AM Or Time is 7:00:00AM Or Time is 8:00:00AM Or Time is 9:00:00AM Or Time is 10:00:00AM Or Time is 11:00:00AM Or Time is 12:00:00AM Or Time is 1:00:00PM Or Time is 2:00:00PM Or Time is 3:00:00PM Or Time is 4:00:00PM Or Time is 5:00:00PM Or Time is 6:00:00PM Or Time is 7:00:00PM Or Time is 8:00:00PM Or Time is 9:00:00PM Or Time is 10:00:00PM Or Time is 11:00:00PM Or Time is 12:00:00PM ] And $sMotionOff is 1 Then

No. It's a dynamic and constantly changing list. There are more selections than PG2 and many are free and most are only a few bucks. Sent from my SM-G781W using Tapatalk

It's a secret!