Pulse Width Accumulate Sensor #8143
Closed
Conversation
This file contains 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
Co-authored-by: Jonathan Swoboda <jonathan.swoboda>
…on_xxxx action (esphome#7796) Co-authored-by: Jesse Hills <[email protected]>
…on_xxxx action (esphome#7796) Co-authored-by: Jesse Hills <[email protected]>
Co-authored-by: Keith Burzinski <[email protected]>
|
Did you forget to edit pull request title? 😁 |
|
Arr sorry I'm a bit lost and overwhelmed with this pull request process. I though after I got it compiled it would be easy sailing.
Cheers
Patrick
…________________________________
From: Djordje Mandic ***@***.***>
Sent: Sunday, January 26, 2025 13:48
To: esphome/esphome ***@***.***>
Cc: pat ***@***.***>; Mention ***@***.***>
Subject: Re: [esphome/esphome] Add files via upload (PR #8143)
Did you forget to edit pull request title? 😁
—
Reply to this email directly, view it on GitHub<#8143 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABSZDSALP2RTFT7JFOAEPRD2MTKTFAVCNFSM6AAAAABV4AJAHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJUGQYDKNBWGI>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
patrick-kiwi
changed the title
|
@patrick-kiwi Read this page https://esphome.io/guides/contributing.html#setting-up-a-development-environment When everything is set-up, use command line for git. Precommit jobs will do most of simple fixes and patches automatically. If it fails, just stage new changes again with git add and retype same commit command. |
DjordjeMandic
suggested changes
Jan 27, 2025
There was a problem hiding this comment.
Your approach to checking parameters in code for invalid configurations is definitely effective in preventing unintended behavior. However, I’d like to suggest an improvement that could enhance the efficiency of the overall workflow.
Performing thorough configuration validation in Python before code generation is generally preferred. By detecting invalid configurations during the YAML validation phase (errors shown to the user either in the YAML editor or during config verification), errors can be caught early, significantly reducing the overhead of proceeding to code generation and compilation just to encounter an error. This not only saves time but also helps users quickly identify and fix issues.
In addition, the configuration schema should be designed to prevent invalid configurations altogether. ESPHome uses the voluptuous library for defining configuration schemas, and it provides a powerful way to enforce constraints, data types, and valid parameter combinations directly at the validation stage. Leveraging this schema can eliminate the need for certain runtime checks, resulting in cleaner code and better performance.
Moreover, handling invalid configurations during config validation reduces the size of the generated binary, as runtime checks become unnecessary. This optimization is especially beneficial for projects where binary size is a concern. That said, if your class is designed to be used manually without the auto-generated code, then retaining parameter checks in the code is important to maintain robustness.
In summary, I’d recommend shifting as many checks as possible to the config validation phase and enforcing valid configurations through the voluptuous schema. This provides immediate feedback to users, minimizes compilation overhead, and ensures an efficient development process. It’s a small change that can have a big impact on the overall experience. Keep up the great work!
| float cumulative_width = this->store_.get_cumulative_pulse_width_s(); | ||
| float polling_interval_s = static_cast<float>(this->get_update_interval()) / 1000.0f; | ||
| // Check and fix errors, and issue warnings if necessary. | ||
| if (polling_interval_s > 4294.9f) { |
There was a problem hiding this comment.
This should be checked in config validation
Comment on lines
82
to
81
| if (cumulative_width < 0) { | ||
| ESP_LOGW(TAG, | ||
| "Warning, cumulative pulse width %.1f s doesn't make sense! " | ||
| "Setting to zero.", | ||
| cumulative_width); | ||
| cumulative_width = 0.0f; | ||
| } | ||
| if (cumulative_width > polling_interval_s) { | ||
| ESP_LOGW(TAG, | ||
| "Warning, cumulative pulse width: %.4f s exceeds the polling " | ||
| "window: %.4f s.", | ||
| cumulative_width, polling_interval_s); | ||
| if ((cumulative_width - polling_interval_s) > 3.0e-3f) { | ||
| ESP_LOGW(TAG, "Clamping cumulative pulse width to range: %.4f", polling_interval_s); | ||
| cumulative_width = polling_interval_s; | ||
| } | ||
| } |
There was a problem hiding this comment.
These warnings can stay, errors should be thrown during config validation if possible.
|
Hi Thanks for that. You're totally right, the check for an excessive polling window belongs in the YAML config. I'll have to try to figure out how to do that. After thinking about it I'll also remove all of the "error correction" in the update function. Reason being that the ISR synchronization has some peculiar self-correcting behavior. If you look at the two edge cases, min and max operating frequency (ie. input always-on, to input ~10.8 KHz pw=22 us, delay=70 us). It's easy to see if you check out the raw output below. If the input is always on then sometimes the on-time overshoots 60s which is wrong, but then it undershoots in the next interval by the precise correction amount. Similarly, at the maximum stable frequency the update function occasionally reports 0 seconds which is seriously wrong, but then it corrects on the next update period. That of course creates a dilemma for the polling period.
Output (GPIO input: continuously on)
[15:01:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00395 s with 2 decimals of accuracy
[15:02:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:02:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00200 s with 2 decimals of accuracy
[15:03:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:03:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99400 s with 2 decimals of accuracy
[15:04:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:04:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00401 s with 2 decimals of accuracy
[15:05:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:05:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99599 s with 2 decimals of accuracy
[15:06:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:06:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00500 s with 2 decimals of accuracy
[15:07:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:07:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99500 s with 2 decimals of accuracy
[15:08:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:08:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00500 s with 2 decimals of accuracy
[15:09:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:09:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99500 s with 2 decimals of accuracy
[15:10:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:10:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00400 s with 2 decimals of accuracy
[15:11:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:11:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99600 s with 2 decimals of accuracy
[15:12:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:12:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00401 s with 2 decimals of accuracy
[15:13:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:13:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99599 s with 2 decimals of accuracy
[15:14:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:14:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00502 s with 2 decimals of accuracy
[15:15:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:15:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99498 s with 2 decimals of accuracy
[15:16:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:16:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00500 s with 2 decimals of accuracy
[15:17:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:17:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99500 s with 2 decimals of accuracy
[15:18:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:18:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00400 s with 2 decimals of accuracy
[15:19:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:19:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99600 s with 2 decimals of accuracy
[15:20:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:20:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00401 s with 2 decimals of accuracy
[15:21:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:21:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99599 s with 2 decimals of accuracy
[15:22:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:22:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00401 s with 2 decimals of accuracy
[15:23:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:23:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00200 s with 2 decimals of accuracy
[15:24:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:24:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99400 s with 2 decimals of accuracy
[15:25:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:25:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00401 s with 2 decimals of accuracy
[15:26:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:26:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 59.99599 s with 2 decimals of accuracy
[15:27:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
[15:27:33][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 60.00401 s with 2 decimals of accuracy
[15:28:33][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 0.00000 Hz with 1 decimals of accuracy
Output (GPIO input: 22 us on and 70 us off)
[14:30:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10861.18359 Hz with 1 decimals of accuracy
[14:30:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.34046 s with 2 decimals of accuracy
[14:31:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.84961 Hz with 1 decimals of accuracy
[14:31:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33720 s with 2 decimals of accuracy
[14:32:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.88379 Hz with 1 decimals of accuracy
[14:32:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33722 s with 2 decimals of accuracy
[14:33:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.03320 Hz with 1 decimals of accuracy
[14:33:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 0.00001 s with 2 decimals of accuracy
[14:34:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10861.15039 Hz with 1 decimals of accuracy
[14:34:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 28.67634 s with 2 decimals of accuracy
[14:35:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10860.71680 Hz with 1 decimals of accuracy
[14:35:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33954 s with 2 decimals of accuracy
[14:36:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.91699 Hz with 1 decimals of accuracy
[14:36:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33735 s with 2 decimals of accuracy
[14:37:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.56641 Hz with 1 decimals of accuracy
[14:37:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33691 s with 2 decimals of accuracy
[14:38:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10857.88379 Hz with 1 decimals of accuracy
[14:38:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33612 s with 2 decimals of accuracy
[14:39:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10860.66699 Hz with 1 decimals of accuracy
[14:39:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33971 s with 2 decimals of accuracy
[14:40:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10859.09961 Hz with 1 decimals of accuracy
[14:40:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 0.00002 s with 2 decimals of accuracy
[14:41:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10859.15039 Hz with 1 decimals of accuracy
[14:41:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 28.67516 s with 2 decimals of accuracy
[14:42:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10857.84961 Hz with 1 decimals of accuracy
[14:42:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 0.00001 s with 2 decimals of accuracy
[14:43:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10861.43359 Hz with 1 decimals of accuracy
[14:43:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 28.67679 s with 2 decimals of accuracy
[14:44:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.38379 Hz with 1 decimals of accuracy
[14:44:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33664 s with 2 decimals of accuracy
[14:45:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10861.33301 Hz with 1 decimals of accuracy
[14:45:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 0.00002 s with 2 decimals of accuracy
[14:46:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10859.25000 Hz with 1 decimals of accuracy
[14:46:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 28.67841 s with 2 decimals of accuracy
[14:47:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.95020 Hz with 1 decimals of accuracy
[14:47:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33739 s with 2 decimals of accuracy
[14:48:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.01660 Hz with 1 decimals of accuracy
[14:48:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33612 s with 2 decimals of accuracy
[14:49:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10860.53320 Hz with 1 decimals of accuracy
[14:49:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 0.00002 s with 2 decimals of accuracy
[14:50:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10859.08301 Hz with 1 decimals of accuracy
[14:50:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 28.67672 s with 2 decimals of accuracy
[14:51:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10858.11621 Hz with 1 decimals of accuracy
[14:51:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.33619 s with 2 decimals of accuracy
[14:52:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10861.45020 Hz with 1 decimals of accuracy
[14:52:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 14.34052 s with 2 decimals of accuracy
[14:53:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10861.13379 Hz with 1 decimals of accuracy
[14:53:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 0.00002 s with 2 decimals of accuracy
[14:54:55][D][sensor:094]: 'Averaged TRIAC Frequency Sensor': Sending state 10859.46680 Hz with 1 decimals of accuracy
[14:54:55][D][sensor:094]: 'Cumulative TRIAC On-Time Sensor': Sending state 28.67778 s with 2 decimals of accuracy
Output (always on)
________________________________
From: Djordje Mandic ***@***.***>
Sent: Monday, January 27, 2025 01:02
To: esphome/esphome ***@***.***>
Cc: pat ***@***.***>; Mention ***@***.***>
Subject: Re: [esphome/esphome] Pulse Width Accumulate Sensor (PR #8143)
@DjordjeMandic requested changes on this pull request.
Your approach to checking parameters in code for invalid configurations is definitely effective in preventing unintended behavior. However, I’d like to suggest an improvement that could enhance the efficiency of the overall workflow.
Performing thorough configuration validation in Python before code generation is generally preferred. By detecting invalid configurations during the YAML validation phase (errors shown to the user either in the YAML editor or during config verification), errors can be caught early, significantly reducing the overhead of proceeding to code generation and compilation just to encounter an error. This not only saves time but also helps users quickly identify and fix issues.
In addition, the configuration schema should be designed to prevent invalid configurations altogether. ESPHome uses the voluptuous library for defining configuration schemas, and it provides a powerful way to enforce constraints, data types, and valid parameter combinations directly at the validation stage. Leveraging this schema can eliminate the need for certain runtime checks, resulting in cleaner code and better performance.
Moreover, handling invalid configurations during config validation reduces the size of the generated binary, as runtime checks become unnecessary. This optimization is especially beneficial for projects where binary size is a concern. That said, if your class is designed to be used manually without the auto-generated code, then retaining parameter checks in the code is important to maintain robustness.
In summary, I’d recommend shifting as many checks as possible to the config validation phase and enforcing valid configurations through the voluptuous schema. This provides immediate feedback to users, minimizes compilation overhead, and ensures an efficient development process. It’s a small change that can have a big impact on the overall experience. Keep up the great work!
________________________________
In esphome/components/pulse_width_accumulate/pulse_width_accumulate.cpp<#8143 (comment)>:
+ }
+ portEXIT_CRITICAL_ISR(&arg->mux_);
+}
+
+void PulseWidthAccumulateSensor::dump_config() {
+ LOG_SENSOR("", "Pulse Width", this)
+ LOG_UPDATE_INTERVAL(this)
+ LOG_PIN(" Pin: ", this->pin_);
+}
+
+void PulseWidthAccumulateSensor::update() {
+ // Retrieve cumulative pulse width, and zero the counter
+ float cumulative_width = this->store_.get_cumulative_pulse_width_s();
+ float polling_interval_s = static_cast<float>(this->get_update_interval()) / 1000.0f;
+ // Check and fix errors, and issue warnings if necessary.
+ if (polling_interval_s > 4294.9f) {
This should be checked in config validation
________________________________
In esphome/components/pulse_width_accumulate/pulse_width_accumulate.cpp<#8143 (comment)>:
+ if (cumulative_width < 0) {
+ ESP_LOGW(TAG,
+ "Warning, cumulative pulse width %.1f s doesn't make sense! "
+ "Setting to zero.",
+ cumulative_width);
+ cumulative_width = 0.0f;
+ }
+ if (cumulative_width > polling_interval_s) {
+ ESP_LOGW(TAG,
+ "Warning, cumulative pulse width: %.4f s exceeds the polling "
+ "window: %.4f s.",
+ cumulative_width, polling_interval_s);
+ if ((cumulative_width - polling_interval_s) > 3.0e-3f) {
+ ESP_LOGW(TAG, "Clamping cumulative pulse width to range: %.4f", polling_interval_s);
+ cumulative_width = polling_interval_s;
+ }
+ }
These warnings can stay, errors should be thrown during config validation if possible.
—
Reply to this email directly, view it on GitHub<#8143 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABSZDSHEI6UC2I4BSHOQ47L2MVZRRAVCNFSM6AAAAABV4AJAHCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDKNZUGQYTQMRQHE>.
You are receiving this because you were mentioned.
|
probot-esphome
bot
added
small-pr
and removed
new-integration
has-tests
core
needs-codeowners
labels
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this implement/fix?
Hi there. I hope I'm submitting this correctly.
This is a new pulse_width_accumulate sensor. It allows you to sum the total on-time of
a GPIO input. For example, this can be used to externally measure the on-time
of rapidly switched MOSFET or TRIAC. The sensor zeros itself every polling
interval, and units of measurement are on-time seconds per update interval.
An optional frequency sensor is also provided.
Threshold stability values were experimentally determined for an esp32 devkit_v4.
Pulse width >= 22 microseconds, pulse width delay >= 70 microseconds
(ie. implied maximum frequency ~10.87 KHz)
There are no overflow problems ie. the pulse width can be infinitely long.
However, the polling window (default 1 minute) must not be set > 71.58 minutes.
Types of changes
Related issue or feature (if applicable):
esphome/feature-requests#3009
Pull request in esphome-docs with documentation (if applicable):
Test Environment
Example entry for
config.yaml:Checklist:
tests/folder).If user exposed functionality or configuration variables are added/changed: