Fire warning from temp sensor

[pos 22]

Hi

 

I got an email from my HC2 yesterday day saying there was a fire risk due to very high temperature in the garage. I have several Popp thermostats and have never seen this before. These are Danfoss made but can report temperature back and therefore show up as two devices (temp sensor + thermostat) instead of one as Danfoss LC13.

 

Any comments to this attached graph... 

 

Screen Shot 2018-01-16 at 01.27.14

Please login or register to see this image.

Please login or register to see this image.

Please login or register to see this image.

Please login or register to see this image.

Please login or register to see this image.

Please login or register to see this attachment.

[10der 832]

1) bad connection (from a sensor to HC2)

2) Fibaro devs recommend add a sensor in secure mode...

 

same issue here 

Please login or register to see this spoiler.

 

[Jamie mccrostie 82]

Ive had this on both fibaro and aeotc multi sensors, the “temp at which hc2 sends fire note” in configuration is now set at 100 degress so this never happens again.

Edited January 16, 2018 by Jamie mccrostie

[kroeatschge 29]

It seems this happens on all kinds of sensors. Temperature, smoke, water, ... you name it.

It's a pitty that the customer has to "fix" it by ignoring temperature alerts or setting it so high it will never alert you, even if there is a real fire.

 

Should realy be looked into by fibaro.

[Jamie mccrostie 82]

8 hours ago, kroeatschge said:

It seems this happens on all kinds of sensors. Temperature, smoke, water, ... you name it.

It's a pitty that the customer has to "fix" it by ignoring temperature alerts or setting it so high it will never alert you, even if there is a real fire.

 

Should realy be looked into by fibaro.

Yes they need to  ignore one off spikes. 

But I guess you could build a scene to achieve that.

Edited January 16, 2018 by Jamie mccrostie

[pos 22]

For me I has just happened once on one sensor. But now I know it has happened to more people and more sensors. Therefor I conclude my sensor is ok.

 

Hopefully Fibaro follow threads like this and act without support case complaints...

 

Tnx

Peo

[petergebruers 1,268]

It will never be fixed. The problem has been around for ages.......... I am not joking or exaggerating.

 

I estimate, about 0.01% (order of magnitude) of all reports on my HC exceed 45 degrees C.

 

I think the best advice I have ever read (apart from "ignore it") is exclude and include in secure mode. But generally I avoid secure mode because it can introduce other problems. As the name implies, it adds (relatively) strong encryption to data exchange, so in theory it could work if we assume these false reports are caused by malformed communication packets. I have indications that this is the probable cause. I never tried secure mode, I just ignore these outliers. This suggestion has been made in a few related topics, but nobody ever reported back...

 

Edited January 19, 2018 by petergebruers

[pos 22]

27 minutes ago, petergebruers said:

It will never be fixed. The problem has been around for ages.......... I am not joking or exaggerating.

 

I estimate, about 0.01% (order of magnitude) of all reports on my HC exceed 45 degrees C.

 

I think the best advice I have ever read (apart from "ignore it") is exclude and include in secure mode. But generally I avoid secure mode because it can introduce other problems. As the name implies, it adds (relatively) strong encryption to data exchange, so in theory it could work if we assume these false reports are caused by malformed communication packets. I have indications that this is the probable cause. I never tried secure mode, I just ignore these outliers. This suggestion has been made in a few related topics, but nobody ever reported back...

 

 

Yes, to ignore the error is maybe the easiest solution

 

But I hate to not be able to track problems down so I at least know where the problem lies even if it could not be solved... Sometimes we could to work arounds...

 

Now...

 

I have seen this error twice on the same Popp thermostat:s temp sensor over 2 weeks. This temp sensor is probably the one that has the longest distance to a routing node (i.e permanent powered Z-wave device) and also to the HC2 main unit. But it has never had any issues before and seems to work as it should now as well ... This thermostat has been in my systen for a year at the same location without problems whatsoever. Note that everything in my system that supports security is included in "secure mode".

 

