Quick Summary (TL;DR)
For a reliable off-grid solar installation, let the solar charge controller, inverter and battery management system (BMS) do their own protective work. Use Home Assistant and an ESP32AliExpress price to observe the system, record trends and send warnings—not to replace those protections. The most robust architecture uses a manufacturer-supported monitoring gateway where available, such as a Victron GX device for compatible Victron equipment. An ESP32AliExpress price running ESPHome is useful as an additional read-only sensor node, particularly when a charge controller or meter has documented Modbus RTU registers.
A practical off-grid dashboard should show PV production, battery voltage, battery current, trustworthy state of charge, AC load and device alarms. Not all equipment exposes every measurement. A battery voltage percentage is not equivalent to a calibrated battery-monitor state-of-charge estimate, and an MPPT charger’s output power is not necessarily the same as instantaneous PV array power.
For remote sheds, cabins and telecommunications sites, network resilience matters as much as sensor selection. The equipment must continue charging, disconnecting on undervoltage and protecting the battery if Wi-Fi, Home Assistant or the internet goes down. Plan for local logging, a low-power gateway, sensible alert thresholds and an independent method of checking the system on site.
What a monitoring-only off-grid architecture looks like
Off-grid solar is not simply a grid-tied system with the utility supply removed. It must continually balance available sunlight, battery charge, inverter demand and the maximum current and voltage permitted by the equipment. A controller may need to stop charging immediately because of battery temperature or BMS instructions, even while the monitoring dashboard is offline.
The safe division of responsibility is straightforward:
| Layer | Hardware example | Primary responsibility | What Home Assistant should do |
|---|---|---|---|
| PV harvesting | Compatible MPPT solar charge controller | Convert PV input to suitable battery charge within its limits | Read charge state, PV power, yield and faults |
| Battery protection | Battery BMS, approved contactors and fusing | Protect cells against voltage, current and temperature faults | Display approved BMS telemetry, report alarms |
| Energy measurement | Properly sized battery shunt or manufacturer meter | Measure signed current and accumulated energy | Display battery current, SOC and trends |
| AC power | Correctly specified inverter/charger | Generate AC and handle its own overload protection | Read power, status and alarms |
| Gateway | Supported GX device or documented Modbus endpoint | Expose telemetry over a documented interface | Collect locally without becoming a control dependency |
| Optional ESP32AliExpress price | ESPHome node with isolated RS485 or low-voltage sensors | Read extra telemetry that supported devices do not provide | Publish read-only measurements and health status |
| Home Assistant | Always-on local host | History, dashboards and alerts | Present insights, not perform the system’s safety functions |
This is an architectural illustration, not wiring approval. PV strings can remain live in daylight, battery banks can deliver extremely high fault currents and inverter AC is a shock hazard. A qualified installer should design mains, battery, protective-earth, overcurrent and isolation arrangements. Never wire a hobby ESP32AliExpress price directly to a PV string or an inverter’s AC output.
Three sensible starting points
All-Victron system: connect compatible SmartSolar/BlueSolar charge controllers, battery monitors and inverter equipment through the documented VE.Direct, VE.Can or VE.Bus paths to a GX device. Home Assistant reads the GX over the local network. This usually avoids trying to reverse-engineer several protocols.
Mixed-vendor equipment with Modbus RTU: keep the MPPT and inverter operating independently. Choose one device with an officially documented read-only register map and connect an ESP32AliExpress price via a correctly rated, preferably galvanically isolated RS485 interface. An ESPHome node converts approved values to Home Assistant entities.
Small, simple cabin: if the only available output is a Bluetooth app or a status display, use that for maintenance and add an appropriately rated standalone battery monitor before trying to infer battery SOC from an inexpensive voltage sensor. You may decide that full Home Assistant integration offers too little benefit for its own energy budget.
Choosing the gateway: supported GX, ESPHome or direct Modbus
The word gateway hides very different products. Some devices translate measurements into local MQTT, some provide registers on Modbus TCP, and some depend on a cloud portal. A Bluetooth dongle used by a phone app is not automatically a local Ethernet gateway.
| Route | How it connects | Best fit | Important limitation | Internet required for local operation? |
|---|---|---|---|---|
| Victron GX with built-in Home Assistant Victron GX integration | Venus OS local MQTT over LAN | Compatible Victron equipment; multi-device off-grid systems | Actual entities vary with connected equipment and firmware | No, with local LAN connectivity |
| Victron GX Modbus TCP | Read documented GX register mapping from local network | Existing industrial monitoring or a specific verified register requirement | Unit IDs, data scaling and permission must match documentation | No |
| ESP32 + ESPHome + isolated RS485 | ESP32 UART to compatible Modbus RTU port | Compatible third-party MPPTs/meters with published maps | Wiring and register implementation require engineering | No |
| Direct Home Assistant Modbus RTU adapter | USB-RS485 adapter connected to HA host | Equipment physically close to HA and no separate ESP32 needed | One RS485 master and cable/host placement constraints | No |
| Vendor cloud portal | Logger uploads measurements to manufacturer servers | Owners happy with a maintained remote service | Internet dependency, latency, possible API restrictions | Usually yes for cloud viewing |
| Bluetooth-only app | Phone to nearby controller/monitor | On-site commissioning and occasional checks | Not necessarily accessible to Home Assistant or from afar | Usually not for nearby phone access |
The built-in Victron GX integration in current Home Assistant versions communicates via MQTT and discovers supported Venus OS equipment. It is a simpler starting point than constructing dozens of handcrafted MQTT sensors. The exact devices and controls depend on the installation. Consult the official integration guide before buying GX hardware.
If an existing Victron GX already exposes all your desired readings, adding an ESP32 just to fetch the same numbers adds power consumption and another failure point. Keep the ESP32 for a genuinely missing sensor, a documented third-party RS485 meter or a non-critical dry-contact status input that has been designed for that use.
Select the data source before selecting an ESP32 board
Start with a wiring and protocol inventory, not a shopping basket. Record the charge-controller model and hardware revision, battery chemistry and pack voltage, inverter model, BMS identity, available ports and existing communications cables. A manufacturer marketing page saying RS485 does not establish that the port accepts Modbus RTU, uses the same register map as another series or permits simultaneous masters.
Check whether each connection is VE.Direct, VE.Can/CAN bus, VE.Bus, Modbus RTU on RS485, Modbus TCP over Ethernet, proprietary serial, Bluetooth or a cloud logger interface. These names are not interchangeable. Even a connector with an RJ45 shell may carry something other than Ethernet. Never attach a generic network cable or UART adapter on shape alone.
What to measure and where
| Desired reading | Preferred source | Frequent mistake |
|---|---|---|
| PV generation now (W) | MPPT or inverter’s documented production sensor | Calling panel open-circuit voltage a generation measurement |
| Solar yield today (kWh) | Controller’s daily energy counter, if available | Treating today’s resettable yield as a lifetime energy counter |
| Battery terminal voltage (V) | Supported battery monitor or approved controller telemetry | Measuring a large battery directly through ESP32 GPIO |
| Battery charge/discharge current (A) | Properly rated and installed shunt/BMS telemetry | Measuring charger output alone and calling it net battery current |
| Battery SOC (%) | Calibrated battery monitor or supported BMS | Deriving a precise SOC from loaded lithium battery voltage |
| Battery temperature | Battery/BMS-provided sensor | Assuming ambient enclosure temperature equals cell temperature |
| AC inverter load (W) | Inverter telemetry or approved AC meter | Equating DC battery current to AC watts with no efficiency allowance |
| Critical alarms | Existing controller/BMS fault flags | Creating Home Assistant-only protections that vanish on Wi-Fi loss |
A single current shunt in the battery’s main return path, installed exactly as its manufacturer’s schematic specifies, can measure the net current in or out of the battery. It must capture all legitimate current paths. A shunt placed only on the charge-controller output reports charging current but misses inverter discharge and other parallel loads. See the companion battery-monitor buying guide once it has been published.
In Home Assistant use correct units, device classes, state classes and sources. Power in watts is a rate; energy in watt-hours or kilowatt-hours is an accumulated quantity. Battery SOC in percent is neither. Incorrectly assigning a power entity to an Energy dashboard slot causes missing or misleading graphs.
Build option A: supported Victron gateway
For an off-grid Victron installation, begin with the GX device’s connection plan. Typical data sources include an MPPT through its appropriate communications interface, a battery monitor and the inverter/charger. Verify how many physical ports and adapters the particular GX model provides; do not assume every Cerbo generation has the same connectors or spare ports.
- Commission the electrical system independently. Use the approved Victron and battery manufacturer procedures to confirm charging voltages, absorption behaviour, current limits, BMS communications and inverter protection. Home Assistant is not part of this step.
- Connect the GX using documented cabling. For example, a compatible VE.Direct device can use a VE.Direct cable to its supported GX connection; some larger MPPTs use VE.Can. Choose the right interface for the exact product.
- Confirm readings locally on the GX. Check PV voltage, charger current, battery voltage and error state. Make sure readings agree with on-device displays or a trusted meter.
- Enable the required local interface. Refer to the applicable Venus OS security profile and the Home Assistant Victron GX integration documentation. Prefer authenticated/TLS access where supported, and limit access to trusted LAN devices.
- Add the built-in Victron GX integration in Home Assistant. Under Settings → Devices & services, use discovery or add the integration manually. Select only the supported entities you need for a compact dashboard.
- Test without internet. Disable the WAN connection while leaving the local LAN running and verify that the dashboard still updates and controllers continue their autonomous operation.
Victron’s documentation confirms that supported MPPT models expose monitoring through VE.Direct or, where equipped, VE.Can. Some models offer Bluetooth with VictronConnect, but Bluetooth app support alone does not imply that a headless Home Assistant gateway can read the same values without extra hardware. See the Victron MPPT manual.
Avoid turning Home Assistant into an ESS controller
The Victron GX integration can expose selected controls as well as sensors, depending on the installation. Do not expose writable energy-management settings to general automations by default. Accidental mode changes, duplicated automation rules or stale data can interfere with an otherwise well-managed system. A low-battery warning should notify the owner; the BMS and charger must already have the independent limits that prevent damage.
For read-only monitoring, disable or hide entities that could alter charger settings, ESS targets, inverter modes or charge limits unless a competent designer has explicitly approved that behaviour. Use a separate, controlled commissioning process for all actual power-system changes.
Build option B: an ESP32 read-only RS485 gateway
An ESP32 works well where the charge controller provides documented Modbus RTU registers. ESPHome’s modbus_controller acts as a Modbus client, reads input/holding registers, applies documented scaling and publishes sensors to Home Assistant. The component can also write registers, which is exactly why this guide intentionally configures sensors only.
Hardware checklist
| Item | Buy/verify | Why it matters |
|---|---|---|
| ESP32 board | Reliable ESP32 module/board with a free hardware UART and compatible GPIO | Avoid pin conflicts and software UART fragility |
| RS485 interface | 3.3 V-compatible isolated transceiver or supported industrial ESP32 module | Reduces ground-potential/noise hazards between devices |
| Power supply | Regulated supply matched to ESP32 board input, with appropriate fusing | Never feed 12/24/48 V batteries directly into ESP32 3.3 V pins |
| Cable | Shielding/twisted pair as appropriate to manufacturer recommendations | Reduces EMI from inverter and PV power wiring |
| Port manual | Exact model, revision, baud, parity, slave ID and register table | RS485 alone does not establish Modbus support |
| Enclosure | Appropriate IP rating, temperature and strain relief | Cabins are often dusty, damp or exposed to insects |
| Surge/ground design | Installer-approved isolation and protective arrangement | Solar and long external cable routes can experience transients |
Do not tap into unknown BMS communications or splice into protected battery control wiring. A BMS CAN connection may carry essential battery limits and faults; attempting to masquerade as a battery or charge controller is not a harmless monitoring experiment.
A read-only ESPHome Modbus RTU template
The following configuration is a template, not a universal register map. Replace pins, baud rate, parity, Modbus address, register type, register address, data type and scale only after checking the exact controller’s official manual. 0x3100 below is used solely as an illustrative address commonly shown in ESPHome’s documentation, not as a claim that your particular MPPT maps PV voltage there. Do not commission a system using this example without verifying the actual register.
esphome:
name: offgrid-monitor
friendly_name: Off-Grid Monitor
esp32:
board: esp32dev
logger:
baud_rate: 0
api:
ota:
- platform: esphome
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
uart:
id: rs485_uart
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 9600 # replace with documented device setting
parity: NONE # replace if your controller specifies otherwise
stop_bits: 1
modbus:
id: rs485_bus
uart_id: rs485_uart
modbus_controller:
- id: solar_controller
address: 1 # replace with the device's actual Modbus ID
modbus_id: rs485_bus
update_interval: 30s
sensor:
- platform: modbus_controller
modbus_controller_id: solar_controller
name: "MPPT PV voltage (example mapping only)"
address: 0x3100 # NOT a universal register; consult your manual
register_type: input
value_type: U_WORD
unit_of_measurement: V
device_class: voltage
accuracy_decimals: 2
filters:
- multiply: 0.01 # EXAMPLE only; verify scale
The template intentionally does not include switch, number, select or output entities for register writes. Use an isolated transceiver that supports the chosen hardware wiring: the simple UART example assumes the RS485 module handles transmit-enable automatically. If your module requires explicit direction control, use the ESPHome Modbus component’s relevant flow-control option and verify the module schematic. Bus termination and biasing depend on the complete RS485 network, not just the ESP32 board.
Use the official ESPHome Modbus controller and Modbus sensor pages to confirm configuration syntax. ESPHome offers support for some controller families, but it does not turn an arbitrary serial port into a universal MPPT integration.
Commission one register at a time
Before creating a large dashboard, read one harmless, stable measurement—for example, battery voltage—and compare it against a trusted reference. A value of 2,520 may mean 25.20 V with a factor of 0.01, or a completely different reading when word order or address mapping is wrong. Check whether the manual uses zero-based or one-based register notation. For 32-bit values, validate signedness, floating-point representation and word order.
Only after voltage is correct should you add charge current, operating state, PV power and lifetime energy. Handle impossible negative values, unavailable states and timeouts explicitly rather than substituting zero. Zero power is a legitimate night-time measurement; unavailable communications is a different state.
Battery monitoring without unsafe DIY shunts
A 3.3 V ESP32 ADC is not a battery terminal measurement instrument. Even a nominal 12 V system can see charging voltages above its label; a 48 V battery is further outside that range. Direct connection destroys the board and can create a hazardous fault path. Proper measurement needs an approved and protected divider/transducer or, preferably, telemetry from a supported battery monitor that already manages isolation and ratings.
The INA226 sensor supported by ESPHome can measure current, voltage and power on appropriately engineered low-voltage DC circuits. However, the small breakout boards commonly sold for laboratory use are not a safe substitute for a professionally rated high-current battery shunt, nor can their input ratings be assumed suitable for a 48 V battery system. Check the complete device, shunt, PCB creepage, insulation and transient ratings—not just the INA226 IC specification.
For usable SOC on lithium systems, prefer the supported BMS or a battery monitor configured for the right capacity, chemistry and charge characteristics. Voltage-based SOC estimates tend to drift under charging/discharging current and can be especially unreliable on lithium iron phosphate’s relatively flat discharge curve. A shunt-based SOC estimate still needs periodic synchronisation and correct settings; it is not magically precise forever.
Map the numbers into Home Assistant correctly
For most remote off-grid setups, the most useful dashboard is a handful of dependable values, not a hundred raw registers. Show battery SOC, battery net current, battery voltage, charger PV power, inverter AC output, today’s solar yield and active fault flags. Add a last updated indicator so a frozen dashboard is not mistaken for a healthy system.
| Entity | Unit | Appropriate interpretation | Energy dashboard caveat |
|---|---|---|---|
| PV production power | W | Instantaneous inverter/controller output | Not an energy total; integrate or use a native counter |
| PV yield total | kWh | Accumulated solar energy over a defined period | Daily-reset values differ from lifetime counters |
| Battery charge power | W | Battery input, only when direction confirmed | Needs charge energy for Energy dashboard |
| Battery discharge power | W | Battery output | Needs separate discharge energy when supported |
| Battery state of charge | % | Estimated charge remaining | Never substitute for kWh |
| Inverter AC load | W | Live AC consumption from inverter | Different boundary from battery DC power |
| Battery alarm | Boolean/text | Native protective event | Show and notify; don’t bypass independent protection |
Home Assistant’s battery energy documentation explains that the dashboard needs battery charge and discharge energy data. If a controller supplies only watts, integration to kWh may be possible but depends on reliable sampling and sign handling. ESPHome’s Total Daily Energy computes a daily quantity from power; because it resets, it should not be confused with a device’s true lifetime accumulator.
Worked example: why measurement boundaries matter
Suppose that over an afternoon the MPPT reports 1.8 kWh delivered to the DC bus, the inverter supplies 0.9 kWh to AC loads, and the battery’s signed net-energy calculation indicates 0.7 kWh stored. The remaining 0.2 kWh is not automatically a fault: it may represent conversion losses, DC loads, differences in logging intervals or measurement uncertainty. You cannot reconcile it precisely without defining the same start/end times and every active path.
Similarly, if an inverter reports 300 W to appliances while the battery reports 360 W leaving the DC bank, do not claim that the inverter is 83.3% efficient based on this snapshot alone. Other DC loads, conversion conditions, power factor, sample lag and battery voltage measurement location may be affecting the values. Treat the calculation as a prompt to investigate, not a laboratory efficiency test.
Signed current convention: record it explicitly. For example, some monitors report charging as positive and discharging as negative, while other systems use the reverse. If you split a single signed battery-power sensor into separate charge and discharge power entities, do so with confirmed signs and test both directions on a known load. A sign reversal can make the Home Assistant Energy dashboard display battery discharge as charge.
Keep monitoring online without flattening the battery
Every extra monitoring device draws energy. This is most noticeable in a small winter cabin where both solar production and battery capacity are limited. A router, small computer, ESP32, USB adapter and cellular modem can together consume more energy than the gadget’s headline standby rating implies.
For planning, a continuous 3 W load consumes 72 Wh per day; a 10 W bundle consumes 240 Wh per day, before conversion losses. At 48 V, the latter corresponds to about 5 Ah/day of energy drawn from the battery if supplied at ideal efficiency. Actual DC input depends on converter efficiency and voltage variation. Measure the complete installation at its real operating load before committing to 24-hour monitoring.
For a small off-grid site consider keeping critical logging on an existing low-power gateway, running Home Assistant at a more central location, connecting over a secure network when available or transmitting telemetry intermittently. If Home Assistant is remote, plan for communications outages. If the local network disappears, the charge controller and BMS must remain fully functional.
Five resilience tests worth performing
- WAN loss: disconnect internet access without disconnecting the local network. Verify which sensors still update and whether any remote alerts stop.
- LAN loss: switch off the access point or unplug Ethernet. Confirm the power system operates normally and note how stale data appears in Home Assistant.
- Gateway reboot: restart the ESP32 or GX device. Check recovery, counter behaviour and whether raw registers reappear with correct scale.
- Night-time low generation: verify PV power settles to a plausible zero while battery SOC and load are still available. Do not mistake a stale daytime value for current production.
- Alarm notification: simulate a safe, non-destructive test alarm using the manufacturer’s supported test method, or test Home Assistant’s notification path with a manual test event. Never force a real over-current or deep-discharge condition to test an app alert.
A local alert cannot reach your phone over the internet when there is no internet. For unattended remote sites, assess a separate communications path if remote notification is critical. The emergency response process must not depend on someone seeing a dashboard at the right moment.
Installation, cybersecurity and data hygiene
Treat power-system gateways as operational technology. Keep MQTT and Modbus interfaces on a trusted LAN or appropriately segregated network. Do not publish port 502 (Modbus TCP), 1883 (unencrypted MQTT), a Venus OS administration page or an ESPHome API endpoint directly to the public internet. Where remote access is needed, use a maintained secure tunnel or VPN that does not make the control interfaces globally reachable.
Use unique credentials, back up your ESPHome YAML and system configuration, and label ports and wire colours. Keep the vendor’s original alarm messages and fault codes wherever possible: converting all faults into a generic problem boolean makes diagnosis harder. Include a documented maintenance path for firmware changes. A firmware update should not be installed on an unattended remote site without a way to recover locally.
Position the gateway away from inverter cooling outlets and noise-sensitive battery sensor wiring. Use a rated enclosure, strain relief and isolation for long serial links. The power hardware must use suitable fusing and disconnection irrespective of how little current the gateway draws.
Buying checklist and recommended configurations
| Situation | Recommended first purchase | Add ESP32? | What to avoid |
|---|---|---|---|
| Existing compatible Victron system | Supported GX device or use existing GX; documented interface cables | Only for missing auxiliary telemetry | Replacing GX with unsupported BMS protocol hacks |
| EPEVER/other controller with verified RTU map | Correctly rated isolated RS485 interface and regulated ESP32 supply | Yes, as read-only bridge | Assuming all model variants share registers |
| Cabin with no communications ports | Approved battery monitor with known gateway support | Only if a separate safe signal is available | Direct battery-voltage wiring to GPIO |
| Mixed 12/24/48 V system | Supported shunt and matching inverter/charger telemetry | Optional | Inferring net battery load from MPPT output alone |
| Remote site needing alerts | Reliable local logging plus maintained remote communications | Sometimes | Treating Wi-Fi or HA as a safety shutdown |
Budget beyond the ESP32 board itself: include the RS485 interface, supported sensor, power conversion, enclosure, fuses, cable, network equipment, installation work and ongoing energy use. A cheaper interface that requires weeks of reverse engineering may have higher total cost than a supported gateway. Conversely, for a single controller with a fully documented Modbus map and existing Wi-Fi, a carefully isolated ESPHome node can be economical.
Before buying, ask these five questions: Does my exact device expose read-only telemetry? Is the protocol map public and current? Will it work when offline? Which component retains battery protection? How will I recover a failed monitoring node? If the seller cannot answer the first two, postpone integration rather than guessing.
Troubleshooting: common symptoms
| Symptom | Check first | Likely explanation |
|---|---|---|
| All Modbus values unavailable | Port function, TX/RX, A/B polarity, common reference/isolation, baud/parity, address | Wrong electrical/protocol connection |
| One sensor reads a huge number | Register addressing, word order, signedness, scale | Wrong map or decoding |
| Battery SOC never changes | Actual monitor synchronisation and BMS feed | Stale SOC or inadequate measurement source |
| PV is zero all day | MPPT status, array condition, device register versus dashboard mapping | Night-mode/stale data/incorrect register |
| Battery current seems wrong | Shunt location, current direction, parallel branches | Monitoring only part of total current |
| Home Assistant shows zero during network loss | Availability handling and template defaults | Missing data incorrectly converted to zero |
| Dashboard kWh doubles | Same energy path counted twice; mixed daily and lifetime totals | Overlapping metering boundaries |
| Device repeatedly reboots | Supply voltage under Wi-Fi transmit, brownout, heat, grounding | Inadequate gateway power/interface design |
For the local network troubleshooting route, see the site’s existing ESP32 Modbus energy meter guide and Energy dashboard troubleshooting guide. These are useful general principles even though their examples use household energy meters rather than solar charge controllers.
Frequently asked questions
Can an ESP32 directly replace a solar charge controller?
No. An ESP32 and ESPHome do not provide the power electronics, independent battery protections, charging algorithms, isolation and hardware fault handling of an approved MPPT controller. The monitoring gateway belongs alongside the charger, not in place of it.
Can I read an MPPT’s Bluetooth data without a GX device?
Sometimes, depending on the exact manufacturer’s supported local protocol and integration. The presence of Bluetooth or an app is not proof that a supported, unattended Home Assistant interface exists. For Victron hardware, check the particular device’s VE.Direct/VE.Can options and the supported GX path first.
Can I use a CT clamp for my DC battery cable?
An ordinary AC current transformer cannot measure steady DC battery current. Use a suitably rated DC shunt, Hall-effect DC sensor or supported battery monitor. The common AC CT method is relevant to an inverter’s AC circuit, installed by a qualified electrician, not the battery’s direct-current return.
Will the off-grid system keep working if Home Assistant fails?
It must. If losing Home Assistant prevents the solar charger, BMS or inverter from protecting the battery and operating within approved limits, the system has been designed with an inappropriate safety dependency. Test failures at commissioning and document recovery methods.
Which should I buy first: a gateway or a battery shunt?
If you already have a suitable GX platform and compatible battery monitor, use it. If you lack reliable battery current/SOC data, an approved shunt/battery monitor is often more valuable than another network bridge. The correct decision depends on existing ports and whether you already have battery telemetry from the supported BMS.
Verdict
Start with a supported monitoring interface, then add an ESP32 only where it solves a specific, documented gap. A Victron GX-based system is generally easier to maintain for compatible Victron installations; an isolated ESPHome Modbus RTU node is useful for third-party equipment with a verified register map. In both cases, battery protection remains local and autonomous, sensor boundaries are documented and remote connectivity is treated as an optional monitoring service rather than an essential safety link.
For more background on the ESP32 side of energy monitoring, see the site’s existing ESP32 CT clamp energy monitor tutorial while remembering that ordinary CT clamps apply to AC, not DC battery cables.
Official documentation and further reading
- Home Assistant: Victron GX integration — supported local MQTT integration, prerequisites and security.
- Home Assistant: Integrating your home batteries — monitoring battery charge and discharge energy.
- ESPHome: Modbus Controller — supported RTU client interfaces and configuration.
- ESPHome: Modbus Controller Sensor — register data types and scaling.
- ESPHome: Total Daily Energy — power-to-energy integration and daily-reset semantics.
- ESPHome: INA226 DC Current and Power — supported chip interface; check the whole module’s ratings before use.
- Victron: MPPT solar charger manual — VE.Direct, VE.Can and approved GX connectivity for documented models.