Daily and monthly values exhibit drops

[protobock]

Describe the bug When plotted in Home Assistant, we can see that daily and monthly produced or used energy sometimes fall to zero and then come back to correct value. This does not happen with total produced or used energy.

To Reproduce Steps to reproduce the behavior: Just monitor these periodic values in Home Assistant

Expected behavior No drops to zero

Screenshots See SC

Hardware information:

• Country: [Switzerland]
• Meter: [Kamstrup 8660]
• Encryption enabled [yes]
• AMS reader: [Pow-K+]
• M-bus adapter (if applicable): N/A

Relevant firmware information:

• Version: [2.2.8 (and earlier)]
• MQTT: [yes]
• MQTT payload type: [HomeAssistant]
• HAN GPIO: [?]
• HAN baud and parity: [2400 8N1]
• Temperature sensors [?]
• ENTSO-E API enabled: [? ]

Additional context Add any other context about the problem here.

[ArnieO]

@gskjold : Strange error. Could it be an overflow error?

[gskjold]

Doubt it. If I interpret this correctly, this is from the realtime sensors. How is the deice uptime? Could it be rebooting at these points?

[protobock]

Some precisions:

Daily used and monthly used energy drop to zero at the same time. I mean, each time daily used energy drops, monthly used energy drops too. Total energy used nerver drops.

Daily and monthly produced energy also have the same drops but they also exhibit peaks every hour. See attached SC. 1Total energy produced has no drops and no peaks.

[gskjold]

1. How is uptime? Does it reboot on any of these drops?
2. Can you get me a verbose debug containing data from your meter? For info on how to do it: https://amsleser.no/blog/post/24-telnet-debug

[protobock]

1. How is uptime? Does it reboot on any of these drops?

I can see on the UI that the PowK has been up for only 2 hours. So it has indeed rebooted. And the last drop was at 17h33 (2h20 ago).

2. Can you get me a verbose debug containing data from your meter? For info on how to do it:

I am now getting a debug log. Do you want the log to contain a moment when there is a drop?

[gskjold]

I think any payload will do at first, just to identify what kind of data we are getting.

In case this is related to wifi issues, you could also disable auto reboot (found in config, in wifi tile)

[protobock]

I think any payload will do at first, just to identify what kind of data we are getting.

OK so here is a log putty 1.log

[protobock]

In case this is related to wifi issues, you could also disable auto reboot (found in config, in wifi tile)

I have just disabled auto reboot. The device rebooted to update the configuration and that did provocate a drop (as expected)

[gskjold]

Thanks. This is exactly the same data as the Danish meters, which should work perfectly fine. Not sure what could trigger the reboots, but we'll wait a bit and see if disabling the auto reboot changes anything for us.

What is the RSSI display showing on the top? What kind of payload have you configured for the MQTT connection? Did you have to configure any multipliers in the meter configuration?

[gskjold]

Sorry, I see you already answered about the payload in first post, I should have checked that

[protobock]

What is the RSSI display showing on the top?

-53dB Wifi AP is an Unifi AP AC Lite

Did you have to configure any multipliers in the meter configuration?

0.1 for kWh

[protobock]

but we'll wait a bit and see if disabling the auto reboot changes anything for us.

Well, there was a reboot/drop tonight.

[gskjold]

Thanks for the update, I have been looking at parts of the code to try and work out what could cause this, but have not yet identified anything that would cause reboot. I have some idea of improvements though.

Do you know if the reboot happens at the same minute every time? Ex 16:33, 17:33, 18:33 etc.. I know we had two cases at some point that had a similar issue which turned out to be related to wifi. I found one of the emails where the customer moved the device closer to the wifi to fix the issue. Of course this is not an option for a pow-k, but curious if this is related.

Do you have more than one access point?

Also wondering if you have prize zone configured and enabled? Just to know if I should dive into that code or not.

[gskjold]

Regarding Unifi config, here is mine:

This is a IoT-only network that I have configured at my house, which is why it only has 2.4GHz. If you have a shared network, it is no problem to have both 2.4GHz ang 5GHz enabled. I recommend having "Optimize IoT WiFi Connectivity" and "Legacy Support" ON and "UAPSD" and "Enable Fast Roaming" OFF.

[protobock]

Do you know if the reboot happens at the same minute every time? Ex 16:33, 17:33, 18:33 etc

Minutes are completely random.

Do you have more than one access point?

