'Fibaro Z-Wave FGK-101 Temperature & Door/Window Sensor' Full Support Handler

You were right… it’s getting picked up as a Fibaro Open/Close Sensor. Doesn’t look like there’s anything I can do except change it to your handler after the fact using the IDE. Unfortunately, doing this causes readings to stop all together. Will try to exclude and re-pair…

Also, not seeing the Custom Attributes/Commands that you mentioned above on the Handler page. Can’t find them in the code either but I could be missing something… Is this a problem?

Sorry about the missing Custom Attributes, Custom Commands, my fault : they appear only with a more advanced version of my custom Device Handler, but they are not needed for normal FGK-101 behavior. I edited my post.

So now that you finally have the proper handler installed, try the “tampering switch” at the bottom of the FGK-101 : that should force immediately an “Is Tampered With !” message, and using the magnet close to the FGK-101 should light the blue LED, and generate an “Is Open” then an “Is Closed” message, and then a “Temperature is xxx°F” message… after some time.

One way I found useful to force the re-initialization of a Device Handler is, from the IDE, to “Save / Publish For me” it, again, selecting then your location and device. To force “Save”, add a space anywhere in the Handler’s code, then suppress it, then Save.
Normally (?!) you should then see in the Log trace an “Updated !” entry, and at that point you should also see regular temperature updates and device wake-up every hour (with or without a Temperature update, depending on the current temperature difference with the last reported one).

FYI, not all the difficulties with Z-wave Device Handlers come from the SmartThings peculiarities : some come from the Z-wave protocol “grey areas” which don’t seem to always behave as specified.

How often this Fibaro-probe assembly should report Temperature to the hub?
Mine is unpredictable. Sometimes it is 4 min sometimes a few hours.
Is anything in the handler can be tweaked?
thanks

@ivictor
This FGK-101 Custom Handler is optimized to report accurate temperatures with a minimum of wake-ups [battery autonomy] and a minimum of temperature events sent to the hub.
You get a temperature event whenever :

  1. the DS18B20 Temperature Sensor detects a +/-0.3°C = +/-0.5°F temperature difference since its last report [managed by DS18B20 sensor]
  2. the FGK-101 wakes up every hour, and there is a temperature difference of at least +/-0.3°C = 0.5°F since the last temperature event [managed by FGK-101 custom handler]
  3. the FGK-101 wakes up every hour, and there has not been any temperature event sent for the last 4 hours [managed by FGK-101 custom handler]

In addition, you can force additional temperature reports at any time :
4. activating the close/open magnetic switch
5. activating the anti-tampering switch at the bottom of the FGK-101

The end result is that 2 temperature reports can follow very closely (1mn : you open a window) or at most every 4 hours (stable temperature), with any intermediate period possible, depending on temperature fluctuations.
The “unpredictable” periodicity of Temperature Events you observe is thus not a bug, but a feature ! :smile:
Note that because of this “variable” periodicity, if you want later on to compute “average” temperature values using Temperature Events history, they should be weighted by the duration between consecutive temperature events, BEFORE computing the average.

You could modify the handler for regular periodic reporting (every 15mn for instance), but it will result in less accuracy, lower battery autonomy and greater hub traffic.
The lines involved are multiples, including :

166 cmdBlock << zwave.wakeUpV1.wakeUpIntervalSet(seconds:6060, nodeid:zwaveHubNodeId).format() // NB : may have to wait 30mn for that value to be refreshed !
167 cmdBlock << "delay 1200"
168 // NOTE : any asynchronous temperature query thru SensorMultilevelGet() does NOT reset the delta-Temp base value (managed by DS18B20 hardware)
169 cmdBlock << zwave.configurationV2.configurationSet(parameterNumber: 12/for FGK101/, size: 1, configurationValue: [5]/
5/16=0.31°C /).format()

217 // Real-time clock of sensors (ceramic resonator) is up to 3% inaccurate
218 def final long maxEventInterval = (4
6060-1060)1000 // at least 1 Temperature Report event every 4 hours

