Settings: Add a sortable priority list

[philipptrenz]

Link to Figma

• Via the arrow up and down buttons, the list can be rearranged.
• Arrow up of first element and arrow down of last element is disabled and grayed out for obvious reasons.
• By tapping the element itself, it leads to a new settings page for this device – content of it is to be specified.

Source of the list will be in dbus-systemcalc, it's structure is to be discussed. As an initial idea, I would suggest a D-Bus path with a JSON array, containing service mappings:

[
    {"service": "com.victronenergy.acload.device_1"},
    {"service": "com.victronenergy.ev_charger.1234567"},
    {"service": "com.victronenergy.acload.device_3"},
    {"service": "com.victronenergy.dcload.abcd"}
]

[mpvader]

Have a look at how com.victronenergy.system /AvailableBatteries works @philipptrenz .

[philipptrenz]

As just discussed with @realdognose, this is our proposal:

[
    { "serviceType": "acload", "deviceInstance": 10 },
    { "serviceType": "system", "deviceInstance": 0 },
    { "serviceType": "evcharger", "deviceInstance": 50 },
    { "serviceType": "acload", "deviceInstance": 11 }
]

The system service name will be "Battery".

If preferred, we can of course also use “com.victronenergy.battery/<device_instance>”, which is what com.victronenergy.system /AvailableBatteries uses.

Some details:

• serviceType defines the D-Bus/MQTT service type for the relevant device (with com.victronenergy. stripped)
• deviceInsance the VRM Device Instance
• The QML settings model to be used when clicking an item will be derived from the given "serviceType"

[philipptrenz]

@DanielMcInnes: @realdognose will implement the above proposed dbus API and deploy it at his system, so that you can use that to test against.

And for reference, below you find the overall current status of how it is planned to be integrated. The blurred subpages will be the ones referenced by configModel and are still to be defined.

[ReinvdZee]

@DanielMcInnes, ( fyi @philipptrenz)

@realdognose and I just discussed this topic and decided that there should be an additional key to the JSON: controllable. This key is there to let the UI know that the service is controllable or not. A service can be controllable because of varying reasons:

• Not configured properly
• Consumer offline
• No car plugged in
• etc.

(A service will have it's controllable key set to false when the RM ONLY offers the 'NO_CTRL' control type.)

Also, the opportunity loads part is stripped from systemcalc and moved to its own service. You can find the path here:

com.victronenergy.opportunityloads/AvailableServices

And it'll look like:

[
	{
		"deviceInstance": 0,
		"serviceType": "system",
		"uniqueIdentifier": "battery",
		"controllable": true
	},
	{
		"deviceInstance": 56,
		"serviceType": "acload",
		"uniqueIdentifier": "shellyPro2PMPVHeat2_56",
		"controllable": false
	}
]

You can ignore the uniqueidentifier, it is used by the opportunity loads service only. And note that the "system" service should be labeled "Battery". For the other services, the standard /CustomName | /ProductName rule applies.

The contents of the subpages are to be designed/implemented later, please focus on the sortable list and modifying the JSON first.