ok, thanks everyone 
have had to give up on V2.1.7.121, have had problems all today, rules not working, dashboards not loading, have rebooted at least 5 times and came home tonight to a dead hub nothing working.
Something in my setup does not like this version 
Will maybe try again, but at the moment i need the Christmas lights on 
Cheers
I have three hubs on v2.1.7.121 (actually 5 because my pair of development hubs are on that version, but don't DO any household actions.)
I'm not experiencing any issues AND because of my multiple hub architecture, I've been actively testing HubConnect v1.6 prior to it's release this morning. All of my Z-Devices (ZWave and Zigbee) are on two of my hubs, one for upstairs devices, one for downstairs. Both 'mirror' the majority of those devices to the 'coordinator' hub where I have all the 'outward facing' apps: Amazon Echo, Homebridge, Dashboard, Weather.
The point of all that is to say.. if there was a problem inherent in the platform, oh boy would I see it.
That's NOT to say you are not having a problem.. in no way am I implying that.. just that the upgrade itself can work. Have you tried the Soft Reset cycle? It seems to only take 5-6 minutes for me.
(I do it a lot as I wish to quickly go from one configuration to another. I made a backup of Configuration X and then Soft Reset back to no config, built it up and backed that up as Configuration Y. This way I can simply Soft Reset into either config in not much more than a reboot time.)
1 Like
Yes have done a soft reset when putting it back to V2.1.6 just to make sure
i was hoping to try and do some more testing, but with quite a few things failing, and the heating and Christmas lights not coming on, i just needed to get things stable again.
I only have the one hub, so maybe this is an excuse to get a second one
as long as everything is OK for a few days, ill give it a try again and see what happens.
Cheers
I too have has issues with my zwave sensors since the firmware update. I got a sensor working perfectly last night (simple lighting rule to turn on a light). It stopped working again this morning.
finally had time to look at why i was having problems with some z wave configurations.
from my testing it appears to be due to a change in the input command and a bug or change to the configuration command
in V2.1.6.x
def test(){
log.info("Command Int ${zwave.configurationV1.configurationSet(configurationValue: [1,2,3,4], parameterNumber: 3, size: 4).format()}")
log.info("Command Long ${zwave.configurationV1.configurationSet(configurationValue: [1L,2L,3L,4L], parameterNumber: 3, size: 4).format()}")
}
produces the following in the logs
Command Int 7004030401020304
Command Long 7004030401020304
both produce the same command
in V2.1.7.x
the same lines produce
Command Int 7004030401020304
Command Long 70040304
When a long is passed in, the data part of the message is lost.
There appears to be one more change that has brought this out
input "p3", "number", title:"Number 1 - 60", range:"1..60", defaultValue:10, required:false
settings.p3 is now a long when in 2.1.6.x it was an integer.
so when using something like
def integer2Array(value, size) {
switch(size) {
case 1:
[value & 0xFF]
break
case 2:
[(value >> 8) & 0xFF, value & 0xFF]
break
case 4:
[(value >> 24) & 0xFF, (value >> 16) & 0xFF, (value >> 8) & 0xFF, value & 0xFF]
break
}
}
it now returns an array of longs which then cause the configuration command to fail.
@mike.maxwell does this sound possible or am i barking up the wrong tree ?
Cheers
In 2.1.7 a few internal zwave classes were changed from groovy to java, this required casting most previously untyped array elements as Bytes.
There must be some difference in how groovy auto casts longs to bytes vs integers to bytes.
I don't beleive there were any changes to the data type of the ui preferences.
I've always cast preferences to integers when used with configuration set commands.
1 Like
Have rechecked the input change and your right, i'm seeing a long for both V2.1.6.x and V2.1.7.x now, not sure what i did before 
i guess there are two ways to workaround the issue
Use scaledConfigurationValue
or
always cast to an integer.
so an easy fix.
But i guess there must be some drivers out there that don't always do the above?
So it could cause problems for people later on when they try to change a parameter or add a new device
cheers
1 Like
There is really no reason not to use this.
Probably, but the change had to be made, and we aren't always going to be able to predict every conceivable repercussion.
Hi @mike.maxwell
Could this have affected the Aeon LED Bulb driver? When I updated to 2.1.7.127 I had issues with CT with these bulbs. I had to rollback to 2.1.6.118 to be able to control them properly.
First I've heard of this issue.
I totally understand sometimes changes have to made to progress, and in complex programmable systems it’s very difficult to test everything.
I was just trying to get the issue out there, issues people know about aren’t issues anymore
Cheers
3 Likes
@mike.maxwell
I won't submit a ticket until I get a chance to update again and try it out. The strange thing is that it wasn't affecting all my bulbs (4 out of 7) and some were immediate and others worked for a day and then failed.
Rolling back to 2.1.6 fixed them all immediately.
Hmmm, a platform change would act consistently, not work for a while then fail...
Unless you changed a parameter on the bulbs that failed after updating, then it wouldn’t be related to this issue.
@entire
I only upgraded, didn't change parameters or device drivers.
My regular RM rule (in place for about 7 months) to turn on a light at CT 2700, level 20 turned the bulb blue.
Another RM rule to turn on another bulb at CT 2700, level 100 also turned that bulb blue. The logs showed CT 2700 being sent.
Going back to 2.1.6 fixed everything. Maybe a DB corruption?
Db doesn't change when reverting to previous platform versions.
The issues you describe shouldn't have been caused by any of the zwave changes, I say shouldnt...
Anyway, if you can reproduce this when 2.1.8 comes out, let me know and well have a look.
Hi @mike.maxwell. I updated to 2.1.7.127 (from 2.1.6.118) this afternoon and just tried my upstairs lights.
There are 3 lights that turn on with a motion rule. One is orange, one is blue and the other is now red!
What can I do to troubleshoot this?
That's not much to go on...
