MQTT Client Received pubcomp for unknown message ID: XX

[Leviathan09]

Platform

ESP32

Assembly

I did the assebly by myself

nRF24L01+ Module

nRF24L01+ plus

Antenna

external antenna

Power Stabilization

Elko (~100uF)

Connection picture

• [ ] I will attach/upload an Image of my wiring

Version

0.7.36

Github Hash

ba218edbdb1b0a168e0c721bc2259fcc97c57f8a

Build & Flash Method

AhoyDTU Webinstaller

Setup

System Config is default Static IP Only 1 inverter, Intervall 6s, max reries 5 de.pool.ntp.org as NTP Longtitude and Latitude set with 45 min offset and pause during night MQTT Broker set with interval 0s, Broker is ioBroker No Display

Debug Serial Log output

No response

Error description

Since the update from 0.6.0 to 0.7.36 i recieve many MQTT log entries in my ioBroker like this

'Client Received pubcomp for unknown message ID: XX`

I didn't change anything accept updating to a newer version.

[lumapu]

Interessting. I have ioBroker here and two ESPs (8266 and 32). Both of them are connected to the mqtt.0 instance. If I check my log in ioBroker, I can't see anything regarding your reported problem. Do you use username and password for MqTT?

[Leviathan09]

Interessting. I have ioBroker here and two ESPs (8266 and 32). Both of them are connected to the mqtt.0 instance. If I check my log in ioBroker, I can't see anything regarding your reported problem. Do you use username and password for MqTT?

Yes, username and password is used but without any special characters or something, just alphabetic character and numbers

[rmayergfx]

Check your mqtt topics, they changed as result of an issue with Home Assistant. Bu sure to select the right ones after update 0.7.x https://github.com/lumapu/ahoy/issues/1066

TIpp: Set ntp to your Router IP, this is faster and more stable. You should block AhoyDTU from internet by setting or activating the rules inside your Router.

[Leviathan09]

Check your mqtt topics, they changed as result of an issue with Home Assistant. Bu sure to select the right ones after update 0.7.x #1066

TIpp: Set ntp to your Router IP, this is faster and more stable. You should block AhoyDTU from internet by setting or activating the rules inside your Router.

iobroker is listening to all mqtt topics, so Home Assistant stuff does not applie here.

Good hint with the router IP for ntp

[rmayergfx]

Listening to all topics is not the problem, can you see all the topics from ahoydtu in iobroker? The update changed the structure, so it could be possible that you need to select the right topic again. Is TasmoAdmin in use? this can also be a reason for the messages!

[BerziOnline]

I have the same setup and it happens after a few hours the same in my case. Restarting the AhoyDTU or the MQTT adapter in my iobroker fixes the problem directly for the next few hours. It doesn't play a role which side of the MQTT connection I restart, I just have to do it for one side and it's directly working again. But after a few hours the logging starts again with the same messages and the DTU stops reacting on limit control commands over MQTT anymore. (but some values are still updating from DTU to broker, it just seems that the DTU stops reacting on MQTT commands)

[BerziOnline]

Because the DTU has freezed right now again, I checked the logs even more on iobroker side and I saw, that the reason is a huge amount of these error-messages:

The error message sometimes changes:

I have this problem since 4 days, but one day it wasn't that bad obviously: (very strange)

Right now I am getting these messages (although the DTU is full functional and always reachable - distance to the router is 20cm):

The log to the same time now on the DTU side:

Rebooting the DTU directly stops the error messages in the iobroker logs and it's working again.

I have no idea why this is happening. I also investigated the logs trying figure out when this error message starts, but I couldn't see any strange behaviour or commands to the DTU before.

[BerziOnline]

The bug comes with the step from 0.7.26 to 0.7.36 very sure.

I went over to dev v0.7.45 and the problem still exists. A downgrade to 0.7.26 eliminates the full problem directly.

[Leviathan09]

The bug comes with the step from 0.7.26 to 0.7.36 very sure.

I went over to dev v0.7.45 and the problem still exists. A downgrade to 0.7.26 eliminates the full problem directly.

