Pow-K+ stops sending payload to MQTT broker after few hours

[yoabau]

Describe the bug
Referring to bug described short after release of the firmware 2.3 last year
I made a new test this week in the hope that the bug was fixed meanwhile but the same problem occurs. The MQTT broker receives data but the device stops sending after few hours. The test started on the 7th of January and at 22: 28 and stopped on the 8th of January at 15:56. The LED blinks green and blue, but I can neither ping its static IP address nor access its web server. I need to unplug, wait 1min and the and plug it again before accessing web server again.

Screenshots
ref. attached data from MQTT broker for more info.

Hardware information:

• Country: [Norway]
• Meter: [Kamstrup, Model: 6841121BN243101040]
• Encryption enabled [no]
• AMS reader: [Chip: esp32s2 (160MHz), Pow-K+]

Relevant firmware information:

• Version: [e.g. 2.3.9]
• MQTT: [yes, SSL]
• MQTT payload type: [JSON flat]
• ENTSO-E API enabled: [yes]

ams_3203_264_6_device_t_variable_ANTYEZKXAX.csv

[ArnieO]

Sounds like it disconnects from your Wi-Fi?
Do you see any red error blinks on the device?
Any chance this could be due to an IP conflict?

[yoabau]

@ArnieO :
I not sure if the ams reader is disconnecting from Wifi, but the LED flashes only blue and green, and not red.
There is unlikely an IP conflict, because I configured my router with 2 separate areas (DHCP and static), where only 3 devices use static IP for home automation.
But, when the ams reader is configured to communicate with my HomeAssistant's MQTT broker, there is no such communication failure. The ams reader sends data at regular interval without being disconnecting:

[ArnieO]

OK, I see - and agree with you: This is unlikely to be an IP conflict.
The issue occurs while sending data to an external (cloud) MQTT broker (Ubidots).

Considering your old bug report (#738 (comment)) I see that @gskjold did not follow up in that thread - so it is possible that he has not investigated this any further; sorry for that.

You proposed in that thread to borrow us access to your credentials at Ubidots.
Could you email me ([email protected]) those credentials?
I will then ensure this is looked into and followed-up.

[avandorp]

You could try using an MQTT bridge between the amsReader and Ubidots. The mosquitto broker e.g. has a bridge mode. Then you could easier analyze with mosquittos logs whether the amsReader stops sending MQTT messages or whether Ubidots stops accepting them.

[yoabau]

You could try using an MQTT bridge between the amsReader and Ubidots.

That's a good idea, but I'm sure if this comment was ment to me or Utilitech?
The payloads between HA's MQTT broker (mosquitto) and Ubidots are different. Do you suggest to set up a new local MQTT broker with mosquitto set up as a bridge and publish with a flat JSON format?

[avandorp]

You could try using an MQTT bridge between the amsReader and Ubidots.

That's a good idea, but I'm sure if this comment was ment to me or Utilitech? The payloads between HA's MQTT broker (mosquitto) and Ubidots are different. Do you suggest to set up a new local MQTT broker with mosquitto set up as a bridge and publish with a flat JSON format?

I'd use what you currently use as payload and just put a bridge in between.

[gskjold]

After some testing I suspect this is triggered by a memory leak. At least in my case the available memory keeps reducing until it suddenly stops working.