Why does OpenBeken cause ioBroker to spam warnings like "Client [...] Message ... deleted after 11 retries" over MQTT?
The warning spam is caused by the MQTT QoS setting: OpenBeken’s QoS 2 publishing does not work correctly with ioBroker’s Sonoff adapter, and switching OpenBeken to QoS 1 stops the repeated "deleted after 11 retries" messages [#20944778][#21116324] The fix was tested with the PR that changes QoS from 2 to 1, and the reporter confirmed that after flashing it, the warnings disappeared and both the minimum setup and the power-meter setup worked normally [#20944778][#20945916] The developer later said this likely means QoS 2 is not implemented in the MQTT library used by OpenBeken, so QoS 1 is the correct workaround [#21116324]
Hey guys, I'm new to using the open source alternative software OpenBeken. I ordered some cheap current measurement power plugs from AliExpress and flashed the OpenBeken SW.
Everything worked well. I connected the power plug via MQTT to my ioBroker.
Now I get a ton of warning messages from the device, but I don't know what's wrong and why these messages appear. Can you please help me understand what's going on?
The message itself is listed. There are no further details. Today I found over 38k messages in the log. See attachment. I found via google more users of OpenBeken in combination with ioBroker which have this problem, but nobody has a solution.
The warning message in the error log appeared before I configured the flags. Is there something wrong?
// interval for automatic publish of tasmota tele/sensor and tele/state
static short g_teleState_interval = 120;
static short g_teleSensor_interval = 3;
Regarding the ioBroker message, I have tried searching on their Github but I haven't found any explanation what this might mean. I can change OBK behaviour quickly per request, but I would need to know what's going wrong in order to make a fix, and this message is so crypting that I have no idea what it relates to. Maybe we should first try asking ioBroker guy what does that mean so I can figure out a way to fix it...
Thank you for your reply and time spent on this issue.
I have searched around regarding the failure behavior. I found a lot of people reporting these warnings. But no one was able to fix it. Someone wrote that it is related to MQTT messages without acknowledge flag. But I am not familiar enough to understand the behavior.
I am trying to figure out in a German forum the ioBroker problem. Until I found the root cause, I tried a different MQTT adapter. There I got this log and the connection is automatically closed. Can you tell me what is happening?
There i got this log and the connection is automatically closed. Can you tell me what is happening?
For a start, I'd suggest to try connecting with the simplest device with no extra power metering topics. The disconnection reason is not shown on the log, it's just 256 - disconnected.
I have now tried the minimum configuration.
1 button and a relay configured in OpenBeken. Status/Flags - only flag 30 (for iobroker).
I noticed that after connecting the warning messages from the "[SH-EM-EB-Rolladen]" device are now less than the other one with full energy meter configuration.
There is a log that shows the behaviour (I know there are no deep details regarding the messages):
The ACK message is the response from the broker after receiving a published message. Sorry, it is not an ACK flag.
I also found out that the ack message should not be the problem.
Thanks for reminding me about that Github discussion. I've checked it out and replied there, but I still don't know what OBK is exactly missing that is required for ioBroker to stop showing warnings.
I have now flashed both units with your new SW version and it works. I configured the one back to the power meter settings and that works too. No warning spam in the log.
That was an amazing discovery of yours!
There are two little things: How is it possible to get yesterday's energy consumption?
And the unit for energy consumption is missing:
If you can see, I have activated the flag: It is displayed on the OpenBeken main page as kWh, but it is sent to the MQTT broker in Wh. I think if the user sets the flag, it should also be published in the same unit?
This means I need to add ability to set QOS in flags, so all ioBroker users can set it to 1, I guess.
TPTim wrote:
There are two little things:
How is it possible to get yesterday's energy consumption?
I think I can add it for you, it's in StatusSNS in Tasmota:
TPTim wrote:
And the unit for energy consumption is missing:
If you can see, I have activated the flag:
It is displayed on the OpenBeken main page as kwh, but it is sent to the mqtt broker in wh.
I think if the user sets the flag, it should also be published in the same unit?
To which publishing are you referring? If you are talking about StatusSNS, then I don't see energy unit there in Tasmota.
I am reffering to tele/SENSORS. This is used by the adapter as defold data source.
Best Regards
Tim
Hello Tim,
It's great to hear that you have the QOS flag set correctly for the IOBroker SonOff Adapter.
To get the JSON data overview, there is typically a way to make an HTTP request to the device running Tasmota to retrieve its status or sensor data in JSON format. This can usually be done by accessing the Tasmota device's web server using its IP address and the appropriate command. The command to retrieve sensor data is usually something like `http://<Tasmota-IP>/cm?cmnd=Status 10`.
Regarding the `tele/SENSORS` topic, this is indeed the default payload for sensor data, which is published at regular intervals (as defined by the `TelePeriod` parameter in Tasmota). If you need to retrieve this data manually, you could publish a command to the topic `cmnd/<device_topic>/STATUS` with the payload `10`, which should prompt the device to publish its sensor data to the `tele/SENSORS` topic.
To clarify, `Status 10` will give you the STATUS10 JSON result which contains the `StatusSNS` information, including sensor readings, which should look similar to the JSON snippet you are referring to.
Regarding the image you've posted, it appears to be a JSON output showing the `StatusSNS` object with various energy readings, such as "Yesterday" and "Today" energy usage. If you're looking to obtain similar data, ensure that your Tasmota device has energy monitoring capabilities and the Tasmota firmware is configured correctly to report this data.
If you could provide me with the model of your Tasmota device or any further specifics about your setup, I could perhaps give you a more detailed walkthrough on retrieving the data you're looking for.
Best regards, ElektrodaBot
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
Hey @p.kaczmarek2, Thanks for your feedback. Sorry for the late reply, I'm working on other smart home stuff at the same time :)
Regarding your snippet, I tried to get the energy data as 'yesterday'. But my SNS data does not provide that information. This is what I get back by reading 'http://192.168.178.161/cm?cmnd=Status%2010':
And the web view does not provide it either:
The hardware is an energy meter plug with a BL0937 power meter chip:
Is it just a setting of open beken, or is it related to the firmware used?
Is it just a setting of open beken, or is it related to the firmware used?
Best Regards
Tim
Tim,
Based on your description and the images you've provided, it seems that your Tasmota device is not reporting the "Yesterday" energy usage as part of the `StatusSNS` payload. This could be due to a few reasons:
1. Firmware Support: Ensure that your Tasmota firmware version supports the feature of tracking and reporting "Yesterday" energy usage. You might need to update to the latest available Tasmota firmware version that includes this feature.
2. Configuration: The Tasmota device needs to be configured correctly to track and report energy usage over time. You may need to enable specific features or set up the device to start recording these statistics.
To enable periodic energy monitoring statistics, you can use the `EnergyReset` command:
Code: Text
Log in, to see the code
This will reset all energy counters and start recording from that moment.
3. Device Compatibility: Ensure that the BL0937 chip in your device is properly supported by the Tasmota firmware and is capable of providing the "Yesterday" energy data.
4. Energy Monitoring Settings: It's possible that the device needs additional configuration to track and retain historical energy data. In the web interface screenshot, it mentions "Periodic Statistics disabled. Use startup command `SetupEnergyStats` to enable function." You may need to enter the command console on your device's web interface and execute the command `SetupEnergyStats` to enable these statistics.
In the Tasmota console, you can try the following command:
Code: Text
Log in, to see the code
This command might need to be adjusted according to the proper syntax for your Tasmota firmware version.
5. MQTT and Web Server: If you're primarily using MQTT with Tasmota, make sure that the MQTT broker is correctly receiving and logging this data. If you're using the web server, ensure you're accessing the correct endpoints.
If you've checked all these aspects and the issue persists, you may want to look into the release notes or documentation of the Tasmota firmware you are using to find any specific notes about energy monitoring.
Lastly, if you're still not seeing the expected data, consider reaching out to the Tasmota community or checking the Tasmota GitHub issues page for similar cases or potential solutions.
Best regards, ElektrodaBot
You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
✨ The discussion revolves around issues faced by a user after flashing OpenBeken firmware onto a current measurement power plug from AliExpress and connecting it to ioBroker via MQTT. The user reports receiving a significant number of warning messages in the ioBroker log, specifically related to MQTT message acknowledgments. Other participants suggest adjusting the QoS (Quality of Service) settings, with a consensus that setting it to QoS 1 resolves the warning spam. The conversation also touches on the need for proper configuration of the device to track energy usage, including the potential for firmware updates to support additional features like reporting yesterday's energy consumption. The final resolution involved merging a pull request that improved MQTT stability and functionality. Generated by the language model.
TL;DR: Users who saw 38k log messages in one day found that changing OpenBeken MQTT from QoS 2 to QoS 1 stopped the ioBroker Sonoff Adapter warning storm. One maintainer summed it up: "QOS 1 is the solution." This FAQ helps OpenBeken and ioBroker users fix Message X deleted after 11 retries, understand the cause, and verify the working firmware path. [#21116324]
Why it matters: This issue can flood ioBroker logs, hide real faults, and make otherwise stable energy-monitoring plugs look broken.
Option
ioBroker Sonoff Adapter result
MQTT behavior in thread
Practical takeaway
OpenBeken with QoS 2
Warning spam appears
Messages retried and deleted
Poor fit for this adapter setup
OpenBeken with QoS 1
Warnings stopped
Devices worked after flashing test build
Best fix reported in the thread
Tasmota-style payloads/StatusSNS
Used as compatibility reference
JSON fields like Yesterday shown as comparison
Helpful model, not the direct fix
Key insight: The thread points to a protocol-handling mismatch, not a bad relay, bad plug, or bad MQTT interval. In this setup, lowering MQTT QoS from 2 to 1 solved the problem and was later merged into the main OpenBeken code line. [#21210433]
Quick Facts
OpenBeken defaults shown in the thread were g_teleState_interval = 120 seconds and g_teleSensor_interval = 3 seconds, so sensor traffic can be much more frequent than state traffic. [#20929505]
One user reported over 38k messages in the ioBroker log before the fix, showing how fast retry-based warning spam can grow. [#20927955]
The ioBroker Sonoff Adapter warning format was consistent: Message X deleted after 11 retries, which indicates repeated resend attempts before the adapter dropped the message. [#20944572]
The successful test build changed MQTT QoS from 2 to 1; later posts reported it worked on both a BK-T plug and an N-module socket. [#21116445]
The problematic energy plug used a BL0937 metering chip, and its HTTP status example was queried with Status 10 from the device web endpoint. [#20972750]
Why does OpenBeken spam ioBroker logs with warnings like "Client [device] Message X deleted after 11 retries" when using the Sonoff MQTT adapter?
It happens because this OpenBeken-plus-ioBroker combination was sending MQTT traffic in a way the Sonoff Adapter kept retrying and then dropping. The thread’s working diagnosis is that QoS 2 caused the mismatch, while QoS 1 stopped the warnings. One affected setup produced tens of thousands of log entries, even with devices otherwise connected and publishing. [#20945916]
How can I fix OpenBeken MQTT warning spam in ioBroker by changing the QoS level from 2 to 1?
Flash a build that changes OpenBeken MQTT QoS from 2 to 1. 1. Open the GitHub pull request build linked in the thread. 2. Download the OTA artifact from the build summary. 3. Flash the device and retest in ioBroker. After that change, the user reported both plugs worked again and the warning spam disappeared, including the unit with full energy-meter settings. [#20945916]
What is MQTT QoS, and why did QoS 1 work with ioBroker Sonoff Adapter while QoS 2 caused problems in OpenBeken?
"MQTT QoS" is a message-delivery setting that controls how an MQTT client sends data and expects confirmation, with higher levels requiring more handshake steps. In this thread, QoS 1 worked because the maintainer suspected QoS 2 was not implemented correctly in the LWIP MQTT library used by OpenBeken. That would explain why ioBroker kept retrying and deleting messages, while QoS 1 stayed stable. [#21116324]
What does the ioBroker warning "Message deleted after 11 retries" actually mean in MQTT communication?
It means the adapter retried a queued MQTT message 11 times and then dropped it. In the logs, ioBroker repeatedly printed lines such as Client [device] Message 8 deleted after 11 retries, which shows the problem was not a single publish failure but a repeated acknowledgement or delivery failure. The warning points to transport-level handling, not to a wrong relay state or wrong power reading. [#20944572]
How do I change the TELE/STAT publish intervals in OpenBeken with TasTeleInterval to reduce MQTT traffic?
Use the TasTeleInterval command to change the automatic Tasmota-style publish intervals. The maintainer stated that the default values were 120 seconds for tele/state and 3 seconds for tele/sensor. Increasing the sensor interval reduces message volume and can make troubleshooting easier, but it did not solve the retry warning by itself in this thread. [#20929505]
Where can I download the OTA firmware file from an OpenBeken GitHub pull request build?
Get it from the pull request build artifacts page. 1. Open the PR. 2. Click Details, then Summary. 3. Scroll down to the generated firmware files and download the OTA image. That was the exact path the maintainer gave when the user asked how to obtain the test firmware without being familiar with GitHub. [#20945133]
How do I request OpenBeken or Tasmota-style JSON data with an HTTP command like Status 10?
Send an HTTP request to the device using http://<device-ip>/cm?cmnd=Status%2010. The thread shows that this returns a JSON-style status payload comparable to Tasmota StatusSNS, and one user tested it directly against 192.168.178.161. This was used to check whether fields like Yesterday energy were present. [#20972750]
Why does OpenBeken disconnect from some MQTT adapters with a generic reason like "256 - disconnected"?
The thread does not show a precise root cause, only a generic disconnect code. The maintainer explicitly said the log showed only 256 - disconnected and did not include the real reason, so he suggested testing first with the simplest device and no extra power-meter topics. That makes this an incomplete diagnostic signal, not a definitive fault code. [#20943750]
What is the BL0937 power metering chip, and how is it used in OpenBeken energy-monitoring plugs?
"BL0937" is a power-metering chip that measures electrical usage data in smart plugs, including the values OpenBeken publishes for energy monitoring. In the thread, the affected plug used a BL0937-based board, and OpenBeken exposed live energy data in its web view and MQTT payloads. The chip itself was not identified as the cause of the retry spam. [#20972750]
How can I get yesterday's energy consumption from an OpenBeken power plug, and is it supported for BL0937 devices?
You cannot assume it is available by default. In the thread, the user queried Status 10 and checked the OpenBeken web view, but Yesterday was still missing on a BL0937 plug. The maintainer said he could add it because Tasmota includes that field in StatusSNS, which means the thread treated it as a firmware-feature gap rather than a simple user setting. [#20949057]
Why is energy shown as kWh on the OpenBeken web page but published as Wh to tele/SENSORS over MQTT?
Because the web UI unit flag did not automatically change the MQTT payload unit in this case. The user reported that OpenBeken displayed kWh on the main page, but tele/SENSORS still published Wh, even after the relevant flag was enabled. The maintainer replied that he did not see an energy unit in Tasmota StatusSNS, so this mismatch remained unresolved in the thread. [#20956546]
OpenBeken vs Tasmota for MQTT with ioBroker: which one is more compatible for energy-monitoring smart plugs?
In this thread, OpenBeken became compatible enough for ioBroker after switching to QoS 1, while Tasmota was mainly a reference for expected JSON fields and payload structure. OpenBeken worked on real energy-monitoring plugs after the patched build, and the maintainer later merged that fix. If you need this exact ioBroker Sonoff Adapter setup, patched or current OpenBeken was the confirmed working path here. [#21210433]
What is the difference between tele/SENSORS, TELE/STAT, and StatusSNS in OpenBeken or Tasmota MQTT payloads?
tele/SENSORS is the default periodic sensor data source the ioBroker adapter used in this setup. tele/state is a separate automatic state publish channel with its own interval, shown as 120 seconds by default. StatusSNS is the JSON block returned by Status 10 over HTTP and was used in the thread as the reference view for fields like energy values, Today, and potentially Yesterday. [#20956546]
If OpenBeken QoS 2 is not fully implemented in the LWIP MQTT library, what side effects should I expect in Home Assistant or ioBroker?
Expect retries, dropped messages, noisy logs, or unstable acknowledgements. The maintainer wrote, "I suspect that QOS 2 is not implemented in our MQTT library... that's why QOS 1 is the solution," and other testers confirmed the QoS 1 PR worked with Home Assistant MQTT on BK-T and N-module devices. The edge case is long-term stability, which testers said still needed overnight confirmation. [#21116371]
What is the best minimal OpenBeken test configuration for troubleshooting MQTT issues before enabling full energy-meter topics?
Use one button, one relay, and only flag 30 for ioBroker first. The user tried exactly that minimal setup and saw fewer warnings than on the full energy-meter configuration, which made it easier to separate MQTT transport issues from extra topic volume. That is the best thread-backed baseline before re-enabling BL0937 power topics and other telemetry. [#20944572]