Metadata-Version: 2.4
Name: moat-ems-inv
Version: 0.2.19
Summary: REPLACE ME
Author-email: Matthias Urlichs <matthias@urlichs.de>
Project-URL: homepage, https://m-o-a-t.org
Project-URL: repository, https://github.com/M-o-a-T/moat
Keywords: MoaT
Classifier: Development Status :: 4 - Beta
Classifier: Framework :: AnyIO
Classifier: Framework :: Trio
Classifier: Framework :: AsyncIO
Classifier: Programming Language :: Python :: 3
Classifier: Intended Audience :: Developers
Requires-Python: >=3.8
Description-Content-Type: text/markdown
License-File: LICENSE.txt
Requires-Dist: anyio~=4.2
Requires-Dist: moat-util~=0.64.0
Requires-Dist: moat-modbus~=0.9.0
Requires-Dist: moat-ems-victron~=0.1.6
Dynamic: license-file

# Victron Scripts

% start synopsis
% start main

This repository attempts to establish a modern framework for talking to
Victron Energy products, mainly via Dbus.

% end synopsis

Also included:

* a modular program to control the charger/inverter.

* a status monitor that emits a single line with the salient facts, every second.

* a couple of patches that this author thinks are particularly helpful.

* Integration with the `twe_meter` project, which adds support for
  several types of energy meter that Venus doesn't support out of the box.

* Integration with the MoaT BMS, which (currently) uses diyBMS cell monitors,
  with a Rp2040 running MicroPython acting as the controller.

## Rationale

The original Victron code uses synchronous Python and manages its
tasks et al. with GLib. Its documentation warns in multiple places
that GLib likes to swallow errors and might leave the system in an
inconsistent state; it even includes a helper that, on error, directly
kills the program, circumventing the SystemExit exception Python
normally uses for this.

This is way beyond ugly, in this author's opinion. To be sure, there
were no good alternatives at the time it was written, but that's no
excuse to keep doing it.

This library thus replaces the whole thing with an async library based on `anyio`
and `asyncdbus`. Usage is a bit different, of course, but there are several
advantages:

* no more swallowing of errors. Ever.

* you can write fallback code, or leave-the-system-in-a-safe-state-when-you-die
  code, that actually has a chance of running when conditions warrant.

* you can write multi-step control loops with timeouts and whatnot
  which don't depend on timer callbacks and related unsafe nonsense,
  yet can be cleanly switched off and replaced without terminating your
  controller.

* etc.

% end main

## Modules

The modules `victron.dbus` and `victron.dbus.monitor` are suitably modified,
if not rewritten, copies of `/opt/victronenergy/dbus-systemcalc-py/ext/velib-python`.

## Battery Management

A submodule of this archive implements a Battery Management System ("BMS").

## Random stuff

### Notes

#### Critical Settings

* com.victronenergy.settings /Settings/CGwacs/OvervoltageFeedIn

needs to be zero. This can happen when you play with your settings,
as some combination of changes appears to set this value but doesn't
bother to clear it.

The idea of this parameter is that an external program will increase
feed-out when the battery is at its charge limit, thus reducing solar
input is not necessary.

Unfortunately there is no safeguard if that feed-out should ever
not work (too much sun, AC inverter overheated, grid offline, …).

The result of this being set is that DVCC always sets solar power to
max and won't reduce it even if the battery becomes overloaded.
This is obviously a very bad idea.

#### Confing file examples

The files named '24 are used on a small test system (24V, 10Ah, Multiplus 24/500),
with 80 Wp solar input.

The others are in use on a "production" 48V, 280Ah, 3-phase Multiplus II 5000 system
with 11 kWp of solar arrays.

The BMS code in `bus/python` controls both sets of batteries.
