Usermod INA219 Current, Voltage & Power Sensor #4237
Conversation
|
since you keep adding commits, is this work in progress? if so, mark it as such or better yet: commit to this PR once you are finished. |
Hi, no its finsied. I just did some small formatting changes while waiting for a reply. But now im happy with it ;) EDIT: im also using it for like 2 weeks now without any problems |
|
ok nice. did you test it working on different ESPs? |
|
i tested it on an ESP32 S2 (lolin_s2_mini) and an C3 (esp32c3dev) where it is working. like i said its already running for around 2 weeks |
|
Hi, i tested it now also with an ESp32 Wroom-32 (esp32dev) and it also worked. did i forget something so it will be added to version 0,15? |
|
looks fine, needs more testing and review, there are a few usermods in pipeline so please be patient. |
changed uint8_t to int8_t for _sdaPin and _sclPin ---> to be able to pick "unused" in pin selection which is -1,
Several optimizations for WLED_MQTT_CONNECTED and if Usermod is enabled/disabled
fixed endif to #endif
- Moved configurable settings to the top of the file for better readability. - Defined default values for each configuration option using #ifndef directives. - Updated default I2C pins to WLED ESP32 defaults (SDA: 21, SCL: 22). - Cleaned up variable initialization to use pre-defined constants for configuration.
|
looks good now. |
|
Hi, im not sure if i also should add this under lib_deps inside platformio.ini: i already added the info to the readme. I mean here:
i compiled it for all default_envs (v0.15) and got no errors:
for my own info, is there a way to exclude COM1 from beeing uploaded? compiling was taking to long that way |
Solve for: This branch has conflicts that must be resolved
WalkthroughThe changes introduce support for the INA219 sensor usermod. A new README file documents the usermod’s features, while a header file implements the Changes
✨ Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (9)
usermods/INA219/usermod_ina219.h (5)
6-8: Consolidate default configuration flags.Having multiple
#defineblocks for all default settings is helpful, but consider consolidating them within one file or grouping them in a dedicated section if they are solely used here. This can improve maintainability and readability.
178-180: Consider using a more time-accurate daily/monthly reset strategy.You reset daily energy after 86,400 seconds and monthly after 2,592,000 seconds. If the device sleeps or reboots, this simple accumulation might drift from actual calendar days. For improved accuracy, consider integrating with NTP or a real-time clock-based approach.
185-207: Clarify MQTT topic deletion logic.When
mqttPublishis toggled off (line 199), the code publishes an empty string withretainto remove the sensor from Home Assistant (line 204). This is a valid pattern, but ensure users are aware it fully removes historical data in some setups. Documenting this behavior improves transparency.
316-357: Add units to JSON keys for clarity.You produce JSON keys like
"current","power", etc. Consider including explicit suffixes (e.g.,current_A,power_W) so end-consumers of the data are unambiguously aware of units.
423-475: Optimize sanitizeMqttClientID.The function handles character-by-character validations and transformations (lines 427-472). This logic works but can be simplified and made more maintainable by using a dictionary/map for replacements instead of large condition blocks. This reduces complexity and potential off-by-one errors.
usermods/INA219/Readme.md (4)
44-60: Replace Hard Tabs with Spaces in the ADC Modes Table.
This block (lines 44–60) is indented using hard tabs, which triggers markdownlint MD010. To comply with markdown best practices and ensure consistent rendering across different editors, please replace these tabs with spaces (e.g., 2 or 4 spaces).Below is a sample diff for the first line of this block:
- ### Options for `INA219_CONVERSION_TIME` + ### Options for `INA219_CONVERSION_TIME`🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
44-44: Hard tabs
Column: 1(MD010, no-hard-tabs)
46-46: Hard tabs
Column: 1(MD010, no-hard-tabs)
48-48: Hard tabs
Column: 1(MD010, no-hard-tabs)
49-49: Hard tabs
Column: 1(MD010, no-hard-tabs)
50-50: Hard tabs
Column: 1(MD010, no-hard-tabs)
51-51: Hard tabs
Column: 1(MD010, no-hard-tabs)
52-52: Hard tabs
Column: 1(MD010, no-hard-tabs)
53-53: Hard tabs
Column: 1(MD010, no-hard-tabs)
54-54: Hard tabs
Column: 1(MD010, no-hard-tabs)
55-55: Hard tabs
Column: 1(MD010, no-hard-tabs)
56-56: Hard tabs
Column: 1(MD010, no-hard-tabs)
57-57: Hard tabs
Column: 1(MD010, no-hard-tabs)
58-58: Hard tabs
Column: 1(MD010, no-hard-tabs)
59-59: Hard tabs
Column: 1(MD010, no-hard-tabs)
60-60: Hard tabs
Column: 1(MD010, no-hard-tabs)
62-71: Convert Hard Tabs to Spaces in the Decimal Factor Options Section.
The section detailing the options forINA219_DECIMAL_FACTOR(lines 62–71) uses hard tabs for indentation. Converting these to spaces will resolve the markdownlint MD010 warnings and improve consistency.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
62-62: Hard tabs
Column: 1(MD010, no-hard-tabs)
64-64: Hard tabs
Column: 1(MD010, no-hard-tabs)
66-66: Hard tabs
Column: 1(MD010, no-hard-tabs)
67-67: Hard tabs
Column: 1(MD010, no-hard-tabs)
68-68: Hard tabs
Column: 1(MD010, no-hard-tabs)
69-69: Hard tabs
Column: 1(MD010, no-hard-tabs)
70-70: Hard tabs
Column: 1(MD010, no-hard-tabs)
71-71: Hard tabs
Column: 1(MD010, no-hard-tabs)
73-82: Remove Hard Tabs from the I2C Address Options Section.
Lines 73–82, which list the available I2C address options, are indented with hard tabs. Please replace these with spaces to adhere to markdown style guidelines and eliminate MD010 errors.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
73-73: Hard tabs
Column: 1(MD010, no-hard-tabs)
75-75: Hard tabs
Column: 1(MD010, no-hard-tabs)
77-77: Hard tabs
Column: 1(MD010, no-hard-tabs)
78-78: Hard tabs
Column: 1(MD010, no-hard-tabs)
79-79: Hard tabs
Column: 1(MD010, no-hard-tabs)
80-80: Hard tabs
Column: 1(MD010, no-hard-tabs)
81-81: Hard tabs
Column: 1(MD010, no-hard-tabs)
82-82: Hard tabs
Column: 1(MD010, no-hard-tabs)
98-110: Standardize Indentation in the Predefine Options Block.
The predefine options (lines 98–110) are currently indented using hard tabs. Replacing these tabs with spaces will resolve markdownlint MD010 issues and maintain consistency throughout the document.🧰 Tools
🪛 markdownlint-cli2 (0.17.2)
100-100: Hard tabs
Column: 1(MD010, no-hard-tabs)
101-101: Hard tabs
Column: 1(MD010, no-hard-tabs)
102-102: Hard tabs
Column: 1(MD010, no-hard-tabs)
103-103: Hard tabs
Column: 1(MD010, no-hard-tabs)
104-104: Hard tabs
Column: 1(MD010, no-hard-tabs)
105-105: Hard tabs
Column: 1(MD010, no-hard-tabs)
106-106: Hard tabs
Column: 1(MD010, no-hard-tabs)
107-107: Hard tabs
Column: 1(MD010, no-hard-tabs)
108-108: Hard tabs
Column: 1(MD010, no-hard-tabs)
109-109: Hard tabs
Column: 1(MD010, no-hard-tabs)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (4)
usermods/INA219/img/homeassistant.pngis excluded by!**/*.pngusermods/INA219/img/info.pngis excluded by!**/*.pngusermods/INA219/img/usermod_settings.pngis excluded by!**/*.pngusermods/INA219/img/usermod_settings_pins_selection.pngis excluded by!**/*.png
📒 Files selected for processing (4)
usermods/INA219/Readme.md(1 hunks)usermods/INA219/usermod_ina219.h(1 hunks)wled00/const.h(1 hunks)wled00/usermods_list.cpp(2 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
usermods/INA219/Readme.md
44-44: Hard tabs
Column: 1
(MD010, no-hard-tabs)
46-46: Hard tabs
Column: 1
(MD010, no-hard-tabs)
48-48: Hard tabs
Column: 1
(MD010, no-hard-tabs)
49-49: Hard tabs
Column: 1
(MD010, no-hard-tabs)
50-50: Hard tabs
Column: 1
(MD010, no-hard-tabs)
51-51: Hard tabs
Column: 1
(MD010, no-hard-tabs)
52-52: Hard tabs
Column: 1
(MD010, no-hard-tabs)
53-53: Hard tabs
Column: 1
(MD010, no-hard-tabs)
54-54: Hard tabs
Column: 1
(MD010, no-hard-tabs)
55-55: Hard tabs
Column: 1
(MD010, no-hard-tabs)
56-56: Hard tabs
Column: 1
(MD010, no-hard-tabs)
57-57: Hard tabs
Column: 1
(MD010, no-hard-tabs)
58-58: Hard tabs
Column: 1
(MD010, no-hard-tabs)
59-59: Hard tabs
Column: 1
(MD010, no-hard-tabs)
60-60: Hard tabs
Column: 1
(MD010, no-hard-tabs)
62-62: Hard tabs
Column: 1
(MD010, no-hard-tabs)
64-64: Hard tabs
Column: 1
(MD010, no-hard-tabs)
66-66: Hard tabs
Column: 1
(MD010, no-hard-tabs)
67-67: Hard tabs
Column: 1
(MD010, no-hard-tabs)
68-68: Hard tabs
Column: 1
(MD010, no-hard-tabs)
69-69: Hard tabs
Column: 1
(MD010, no-hard-tabs)
70-70: Hard tabs
Column: 1
(MD010, no-hard-tabs)
71-71: Hard tabs
Column: 1
(MD010, no-hard-tabs)
73-73: Hard tabs
Column: 1
(MD010, no-hard-tabs)
75-75: Hard tabs
Column: 1
(MD010, no-hard-tabs)
77-77: Hard tabs
Column: 1
(MD010, no-hard-tabs)
78-78: Hard tabs
Column: 1
(MD010, no-hard-tabs)
79-79: Hard tabs
Column: 1
(MD010, no-hard-tabs)
80-80: Hard tabs
Column: 1
(MD010, no-hard-tabs)
81-81: Hard tabs
Column: 1
(MD010, no-hard-tabs)
82-82: Hard tabs
Column: 1
(MD010, no-hard-tabs)
100-100: Hard tabs
Column: 1
(MD010, no-hard-tabs)
101-101: Hard tabs
Column: 1
(MD010, no-hard-tabs)
102-102: Hard tabs
Column: 1
(MD010, no-hard-tabs)
103-103: Hard tabs
Column: 1
(MD010, no-hard-tabs)
104-104: Hard tabs
Column: 1
(MD010, no-hard-tabs)
105-105: Hard tabs
Column: 1
(MD010, no-hard-tabs)
106-106: Hard tabs
Column: 1
(MD010, no-hard-tabs)
107-107: Hard tabs
Column: 1
(MD010, no-hard-tabs)
108-108: Hard tabs
Column: 1
(MD010, no-hard-tabs)
109-109: Hard tabs
Column: 1
(MD010, no-hard-tabs)
🔇 Additional comments (10)
usermods/INA219/usermod_ina219.h (4)
64-74: Validate after disabling the usermod.When
enabledis set tofalse(line 64) due to invalid pins or other reasons, ensure that checks later in the code (e.g., sensor read in mainloop) skip operations or handle the disabled scenario gracefully. You might want to log a message or update logs to clarify that the usermod is disabled.
128-132: Confirm pin usage and resource allocation.You disabled the usermod when
i2c_scl < 0 || i2c_sda < 0. This prevents improper usage, but consider also logging an actionable message or referencing the WLED global I2C settings if these pins are not automatically set. This helps users debug their hardware setup more easily.
231-247: Remove references with consistent naming or placeholders.In lines 236-242, you remove previously created sensors by calling
mqttRemoveHassSensor(...). Notice that “Shunt-Voltage,” “Daily-Energy,” “Monthly-Energy,” etc., have hyphens, while your create calls do not. For consistency, confirm the names match exactly so sensors are correctly removed.
480-505: Check for potential integer overflow in time-based calculations.When using
durationMs(unsigned long) to accumulate daily or monthly reset times, watch for potential overflows if the device runs for very long without a reset. Consider using a larger data type (e.g.,uint64_t) if that is a concern for extremely long uptimes.wled00/usermods_list.cpp (1)
185-187: Ensure consistent inclusion guard usage.You conditionally include
"usermod_ina219.h"with#ifdef USERMOD_INA219but verify that the configuration macros are properly declared in build settings. This is consistent with other usermods. No immediate issues found here.wled00/const.h (1)
209-209: New usermod ID assignment looks correct.Assigning
USERMOD_ID_INA219to58is consistent with existing values. Just ensure there are no merges or reassignments that accidentally reuse 58 later.usermods/INA219/Readme.md (4)
1-43: Excellent Documentation Structure and Clarity.
The initial sections—title, introductory description, and feature list—are well structured and clear. The content effectively communicates the purpose of the INA219 WLED Usermod and its relevant features.
84-97: Usage Section is Clear and Effective.
The usage instructions (lines 84–97) are concise and provide clear step‐by‐step guidance for users on how to integrate the usermod. No changes are needed here.
111-117: Energy Calculation Section is Concise and Informative.
The explanation of energy calculations (lines 111–117) clearly communicates how total, daily, and monthly energy are handled, providing valuable context for users.
119-134: Dependencies and I2C Configuration Section is Well-Documented.
The final section (lines 119–134) outlining required library dependencies and mandatory I2C configuration steps is comprehensive and clear, ensuring that users know how to set up the hardware communication before enabling the usermod.
Fix missing pound in #endif. Line 504 has “endif” without a leading #. This is likely a small typographical mistake that can break compilation.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
wled00/usermods_list.cpp (1)
502-504: Consider moving the registration to maintain alphabetical order.The registration code is correctly implemented but could be moved to maintain alphabetical order with other usermods (between INA226 and LD2410).
Apply this diff to move the registration:
#ifdef USERMOD_INA226 UsermodManager::add(new UsermodINA226()); #endif + + #ifdef USERMOD_INA219 + UsermodManager::add(new UsermodINA219()); + #endif #ifdef USERMOD_LD2410 UsermodManager::add(new LD2410Usermod()); #endif #ifdef USERMOD_POV_DISPLAY UsermodManager::add(new PovDisplayUsermod()); #endif #ifdef USERMOD_DEEP_SLEEP UsermodManager::add(new DeepSleepUsermod()); #endif #ifdef USERMOD_RF433 UsermodManager::add(new RF433Usermod()); #endif #ifdef USERMOD_BRIGHTNESS_FOLLOW_SUN UsermodManager::add(new UsermodBrightnessFollowSun()); #endif - - #ifdef USERMOD_INA219 - UsermodManager::add(new UsermodINA219()); - #endif
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
wled00/usermods_list.cpp(2 hunks)
🔇 Additional comments (1)
wled00/usermods_list.cpp (1)
185-188: LGTM! Include directive is well-placed.The include directive follows the established pattern and is properly placed in alphabetical order among other sensor usermods.
Handle INA219 initialization failure more robustly. Currently, you only log "INA219 initialization failed!" if _ina219->init() fails. Consider disabling enabled or providing fallback logic to avoid subsequent read attempts on a failed initialization, preventing usage of a potentially invalid object.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
usermods/INA219/usermod_ina219.h (4)
127-147: Consider preserving the existing Wire object for I2C.
Callingdelete _ina219;and creating a new instance on every settings update is acceptable, but it reinitializes the sensor each time. If the sensor’s configuration changes frequently, this can introduce unnecessary overhead. Reusing or reconfiguring the same instance might be more efficient.
365-413: Check for potential naming collisions in MQTT topics.
When creating Home Assistant sensors, the unique_id is built frommqttClientIDand replaces spaces with hyphens. Ensure that collisions won’t occur if multiple devices share similar names or if character replacements become identical. Adding additional uniqueness factors like_i2cAddressmight help.
424-476: Remove or clarify leftover commented-out code.
Multiple lines (e.g., 435, 438, 442, 446, 450, 454, 458, 459) contain references to extended replacements (“ue”, “oe”, “ss”) that are now commented out. Unless these are intentionally kept for later reference, removing them will reduce confusion and improve readability.Here’s a sample snippet to remove them:
- //sanitizedID += "ue"; // Replace ü with ue + sanitizedID += "u"; // Replace ü with u(Similarly remove all other commented-out replacements in the same pattern.)
634-668: Guard against invalid intervals in config.
Your fallback handling in lines 643–647 helps avoid invalid intervals, but consider logging a message or storing an error code ifcheck_intervalis out of range. This ensures end users can diagnose misconfigurations quickly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
usermods/INA219/usermod_ina219.h(1 hunks)
🔇 Additional comments (5)
usermods/INA219/usermod_ina219.h (5)
6-8: Good use of conditional compilation and default value.
DefiningINA219_ENABLEDtofalseby default is a clean approach for conditionally enabling the usermod. No concerns here.
163-201: Ensure consecutive loops handle sensor reads accurately.
Within theloop()method, the sensor data is fetched everycheckInterval. However, if the device is under heavy load or the loop is sometimes delayed, consider whether the time-based calculations remain accurate ifmillis()increments significantly between checks. If major timing delays are possible, further checks or accumulative error handling may be needed to maintain consistent measurement intervals.
253-255: Threshold-based comparison approach looks correct.
The methodhasSignificantChange()with a fixed threshold of0.01fis a straightforward solution for filtering out minor fluctuations. Ensure 0.01 suits your precision and application needs.
481-506: Verify resetting logic for daily and monthly energy.
The conditions to reset (>= 86400 seconds for daily, >= 2592000 seconds for monthly) are straightforward but assume fully continuous uptime. Long sleep or downtime might throw these counters off. Consider tracking real dates for more robust resets if system time is available.
581-596: Confirm storage of fundamental parameters in the usermod config.
Storing all key operational settings (likei2c_address,check_interval) is helpful for permanent record. Just ensure future changes (e.g., correction factor or advanced sensor options) also get included.
coderabbitai -> 502-504: Consider moving the registration to maintain alphabetical order. The registration code is correctly implemented but could be moved to maintain alphabetical order with other usermods (between INA226 and LD2410).
316-357: Add units to JSON keys for clarity. You produce JSON keys like "current", "power", etc. Consider including explicit suffixes (e.g., current_A, power_W) so end-consumers of the data are unambiguously aware of units. 423-475: Optimize sanitizeMqttClientID. The function handles character-by-character validations and transformations (lines 427-472). This logic works but can be simplified and made more maintainable by using a dictionary/map for replacements instead of large condition blocks. This reduces complexity and potential off-by-one errors. 365-413: Check for potential naming collisions in MQTT topics. When creating Home Assistant sensors, the unique_id is built from mqttClientID and replaces spaces with hyphens. Ensure that collisions won’t occur if multiple devices share similar names or if character replacements become identical. Adding additional uniqueness factors like _i2cAddress might help. 424-476: Remove or clarify leftover commented-out code. Multiple lines (e.g., 435, 438, 442, 446, 450, 454, 458, 459) contain references to extended replacements (“ue”, “oe”, “ss”) that are now commented out. Unless these are intentionally kept for later reference, removing them will reduce confusion and improve readability. 634-668: Guard against invalid intervals in config. Your fallback handling in lines 643–647 helps avoid invalid intervals, but consider logging a message or storing an error code if check_interval is out of range. This ensures end users can diagnose misconfigurations quickly.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
usermods/INA219/usermod_ina219.h(1 hunks)wled00/usermods_list.cpp(3 hunks)
🔇 Additional comments (5)
wled00/usermods_list.cpp (2)
185-188: Looks correct for conditional inclusion.Including the INA219 usermod header within these preprocessor guards is consistent and aligns well with the approach used for other usermods.
482-485: Registration logic appears sound.Registering
UsermodINA219under the#ifdef USERMOD_INA219block cleanly integrates this usermod into the system. No issues spotted with heap allocation; the memory management matches WLED’s common pattern for usermods.usermods/INA219/usermod_ina219.h (3)
130-144: Good approach to re-initializing the sensor.Re-creating the
_ina219object after deleting the old instance ensures updated configurations take effect and cleans up the previous pointer correctly.
464-475: Daily and monthly reset approach is fine.The logic to reset daily usage at 24 hours (
86400seconds) and monthly usage at 30 days (2592000seconds) is straightforward and sufficient for most use cases.
579-603: Configuration UI is neatly implemented.Providing dropdowns for I2C address and ADC modes, along with decimal precision, is user-friendly and consistent with other WLED usermods.
⚠️ Potential issue Avoid casting float to bool for overflow checks. The call to truncateDecimals(_ina219->getOverflow()) returns a float, which is then implicitly converted to bool. If the library returns non-integer values, this could cause unexpected results. For clarity and correctness, consider: - overflow = truncateDecimals(_ina219->getOverflow()); + overflow = _ina219->getOverflow() != 0;
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
usermods/INA219/usermod_ina219.h (2)
1-44: Consider splitting configuration constants into a separate header or config file.
Placing extensive configuration defines and defaults at the top of this header adds noise and makes future maintenance challenging. Extracting them into a dedicated config file (e.g.,usermod_ina219_config.h) can improve clarity and encourage reusability.-#ifndef INA219_ENABLED -#define INA219_ENABLED false // Default disabled value -#endif ... -#define INA219_HA_DISCOVERY false // Default: Home Assistant discovery disabled -#endif +#include "usermod_ina219_config.h"
118-144: Suggest retry logic for sensor initialization failures.
Currently, if_ina219->init()fails, the usermod is disabled for the remainder of the session. Offer the user a mechanism (e.g., a button in the UI or a timed automatic retry) to attempt re-initialization later rather than permanently disabling.if (!_ina219->init()) { DEBUG_PRINTLN(F("INA219 initialization failed!")); enabled = false; - return; + // Optionally schedule a retry or provide an alternate path }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
usermods/INA219/usermod_ina219.h(1 hunks)
🔇 Additional comments (3)
usermods/INA219/usermod_ina219.h (3)
160-243: Validate potential edge cases in energy calculation intervals.
The code uses(lastCheck - lastPublishTime)in milliseconds to update energy consumption. If the interval is too short or if the system time wraps around (e.g., after ~50 days of uptime), the calculation might yield unexpected values. Consider safeguards or reset logic for edge cases.Would you like a script to scan for other references to time wrapping or negative intervals, ensuring no additional vulnerabilities exist?
265-285: Fix MQTT topic mismatch for onMqttMessage.
Because you subscribe to the topic"<deviceTopic>/sensor/ina219", the checkstrcmp_P(topic, PSTR("/sensor/ina219")) == 0will fail in most setups that include a custom device topic.
553-603: Add user-friendly validations for out-of-range config values.
You partially validatecheck_intervalinreadFromConfig, but other fields (e.g., shunt resistor, correction factor, decimals) might also need explicit checks to ensure they remain within valid ranges and avoid sensor misconfiguration.
Hi,
i created a usermod for the ina219 Current, Voltage & Power Sensor:
I took a liking to the INA226 Usermod here:
https://github.com/Aircoookie/WLED/tree/0_15/usermods/INA226_v2
and took some parts and added my 3 cents to it.
I hope the readme states everything needed to get what can be done.
the only think i couldnt solved is to add the sensors data to the wled home assistant integration page (if thats even possible) so instead it is added just to mqtt. if there is a way to have the autodiscover to add it directly to the wled integrations page, i would be more than happy to change the usermod.
also i hope i added everything correctly in git, since its my first time working like this in git
Summary by CodeRabbit
New Features
Documentation