Jump to content

Recommended Posts

I found a very curious bug with the ZW5 version (version >=3.2) of the FGK-101+DS18B20 temperature sensor.

When explicitly requiring a temperature report [thru "Sensor Multilevel Get" -> "Sensor Multilevel Report" commands], the actual temperature value reported via the ++synchronous++ Sensor Multilevel Report answer is buggy : +/- 0.5 to +/- 1°C random error from the correct temperature value; the variable size of the error is similar to what you would expect using only 8 bits of resolution from the DS18B20 measures.

 

But when the FGK-101 itself sends an ++asynchronous++ report, after setting parameter#51 "Temperature reports threshold" to 3/10 °C and parameter#52 "Interval of temperature reports" to 4hours, then the temperature reported by the SAME Sensor Multilevel Report() from the SAME FGK-101+DS18B20 is correct !?.

Note that parameter#50 "Interval of temperature measurements" is set to 60 seconds, which precludes such large variations in so little time; I also tried setting it to 5 seconds, no difference.

   

I found this problem while developing a FGK-101\ZW5 handler for the SmartThings platform, but I would expect this bug to be present as well with the Fibaro Home Center 2... unless Fibaro uses some "hidden parameter" which corrects this bug.

At that point, I have no idea how to correct this bug, except by removing from my handler all "Sensor Multilevel Get()" synchronous temperature requests, and relying only on asynchronous notifications.

 

Interestingly, the correct asynchronous Sensor Multilevel Reports come CRC16-encoded, while the buggy synchronous ones come in clear.

That suggests to me 2 different branches of code inside the FGK-101 firmware, but does not help me to workaround this extremely curious bug...

And the same handler works fine with the older FGK-101 (version <=2.5).

 

While I expect the same bug to exists when pairing the FGK-101\ZW5 to a Fibaro Home Center 2 controller, I would still be interested in getting a confirmation, which would definitely exclude the SmartThings hub from the list of suspects.

 

Any help or suggestion greatly appreciated : this has been driving me crazy for days !

Edited by geeji
Link to post
Share on other sites

Since this is a battery operated device, I don't quite understand how you would do a synchronous get. You could do a GET on a Universal Binary Sensor, though.

But to answer your question: a HC2 has no provisions to send such low level command devices, impossible to test...

But I think... if SmartThings "allows you to send a GET to a battery operated device" then they probably queue this, and cache the result from the previous update. It *might* queue the GET until the sensor wakes up, but I don't own such a controller so it is pure speculation. I have a RaZberry, but no FGK-101 Gen5.

I can confirm that the Gen5 is a CRC-16 device and its predecessor was CRC-8 only.

Maybe I've only added to the confusion... In that case: I'm sorry...

Link to post
Share on other sites
1 minute ago, petergebruers said:

Since this is a battery operated device, I don't quite understand how you would do a synchronous get.

Sorry, I should have provided more details : I send the "Sensor Multilevel Get" command AFTER the FGK-101 wakes up, while it is listening, and BEFORE it goes back to sleep.

The Report is thus "synchronous"... with the provision you get those synchronous Reports ONLY when you post your Get request at the right time.

 

4 minutes ago, petergebruers said:

I can confirm that the Gen5 is a CRC-16 device and its predecessor was CRC-8 only.

Interesting, but AFAIK, there is only a "CRC16 Command Class" in the Z-wave specification, NOT a "CRC8 Command Class". So how can this CRC8 messages be correctly parsed if sent ?

Link to post
Share on other sites
8 minutes ago, geeji said:

Sorry, I should have provided more details : I send the "Sensor Multilevel Get" command AFTER the FGK-101 wakes up, while it is listening, and BEFORE it goes back to sleep.

The Report is thus "synchronous"... with the provision you get those synchronous Reports ONLY when you post your Get request at the right time.

 

Interesting, but AFAIK, there is only a "CRC16 Command Class" in the Z-wave specification, NOT a "CRC8 Command Class". So how can this CRC8 messages be correctly parsed if sent ?

 

I see! So your GET either fully passes, or completely fails. It wouldn't explain why you don't get precise data.

 

I think the sensor might not measure the temperature when you do a GET, there is a sampling interval (for the sensor). But when it samples, and the new value meets the criteria set out by the parameters, a report is sent immediately. So I'd say you always get the "latest" temp when it's asynchronous, but the synchronous version might return data from the previous sample. Sorry, lots of speculation here.

 

Z-Wave started with CRC-8 so it is part of Z-Wave since day one. It's not a command class, it's part of the packet format. To increase fault tolerance, but keep compatibility, CRC-16 was later added as a command class (without touching the packet format) and now it's mandatory in Z-Wave Plus.

Edited by petergebruers
Link to post
Share on other sites
5 hours ago, petergebruers said:

I think the sensor might not measure the temperature when you do a GET, there is a sampling interval (for the sensor). But when it samples, and the new value meets the criteria set out by the parameters, a report is sent immediately. So I'd say you always get the "latest" temp when it's asynchronous, but the synchronous version might return data from the previous sample. Sorry, lots of speculation here.

Yes, I thought of that too.

But first, it is incompatible with the setting of parameter#50 "Interval of temperature measurements" to 60 seconds : the temperature I measure is stable, with ZERO chance of it changing for real by +/-1°C in 1mn or less; as explained above, even with a temperature refresh every 5 seconds, I do have the same glitch.

Second, I have too many observed sequences like that one, from Live Logging Events List :

2017-05-03 7:43:53.417 AM CEST	DEVICE	temperature	23.8	<- correct (asynchronous)
2017-05-03 7:42:19.546 AM CEST	DEVICE	temperature	22.5	<- buggy, synchronous "Sensor Multilevel Report" response to "Sensor Multilevel Get"
2017-05-03 7:42:17.123 AM CEST	DEVICE	forcedWakeUp	0   	JJ's ZW5 forced wake up is 0
2017-05-03 7:40:52.336 AM CEST	DEVICE	temperature	23.5	<- correct (asynchronous)
 

And third, there is this very explicit NOTE page 16 of the FGK-10x Operating Manual :

NOTE : Temperature measurement is performed before sending any report (regardless of parameter n°50).

 

Regarding the CRC-16 being "mandatory" in Z-wave+, I have in that case some serious doubts about the FGK-101\ZW5 full compliance :

  1. "Sensor Multilevel Get" is completely ignored if sent CRC-16 encoded
  2. I have multiple instances of "Sensor Multilevel Report" returning in plain, without any encoding (and most of the times the wrong values)

 

Edited by geeji
Link to post
Share on other sites

I see, I stand corrected. But I didn't look at that version of the manual, because I own the previous version of the device. After all these years with Fibaro, I learn something new every day! Interesting observation. Sorry I can't help you. I'm out. :-)

 

Link to post
Share on other sites
8 minutes ago, petergebruers said:

Sorry I can't help you. I'm out.

Thanks anyway, I could also have missed something obvious...

...and would actually love to discover I did so, thus ending this multiple days nightmare ;(  

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...