Community
OpenEnergyMonitor

Community

Data Quality got worse recently on Heatpump board

Hi,

Recently the data quality posted to Emoncms.org fell from 100% to 91%.

All i have changed is that the board now has M-BUS working @ 2400 baud to a Kamstrup 403 heat meter.
Also, the EmonTxV3 is no longer transmitting data to the heatpump board.

Any ideas please?

Can you see a regular missing datapoint in the graph, or specific period in the day?

Here’s mine:

you can see some missing packets around 3:30pm, my heatpump board has an RSSI of -80 its on the edge of WiFi range… I also rebooted my Pi several times yesterday

Hi @TrystanLea

Interesting, so i took a look and my RSSI is -51.
Similar to my EmonTxV3 @ -48, which is working fine.

I just noticed, when logged into the EmonESP, it suggests packet success is 99.9%.
Could that mean that the board is not generating the messages when required?
Could the newly added comms over M-Bus be interfering with the process in any way?

Update:

Looks like the 93% quality is infact the Emon comms. Reset and:

What is the data period? If where you did the upgrades, you will have of course lost some packets.

The graph will show you where there are missing data as Trystan said.

Hi, thanks for helping.

Feeds are set at 10s, if that was your question?

The data loss is regular.
Avery few minutes it looses data for 15 seconds exactly (is this a clue?).

@TrystanLea is your better bet for the detail :grin:.

Is that the sending end or the receiving end, or both?

For a while, it’s been considered a “good idea” to send the data a little more frequently than the database is set to receive it. If the rates are exactly matched, and the data arrives in the middle of its time slot (for the PHPFINA database), all is well. But if it sent at a slightly slower rate - because the timebase isn’t perfect - it will slowly creep towards the trailing end of its slot and then fall into the next one, leaving an empty slot. On the other hand, if it’s sent slightly faster, it will creep forwards and eventually fall into a slot that still contains the previous value. That gets overwritten, you lose it but there aren’t any gaps in the data. I suspect what you’re seeing could be explained in this way.

I was just looking at that exact principle.

Looks like the code is set to 9.8 seconds. Too close maybe?

if ((now-last)>=9800 || firstrun)

If it’s the repetition rate, it’s probably OK. If it’s the time between doing its thing (therefore you add the time for that), it may well not be, depending on what it’s doing. I don’t know that software, I’d need to find it and check.

Thanks, i will try reducing it just incase. But just thinking, that data quality issue only started a few days ago.

Since then all i have done is:

Wire in the M-Bus and change the baud from 4800 to 2400 to get it talking.
Moved the Heatpump board from inside the heatpump casing to outside…

And it looks like its EmonESP thats not getting the data through? (Screen shot of EmonESP page)

That could be enough.

Thanks @Robert.Wall

Quick update.

Over the last hour, EmonESP reported 100% success rate
EmonCMS plotted 96%.

So im still not sure where the problem lies.


Looking a bit closer, I can see something similar here, its a higher success rate than yours but still something periodic in there:

1 Like

I have a sontext 531 which requires reading two pages of MBUS data so the feed interval for the mbus data is 20s rather than 10s for the kamstrup 403.

I also realise I have a few delays in the firmware timing that may well be pushing the timing out e.g: https://github.com/openenergymonitor/HeatpumpMonitor/blob/master/Firmware/Arduino/HeatpumpMonitor_AutoTemp_MultiPage/HeatpumpMonitor_AutoTemp_MultiPage.ino#L406

another here:
https://github.com/openenergymonitor/HeatpumpMonitor/blob/master/Firmware/Arduino/HeatpumpMonitor_AutoTemp_MultiPage/HeatpumpMonitor_AutoTemp_MultiPage.ino#L486

and here:
https://github.com/openenergymonitor/HeatpumpMonitor/blob/master/Firmware/Arduino/HeatpumpMonitor_AutoTemp_MultiPage/HeatpumpMonitor_AutoTemp_MultiPage.ino#L593

You could try reducing these. Perhaps try reducing them all to 50ms.

1 Like

Thank you @TrystanLea

I will give that a test this weekend and report back!

1 Like