Wrong graphs when multiple heat controllers share one sensor

[marcwau 30]

In some rooms, I have two or three FGT's that are paired with one single external sensor.

 

If you look at the temperature control charts, only the first FGT shows the measured temperatures.

 

Please login or register to see this image.

/monthly_2022_02/image.png.38b5c5ccf90542f07b4d1f1b704179c4.png" />

 

The one or two other FGT's paired with the same sensor, only show a straight line:

 

 

It's the same behavior on all FGT's that share an external temperature sensor.

 

All firmware is on the latest versions, so FGT's on v4.9 and HC3 on v5.100.

But it is not a new problem; it was the same in the previous firmware versions.

 

 

[Giovanni_Genoa 11]

Hi @petergebruers

I read your explanation (published very long time ago on Aug 26, 2018) about the functioning of the FGT-001 and related Temperature probe.
Following your clarification I installed 7 FGT 001 and 5 temperature probes FGBRS-001 (one room has three radiators paired with same sensor).

Sistem HC2 - Ver 4.62,  firmware of all FGT 001 successfully updated to version 4.9
In such room i noted the same problem illustrated  above by @marcwau, same sensore, different graphic from the three FGT 001. 
Furthermore I noted that randomly graphs from various FGT 001 show a strange behavior, as per picture sample posted hereafter: temperature graphic shows spikes, sometimes it lasts few minutes, but sometime it lasts very longer and this causes valve closing.
Is that a "bug" or there is something else that we can do? or maybe... there is no explanation!
Many thanks in advance for your kind attention.

Giovanni

Please login or register to see this attachment.

[marcwau 30]

Hi!
After writing the initial post above, I did some more testing and I found the cause of showing a straight line for the second and third FGT paired to the same sensor.

 

When I installed them, I thought: there is only 1 physical sensor and all 3 FGT's are in the same room, so I'll only show one temperature value in the panel, and hide the other two, to avoid clutter. So I set the (virtual) sensors for the second and third FGT to "device hidden" and "do not save events to history".

In retrospect, that was wrong. The shared sensor is apparently considered by each FGT as "his" sensor, and all three FGT's need the events. In other words: to show the correct graphs, 3 FTG's with 1 sensor need to send the sensor value 3 times to the history. 

I guess it's not a bug, but a design choice.

[Giovanni_Genoa 11]

7 minutes ago, marcwau said:

Hi!
After writing the initial post above, I did some more testing and I found the cause of showing a straight line for the second and third FGT paired to the same sensor.

 

When I installed them, I thought: there is only 1 physical sensor and all 3 FGT's are in the same room, so I'll only show one temperature value in the panel, and hide the other two, to avoid clutter. So I set the (virtual) sensors for the second and third FGT to "device hidden" and "do not save events to history".

In retrospect, that was wrong. The shared sensor is apparently considered by each FGT as "his" sensor, and all three FGT's need the events. In other words: to show the correct graphs, 3 FTG's with 1 sensor need to send the sensor value 3 times to the history. 

I guess it's not a bug, but a design choice.

Hi,
I Attache herewith the reading from power consumption, temperature readings set to compare readings from the three FGT sharing same temp. probe.
It looks that they run together, but there is some delay in updating information... I think it depends from the time elapsed between the pairing.

However there are spikes that I do not understand.  
 

Please login or register to see this attachment.

[petergebruers 1,261]

Sorry for the delay... Yes, I see "Spikes" as well on at least one of 1 x FGT-001 running firmware 4.9 with 1 x external probe. IMHO the spikes might happen if the FGT switches its reporting from internal sensor to external sensor and back. I don't think I saw this with firmware 4.7, but I might have missed it. I need to investigate

 

@m.roszak have you seen reports from other users? Shall I collect a diagnostics log?

 

Please login or register to see this image.

/monthly_2022_02/567944952_Screenshot2022-02-22at20_26_19.png.1a1f124044bdb165060d2becd5ac492f.png" />

[Tony270570 92]

Hi all, unfortunately those spikes were already existing in 4.7 aswell. 

I saw them for the first time about 1.5 year ago for the first time and have many of them every day. 

Side effect is not only switching the FGT off for a certain periode of time (sometimes very long ...) but it also switches off the heater when a FGT is driving it. 

Anoying i would say  

I was thinking about a BLE interference with other devices, i might be wrong.

 

[m.roszak 474]

Please download the logs and send them to me, we will investigate the issue.
This never happened during our tests.

Regards,
Michał 

[Tony270570 92]

I would be happy to do so, but i've tried 5 times(6 after edit ...) , 2 FGTs and 1 reboot to generate the logs, but each time the log file is empty. Each time it takes 5 to 7 mn to read data from the FGT and no way it's still empty.

@petergebruers, @Giovanni_Genoaare you luckier then I and  try to download your logs ? giving me a chance to find out what's wrong with the mines...

Thanks !

 

EDIT : 

Please login or register to see this image.

/monthly_2022_02/image.png.9f4647b9901a4adf29f61a6b54a14625.png" /> 

Please login or register to see this attachment.

 

Please login or register to see this attachment.

 

EDIT 2 :

@m.roszak

I think that i found the reson why I can't generate the logs. 

The FGTs where i was trying to generate the logs are on a HC3 slave machine. 

I've tryed to generate the logs from a FGT that is included into the master HC3 are well generated.

Maybe you'll be able to reproduce.