Yes. But only one in the basements. I think the Pow-K does never roamed to another AP because the signal of the AP in the basements is much stronger than the other ones'.

Also wondering if you have prize zone configured and enabled?

No

[protobock]

This is a IoT-only network that I have configured at my house, which is why it only has 2.4GHz. If you have a shared network, it is no problem to have both 2.4GHz ang 5GHz enabled. I recommend having "Optimize IoT WiFi Connectivity" and "Legacy Support" ON and "UAPSD" and "Enable Fast Roaming" OFF.

I'll give it a try later today. I am now arriving at work :-(

I want to thank you very much for the time you are spending on my case

[gskjold]

I think the Pow-K does never roamed to another AP because the signal of the AP in the basements is much stronger than the other ones

Pow-K will never do any roaming after connection unless the connection is lost. The wifi driver is known to sometimes be bad at selecting the optimal access point though (See #393) But judging from your RSSI, it has most likely selected the closest AP.

I'll give it a try later today. I am now arriving at work :-( I want to thank you very much for the time you are spending on my case

No problem, I hope we can figure out the cause for this issue :)

[protobock]

I think I could figure out why the PowK disconnected tonight at 3:01. I had ticked "Nightly Channel Optimization" on my Unifi controller. And the AP has indeed changed channel at 3:01. But the PowK should not have rebooted and the up time should not have been reset. I have now excluded my basements AP from the nightly channel optimization.

Let's wait to check if there is another drop today (none so far).

I do not have the same options as you in advanced settings on my Unifi controller. I am running version 7.3.83 on an USG. No option for legacy support. But I clearly remember seeing this option. Maybe it was dropped in a recent update...

[ArnieO]

But the PowK should not have rebooted and the up time should not have been reset.

I think it will - if you have "Auto reboot on connection problem" activated.

[protobock]

I think it will - if you have "Auto reboot on connection problem" activated.

I had deactivated this option yesterday evening

[ArnieO]

I think it will - if you have "Auto reboot on connection problem" activated.

I had deactivated this option yesterday evening

Then I agree - it should not have rebooted!

[gskjold]

Most likely there is an issue here. Interesting to know that there is such thing as "Nightly Channel Optimization", this could be a clue to what is triggering the problem.

[protobock]

I was hoping the problem was solved by disabling "auto reboot on connection problem" because I had had no drop since 3AM. But a drop has just happened and I can see de PowK has rebooted (up time is 15 minutes).

[protobock]

Unifi controller's logs shows no sign of the PowK disconnecting and reconnecting during the drop. So it seems it remains connected while rebooting, Or the disconnection is too short for the controller to "notice" it?

[gskjold]

Ok, and the channel optimization is also off now? The downtime is probably too short for the controller to register

[protobock]

Ok, and the channel optimization is also off now?

Yes, it is OFF for the AP the Pow-K is connected to. Besides, the drops occur randomly and the nightly optimization happens at 3AM

[ArnieO]

The way I see it, there are two issues going on with your device:

1. The Pow-K reboots every now and then, at random times. This should not happen.
2. Apparently linked to the reboots, there are errors in the accumulated energy reported to HA.

Regarding issue 1 We have seen (very few, but still some) units with some kind of hardware error on the ESP module, causing them to do occasional reboots at random intervals (I have seen 1-2 times per day). We replaced one such unit and got the old back for long term testing, and see that identical HW with identical firmware behaves correctly (never reboots) on the same Kamstrup meter. So we are quite confident the issue is HW.

Regarding issue 2 As you are the only one having reported this issue, my hypothesis is that is it linked to Issue 1 in some way. Maybe there are issues with the flash memory in your device; I can only speculate!

Bottom line I would like to send you a new replacement Pow-K, as I suspect yours has a hardware issue. (At no cost for you, of course.) Please contact me on post@amsleser.no for the practical arrangements.

[protobock]

Thank you very much for your support. I really appreciate a lot!

Maybe there are issues with the flash memory in your device

It would surprise me because my Home Assistant OS is running on an Intel NUC and the database is MariaDB in a docker on my Synology NAS.

[ArnieO]

Thank you very much for your support. I really appreciate a lot!

Maybe there are issues with the flash memory in your device

It would surprise me because my Home Assistant OS is running on an Intel NUC and the database is MariaDB in a docker on my Synology NAS.

Sorry, I was not clear! 😄 What I meant was the flash memory in the ESP32-module of the Pow-K device.