larryllix

After bricking two polisys with the latest upgrade I have noticed a few different lighting devices turning on at random in the middle of the night. Now I have transferred back to my ISY994 and noticed some still happening. Unplugged the "not-quite functioning" polisy and the random events have stopped. Not 100% yet, and time will prove it, one way or another but, WoLs didn't work at all, still modulus function errors on fractional variable values (existing from ISY994), and internal time clocks are still offset by double the UTC offset. I have found work-arounds for most of it but the random stuff on WiFi bulbs and Insteon Switchlincs had me perturbed. Those I didn;t know about until switching back to ISY994 again (and another f%$ckin' days work and still finding upgrades that I have to recreate in my head ). Currently on hold for commitment point again, until better successes are heard consistently here. IIRC the original IoP was less buggy and no way to undo upgrades yet.

While that seems to work well, once his routines are all destroyed they won't heal automatically and the routines will need to be touched up. Sent from my SM-G781W using Tapatalk

Is it zWave? That's the way all my limited experience with zWave has been so far. However, I found parameters that can control what power levels my devices will start reporting changes at. Most of these settings were not made user friendly by UDI updates and reading the tech manuals becomes necessary to make some zWave modules useful. Once you discover how and write a program to send the coded numeric messages the devices will act more like Event triggered devices, not needing queries constantly. Sent from my SM-G781W using Tapatalk

If you disconnect and then reconnect your ISY skill the pseudo devices you have created will have disappeared from existence and you will have to edit each routine, reconnect each device as a trigger and re-enable each Routine. Some have had success with disabling their ISY skill for a very short time before the updating process in the Alexa app wakes up and "ruins" the Routine triggers.

Then you have noise interfering with your communications. You will need to find the noise source and eliminate or reduce it first. Sent from my SM-G781W using Tapatalk

I haven't noticed a lot of rain triggers. However snow flakes will trigger the motion sensors as fast as the MS shuts off. Typically MS lights are on 89 to 90 % of the time while it is snowing. When the sensitivity is turned down lights typically will not respond to a human further than about 8 to 10 feet away. When visible light cameras with iR illumination see snow, a continuous sheet of moving white flakes on the front row are all you will ever see. They seem to glow in the dark and blind everything else. A cam in my garage sees the reflective strip on my snowblower hood and the rest of the view goes blank in the garage with iR illumination. I have cover the reflective strips or anything shiny metal or all the cams go blind to everything else. Possibly the HDR technique better android cams have now, with two different technology sensors could make a difference but then who wants to pay 500 or 600 dollars for every cam? Sent from my SM-G781W using Tapatalk

The cams using iR illumination attract many wild animals that see by iR. Lights up their world. Sent from my SM-G781W using Tapatalk

Looks like the motion sensing would be a waste of money here. There is a reason they use iR. Mine would always be on 24 x 7 with such sensitive settings, or they would see nothing at all at night, unless the moon moving triggered them. As it is using iR mine blink on and off all night with every snow flake and wisp of wind during temperature changes. My 8 cams are mostly disabled for motion if they are outside. Who can look through 20 to 30 events per day x 8 cams? My inside MSes are close to flawless though. They use iR. Sent from my SM-G781W using Tapatalk

Keep in mind that top end cameras use a separate motion sensors to detect motion. Visible light is not a good medium to detect motion, thus the usage of the iR spectrum in most motion detectors. Prepare for many false alarms.

I have read your post three or four times now. Maybe it is my accent or your font, but I still don't understand what you mean exactly.....j/k

There are two directions of "connection". Are you having trouble with the status getting into ISY, trouble with controlling things from ISY, or both? I believe the "connected" you see in PG2 is the connection to the end device and not related to ISY.

Are you running IoP or an ISY994? I had several random lights go on with IoP but they weren't repetitive, except for one particular light / scene. wrote it off to an OnOffLinc that went bad a few years ago and marked it for death this time. From your log, I see a lot of action around yur garage door system. I would try unplugging it (them) for a day and see what happens. I have two GDO from different technologies and they both interfered with my Insteon signals and HA. The latest one with DC motor and battery backup, drove my HA down to about 10% reliability and gave me the clue what was happening for the last few years. Two FilterLincs resolved those problems.

