Add ability to throttle HLW8112 MQTT publishing#2139
Open
wsot wants to merge 1 commit into
Open
Conversation
HLW8112_ScaleAndUpdate() published all 12 channels every second through unconditional CHANNEL_Set calls causing a high volume of MQTT messages and no mechanism to limit them. This change adds the same pattern of change-threshold + min/max frames as used in the BL drivers. For consistency with BL/CSE, VCPPublishIntervals console command is used, and can be persisted via autoexec.bat. This doesn't cause conflict because the drv_bl_shared where it is otherwise defined is not included in HLW8112 builds. (The inclusion of BL/CSE is explicitly #unset if OBK_VARIANT_HLW8112 is used). A new HLW8112_PublishIfNeeded helper tracks the last-published float value per channel (CHANNEL_Set compares integers and would miss sub-integer drift) and publishes with CHANNEL_SET_FLAG_FORCE so a due heartbeat is never suppressed by the integer-equality short-circuit. The first frame after boot force-publishes every channel via a one-shot flag, avoiding any dependency on when VCPPublishIntervals runs relative to driver init. Per-quantity thresholds are fixed local constants. HLW8112_Set_EnergyStat publishes immediately on user set/clear/reset. Assistant-model: Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
HLW8112_ScaleAndUpdate() published all 12 channels every second through unconditional CHANNEL_Set calls causing a high volume of MQTT messages and no mechanism to limit them.
This change adds the same pattern of change-threshold + min/max frames as used in the BL drivers. For consistency with BL/CSE, VCPPublishIntervals console command is used, and can be persisted via autoexec.bat. This doesn't cause conflict because the drv_bl_shared where it is otherwise defined is not included in HLW8112 builds. (The inclusion of BL/CSE is explicitly #unset if OBK_VARIANT_HLW8112 is used).
A new HLW8112_PublishIfNeeded helper tracks the last-published float value per channel (CHANNEL_Set compares integers and would miss sub-integer drift) and publishes with CHANNEL_SET_FLAG_FORCE so a due heartbeat is never suppressed by the integer-equality short-circuit. The first frame after boot force-publishes every channel via a one-shot flag, avoiding any dependency on when VCPPublishIntervals runs relative to driver init.
Per-quantity thresholds are fixed local constants. HLW8112_Set_EnergyStat publishes immediately on user set/clear/reset.
NOTE: the existing commands mqtt_BroadcastInterval and mqtt_BroadcastItemsPerSec do not solve this because the publishing mechanism for the HLW8112 data was triggered every second by the HLW8112_RunEverySecond, whereas the BroadastInterval and BroadcastItemsPerSec only apply to the sending of all data (one piece at a time) on a regular cycle.
NOTE 2: Currently running this myself - I did notice that my MQTT host name disappeared and I had to re-enter it: not sure if it is related to my changes though 😦 - don't see why it would be, but hard to be certain. (UPDATE: At 12 hours of running, this hasn't happened again but will continue to monitor)