Release 5.1.0 (RC2) is now available

jec6613 · August 4, 2020

8 hours ago, kevinkaz said:

Upgraded yesterday. After syncing zwave nodes all then renaming the devices back to my method most are functioning but the two Aeon Labs MultiSensor devices I must perform a zwave synchronize to update the ISY..

Event viewer set to level 3

Log is only one zwave device but both exhibit the same issue.

Aeon Labs MultiSensor L3.txt 4.92 kB · 4 downloads

Message when only PIR enabled

Mon 08/03/2020 13:59:01 : [ZWAVE-RX ZW119_1] [20/01] Basic Set val=0xFF ACK,AUTO,EXPLORE From=0x77

Message after 20 second timeout

Mon 08/03/2020 14:02:11 : [ZWAVE-RX ZW119_1] [20/01] Basic Set val=0x00 ACK,AUTO,EXPLORE From=0x77

ISY status for device does not update.

I am also seeing this exact issue on three multisensors ... one secure and two non.

Edit: Update, they now work after an ISY reboot. Not sure what was going on there.

Edited August 4, 2020 by jec6613

Schlyguy · August 4, 2020

I upgraded from 4.7.5 to 5.1.0 on Sunday. It's taken 2 days and a few restarts to get most routine programs back working again. One thing which doesn't seem to work are the multiple users - when I set a new User ID and PW for User ID #1 - the ISY doesn't record it - after restart - the User ID #1 comes up blank again. image.png.e293237cd122e609efff429c548ad70f.png

I have all my leak sensors working again - total of 8 - found one which had a dead battery, and am now waiting for 2 of the 8 to produce a heartbeat and that will close out the leak sensors. Getting used to the small interface changes - I can see this will take some fiddling - like the "click to verify" fields. Have sorted out a few programs which were not working properly - had to set on levels to 100% (from 0 for some reason) and they now seem to be functioning.... As I figure things out I'll post updates.

MrBill · August 4, 2020

30 minutes ago, Schlyguy said:

One thing which doesn't seem to work are the multiple users - when I set a new User ID and PW for User ID #1 - the ISY doesn't record it - after restart - the User ID #1 comes up blank again.

Correct. It doesn't work. UDI never comments if that is a bug, or they exist for a future use reason we haven't been told. You can only set the admin user name and password, the rest don't work.

Edited August 4, 2020 by MrBill

drich · August 4, 2020

16 hours ago, jec6613 said:

I am also seeing this exact issue on three multisensors ... one secure and two non.

Edit: Update, they now work after an ISY reboot. Not sure what was going on there.

Same problem here. Both of my Aeotec sensors had to be synchronized in order to get them talking to the ISY again. This also deleted them and recreated them, which meant I had to rename them all over again. It took me three tries to get one of them to resync, I almost had to climb a ladder to pull it down and move it closer to the ISY (IMHO, the antenna on the 500 series dongle is almost useless).

kevinkaz · August 4, 2020

Aeon Labs Appliance switch Model DSC061606-ZWUS zwave synchronize command nuisance:

Device identifies & functions correctly

Issuing a device zwave synchronize command will:

1-> move the device to the master folder, from a sub-folder

2-> then the device will be renamed to the to the default name

3-> the device is removed from all scenes

Edited August 4, 2020 by kevinkaz
added third issue

gviliunas · August 4, 2020

Dome Window Sensor works after v5.1.0 upgrade but stuck in "1010 state" - RESOLVED

EDIT 08/05/2020 - In the end, this was too easy. After excluding, factory reset, including, and "fiddling" with parameters, the final solution to this was just to power-cycle ISY (a software reboot was not enough). All device icons are now correct and devices work properly

-------------

I have 5 Dome Z-Wave window sensors that would not update their state after the ISY v5.1.0 upgrade. I tried to Synchronize in ISY but could not time the sensor wakeup to make this happen. It was just easier to exclude and re-include each of these. After re-inclusion and re-mapping into their appropriate programs all 5 of the sensors worked. At that time, none of the sensors are in 1010 State.

Later, I logged into the AC and noticed the one sensor in a "1010 State." The sensor is working and reporting its state correctly but after many attempts, I can't fix the 1010 State.

I have tried:

1. Excluding, factory resetting, and re-including the sensor. (Also, new battery installed). After doing this, initially, the sensor is in normal state and works normally. If I close the AC and re-open this later, this, and only this, sensor will be in 1010 state.

2. Excluding, performing backup and restore on the ISY (2n generation) dongle then re-inclusion of the sensor

3. After removing the sensor from all other programs, I wrote a program that just writes changes to this sensor upon the sensor in Alarm mode (and captured a Level-3 Event log)