The interesting is what has changed in my system since there were no problem. Before I did the below I have never ever seen this problem at all.

* Now I have 13 popp thermostats instead of 1 (dual devices with thermostat + temp sensor) in my system

* I have switched over to try the heating panel

 

Could it bee the heating panel or the fact I have more devices in the system now?

 

 

( /fibaro/us/configuration/zwave.html says: "Number of devices: 46" and "Devices polling time interval: 300" )

 

/Peo

Edited January 19, 2018 by pos

[petergebruers 1,268]

56 minutes ago, pos said:

But I hate to not be able to track problems down so I at least know where the problem lies even if it could not be solved... Sometimes we could to work arounds...

 

Me too. Have chased this ghost for years. The most plausible explanation is basically Z-Wave packets have only 8 bit CRC. The plus version adds 16 bit CRC as an option. It is possible to have bits flipped in a report, so CRC is valid but temp is wrong.

 

I am unsure if CRC 16 is always used. Documents with details on this probably are not public. Some docs can be downloaded from Sigma.

 

1 hour ago, pos said:

This temp sensor is probably the one that has the longest distance to a routing node (i.e permanent powered Z-wave device) and also to the HC2 main unit. But it has never had any issues before and seems to work as it should now as well ... This thermostat has been in my systen for a year at the same location without problems whatsoever. Note that everything in my system that supports security is included in "secure mode".

 

Agreed. A few thoughts that seem to confirm the corrupted packet theory. I also should mention things that contradict that theory, but I can think of none.

 

More devices, more routing, lower quality signal, more reporting and polling all increase the chances of collision.

 

Still, with 100 devices, only about 1 in 10000 reports are to high. So it is very random. It is chasing a ghost.

 

I have a script somewhere to count the number of reports. If you want to check your ratio I will look it up.

 

Regarding secure mode. I do not know a lot about it. It was added to Z-WAVE at some time and was recently upgraded. New device should support S2 which, according to the consortium, should be the best ever. So I am not too keen on studying the older S0. I can say, it is quite possible that secure devices do not actually report temperature using secure mode. I do not know.

 

Do your "naughty" sensors have a padlock symbol on them? So you are sure they are in secure mode?

 

[pos 22]

My Popp thermostats seems to not support security. At least there are not locks (I always click in security during inclusion)....

 

Now I have seen this fire warning temp spikes a few more times and on other sensors as well. Had never seen this before I added 13 more Popp thermostats. You say.... "More devices, more routing, lower quality signal, more reporting and polling all increase the chances of collision."  Yes.. I think I agree with your reasoning...

 

 

/Peo

[pos 22]

This problem actually start to increase. I have had two more notifications about potential fire today. As said in the post above. The first problem came after adding 13 more thermostats...

 

/Peo

[petergebruers 1,268]

Thanks for reporting back! That is very unfortunate! I don't know how to fix this... You can try to reduce the traffic (of all devices, not only the thermostats). But without extra tools it is difficult to know "how busy your network is"... Sorry, no more wise words...

[pos 22]

Do you think there is a drawback of increasing the default 300s Zwave polling interval to all devices with maybe 50s or so? What you you think? As a test.... Or do you think it is a meaningless test in this case?

 

 

Tnx

/Peo

[petergebruers 1,268]

Yes, changing polling makes a lot of sense...

 

To answer that question...can you please have a look at one of my scripts + explanation in the download section?

 

 

If that does not help to answer your question, please report back...

[pos 22]

Just now, petergebruers said:

Yes, changing polling makes a lot of sense...

 

To answer that question...can you please have a look at one of my scripts + explanation in the download section?

 

 

If that does not help to answer your question, please report back...

 

Will check it up later today....

 

 

[pos 22]

@petergebruers I will correct myself. I will try the code when I have checked the warning of what "could cause the roof to leak"   I will take a day more or so because of to much work...

 

 

 

/Peo