With the new design, we would also like to add support for grid meters, as not all systems have a Multi/Quattro, but do have a grid meter installed. This would apply to the shore/grid input and possibly also to the generator.
The paths that are related can be used find out which service is responsible for the data.
I assume VRM is using similar logic to populate the AC input (and generator?) blocks.
com.victronenergy.system:
Ac/In/[0,1]/Connected <-- 0=disconnected, 1=connected
Ac/In/[0,1]/DeviceInstance <-- Device instance, typically used for MQTT
Ac/In/[0,1]/ServiceName <-- The full dbus service name
Ac/In/[0,1]/ServiceType <-- E.g. vebus, grid, etc. typically used for MQTT
Ac/In/[0,1]/Source <-- 0=not used, 1=grid, 2=generator, 3=shore
Generators
A generator is typically connected to the AC input of a Multi/Quattro. This would be reflected by com.victronenergy.system/Ac/In/n/*.
This would also be the case with a Fischer Panda generator. However, in that particular case, we could prefer to take the AC readings from the generator itself, rather than the Multi/Quattro.
Feature request from community: https://community.victronenergy.com/questions/177768/nmea-2000-2.html
With the new design, we would also like to add support for grid meters, as not all systems have a Multi/Quattro, but do have a grid meter installed. This would apply to the shore/grid input and possibly also to the generator.
The paths that are related can be used find out which service is responsible for the data. I assume VRM is using similar logic to populate the AC input (and generator?) blocks.
Example:
Generators A generator is typically connected to the AC input of a Multi/Quattro. This would be reflected by
com.victronenergy.system/Ac/In/n/*
. This would also be the case with a Fischer Panda generator. However, in that particular case, we could prefer to take the AC readings from the generator itself, rather than the Multi/Quattro.