Support thread for: ISY on Polisy (IoP) v5.4.1 (March 8, 2022)

[mmb]

22 minutes ago, larryllix said:

Sounds exactly what I was seeing. Michel remote sessioned in, and found a bricked BIOS chip (old version 100).

@larryllix This is what I see in my log file referencing bios version 100

Tue Mar  8 16:30:00 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios version 100 is old and needs to be upgraded  
Tue Mar  8 16:30:00 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: starting forcing bios update  
Tue Mar  8 16:30:00 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices  
Tue Mar  8 16:30:00 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy  
Tue Mar  8 16:30:00 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0  
 

[...]

Tue Mar  8 16:50:14 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy  
Tue Mar  8 16:50:14 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.1.3  
Tue Mar  8 16:50:14 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios has the correct version  
Tue Mar  8 16:50:14 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: OS Version 1303  
Tue Mar  8 16:50:14 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: tpm2-tss is installed, checking version   
Tue Mar  8 16:50:14 MST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: tpm2-tss has the correct version 245  
 

[larryllix]

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

[brians]

On 3/8/2022 at 4:30 PM, brians said:

I did and does not display correct version. I restarted entire Polisy also.

 

Today I went into PG2 and checked for Polisy updates, said it found 8 and then I updated Polisy. I waited a bit and restarted PG3. Now PG3 shows correct IoP version 5.4.1, and also a couple Nodeservers updated that would not before.

This is not very intuitive - using a "deprecated" PG2 interface to update Polisy and PG3 while there is no update option in PG3. The update 5.4.1 in IoP did not seem to do these updates and is that just supposed to update IoP and nothing else? We are told that ssh updates will be a thing of the past. I anticipate that all the updates are going to be consolidated into one area one day.

 

 

[bpwwer]

5 minutes ago, brians said:

Today I went into PG2 and checked for Polisy updates, said it found 8 and then I updated Polisy. I waited a bit and restarted PG3. Now PG3 shows correct IoP version 5.4.1, and also a couple Nodeservers updated that would not before.

This is not very intuitive - using a "deprecated" PG2 interface to update Polisy and PG3 while there is no update option in PG3. The update 5.4.1 in IoP did not seem to do these updates and is that just supposed to update IoP and nothing else? We are told that ssh updates will be a thing of the past. I anticipate that all the updates are going to be consolidated into one area one day.

Yes, this definitely needs some work.   The process that I've been using to notify developers and testers of new PG3 is a stop-gap solution.  

[DennisC]

@Michel Kohanim

I updated this morning to IoP v5.4.1.1, udx is v2.6.0_7, and PG3 is v3.0.45, using ssh commands. After the update, I saw the following notice:

"you can disable uftdi driver by adding isy_load_uftdi=NO in /etc/rc.conf

 7    1 0xffffffff81d12000     8320 uftdi.ko"

Is this something that needs to be done?

[wrj0]

Successfully upgraded from 5.4.0 to 5.4.1 using Polisy front panel push button.  AC and PG2 appear to be functioning without any issues.  Log shows bios ver: 1.1.3, after successful installation of UEFI.

[mmb]

2 hours ago, DennisC said:

@Michel Kohanim

I updated this morning to IoP v5.4.1.1, udx is v2.6.0_7, and PG3 is v3.0.45, using ssh commands. After the update, I saw the following notice:

"you can disable uftdi driver by adding isy_load_uftdi=NO in /etc/rc.conf

 7    1 0xffffffff81d12000     8320 uftdi.ko"

Is this something that needs to be done?

@DennisC A normal message.

uftdi -- USB support for serial adapters based on the FTDI	family of USB
     serial adapter chips.

As pointed out previously do a "sudo cat /var/udx/logs/log | grep bios" using SSH to see if you updated properly.

[DennisC]

2 hours ago, mmb said:

@DennisC A normal message.

uftdi -- USB support for serial adapters based on the FTDI	family of USB
     serial adapter chips.

As pointed out previously do a "sudo cat /var/udx/logs/log | grep bios" using SSH to see if you updated properly.