Verified that "Write Updates to Battery-Powered devices is enabled.

The sensor is sensing the window properly. The OCD in me would just like to resolve this 1010 issue.

Note: The sensor is currently ZW123. I took a screenshot of this device's parameters before the last exclude/include, when it was ZW122

Edited August 5, 2020 by gviliunas

larryllix · August 4, 2020

51 minutes ago, gviliunas said:

Dome Window Sensor works after v5.1.0 upgrade but stuck in "1010 state"

I have 5 Dome Z-Wave window sensors that would not update their state after the ISY v5.1.0 upgrade. I tried to Synchronize in ISY but could not time the sensor wakeup to make this happen. It was just easier to exclude and re-include each of these. After re-inclusion and re-mapping into their appropriate programs all 5 of the sensors worked. At that time, none of the sensors are in 1010 State.

Later, I logged into the AC and noticed the one sensor in a "1010 State." The sensor is working and reporting its state correctly but after many attempts, I can't fix the 1010 State.

I have tried:

1. Excluding, factory resetting, and re-including the sensor. (Also, new battery installed). After doing this, initially, the sensor is in normal state and works normally. If I close the AC and re-open this later, this, and only this, sensor will be in 1010 state.

2. Excluding, performing backup and restore on the ISY (2n generation) dongle then re-inclusion of the sensor

3. After removing the sensor from all other programs, I wrote a program that just writes changes to this sensor upon the sensor in Alarm mode (and captured a Level-3 Event log)

Verified that "Write Updates to Battery-Powered devices is enabled.

The sensor is sensing the window properly. The OCD in me would just like to resolve this 1010 issue.

Note: The sensor is currently ZW123. I took a screenshot of this device's parameters before the last exclude/include, when it was ZW122

With Insteon, I have turned off Battery Writes and disabled my folder Battery Device AutoUpdating.

You can do the right click|write updates manually, when you need them. The automatic Use my open time window method was causing my ISY to hang and bog down until the next even caused it to correct itself.

OTOH, ISY scene modifiers were attempting to write to battery devices in v5.0.16C. I assume that was fixed in V5.1.0 so this problem may not exist now.

51 minutes ago, gviliunas said:

gviliunas · August 4, 2020

2 minutes ago, larryllix said:

You can do the right click|write updates manually, when you need them.

@larryllix, Yes, I tried that but the sensor needs to be awake. I followed the manual which instructed me to hold the button for 0.5 second, release and see a "flash." I saw the flash confirming the sensor to be awake and then tried the right-click manual update route and then received a can't communicate with the device message. Maybe the manual method doesn't work with Z-Wave devices anymore???

Anyway, I may have found a fix to my original 1010 problem. I just power-cycled ISY and my 1010s are gone. I will wait 12hr (the stated wake-up time for these sensors) before declaring victory. If this works, I'll update my original post.

Thanks for your advice.

gviliunas · August 5, 2020

@larryllix I can declare victory over 1010. All it took was to power-cycle ISY. A software reset was not enough to restart the Z-Wave dongle.

larryllix · August 5, 2020

37 minutes ago, gviliunas said:

@larryllix I can declare victory over 1010. All it took was to power-cycle ISY. A software reset was not enough to restart the Z-Wave dongle.

Nice! I am glad I am not 1010 anymore!

* 10102

Edited August 5, 2020 by larryllix

Schlyguy · August 5, 2020

I've had 2 incidents now where my laptop internet connection has been interrupted while running the ISY admin console - it may have been associated with starting a VPN session for work while the admin console is open. In each case, I've had to close all my windows and restart to get the network adapter / local wifi functioning again. FWIW.

madmartian · August 5, 2020

Upgraded today in hopes of fixing the "always green 10101" problem for some z-wave battery devices. At first the problem was worse - with "cannot communicate with" errors. I tried synching and Update Neighbors for individual devices, but that did not fix the problem. I removed and re-added the devices - THAT fixed the problem for two of the three devices. Sadly my smoke detector still has the green 10101 even after removing and re-adding, and then later changes to "!" with a "cannot communicate" error.

image.png.d3170bb4eeb0b1aa827f3c9d4a9224b1.png

Problem was happening with these battery devices:

Fibaro The Button FGPB-101 v3.2 US (fixed by removing/re-adding)
Fibaro Motion Sensor FGMS-001 ZW5 v3.3 US (fixed by removing/re-adding)
First Alert Smoke/CO Alarm ZCOMBO (NOT fixed by removing/re-adding)

Problem was NOT happening with these battery devices:

GoControl Remote WA00Z-1
NodOn Remote CRC-3US-6
Dome Mouser
Ecolink Flood and Freeze Sensor FLF-ZWAVE5-ECO