262 }
263 if (((ftemp-state.lastReportedTemp).abs()>0.299) | (nowTime-state.lastReportTime > maxEventInterval) | state.forcedWakeUp) {

402 // Make sure sleepy battery-powered sensors send their WakeUpNotifications to the hub
403 zwave.wakeUpV1.wakeUpIntervalSet(seconds:60
60, nodeid:zwaveHubNodeId).format(),
404 // NOTE : any asynchronous temperature query thru SensorMultilevelGet() does NOT reset the delta-Temp base value (managed by DS18B20 hardware)
405 zwave.configurationV2.configurationSet(parameterNumber: 12/for FGK101/, size: 1, configurationValue: [5]/* 5/16=0.31°C */).format(),

Wow, thank you so much. Can it be modified to mantadory 5 min temperature reports? I use it as a probe only
and willing to accept shorter battery life or traffic increase. If yes, could you show me please how to do it in the handler?
Regards,
Victor

With a 5mn wake-up interval, the battery life may be lowered to 1 month…

lines 166 and 403 : replace “wakeUpIntervalSet(seconds:60*60,” by : "wakeUpIntervalSet(seconds:60*5,"
line 263 : replace the whole line by "if (true) {"
Wait 1 hour after the Handler’s update from the IDE [Save / Publish for me / Install].
That should be enough.
YMMV.

Thank you. I will test it and check the battery life. Regards.

I REALLY appreciate you taking the time to help me - although I’m not up and running yet. I’ve followed each step to a ‘T’ several times (with the exception of changing the namespace, because I don’t have one but I don’t think it matters, right?). The only time it veers off your list is when I get to #6. When I add the sensor back to SmartThings, it does not automatically pick up the handler. I have to go into the IDE and change the handler myself. Any idea why?

@nattyb :[quote=“nattyb, post:29, topic:5483”]
The only time it veers off your list is when I get to #6. When I add the sensor back to SmartThings, it does not automatically pick up the handler. I have to go into the IDE and change the handler myself. Any idea why?
[/quote]
I have had a similar problem in the past, and I am not too sure from where it comes from. I suspect SmartThings tries first the “standard handlers” compatible with a Device signature BEFORE it tries the “custom handlers” compatible with the same signature (which makes sense from a layman point of view, but not from a developer point of view).
But as long as you correct the problem from the IDE, and the Device info in the IDE shows the proper custom handler, you should be fine.
Regarding Namespace, if you are not on GitHub, you can enter from the IDE any string you want instead of ‘JJG2014’, for example ‘NATTYB2016’.

Just to be 100% sure, you may want to re-install your copy of my custom Device Handler for your Device now that it is properly paired, doing that from the IDE :
IDE / My Device Handlers / JJG2014 : JJ’s Fibaro FGK-101 Handler / …Save / Publish for me / …Set Location / …Install
Once the Install is completed, you should see some Trace Logs events appearing at the bottom of the IDE.

You say “I’m not up and running yet” : but if you now have the proper custom handler, which should work (after 1 hour delay at most), what are the problems remaining ?

It seems like the device handler code has been entered correctly - I have done it several times:

All the capabilities are there. However, when I then add it as the device type, all of the capabilities are not present ( it looks like alarm and others are missing) and it stops updating. The magnet will no longer prompt an open/close response like it does with the default type without issue. As soon as I put in the custom device type, it pretty much stops working altogether. Doesn’t make any sense to me. Let me know what other information I can provide. I hope its nothing obvious I’m missing here, I’ve been pulling out what little hair I have left (and I’m only 32…).

*edited to show proper version on second screenshot

@nattyb : I am sorry you have all this trouble, and unfortunately it is not clearer for me why it happens : you have the right capabilities, and the only difference I see from your screen copies is that the “Label” is missing from your Device.
And also your FGK-101 device seems to be of a slightly more advanced hardware version than mine, which shows :
Raw Description 0 0 0x2001 0 0 0 c 0x30 0x9C 0x60 0x85 0x72 0x70 0x86 0x80 0x84 0x7A 0xEF 0x2B
But I doubt (?) any of those differences could explain your problems.

I cannot update my original Device Handler code in the post #1 of this thread, but below is my current version of my handler, slightly more advanced. It should not make any difference in your case, but both of us having the exact same version will help checking any behavior difference, even minor.

===> moved to github <===

To update your Device Handler to this latest code :

  • copy the above code
  • paste into the IDE [IDE / My Device Handlers / JJ’s Fibaro FGK-101 Handler / Paste / Save / Publish For Me / …Set Location / …Install]

When you reach the last “Install” step, you should get a Log trace at the bottom of the IDE window : do you ?

IMPORTANT EDIT : the latest version of the “JJ’s Fibaro FGK-101 Handler” is now uploaded to github, so please download it from there.

Any word if this new code is working for anyone?

This code works for me. Or rather, when I update the code i get the status window at the bottom of the IDE. Unfortunately the same thing happens to me that has happened from the start.

I get an updated UI (in French) looks great, everything looks normal but then no further updates. Neither temperature nor door open/closed status.

I’m sure I’m doing something wrong.

Any ideas on what to try or is there some output I can post to help work through it?
Thanks,
Fred

You could post the Log trace which shows at the bottom of the IDE +++AFTER+++ you Updated and successfully Installed the custom driver for “your_FGK-101_device”, during the first 1 hour after Install.
And also post the last 8h Events List log from : IDE / My Devices / “your_FGK-101_device” / List Events / all.
A screen copy of your IDE “Show Device” window could also be useful.

Note that all messages in my custom handler are in English, so I wonder what is your “updated UI (in French)” ?

Hi,
Thank you for the reply. OK. I just made a small change to a commented line in the handler code, then Save/Publish For me. Then did the Location then Install to the device.

Here’s a screenshot of the phone so you can see what I mean about the UI.

Here’s the results of the Device Type Settings

Here is the device info screen. I did notice the version is Draft. Am I supposed to change that manually or is that a symptom?

I’ll wait an hour and post the logs from the bottom of the device handler page then post the Event List logs in a few hours.

What will happen is that there will be no updates to the UI on the phone. Maybe the logs will show something. Is there some trick for posting the log trace or do I just copy the text and paste it in a message?

Thanks again for your help. I’ll post the rest later tonight.
Fred

Here’s the first hour of log data. I’ve reversed the order so it’s easier to read.

The log starts like this:

65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug Updated !
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug state.deviceID: Fibaro Door/Window Sensor
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug state.batteryInterval : 83700000
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug state.maxEventInterval : 13800000
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug device.currentValue(‘reportASAP’) : 1
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug zwaveHubNodeId: 1
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug device.displayName: Fibaro Door/Window Sensor G
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug device.id: 65d38753-9a63-4066-8ae7-a717dff4459d
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug device.name: Fibaro Door/Window Sensor
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug device.label: Fibaro Door/Window Sensor G
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎48‎:‎26‎ ‎PM: debug device.data: [:]

Then this repeats every 4 minutes and 12-16 seconds:

65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎49‎:‎58‎ ‎PM: debug Parsed Crc16Encap(checksum: 81, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 217, 168]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 81, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 217, 168]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎49‎:‎58‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F8 D9 A8 51 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎49‎:‎58‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 1--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎54‎:‎12‎ ‎PM: debug Parsed Crc16Encap(checksum: 56, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 148, 49]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 56, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 148, 49]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎54‎:‎12‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F8 94 31 38 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎54‎:‎12‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 2--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎58‎:‎25‎ ‎PM: debug Parsed Crc16Encap(checksum: 225, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 98, 190]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 225, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 98, 190]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎58‎:‎25‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F8 62 BE E1 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎2‎:‎58‎:‎25‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 3--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎02‎:‎42‎ ‎PM: debug Parsed Crc16Encap(checksum: 56, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 148, 49]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 56, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 148, 49]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎02‎:‎42‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F8 94 31 38 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎02‎:‎42‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 4--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎06‎:‎54‎ ‎PM: debug Parsed Crc16Encap(checksum: 95, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 11, 112]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 95, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 11, 112]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎06‎:‎54‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F9 0B 70 5F '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎06‎:‎54‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 5--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎11‎:‎08‎ ‎PM: debug Parsed Crc16Encap(checksum: 254, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 130, 112]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 254, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 130, 112]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎11‎:‎08‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F9 82 70 FE '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎11‎:‎08‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 6--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎15‎:‎21‎ ‎PM: debug Parsed Crc16Encap(checksum: 105, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 242, 14]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 105, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 242, 14]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎15‎:‎21‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F9 F2 0E 69 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎15‎:‎21‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 7--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎19‎:‎35‎ ‎PM: debug Parsed Crc16Encap(checksum: 84, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 250, 86, 174]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 84, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 250, 86, 174]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎19‎:‎35‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF FA 56 AE 54 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎19‎:‎35‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 8--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎23‎:‎49‎ ‎PM: debug Parsed Crc16Encap(checksum: 67, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 250, 174, 192]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 67, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 250, 174, 192]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎23‎:‎49‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF FA AE C0 43 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎23‎:‎49‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 9--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎28‎:‎02‎ ‎PM: debug Parsed Crc16Encap(checksum: 173, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 250, 130, 37]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 173, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 250, 130, 37]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎28‎:‎02‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF FA 82 25 AD '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎28‎:‎02‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 10--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎32‎:‎16‎ ‎PM: debug Parsed Crc16Encap(checksum: 159, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 199, 104]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 159, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 199, 104]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎32‎:‎16‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F9 C7 68 9F '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎32‎:‎16‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 11--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎36‎:‎31‎ ‎PM: debug Parsed Crc16Encap(checksum: 28, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 42, 68]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 28, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 249, 42, 68]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎36‎:‎31‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F9 2A 44 1C '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎36‎:‎31‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 12--------------------------