Since the beginning of IoP, mine originally sowed incorrect times and couldn't set time zones or lat/long properly. However UDI corrected that on the surface and all showed properly, but the internal time clocks were never correct and all based on being 5 hours out. [minutes since start of day], sunrise and sunset parameters in programs were all off by 5 hours. Also events, and variable change times were recorded by the same 5 hour off clock. When writing variable values manually, the times were correct. A ticket was opened on this issue by me and possibly several others so a fix should be coming soon, hopefully. With many other MAJOR problems, based on the last upgrade I gave up and went back to ISY994 and polyglot on RPi 3, for now.

Yeah, polyglot-v2 works just fine on a RPi 3. There is an install script on the github website that will do the whole thing for you. https://github.com/Einstein42/udi-polyglotv2 However I have found with three different installations it sets up some parameters incorrectly and the instructions for the .env parameter override file are incorrectly identified and have caused me a lot of grief over the years. The descriptions of the parameters are wrong and despite complaining they remian incorrect for the last few years. It appears to install Node server configurations in ISY994 with port 443 while the Polyglot node server expects port 3000. Not sure any more but HTTPS may be disabled in Polyglot and enabled inside the ISY NS configurations. None of my installations have ever functioned out of the box. The status will update and fool you but the controls never have worked. Here is a .env file with some corrections (in text descriptions) I have discovered after many weeks of hair pulling. Instructions to create it are found in the linked github page above, but I have corrected a few important lines. Biggest problem is many parameters affect two factors and not one as described in the github descriptions. # Overrides the IP address Polyglot listens on the local machine. #BIND_IP='192.168.0.163' # Overrides the IP address Polyglot tells ISY to send node commands HOST_IP='192.168.0.163' # Overrides the port Polyglot listens on for its webpage service & ISY control interface. HOST_PORT='3000' # Overrides the default mode HTTPS for Polyglot webpage service & ISY control interface. USE_HTTPS=false # Username used to login to the ISY. #ISY_USERNAME='admin' # Password used to login to the ISY. Careful this is clear text, I wouldn't recommend setting this here. #ISY_PASSWORD='password' # ISY IP address. This is automatically discovered on the initial run of Polyglot if you are on the same network. If you have multiple you can update it on the settings page of the frontend, or override it here. #ISY_HOST='192.168.0.161' # ISY Port #ISY_PORT='80' # ISY HTTPS: True/False This isn't fully tested so beware HTTPS at the moment. #ISY_HTTPS=false # MQTT Host is the IP address of the host running a MQTT server. This is built in to Polyglot so you won't need this unless you'd prefer an external MQTT server. #MQTT_HOST='127.0.0.1' # MQTT Port is the port used to connect to the MQTT server. Default is 1883 #MQTT_PORT='1883' # URI to access MongoDB. You might need this if you have an off-box Mongo instance. #MONGO_URI='mongodb://localhost:27017/' # To enable debug logging set the NODE_ENV override to 'development' #NODE_ENV='development' # To enable Custom SSL Certificates CUSTOM_SSL=true # Enable Beta Software Updates USE_BETA=true Now your Node server configuration in ISY needs to match and has never done so in my installs, so far (yesterday was the latest 24 hours of hair pulling). The red circled parameters need to match what is found in the polygot .env parameters override file (above). You will need to create this file from scratch. It probably doesn't exit and parameters are assumed incorrectly from my script usages. Best of luck. RPi 3 works just fine and may be a good stop-gap until the confusion falls aside and polisy is more reliable.

I think it is not the bios firmware, but rather the size of the early bios chips not being able accommodate both bioses until the flash burning is done and the old bios can be erased....or hidden? Sent from my SM-G781W using Tapatalk

