no problem 
oic, sets normally aren't mapped this way since they are usually commands sent from the hub to a device, not the other way around.
I can get this fixed, in the mean time if you add [ 0x20: 1] to your parse(description,[ 0x20: 1]) that should fix it
For the record I have multiple devices that send a basic set event after the state changes, whether it originated locally at the device or from the hub.
that's fine, we're talking about parsing a basic set, not sending one
Yup, I know. Receiving a basicset (and thereby needing it to be parsed in the receiving driver) is very common when you have associations defined. (Or am I still missing your point?)
Oh, also, Jasco uses basicset to send their doubletap events to the hub, too. At least in the old devices. In the enbrighten models they use centralscene reporting like good boys.
Well this might explain why my Eaton scene controller driver broke for one user: [RELEASE] Cooper Eaton Aspire RFWC5 Keypad driver for Hubitat
I had thought maybe their firmware was different and sending a v2 BasicSet instead of the v1 my driver was expecting. But it was actually a change in v2.1.7?
I’m still on 2.1.6 and waiting for a bit before upgrading.
I think that is why associations "look" broken to one user of my GE drivers, too... Which was new in 2.1.7.
Because the association definitely sends basicset commands in this application, which are likely generating errors (although I don't think they looked for/specifically reported that error).
yes, and we didn't add the various command classes that got added to the change log (our bad), there's more coming, and these will all be noted in the 2.1.8 release notes...
3 Likes
Thanks for your help this issue. (and patience in understanding what we were trying to explain [albeit poorly])
3 Likes
Have updated to V2.1.7.121 again and tried updating a parameter on one of my devices (driver posted above) and it has failed to update correctly.
These are the logs from V2.1.6.118 when i changed parameter 6
2019-12-07 18:27:31.321 [info] parameter 6 reported value 20. All parameters updated
2019-12-07 18:27:29.829 [info] Setting parameter 6 to 20 last value 15
2019-12-07 18:27:29.803 [info] Device woke up
These are logs from V2.1.7.121 when i changed parameter 6 back
2019-12-07 18:42:30.620 [info] parameter 6 reported value 256. 1 setting(s) left
2019-12-07 18:42:29.778 [info] Setting parameter 6 to 15 last value 20
2019-12-07 18:42:29.772 [info] Device woke up
parameter 6 is motion cancel time and it has changed to a long time so it appears the correct value was reported, so it must have sent the wrong value to the device.
As no one else appears to be having this issues i guess its something in the driver that i was getting away with in the last versions, so any ideas why this is going wrong ?
Cheers
each time it updates the number changes
2019-12-07 19:00:34.483 [info] parameter 6 reported value 2560. 1 setting(s) left
2019-12-07 19:00:33.770 [info] Setting parameter 6 to 15 last value 3584
2019-12-07 19:00:33.760 [info] Device woke up
2019-12-07 18:57:34.297 [info] parameter 6 reported value 3584. 1 setting(s) left
2019-12-07 18:57:33.156 [info] Setting parameter 6 to 15 last value 512
2019-12-07 18:57:33.148 [info] Device woke up
2019-12-07 18:54:33.179 [info] parameter 6 reported value 512. 1 setting(s) left
2019-12-07 18:54:32.494 [info] Setting parameter 6 to 15 last value 1536
2019-12-07 18:54:32.488 [info] Device woke up
Cheers
thanks for raising this; i have the exact same issue with 5 of these motion sensors and the associated driver (yours, i think!). I assumed i had broken them somehow when i did a ZWave repair, but it appears there's more to it. At the moment i think it's beyond me 
I get the following logs from my motion sensors when they detect motion; no doubt as you do:
Unhandled event BasicSet(value:255)
Parsed 'zw device: 18, command: 2001, payload: FF B8 00 , isMulticast: false'
1 Like
the basic set issue is an easy fix, i have added the update from @mike.maxwell , if you grab the driver from the link further up that should be fixed.
but dont change any parameters at the moment as it will go horribly wrong 
Cheers
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