Good to known that a downgrade help. In the meantime i changed the log level of the mqtt adapter to warning which also helped

[I2e4per]

I had this issue too. I am controlling two inverters over iobroker -> jscript -> mqtt. (Powerlimit) but i am still on 0.7.45. The only thing i messed around with was that the values i send to the inverter were of type float and not of type string. It expects type string, so i cast them to string. Furthermore, i rounded the values down to only full decimal values. Reseted the inverter, rebooted ahoy dtu and since then, this error messages are gone and everything seems working fine.

[Leviathan09]

I use this script HoymilesZeroExport for controlling my inverter. But maybe the float/string part could be a problem when ahydtu reports the stuff back to iobroker with mqtt

[I2e4per]

I had a quick look at this *.py script. as far as i can see there is a cast from float to int, which is basically sort of the same i am doing by rounding to full decimal values. Therefore, yes. This could be related.

[I2e4per]

see def SetLimit(pLimit): ... NewLimit = CastToInt(pLimit*Factor)

So the def CastToInt() Method should be changed to Cast ToString() or additional be implemented. A simple str(..) of the result might also do the trick already.

[I2e4per]

The question is, wht exactly ahoy dtu or iobroker is expecting here.

[BerziOnline]

I don't think it's the source of the problem. The data sent from my iobroker to the inverter is always a string, because I am using not the percentage as limit, I am using the absulte values. So the limit is a built string with the number and the unit sign "W". This is how the mqtt limit field distinguishes if you want to have an absolute limit or not. So the only chance giving to the same datapoint an absolut limit is in adding "W" to your number, what is only possible if you build a string before. It's described in the documentation of the MQTT part of AhoyDTU.

So as a conclusion: I already just sending the limit control as a string, because the AhoyDTU exactly needs that to understand it as an absolute value.

[Airwalk007]

Ich muss diese issue nochmal aufwärmen:

Mein Setup: AhoyDTU 0.8.111 mit 3x HM-800, HoymilesZeroExport-Skript, VzLogger, ioBroker mit MQTT-Server

Seit einigen Versionen (0.8.97 - 0.8.111) habe ich im ioBroker-Protokoll alle 10 Sekunden die folgende Fehlemeldung der MQTT-Servers:

Client [ahoydtu] Received pubrel for unknown message ID

Die IDs wiederholen sich alle 10 Sekunden bzw. werden irgendwann immer mehr ...

Diese "Infos" treten nach einigen Stunden nach dem Neustart der Ahoy DTU (oder der MQTT-Instanz) auf. Ich hab nun schon mehrere Ansätze verfolgt - vom Abschalten des HoymilesZeroExport-Skripts über das Aufsetzen einer neuen MQTT-Instanz im ioBroker und die Veränderung des Abfrageintervalls der AhoyDTU mit den Wechselrichtern (höher und niedriger als 10 Sek.) ... nichts hat geholfen (und die Fehlermeldung kam immer alle 10 Sekunden - egal, wie das Abfrageintervall in der AhoyDTU eingestellt ist). MQTT-Intervall steht auf 0 (Standard) in der Ahoy-DTU.

Hat irgendwer noch eine Idee wo man schauen könnte? Diese Problematik trat die letzten Monate nie auf und kam (meiner Meinung nach ohne Veränderungen am Setup) plötzlich. Die Ahoy-DTU habe ich immer geupdated (und die Config übernommen/angepasst) - seit 0.6.xx .... liegt darion vielleicht das Problem? Mich machen die 10 Sekunden stutzig (und die Fehleranzahl - es sind jeweils 50, 52 oder mal 118 Fehler gleichzeitig) ...

[RALFISBORN]

Gleiches Problem hier bei IOBroker MQTT Adapter V5.2.0 und AhoyDTU V0.8.83

[lumapu]

ich verwendet auch ioBroker, kann den Fehler aber garnicht sehen 🫤

[RALFISBORN]

bisher konnte ich den Fehler leider nicht mehr reproduzieren.