. I have a socket with openbeken firmware uploaded and connected to Home Asaistant via mqtt. On the generated graphs, the minimum time interval is 6 seconds. It is possible to change this, where is it set?
What @ElektrodaBot will answer: I have a socket with OpenBeken firmware uploaded and connected to Home Assistant via MQTT. On the generated graphs, the minimum time interval is 6 seconds. Can this be changed, where is this set?
What will @ElektrodaBot answer :
I have a socket with openbeken firmware preloaded and connected to Home Asaistant via...
Fast answer . The minimum time step you see in the Home Assistant graphs is due to the fact that a socket from OpenBeken publishes MQTT packets every 6 s . To change this, you must set a longer (or shorter) publication interval in the firmware itself:
1. go to the IP address of the socket in your browser. 2. Open the Console tab. 3. type one of the following commands (depending on the OpenBeken version): - `SensorInterval 15` - sensor readings every 15 s. - `PowerMonitorInterval 15` - same, but only for power measurement systems - `mqtt_broadcastInterval 15` + previously `Flag 2 1` - constant dispatch of all channels every 15 s - (≥ v1.15.592) `VCPPublishIntervals 15` - common for voltage, current, power
4 Restart the socket or type `restart 1`.
After restart, the MQTT broker and Home Assistant will get data in a new rhythm, so the smallest interval between points on the graph will change from 6 s to the selected value.
---
Further explanation .
1. Where exactly does 6 s come from? OpenBeken has a built-in counter that: - every `SensorInterval` seconds queries the chips (BL0937/BL0942, CSE7766, etc.), - collates the results and immediately publishes them on the `tele/<dev>/SENSOR` and possibly `stat/<dev>/POWER` topics.
Default values depend on the template, but for many common sockets it is written 6 s - hence the identical step in the graph in HA.
2. Available parameters and version differences .
Command
From version
3.
What does
SensorInterval X`
always
global reading interval of all sensors
`PowerMonitorInterval X`
≥ 1.15.200
only for power meter, rest not affected
`Flag 2 1` + `mqtt_broadcastInterval X`
≥ 1.15.260
must. shipping all channels every X s, even unchanged
`VCPPublishIntervals X`
≥ 1.15.592
common voltage-current-power interval ("V, C, P")
.
Setting more than one command works by priority: `mqtt_broadcastInterval` > `VCPPublishIntervals` > `PowerMonitorInterval` > `SensorInterval`.
3. Setting in practice .
1 In the console, type for example. `SensorInterval 30` ➜ read and publish every 30 s. 2. you want clear but not too frequent power sampling? `PowerMonitorInterval 10`. Web traffic grows 3× slower than with 3-second samples and the graph is still smooth. 3. if you need a rigid periodic publication (e.g. for InfluxDB integration):
Code: Text
Log in, to see the code
. Then every 20 s a set of data flies, regardless of changes.
4. Effect check (diagnostics) .
- Install MQTT Explorer → connect to broker → observe `tele/<dev>/SENSOR` topic. - Count down the seconds between packets - must match the new value.
If you can see the correct interval in MQTT Explorer and the graph in HA is still 6s: 1. make sure your sensor is added by MQTT Discovery and not manually with the `scan_interval` parameter - HA responds immediately after receiving the message anyway. 2. remember that HA records only changes in value ; if between two publications the counter reports an identical power, a single point will appear in the database, which may look like a 'hole' in the timeline.
5. Recommendations and limits .
- Do not go below 2-3 s with ESP8266 - possible Wi-Fi clipping and MQTT buffer overflow. - Above 60 s the energy measurements are still reliable and the HA database grows more slowly - good for multiple sockets on the network. - A reasonable average for home monitoring is 10-30 s.
---
What's next? .
1 Provide the socket model and OpenBeken version in the thread if the described commands do not work - there are rare fork-builds with different syntax. 2. consider adding publication thresholds to send data only when something really changes : `VCPPublishThreshold 2 0.5 2` (ΔV 2 V, ΔI 0.5 A, ΔP 2 W). 3. if you plan to log a large archive, look at integrating `InfluxDB` or `MariaDB` - they are more efficient than the default SQLite.
Good luck! Should there be any questions or non-standard device behaviour, upload the console log and some frames from MQTT Explorer - we'll advise more precisely.
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.
Hmm, it's that Gemini (specifically AI Studio) not so 'lost', as he wrote:
Quote:
. The VCPPublishThreshold command is used for this. Suggested solution: Please try using the VCPPublishThreshold command in the device console to set thresholds beyond which data will be sent. Command syntax: VCPPublishThreshold [threshold_change_V] [threshold_change_W] [threshold_change_A]. [threshold_change_V] - by how many volts the voltage must change. [threshold_change_W] - by how many watts the power must change. [threshold_change_A] - by how many amps the current must change. Practical example: If you want data to be sent only if the voltage changes by at least 2V, the power by 5W and the amperage by 0.1A, type in the console: code Code VCPPublishThreshold 2 5 0.1
After executing this command, the device will ignore smaller fluctuations, significantly reducing the number of MQTT messages sent and 'thinning' the data in the graphs in Home Assistant. You can adjust these values to suit your needs by observing how often the data updates.
Generally I have a pump connected to this socket and wanted to observe more closely how it was running, and it sometimes runs for less than 6 seconds.
Added after 8 [minutes]:
Then confirmed, in my case "VCPPublishThreshold" will be the best. Because either nothing (or almost nothing) changes, or it changes very quickly, from 2 W to 1100 W.
>>21638380 .
My fault, I wrote imprecisely. I don't mean reducing the frequency of reporting, but increasing it, such a "magnifying glass".
If you are not "pumping", the reports can be every e.g. 15 seconds, but if you turn the pump on, even 500ms would be useful.
Below is my "conversation with AI.
True/not true ?
Quote:
This is how you can explain that on the graphs in HA the minimum quantum of time is 6 seconds?
AI answer:
Quote:
.
This is an excellent and very insightful question. If the threshold mechanism (VCPPublishThreshold) combined with stabilisation (changeDoNotSendMinFrames) should respond in about 0.5 seconds, why does the graph in Home Assistant show a constant minimum 'quantum' of time of 6 seconds?
The answer lies in the fact that there are two parallel reporting mechanisms running in the software, and the default mode of the device favours one of them.
Event (Threshold) Reporting: This is the VCPPublishThreshold. It works as we described - it sends data immediately (after a brief stabilisation) when a change in value exceeds a set threshold. It is a reactive mechanism.
Temporal (Periodic) Reporting: This is the mechanism you observe in the charts. It runs in the background and sends data at fixed intervals, regardless of whether the value has changed. It acts as a 'heartbeat' or 'keep-alive', informing Home Assistant that the device is online and what its current status is, even if it is unchanged.
Main Reason: Saving energy (PowerSave)
The most likely reason for the constant 6-second interval is the power-save mode enabled by default.
How it works: In PowerSave 1 mode (the default), the microcontroller (BK7231T) does not run at full power all the time. Instead, it performs a cycle:
Enter a light sleep state for a specified period of time.
Wake up.
Take measurements.
Send MQTT report.
Return to sleep.
Why 6 seconds: The duration of this 'sleep-wake-report' cycle is most likely set in the firmware to around 6 seconds. This is a compromise between responsiveness and the power consumption of the socket itself.
As a result, you observe on the graph the effect of this particular cycle. Even if the power fluctuations are too small to trigger threshold reporting (VCPPublishThreshold), the device still 'reports' with its current state every 6 seconds.
How do these two systems interact?
When the load is stable (or its changes are small): Power changes do not exceed a threshold. You then only see time reports, appearing regularly every 6 seconds.
When there is a large change (e.g. switching on a kettle): The power change exceeds the threshold. The threshold mechanism will act immediately, interrupting the 6-second cycle and sending the data immediately. After this event, if the power stabilises again, reporting will return to the regular cycle of every 6 seconds. On the graph, you would then see one point "out of rhythm" and then another already at the normal interval.
How do you check and change this?
You can carry out a simple experiment to confirm this theory.
Enter the OpenBeken console.
Turn off power save mode by typing the command:
code
Code
download
content_copy
expand_less
PowerSave 0
Confirm with Enter.
What happens now?
The device will be permanently active. The time reporting mechanism (6-second cycle) will be disabled or its frequency will increase dramatically. From now on data will only be sent to MQTT if the change in value exceeds the threshold defined in VCPPublishThreshold.
Effect on the graph: Points on the graph will stop appearing regularly. They will only appear at times of significant load change. If the load is perfectly constant, no new point may appear for many minutes.
Summary
The minimum time quantum of 6 seconds in the graphs is not due to delays in threshold reporting, but is the result of the device periodically waking up from PowerSave mode to send a periodic status report. This is the default safe behaviour, which can be changed by disabling PowerSave, which will move all reporting logic to the threshold mechanism.
