New Fibaro ZW5 FGK-101+DS18B20 is Making Me Crazy ! : Random Temperature Reports

2 years ago, I developed a custom Handler for the Fibaro FGK-101 which at that time was not supported at all by SmartThings.
I posted this Handler on github and made it available to the SmartThings community.
So when one of the users reported it was not working with his new Z-Wave+, aka ZW5, version of the FGK-101, I investigated and decided to fix my Handler… if I could.

Several months later, this (supposedly) “easy” fix turned into a nightmare.
The latest problem is that the temperature reports I get from the FGK-101+DS18B20 are sometimes right, sometimes buggy, but close enough to be misleading.

It all depends who initiated the SensorMultilevelReport() :

  • if “spontaneous”, initiated by the FGK-101 itself (every 4 hours, or when temperature difference is greater than 0.3°C), the reported temperature values are correct
  • if an answer to an asynchronous SensorMultilevelGet() from the Handler, the temperature value is different from the one above by about 1°C, sometimes in excess, sometimes below.
    Furthermore, sometimes the SensorMultilevelReport() returns CRC16 encoded, sometimes it is plain (with the SAME SensorMultilevelGet() call !).

See for example the trace below : all 24.25°C reported values (cmd.scaledSensorValue) are actually buggy, [16:10:44, 15:56:02, 15:56:01, 15:27:36, 15:27:35] although 1°C close to the other, correct, temperature values reported less than 1 second after.
Sorry, entries are missing randomly in that trace, because log.debug drops randomly entries (due to race conditions ?).

> 94d60b86-4430-41df-807b-a24d03e2fbee 16:28:13: debug cmd.scaledSensorValue : 23.81
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:28:13: debug CRC16.......... cmd : Crc16Encap(checksum: 32004, command: 5, commandClass: 49, data: [1, 66, 9, 77])
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:28:13: debug Parsing... 'zw device: 18, command: 5601, payload: 31 05 01 42 09 4D 7D 04 '

> 94d60b86-4430-41df-807b-a24d03e2fbee 16:23:59: debug Parsed Crc16Encap(checksum: 18759, command: 5, commandClass: 49, data: [1, 66, 9, 108]) to null
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:23:59: debug SensorMultilevelReport.scaledSensorValue : 24.12
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:23:59: debug CRC16.......... cmd : Crc16Encap(checksum: 18759, command: 5, commandClass: 49, data: [1, 66, 9, 108])

> 94d60b86-4430-41df-807b-a24d03e2fbee 16:23:41: debug Parsed SensorMultilevelReport(precision: 2, scale: 0, scaledSensorValue: 23.93, sensorType: 1, sensorValue: [9, 89], size: 2) to null
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:23:41: debug cmd.scaledSensorValue : 23.93
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:23:41: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 59 '

> 94d60b86-4430-41df-807b-a24d03e2fbee 16:10:45: debug cmd.scaledSensorValue : 23.31
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:10:45: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 1B '
> **94d60b86-4430-41df-807b-a24d03e2fbee 16:10:44: debug cmd.scaledSensorValue : 24.25**
> 94d60b86-4430-41df-807b-a24d03e2fbee 16:10:44: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 79 '

> 94d60b86-4430-41df-807b-a24d03e2fbee 15:59:15: debug cmd.scaledSensorValue : 23.25
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:59:15: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 15 '
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:56:02: debug Parsed SensorMultilevelReport(precision: 2, scale: 0, scaledSensorValue: 24.25, sensorType: 1, sensorValue: [9, 121], size: 2) to null

> **94d60b86-4430-41df-807b-a24d03e2fbee 15:56:02: debug cmd.scaledSensorValue : 24.25**
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:56:02: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 79 '
> **94d60b86-4430-41df-807b-a24d03e2fbee 15:56:01: debug cmd.scaledSensorValue : 24.25**
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:56:01: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 79 '

> 94d60b86-4430-41df-807b-a24d03e2fbee 15:43:40: debug cmd.scaledSensorValue : 23.18
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:43:40: debug CRC16.......... cmd : Crc16Encap(checksum: 1443, command: 5, commandClass: 49, data: [1, 66, 9, 14])

> 94d60b86-4430-41df-807b-a24d03e2fbee 15:32:41: debug Parsed SensorMultilevelReport(precision: 2, scale: 0, scaledSensorValue: 23.18, sensorType: 1, sensorValue: [9, 14], size: 2) to null
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:32:41: debug SensorMultilevelReport.scaledSensorValue : 23.18
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:32:41: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 0E '