Unfortunatly I don't have this issue on FGTs included into my main HC3 therfore I'll not be able to provide any help, except the nice graphs

Thank you in advance for your help @m.roszak!

Edited February 23, 2022 by Tony270570

[m.roszak 474]

I will add a ticket to fix logsDump from slave gateway, thanks for the report.

[Tony270570 92]

Thank you, hope that you also be able to reproduce the spike issue. 

Maybe try in your labotary having a phone with a covid app bombarding BLE signals.  Coincidence or not, it was when I noticed the first spikes issues. I'm paranoid  

[petergebruers 1,261]

Sorry guys, no time to talk, I have to rush, but here you have the log of the "Sarah FGT_TEMP", the one with the spikes I talked about (graph is a few posts back).

 

Please login or register to see this attachment.

[Tony270570 92]

Thank you Peter.

[m.roszak 474]

Ok, I have got the feedback already.

So, this spikes is related to an issue with communicating with external sensor (no report received), during this time FGT reports temperature from internal sensor.
This does not affect the regulator directly so single or 2-3 missing reports won't affect the valve control.

We already talking about a possible solutions to make it more humane.  

[Tony270570 92]

Great new ! thank you for your feedback. 

4 hours ago, m.roszak said:

This does not affect the regulator directly so single or 2-3 missing reports won't affect the valve control

Well, during this time the valve is not reporting anymore as being in demand. So if we use the on demand state like Fibaro heat activator plugin does, the boiler is switched off. Somewhere it impacts a bit the way the system should behave. 

In the graph that I've posted above, you can see the red and green dots, it's when the boiler is switching on/ off. It happens when the target temperature is reached or when an abnormality occurs.

Anyway it's cool that you are aware and already have some ideas to fix it.

[m.roszak 474]

Ah, didn't think about the heating demand reports - this may be affected.
I will report it

[Tony270570 92]

Don't worry leaving with that since mor than a 1.5y and still alive  

btw 4.9 is working really well. 

 

[petergebruers 1,261]

Ha! In my case I am 99,9 % sure that the spikes are cause by poor quality CR2032 cell.

 

I never liked this type of battery for HA application... It has good voltage and reasonable capacity, but it suffers from high internal resistance. I was really happy when Fibaro designed its keyfob with the bigger CR2450. I know, the ZW500 chip is more power-hungry than the bluetooth SoC in the FGT-001 so it is a bit apples-orange but still, let me explain...

 

You cannot use a voltmeter to check a CR2032. Te be more precise, you can use a voltmeter to tell it is near 100% (because voltage is > 3.3 V) or certainly empty (because it is < 2.5 V) but in between those extreems you need to know its internal resistance. You can measure that with a trick but I happen to own a special tester. It uses an AC signal to test the resistance. This is what it says:

 

Please login or register to see this image.

/monthly_2022_02/BAD-COIN.jpg.1121c75c1ec9843099002dc9b8515994.jpg" />

 

The 2.94 V is not bad at all, but 103 ohm is about 10 x what a good cell would have...

 

I do have bigger lithium cells, and I managed to fit a CR123A in on my BLE probe. This cell has less than 1 ohm AC resistance, and I estimate that it will last for at least five years

 

 

As expected, it is "connected" and the temp graph looks good. Before 15:00 you'll see the "spikes" with the cr*ppy CR2032, after that you see one spike cause by me, soldering the wires heated up the device. The last spike happens when I reconnect everything and the probe slowly cools back to room temperature.

 

Please login or register to see this attachment.

 

If you don't hear from me again, the battery swap worked. If I still get spikes, I'll post more info here... Then my theory was wrong. But at least, I won't have to change the battery before 2027

 

[Tony270570 92]

hey hey a new theory, I like it ! ? didn't thought about the battery, I was stuck with the ble interferences theory ?

I hope never here about any news from you anymore regarding that storry.

 

 

[petergebruers 1,261]

I could not let go yet, I wondered: "how could I miss such a poor quality battery?". IMHO the reason is simple, the BLE probe does not really take into account thet "AC resistance".

 

I happen to keep my data in a PostgreSQL database, like zo:

 

Please login or register to see this code.

 

And the result is interesting...

 

Please login or register to see this code.

 

As you can see, it occasionally dips ... To 97 and 81. But overall and on average I get 100%.

 

The graph looks really nice since I connected that CR123A, yesterday, at around 17:00:

 

Please login or register to see this attachment.

 

[Giovanni_Genoa 11]

@petergebruers

@m.roszak
Many thanks for latest information.

 

I have the possibility to implement the suggestion of @petergebruers, but

Just a small consideration,

the small temp.probe is in somewhere and sometimes is in dayroom anyhow "visible",

infact Fibaro designers considered this aspect to design it small and nice.

It's pitty that they did non consider the quality and the behaviour of the device in relation to the batteries...

 

The question is always the same :

"hardware shall follow the software (and humanware) necessities or the Software (humanware) must be engineered to satisfy hardware needs (Defects)

The dog bites its tail

In the specific case Fibaro should solve the "dilemma". (?)

Ciao

[Tony270570 92]

3 hours ago, petergebruers said:

As you can see, it occasionally dips ... To 97 and 81. But overall and on average I get 100%.

Very strange indeed, I don't remember having noticed this phenomenon, but the way I use to do my battery consumption statistics may not be precise enough. I'll double check if it has already happened and i didn't notice that.

PostgreSQL no more influx ?