Scenario 1: The hardware knows what class/role/service type it is. This is where we are going with Victron hardware: Settings are stored on the device. In this scenario, when the driver calls AddSettings, whatever class it asks for can overwrite what is in localsettings, and it will make sure the Vrm Instance is unique for that class.
Scenario 2: The hardware does NOT know what class it is. It derives that from the value of ClassAndVrmInstance. dbus-modbus-client and dbus-cgwacs does this. When it calls AddSettings, it expects the setting to be added if it does not exist yet, or for the existing value to be returned if the setting already exists. This way the service can call AddSettings at the beginning, and immediately get back the relevant information in a single dbus call.
Scenario 1 is in v1.57.
Scenario 2 is how it was before Localsettings v1.57.
Introduced in Venus 3.20~9. Suspect it is caused by changes in localsettings v1.57.
Related to this change: https://github.com/victronenergy/venus/issues/1150
After some discussions, there are two scenarios.
Scenario 1: The hardware knows what class/role/service type it is. This is where we are going with Victron hardware: Settings are stored on the device. In this scenario, when the driver calls
AddSettings, whatever class it asks for can overwrite what is in localsettings, and it will make sure the Vrm Instance is unique for that class.Scenario 2: The hardware does NOT know what class it is. It derives that from the value of
ClassAndVrmInstance. dbus-modbus-client and dbus-cgwacs does this. When it callsAddSettings, it expects the setting to be added if it does not exist yet, or for the existing value to be returned if the setting already exists. This way the service can callAddSettingsat the beginning, and immediately get back the relevant information in a single dbus call.Scenario 1 is in v1.57. Scenario 2 is how it was before Localsettings v1.57.