65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎40‎:‎45‎ ‎PM: debug Parsed Crc16Encap(checksum: 73, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 192, 43]) to [‘descriptionText’:!!! Fibaro Door/Window Sensor G: Crc16Encap(checksum: 73, command: 13, commandClass: 96, data: [2, 2, 49, 5, 1, 68, 255, 255, 248, 192, 43]), ‘displayed’:false, ‘isStateChange’:false, ‘linkText’:‘Fibaro Door/Window Sensor G’]
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎40‎:‎45‎ ‎PM: debug Parsing… 'zw device: 08, command: 5601, payload: 60 0D 02 02 31 05 01 44 FF FF F8 C0 2B 49 '
65d38753-9a63-4066-8ae7-a717dff4459d ‎3‎:‎40‎:‎45‎ ‎PM: debug --------------------------Parsing… ; state.parseCount: 13--------------------------

Thanks again. I’ll add the 8 hour log (or close to it) later tonight.

Fred

Here is the device log with “all” selected (This is a current screen. I separated out the entries for easier readability):

DateSourceTypeNameValueUserDisplayed TextChanged

				2016-05-12 2:48:27.263 PM MST

7 hours ago DEVICE ENTITY_UPDATEDeviceUpdated false

				2016-05-12 2:48:26.436 PM MST

