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. Summary generated by the language model.