> 94d60b86-4430-41df-807b-a24d03e2fbee 15:28:04: debug Parsed Crc16Encap(checksum: 32004, command: 5, commandClass: 49, data: [1, 66, 9, 77]) to ['displayed':true, 'value':'23.8', 'isStateChange':true, 'linkText':JJ's ZW5, 'name':'temperature', 'unit':'C', 'descriptionText':JJ's ZW5 temperature is 23.8°C]
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:28:04: debug ftemp : 23.8
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:28:04: debug CRC16.......... cmd : Crc16Encap(checksum: 32004, command: 5, commandClass: 49, data: [1, 66, 9, 77])

> **94d60b86-4430-41df-807b-a24d03e2fbee 15:27:36: debug SensorMultilevelReport.scaledSensorValue : 24.25**
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:27:36: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 79 '
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:27:35: debug Parsed SensorMultilevelReport(precision: 2, scale: 0, scaledSensorValue: 24.25, sensorType: 1, sensorValue: [9, 121], size: 2) to ['displayed':true, 'value':'24.3', 'isStateChange':true, 'linkText':JJ's ZW5, 'name':'temperature', 'unit':'C', 'descriptionText':JJ's ZW5 temperature is 24.3°C]
> **94d60b86-4430-41df-807b-a24d03e2fbee 15:27:35: debug cmd.scaledSensorValue : 24.25**
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:27:35: debug SensorMultilevelReport.sensorValue : [9, 121]
> 94d60b86-4430-41df-807b-a24d03e2fbee 15:27:35: debug Parsing... 'zw device: 18, command: 3105, payload: 01 42 09 79 '

At the beginning, I thought the problem was in my Handler; then I suspected some faulty DS18B20 and replaced it : no improvement.
At that point I suspect some subtle bug in SmartThings parsing routines, but I cannot submit a Bug Report to SmartThings Support, since they reject immediately anything related to a Custom Handler.

So my question is : has anybody ever seen something similar ?
Do you have any suggestion on a workaround or a way to refine the source of the problem ?

Thanks for all the work you’ve been doing on this topic. I am completely new to ST and FIbaro and have a new ST Hub just received yesterday and a new Fibaro FGK-101 ZW5 with an external DS18B20.
There were no issues with the set up and the Hub auto-discovered the FGK right off the bat and started to display door status, temperature, and tamper status.
I know you’ve published a lot of help on the sampling intervals of the FGK and how this affects battery life and that is where my questions lie:

  1. Although the door status updates instantly upon change of state, the temperature updates don;t seem to follow any rules that I can determine. I am going from a reading of 71 degrees F to 41 degrees after placing the warerproof temp probe in a bowl of ice water, but there is a 10 minute lapse between the two readings in the “Recent” list.

What are the real default rules for temperature reading updates using the ST device handler and an FGK w/temp sensor?

  1. I then placed the entire probe in between two chucks of ice, and the reading went from 41.32 to 32.22, but the interval was 19 minutes. I would have expected a much shorter interval between the two readings.

  2. Sometimes I get a reading only 4-5 minutes apart and the change is usually much smaller, like one I got that went form 32.22 to 31.33 That’s the lowest it got with the probe in direct and constant contact with ice.

These sampling intervals are too far apart for practical use in my case, as I need to know if the temperature changes more than 1-2 degrees as soon as it occurs. As I indicated above, there was a 19 minute lapse between a reading of 41.32 and 32.22 … there were no reported readings in between.

As I understand it, your custom device handler allows the sampling rate to be modified … can this be done on a delta-T parameter as well as a time parameter even if the temp value doesn’t change we still get a reading every 15 minutes?

We do need the delta-T change to be immediately reported, which doesn;t appear to be happening now with the defualt FGK device handler that is already in ST.

Thanks for any help you can provide!

Hi Damon,

Since you are not really answering to the first post of this thread, I would suggest you post any further enquiry on the regular thread for my FGK-10x custom handler.
Anyway, I will try to answer your questions :

  1. First, check you are actually using my custom handler : My Devices / Show Device “your_device” / Type = JJ’s Fibaro FGK-10x ZW5 Handler.
    If not, you need to install my v0.9.7.2 custom handler before I can help you. See the above aforementioned thread for that.
  2. Assuming you DO have my v0.9.7.2 handler, a Temperature Report event will be generated whenever the temperature changes by at least 0.3°C = 0.56°F, or every 4 hours when temperature remains constant.

Hope this help, but if you encounter further difficulties, please report them on the other thread.