Things I tried before removing/re-adding:

Disabled automatically putting devices back to sleep
Put all devices within 2 feet of the ISY
Triggered the devices so they would not be sleeping
Synchronized individual z-wave devices
Ran "Update Neighbors" on individual devices
Tried "Query" and "Write Updates" for individual devices

larryllix · August 5, 2020

On 8/4/2020 at 3:57 PM, gviliunas said:

@larryllix, Yes, I tried that but the sensor needs to be awake. I followed the manual which instructed me to hold the button for 0.5 second, release and see a "flash." I saw the flash confirming the sensor to be awake and then tried the right-click manual update route and then received a can't communicate with the device message. Maybe the manual method doesn't work with Z-Wave devices anymore???

Anyway, I may have found a fix to my original 1010 problem. I just power-cycled ISY and my 1010s are gone. I will wait 12hr (the stated wake-up time for these sensors) before declaring victory. If this works, I'll update my original post.

Thanks for your advice.

It seems v5.1.0 has introduced another problem with this item. Adding another MS 1 I found trouble manually updating the device, even in linking mode. Remembering I have the Battery Write option disabled, I re-enabled it so I could manually write the options back to the MS. What a mistake. Now I have about 5 MSes with green 1011s beside them and lots of constant busy boxes in admin console.

I haven't experimented to see if UDI fixed this problem with v5.1.0, but I thought I had all my owing battery device writes cleared out before I disabled the delayed "Battery Write" option, a few days ago. If I cannot find a workaround for this bug, I will be going back to v5.0.15 before this seeming botched attempt at making it work better was created. I use Insteon Scene adjustments each evening and morning to adjust the 100W equivalent bulbs in bedrooms to an acceptable level and this may indicate the write to battery devices upon scene updates, may not have been fixed in V5.1.0. More testing needed here.

This stuff grinds my ISY to a snail's pace as I have about 12 MSes that really exemplify the problem. **SIGH**

Edited August 5, 2020 by larryllix

larryllix · August 5, 2020

@Michel Kohanim @gviliunasV5.1.0 did not fix the Insteon Scene update battery write problem for Insteon. V5.1.0 scene updates still attempts to write to battery devices. This becomes a big problem as the logic doesn't work.

If "Battery Device Writes" is disabled, the system saves up the updates inside ISY, as designed.

Now,

if the Battery Writes option is ever enabled, by accident, or mistake, all the cached writes are attempted to be written to the battery devices, and can never be cleared from ISY. Rebooting ISY does NOT make ISY forget the cached writes and cannot be cleared with any normal means. hmmmm. I didn't try a power cycle yet but I just finished making the rounds to manually put about 6 MS 1s into linking mode, then disabled the option again. maybe later, if it happens again.
if programs are written to update battery devices, ISY attempts to not clog up the Insteon comm channel by spacing out writes with time gaps...good ploy. However, by the time ISY gets to most devices the "Linking Window" time has expired and more battery device updates become cached. This process eventually bogs ISY Insteon comm channels down, with owing updates and retries until ISY processing almost stops. The busy box never goes away in admin console.
if the delayed "Battery Write" option is enabled, manually writing updates to battery devices, from the admin console, are also blocked. This results in the user having to enable the "Battery Writes" option to accomplish the clear the cached updates and then all other owed updates get dumped on Insteon battery devices again, bogging the Insteon system again.

Please hurry with the bug fix!!!
Thanks!!

Edited August 5, 2020 by larryllix

DaveYHZ · August 6, 2020

Hope I'm not repeating a question, but when the 5.x goes in to production, will there be an upgrade advising tool for the 4.x crowd? I'm reading a lot of people spending a lot of time going through each scene and program to verify them one-at-a-time. I'm hoping that the deprecated functions will be listed in a "ToDo after you upgrade" list.

Apologies if this has been covered elsewhere.

Dave.

larryllix · August 6, 2020

14 hours ago, DaveYHZ said:

Hope I'm not repeating a question, but when the 5.x goes in to production, will there be an upgrade advising tool for the 4.x crowd? I'm reading a lot of people spending a lot of time going through each scene and program to verify them one-at-a-time. I'm hoping that the deprecated functions will be listed in a "ToDo after you upgrade" list.

Apologies if this has been covered elsewhere.

Dave.

I would advise to upgrade sooner than later. It isn't that bad for 99% of the people. Most, if not all, failed conversions, are marked with yellow icons for the programs devices that the auto process couldn't figure out. Inside the programs are explanations, usually with clues about what the original was. Scenes can sometimes drop devices or settings, but I think that has been improved. If all goes to hell in a handbasket you can always load your previous version back in, and restore your backup.