Yup. Software tries and retries to erase chip using techniques for 4K, 8k, 16k, 32k etc.. size chips. When it cannot find a space left in the chip the flash process cannot continue. It then reports that the version 100 needs to be replaced. Then a partial v5.4 1 becomes unstable and refuses to function properly. Likely if I could reload an older IoP I could get back up but it contained so many crippling bugs, so I tried my polisy spare. It seemed to function for a while but got bad when I rebooted it. That one upgraded the bios ok but no previous version is available to manually load. Back to ISY994. In the words of Johann Sebastian.... ...I'll be Bach! Sent from my SM-G781W using Tapatalk

'covered patio'? Shouldn't that be 'alligator fencing'? Sent from my SM-G781W using Tapatalk

Yup. Version 100 appears to be the shortcut message the Bios writing code was installed with to describe v1.0.0 when the bios upgrade fails. Sent from my SM-G781W using Tapatalk

Thanks Michel. I am getting my ISY994 back working for now. PG2 is giving me trouble though. I have had to implement the .env file again to force ports to where they should be though. Even the webport was not configured as stated in the docs but now it responds to a browser. Only snag I have left is ISY994 cannot issue commands without failing and there seem to be no way to discover what port should be used. 443 doesn't function. Statuses are all reporting into ISY OK but no commands. Been here before. With polisy, I will wait until the BIOS chip comes and see how it performs before attempting a long days work to switch back again. For my polisy-spare, which reported the BIOS upgrade OK, I will wait until I can get a complete image from factory reset. I don't know what kind of mess is inside. Somebody sold it cheaply and it appears to be a run away for the same reason. When it refused to receive Insteon data via USB PLM, I figured some hardware crashing is going on. Frustrating, but time should figure it out. Thanks again.

Yeah. I found it referred to by both version names in different spots. I assumed V100 was v1.0.0.

Apparently there are two BIOS chip sockets with a selector switch beside them. Original sounds welded in and the other replacement coming has a socket for it. When the update software script runs it attempts t run some erasing software for a 4KB space, then tries 8K, 16K, 32K and 64KB? When they all fail, the software script gives up. Mine reports there is no more space left in the chip...it's bricked, so a new chip is being sent. I am not sure if the chip size was just too small to hold the replacement BIOS firmware until burned into the eprom or how that works. I think once you get v5.4.1 installed and your BIOS isn't upgraded the interlocking UDI tried to install locks you out. With a good BIOS one should be able to stop all the IoP stuff and reflash the bios from there, or downgrade the IoP firmware. Mine had way too many serious bugs to be kept though.

Make sure you do not have the version 100 of the BIOS chip. I have one polisy bricked here, waiting for a new BIOS chip, and a used polisy that UDI got working, but it slowly degraded, losing it's UUID, then Port won't connect and PG2/PG3 will not connect, and later it stopped accessing my PLM properly. I bought it used so who knows, even though the BIOS chip shows updated. Currently going back to ISY994 but cannot get install script to show the polyglot port number to set it up on a RPi again. 3000 doesn't works despite all indications it is running and should. 48-60 hours of hair pulling has me out of the polisy game for a long time now. I've had enough.

Anybody seeing their polisy uuid reseting to 00 00:00:00:00 01 ? When this happens ISY portal disconnects because it connects by uuid. Michel fixed that with a udx update or correction but it has since gone back to the 01 again.... on both polisys too. Too weird. My bad chip spare polisy has just been sitting untouched. Sent from my SM-G781W using Tapatalk

Thanks! Sounds exactly what I was seeing. Michel remote sessioned in, and found a bricked BIOS chip (old version 100). However I have a spare polisy and have flipped over to it (Michel did). Works fairly well but am currently trying to get PG3 working, and have given up with it refusing to add or find any ISY, and refusing to accept and new settings due to "no backend connection. Settings unchanged". I tried Edge browser and things seemed a little different, so I disabled firewall things for Firefox (GD MS!). Didn;t make any difference, so far. I am currently deleting PG3 and attempting to return to PG2, where it worked well for a few years now. I wonder if IoP v5.4.1 will allow that at all.

Thanks! "Version 100 is old and needs to be updated"