I am not currently at that site and don't leave ssh active for remote sessions. However, I did run that command earlier in the week after the previous upgrade and all was good.

I am trying to determine if the command needs to be run, or to leave it alone. For know, it will need to stay the way it is.

[asbril]

I would like to share how I have  "connected" my IoP to my ISY.

As I am full Zwave and had some issues with my ISY setup, a few weeks ago I moved  the Zwave devices in two rooms from ISY to IoP.  I will not move my whole setup to IoP until there is the migration tool, and I also use some nodeservers that are not yet on PG3.

In our master bedroom I have a Homeseer 200 switch that I have programmed so that each of the 7 sentinels show red when the lights in a zone of our home are ON.  When I moved 2 rooms to IoP, those rooms would no longer show on the Homeseer switch sentinel.

I realized that the Kasa Node server can be added to both ISY and IoP and  when the status of Kasa switches change in IoP they also change in ISY, and vice versa. 

I got some Kasa switches that I programmed in IoP to go On or OFF depending on the status of the lights in the 2 rooms. In my ISY I programmed so that when the dedicated Kasa switch is on, the sentinel will go red (or green when lights are off).  

There may be more sophisticated ways to achieve my objective, but this works !  

[Jimbo.Automates]

On 3/9/2022 at 2:07 PM, simplextech said:

@larryllix yeah sounds familiar.  Likely same old chip as I have one of the very early release Polisy boxes.

So what is the fix?  Something we can do before installing to not have the same problem?  

[mmb]

7 minutes ago, JimboAutomates said:

So what is the fix?  Something we can do before installing to not have the same problem?  

@JimboAutomates As an early adopter I expect a few bumps but nothing so far to worry about.

I ordered mine soon after launch...

[Jimbo.Automates]

@JimboAutomates As an early adopter I expect a few bumps but nothing so far to worry about.
I ordered mine soon after launch...

Yes of course I realize that. I just don't want to get stuck in a boot loop like @simplextech since I have 3 very early versions as well. What can be done to prevent that with the original ones was my question.

Sent from my Pixel 6 Pro using Tapatalk

[larryllix]

18 minutes ago, JimboAutomates said:

So what is the fix?  Something we can do before installing to not have the same problem?  

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.

Edited March 11, 2022 by larryllix

[Jimbo.Automates]

11 minutes ago, larryllix said:

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.

Well, I did, but looks like it upgraded last time succesfully?

Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios version 100 is old and needs to be upgraded
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: starting forcing bios update
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0
Tue Mar  8 17:27:48 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios update ... rebooting
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.1.3
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios has the correct version

 

[stillwater]

@larryllix I feel your pain.  I am grateful to you and others on the "bleeding edge" -- will accelerate stable IoP for everyone else. 

 I hesitated to comment because I am out of my depth but in case it affects others my Polisy log shows successful updating to Bios ver 1.1.3 from ver 1.0.0 despite a previous message saying "bios version 100 is old and needs to be updated."   My polisy is very new and so there may indeed be some hardware difference but had I just read your post and had I not already updated I would have assumed based on my log  that I had the "version 100 bios chip" you speak of and would have been fearful about upgrading.     

I am sure UDI will provide info once they understand the problem.  

PS My log looks like that of  @JimboAutomates

Edited March 11, 2022 by stillwater
added reference to post that was made while I was writing mine.

[simplextech]

43 minutes ago, JimboAutomates said:

So what is the fix?  Something we can do before installing to not have the same problem?  

I worked with @Michel Kohanimthis afternoon and tried running a manual update but both failed in my case.  He's sending me something in the mail.  Not sure if it's a pin connected flasher for the chip or a new Polisy.  It'll be a surprise ?

[mmb]

29 minutes ago, larryllix said:

Make sure you do not have the version 100 of the BIOS chip.

@larryllixI can't find any reference of the "version 100" but I see a reference to bios ver: 1.0.0  which was updated to bios ver: 1.1.3  - is this what you're referring to?

Let me know and I'll have a look for it...

[larryllix]

3 minutes ago, simplextech said:

I worked with @Michel Kohanimthis afternoon and tried running a manual update but both failed in my case.  He's sending me something in the mail.  Not sure if it's a pin connected flasher for the chip or a new Polisy.  It'll be a surprise ?

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.

[larryllix]

4 minutes ago, mmb said:

@larryllixI can't find any reference of the "version 100" but I see a reference to bios ver: 1.0.0  which was updated to bios ver: 1.1.3  - is this what you're referring to?

Let me know and I'll have a look for it...

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

[smileyw]

I just want to say that I think this is the first time ever in my ISY lifetime that I just simply told the UI to do an automatic upgrade.  It has always been manual updates to various beta versions.  It worked, and updated the BIOS too as it was supposed to.

[DennisC]

9 hours ago, larryllix said:

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.

It's been a long time since I ran Polyglot on a RPI and I don't remember how to set up port number. I'm not sure if this will help, but I think PG2 was using port 443.

[glarsen]

11 hours ago, JimboAutomates said:

Well, I did, but looks like it upgraded last time succesfully?

Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios version 100 is old and needs to be upgraded
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: starting forcing bios update
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy
Tue Mar  8 17:27:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.0.0
Tue Mar  8 17:27:48 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios update ... rebooting
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios mfr: Universal Devices
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios product: Polisy
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios ver: 1.1.3
Tue Mar  8 17:29:06 PST 2022|/usr/local/etc/udx.d/static/udx_startup.sh: bios has the correct version

 

Yes, mine upgraded successfully too, showing the same log entries. My Polisy is also one of the early ones (geek release ?)

Edited March 11, 2022 by glarsen

[Michel Kohanim]

@JimboAutomates, the earliest versions might have an issue depending on what's been flashed. I would say the first 30 units in the early batch might have this issue. In addition, the flash update might take up to 5 minutes and, in at least one instance, the customer rebooted during the flash update (the 2 and 3 light blink while updating the flash). The good news is that, even if the flash is destroyed, there's a flash chip that you can plugin. The bad news is that it'll take time.

@larryllix, I am sorry. When I did a remote session to your unit (spare), rc.conf had been modified by the original owner not to include polyglot_enable="YES" (it was changed to NO) and mongod_enable="YES" ... udx (the thing that talks to hardware) requires both of these to be running. If they don't run, udx doesn't have the cert to communicate with anything else including ISY. That's why you would get 0000 as the UUID. Once I left the session, everything was working. What changed thereafter was changing the IP address and most probably a reboot. Perhaps the original owner has a script that disables those and which runs after reboot?

With kind regards,
Michel

[larryllix]

23 minutes ago, Michel Kohanim said:

@JimboAutomates, the earliest versions might have an issue depending on what's been flashed. I would say the first 30 units in the early batch might have this issue. In addition, the flash update might take up to 5 minutes and, in at least one instance, the customer rebooted during the flash update (the 2 and 3 light blink while updating the flash). The good news is that, even if the flash is destroyed, there's a flash chip that you can plugin. The bad news is that it'll take time.

@larryllix, I am sorry. When I did a remote session to your unit (spare), rc.conf had been modified by the original owner not to include polyglot_enable="YES" (it was changed to NO) and mongod_enable="YES" ... udx (the thing that talks to hardware) requires both of these to be running. If they don't run, udx doesn't have the cert to communicate with anything else including ISY. That's why you would get 0000 as the UUID. Once I left the session, everything was working. What changed thereafter was changing the IP address and most probably a reboot. Perhaps the original owner has a script that disables those and which runs after reboot?

With kind regards,
Michel

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.

[tmorse305]

I'm running 5.3.0 and 3.0.41.  I saw the upgrade message in the AC regarding the newer version for IoP.  I'm so glad I checked the forum before pushing the button.  I have version 100 of the Bios.  Should I just wait for the dust to settle a little more before upgrading?  One concern, I know there are new versions of the NSs I'm using out there.  Some require 5.4.0.  If I have to reboot a NS or Polisy will the NS update even though it's not compatible with my current version of IoP?

Thank you