On average, the process takes about 10-15 minutes, plus the time to do a new and fresh V5 backup.

There are also ways to save your programs into a readable text file. Forgot the syntax, now.

Edited August 6, 2020 by larryllix

lilyoyo1 · August 6, 2020

7 hours ago, DaveYHZ said:

Hope I'm not repeating a question, but when the 5.x goes in to production, will there be an upgrade advising tool for the 4.x crowd? I'm reading a lot of people spending a lot of time going through each scene and program to verify them one-at-a-time. I'm hoping that the deprecated functions will be listed in a "ToDo after you upgrade" list.

Apologies if this has been covered elsewhere.

Dave.

Its been covered many times but while there are some that has had issues, there are many more without. Generally, if things go smoothly there isnt a reason to come on here. If a person has issues they come on here for help which is why it seems like a lot of people have issues. Its the nature of the game.

There probably wont be an upgrade tool available. Verifying things should be done anyway after any firmware update as a best practice to ensure everything functions to avoid nasty surprises later. Most likely your scenes themselves should be intact as they would be insteon only. The really good stuff involving scenes do not occur until 5.0 when zwave and other nodes such as hue are able to be added to them. As Larryllix alluded to, problem programs will have a yellow box next to them. I still re-save all of mine individually as I've found that sometimes they wont fire properly if I dont.

There are quite a few posts written by people who has had success that detailed what they did. I wont rehash those posts but will give a general run down of the main points

Make a back of of your current system. You should always do this regardless before upgrading to anything.

If you have zwave, back that up as well. The zwave backup is separate from the isy backup.

Take pictures, screen shots, or copy/paste your programs so that you can reference them later. Depending on the install size and program amount I use the first 2 methods as I can split screen what Im doing and go through each program 1 at a time to verify any changes I need to make.

Whitehambone · August 6, 2020

10 hours ago, DaveYHZ said:

Hope I'm not repeating a question, but when the 5.x goes in to production, will there be an upgrade advising tool for the 4.x crowd? I'm reading a lot of people spending a lot of time going through each scene and program to verify them one-at-a-time. I'm hoping that the deprecated functions will be listed in a "ToDo after you upgrade" list.

Apologies if this has been covered elsewhere.

Dave.

@DaveYHZ See if this post by @hart2hart helps.

sumguy · August 7, 2020

So far I haven't had any major problems with this release. The only issue I have had so far is with my Yale locks.

1. The settings button disappeared which used to allow me to edit the lock settings in a nice GUI. I know I can still edit the settings using the parameters but it was a convenient feature.

2. The "User Number" box isn't populating and I have rules based on which user unlocks the door. The user number is being seen in the Event Viewer but it is not displaying in the User Number window which the rules are based off of.

To try to fix this, I synchronized both locks. I also did a soft and hard reset of the ISY. I have attached a screenshot of the user number issue.

kevinkaz · August 7, 2020

So far all of the issues I have experiencing are with the Aeon Labs z-wave devices.

ZooZ z-wave motion sensors are functioning.

GE z-wave lamp module functioning.

Insteon device are functioning.

JTsao · August 8, 2020

Complete disaster over here - I upgraded and the few z-wave devices that I have stopped working (3 locks, 2 repeaters, 2 sirens, 1 motion detector switch) - I backed up, then tried to synchronize, didn't work - went back to v5.016C and restored the backup, tried multiple resets and still nothing works - any suggestions?

errors below:

at 08/08/2020 03:06:26 PM : [n003_harmonyctrl] DON 0

Sat 08/08/2020 03:06:26 PM : Completing initialization

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0062.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW025 Database error 12 /CONF/0062.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 62 (/CONF/0062.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0062.CZW

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0079.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW020 Database error 12 /CONF/0079.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 79 (/CONF/0079.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0079.CZW

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0080.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW019 Database error 12 /CONF/0080.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 80 (/CONF/0080.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0080.CZW

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0081.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW024 Database error 12 /CONF/0081.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 81 (/CONF/0081.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0081.CZW

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0086.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW027 Database error 12 /CONF/0086.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 86 (/CONF/0086.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0086.CZW

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0337.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW027 Database error 12 /CONF/0337.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 337 (/CONF/0337.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0337.CZW

Sat 08/08/2020 03:06:26 PM : [ZW-DB /CONF/0317.CZW] CCData buffer overflow

Sat 08/08/2020 03:06:26 PM : UZW027 Database error 12 /CONF/0317.CZW

Sat 08/08/2020 03:06:26 PM : Cannot load ZW database 317 (/CONF/0317.CZW)

Sat 08/08/2020 03:06:26 PM : UZW000 Database error 15 /CONF/0317.CZW