7 hours ago DEVICE reportASAP 1 Fibaro Door/Window Sensor G report asap is 1 true

				2016-05-12 2:37:23.857 PM MST

7 hours ago DEVICE ENTITY_UPDATEDeviceUpdated false

				2016-05-12 2:37:23.800 PM MST

7 hours ago DEVICE reportASAP 1 Fibaro Door/Window Sensor G report asap is 1 true

			2016-05-12 2:33:00.947 PM MST

7 hours ago DEVICE temperature 7.25 Fibaro Door/Window Sensor G temperature is 7.25°F true

			2016-05-12 2:28:47.254 PM MST

7 hours ago DEVICE temperature 5.68 Fibaro Door/Window Sensor G temperature is 5.68°F true

				2016-05-12 2:24:33.558 PM MST

7 hours ago DEVICE temperature 3.78 Fibaro Door/Window Sensor G temperature is 3.78°F true

                2016-05-12 2:20:19.631 PM MST

7 hours ago DEVICE temperature 1.74 Fibaro Door/Window Sensor G temperature is 1.74°F true

				2016-05-12 2:16:05.625 PM MST

8 hours ago DEVICE temperature -0.40 Fibaro Door/Window Sensor G temperature is -0.40°F true

Thanks for any thoughts or suggestions.
Fred

@Woo Fred Chavez
Thanks a lot for all the traces, I believe I understand now what happens.

The good news is that you did nothing wrong and properly installed my custom handler.

The bad news is that you must have either a v2 Hub or a more advanced version of the Fibaro FGK-101 device, or both : the “Parsed Crc16Encap(…)” you see in the IDE trace shows that the Z-Wave exchanges between your Hub and your Fibaro FGK-101 Device are now CRC16 encoded, which they were NOT for my own 13 units of FGK-101.
And since my handler does not currently support this encoding, most of the exchanges fail to be effective :frowning: .
This is actually confirmed by the “Raw Description” shawn for your FGK-101 Device, which ends with “86 80 56 84 7A” while mine ends only with : “86 80 84 7A” : the additional 56 capability is the CRC_16_ENCAP capability.

I will look into it and try to find a way to correct this encoding problem. But it is complicated by the fact that I have neither a v2 Hub, nor your (more advanced ?) version of the FGK-101. So any correction I do would be “blind” and could only be tested remotely by you…
…which could necessitate quite a number of iterations.
I will come back to you within 72h, after I have looked somewhat into this issue.

Regarding the “French UI”, I apologize, I thought I had translated all the French to English, but I missed a few. You just need to replace those 8 lines to be full English.

132         standardTile("contact", "device.contact") {
133 			state "open", label: 'open'/* in English :'${name}' */, icon: "st.contact.contact.open", backgroundColor: "#ffa81e"
134 			state "closed", label: 'closed'/* in English :'${linkText}' */, icon: "st.contact.contact.closed", backgroundColor: "#79b821"
135 		}
136         
137         valueTile("battery", "device.battery", inactiveLabel: false, decoration: "flat") {
138 			state "battery", label:'battery @ ${currentValue}%' /*battery*/, unit:""
139 		}

Again, thanks for all the traces, this explains the difficulties some people had those last months with my handler while I had none. As you can imagine, neither Fibaro nor SmartThings broadcast such low level changes when they push them onto unsuspecting users…
Seems like “upward compatibility” is not yet a recognized practice in the home automation world… :frowning: :frowning:

I have just updated my custom Device Handler in Post#32.
It works as well as the previous code for me (v1 Hub), but I have no way to test if it corrects the CRC16 issue which appeared with v2 Hub. The FGK-101 Device itself seems to be innocent, it is just that it answers differently now that the v2 Hub firmware is different from v1.
This same issue was encountered in January with an other Fibaro Device (FGMS Motion Sensor) and a fix was proposed by Duncan.
Hope this works as well for my FGK-101 custom handler.
Let me know.