01 · Install

Installing on Venus OS

Use the selected repository's released installer and configuration example. These projects are independent repositories; there is no organization-wide bootstrap.sh.

Check the device first

cat /opt/victronenergy/version
python3 --version
uname -m
command -v svc svstat multilog

The September 2026 audit used Venus OS v3.75 and Python 3.12.13 on a Raspberry Pi 3 Model B with approximately 1 GB RAM. Other hardware and firmware need their own checks.

Native service installation

Use daemontools: persistent application and service files under /data, symlinks under volatile /service, and offline boot restoration from /data/rc.local before any exit 0. A systemd unit or an unreferenced /data/rc/S99* file will not install a native Venus service.

Install SetupHelper when the package requires it. Preserve local configuration and venvs during updates. Check dependencies before stopping the existing service; do not run global pip upgrades or network installers at boot.

• Battery and PV bridges: follow dbus-mqtt-battery, dbus-virtual-battery, and dbus-tasmota-pv.
• Home Assistant bridges: Emporia and water tank, pump and valve depend on their configured HA endpoint.
• dbus-ev reads Mercedes or Home Assistant vehicle telemetry; its integrated charger requires the Mercedes backend. The standalone charger repository is archived. Follow the migration and rollback guide and never run two owners of the same charger service.
• inverter-control uses local_config.py, with a preserved copy under /data/setupOptions/inverter-control/. Verify metering before enabling control.
• Observability: use metrics-only mode when trace export is unnecessary.

Inverter Climate thermostat controls

inverter-climate runs natively on Venus OS and uses the existing Home Assistant thermostat integration, including Google Nest. It reads local D-Bus energy data and publishes an Inverter Climate room-temperature device.

In SetupHelper PackageManager, add package inverter-climate, GitHub user victron-venus, branch latest. This is the packaged stable release; main is development source. Python 3.12+, firmware D-Bus/GLib bindings and velib_python are required.

A first installation stays disabled until configured and explicitly started. Follow the native lifecycle guide and configuration example. Keep HA credentials and configuration private under /data/setupOptions/inverter-climate; select the real thermostat and energy sources, and begin with [service] mode = "observe".

Settings → Devices shows temperature and metadata. For manual commands, add control_enabled = true to the existing [device] section and restart the service according to the lifecycle guide. Open the Switch pane from the small icon at the upper left of GUI v2: Temperature setpoint is a slider, and Heating mode offers Heat / Off. The same controls are available through VRM Remote Console.

Manual control can remain in observe mode. Automatic preheating requires the separate mode = "active" choice and a validated energy configuration. Updates preserve private settings, device identity and command journals; uncertain commands are not automatically retried. Follow the package guide for recovery.

Keep companion workloads off the GX

Run Docker dashboards, Grafana/Loki, databases and forecasting on a NAS/server. Flash ESPHome on the ESP32. Check architecture and resource headroom before adding optional dashboard binaries to a GX. Not every repository is a deployable native package.

Verify uptime, logs and D-Bus types

svstat /service/dbus-mqtt-chain1 /service/dbus-mqtt-chain2
svstat /service/dbus-ev /service/vrmlogger
tail -n 80 /var/log/dbus-ev/current
tail -n 80 /var/log/vrmlogger/current

svc -s suspends a process; it does not show status. Never cat supervise/ok, which is a FIFO. Repository names and supervised instance names can differ.

Verify numeric D-Bus values, /Connected, fresh source data and successful VRM uploads. Native MQTT topics use N/<portal-id>/...; raw sensor and application topics have their own contracts. Use the actual portal ID and the existing GX broker.

On the audited device /var/log points to persistent /data/log. Bound logs with multilog and keep frequent cursors/heartbeats under /run. Test reboot and firmware recovery during a planned maintenance window.

A connected broker or successful HTTP response does not prove fresh telemetry. Keep blocking requests outside the D-Bus main loop, preserve acquisition timestamps through queued callbacks, and expire MQTT fields independently. Freshness checks and network polling can have different intervals.

The September audit closure records the additional releases, device checks, passive meter capture and remaining physical validation limits.

Read the complete installation guide and service audit.