V2.1.7.118 problems configuring z wave devices

📰 News and Updates
22

Do you know if the device is using CRC16?

If it is, you may need to remap the command version in the CRC16 event handler. I have a device I had to do that in the driver. Might be worth putting some debug code in that section and see if that is what is doing the calls that lead to the basic v2 error.

Basically something like this, where I had to force some versions to 1 or 2 on a few commands:

def zwaveEvent(hubitat.zwave.commands.crc16encapv1.Crc16Encap cmd) {
    if (logEnable) log.debug "zwaveEvent(): CRC-16 Encapsulation Command received: ${cmd}"
	
	def newVersion = 1
	
	// Configuration = 112 decimal
	// Manufacturer Specific = 114 decimal
	// Association = 133 decimal
	if (cmd.commandClass == 112) {newVersion = 2}
	if (cmd.commandClass == 114) {newVersion = 2}								 
	if (cmd.commandClass == 133) {newVersion = 2}		
	
	def encapsulatedCommand = zwave.getCommand(cmd.commandClass, cmd.command, cmd.data, newVersion)
	if (encapsulatedCommand) {
       zwaveEvent(encapsulatedCommand)
   } else {
       log.warn "Unable to extract CRC16 command from ${cmd}"
   }
}
23

No not sure if its using CRC16, but will give that ago this weekend when i can try updating again

Cheers

25

I'm totally confused, nowhere in this driver is a basicReport being used, so from that perspective any basic reports this device issues are being ignored by the driver anyway, so the fact that we are returning a basicv2.basicReport is of no consequence...

We're returning a V2 report since parse didn't specify v1, and even if it did not specify v1, had this driver declared a zwaveEvent(hubitat.zwave.commands.basicv1.BasicReport cmd) method, since basicv2 extends basic v1 the basicv1.BasicReport method would have been called...

26

I didn't realize that. :confused: Learn something new every day.

I (almost) always explicitly specify versions in my drivers, so I guess I haven't put enough thought into what happens when the default version is higher than the device supports, but is backward compatible. Sorry to add any confusion to the matter (it was well intentioned).

Thanks for clarifying. I guess when @entire has time to post the actual errors he is getting this weekend it will be easier to tell what is really happening.

27

it was the basicset message that changed

/////////////////////////////////////////////////////
// basicv1.BasicSet
def zwaveEvent(hubitat.zwave.commands.basicv1.BasicSet cmd) {
  def motion
	
  motion = (cmd.value) ? "active" : "inactive"
  if(device.currentValue("motion") != motion)
  {
    log.info("motion '${motion}'")
    sendEvent(name: "motion", value: motion)
  }
}

this was called in V2.1.6, but not in V2.1.7

29

not quite sure i understand that.
It sends a basicset message when it detects motion, what am i not setting ?

Cheers

30

Disregard my last comment. I'm trying to do too many things at once, and am F'ing all of them up simultaneously apparently. You are correct.

31

no problem :+1:

32

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

33

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.

34

that's fine, we're talking about parsing a basic set, not sending one

35

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.

36

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.

37

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).

38

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
39

Thanks for your help this issue. :+1: (and patience in understanding what we were trying to explain [albeit poorly])

3 Likes
40

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

41

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

42

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 :flushed:

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
43

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 :cry:

Cheers