larryllix

Can't remember if I just powered it back up, loaded the old image back into it, or how it was done now. However, I had just moved and downsized a lot from a large home to an apartment and a lot of HVAC and security functions were not required any more, so I am not a good model to follow. The PLM is the worst problem as it has to totally reconfigured to talk to your ISY994. If you are using a different PLM then every Insteon device has to be factory reset and reconfigured for that PLM. If you have lots of battery devices it can take more than a full day. IOW: I don't recommend it at this point. I would tough it through with your polisy or eISY. If you cannot solve it, then open a ticket with UDI. Michel can log into your box and solve almost any problem. If he can't, it will become a priority for UDI to fix with a new version.

I could put it in the same box with my two ISY994s and keep them company. or Put it with your Apple II computer and monochrome monitor?

My reverse migration back to ISY994 was during the toddler time of polisy when features were non-existent and many more bugs were encountered. Since then I have gone back to polisy and abandoned my 2 ISY994s. Polisy now performs as well as ISY994 did so there would be no point in stepping back again, at this point. My beefs are still existing in both platforms now and minor AFAIK.

Yeah, we are waiting to see what QUebec and New York does about it because if we have a different clock time than them, the world might stop. Geeeshhhh! ...No. You go first then we'll do it... no you, I dare you!... no you....

I would encourage every user to petition their politicians to stop this DST nonsense. Many locations have. Just wait until fall, when your ISY has two 1:30 AMs to deal with in the same night. Then what? What will a program loop that executes every ten minutes do? What about a program that executes at 1:45 AM do? 2:00 AM? This will never be working properly for all program logic.

Oh he's good, but send money to me at .....

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.