systemcalc: get AC volts, amps and frequency to the UIs

[mpvader]

There are multiple solutions.

The reason for this is the VRM Dashboard, which is currently being extended by Teun to have far more data in its detailed-mode.

Discussed on slack here: https://victrondevelopment.slack.com/archives/C7C1ZU6UD/p1629140050083000

[izak]

Background:

• Systemcalc already knows which meters it will use for grid and genset: https://github.com/victronenergy/dbus-systemcalc-py/blob/master/dbus_systemcalc.py#L703

• If no grid meter and/or no genset meter, it falls back to vebus

• When using vebus for grid and generator values, it can only give you information about the one that is currently connected, so in this case you must unavoidably lose information about the other input.

Specification

• Create a set of dbus paths under /Ac/In/0/... and /Ac/In/1/..., with some suitable representation below it.

• VRM can't really do anything with a service name, it will need the service type and the device instance in order to construct an MQTT path. Other local dbus services will find the service name itself more useful. So I suggest:

  • /Ac/In/0/ServiceName (eg com.victronenergy.grid.ttyUSB0 or com.victronenergy.vebus.ttyO1)
  • /Ac/In/0/ServiceType (grid, genset or vebus)
  • /Ac/In/0/DeviceInstance (device instance on venus)
  • /Ac/In/0/VrmDeviceInstance (same as DeviceInstance, except on a CCGX where it historically must be zero. Logged to VRM).
  • /Ac/In/0/Source (1 = grid, 2 = generator, 3 = shore)
  • /Ac/In/0/Connected (0 = disconnected, 1 = connected, this duplicates the information in /Ac/ActiveIn/Source somewhat, but less ambiguously)

• And the same for /Ac/In/1.

• Additionally, the number of available inputs will be republished from the Multi for convenience. This can be 0, 1 or 2. If an input is not used (as set in com.victronenergy.settings/Settings/SystemSetup/AcInput1), this could be lower than the actual set available on the hardware.

  • /Ac/In/NumberOfAcInputs

How it will work:

Below, "grid meter" means an energy meter used to measure the grid, and "genset meter" means an energy meter used to measure a genset. Subtree refers to the part under /Ac/Sources that provides information about that source.

To make the example concrete, assume the generator is on AC-IN-1, and the grid is on AC-IN-2.

1. If you have both a grid meter and a genset meter, then /Ac/In/1 will contain the information for the grid meter, and /Ac/In/0 will contain the information for the genset meter. Easy peasy.
2. If you have meters for neither grid nor genset, then only one of the subtrees will be populated at a time depending on the active input of the Multi/Quattro. The other one will show all values invalid (except Source). The ServiceType for the active input will be vebus in this case.
3. If you have a grid meter, but no genset meter, then /Ac/In/1 always points to the grid meter, and /Ac/In/0 points to vebus ONLY when the active AC input is configured as a generator, otherwise all values are invalid (except Source).
4. Conversely, if you have a genset meter, but no grid meter, then the /Ac/In/1 points to vebus ONLY when the active AC input is grid, otherwise it is invalid. /Ac/In/0 always points to the genset meter.
5. /Ac/In/x/Source is always available, since that is configured in localsettings and always known.

[AlexImb]

@izak can we add data attributes for these new paths? Most of the logic in VRM relies on data attributes that are then mapped to MQTT paths.

[izak]

@AlexImb I added the attributes to vrmlogger, and I made an issue documenting them as usual in the VRM tracker.

[mpvader]

This is all done and works.