Config UI: visualize Modbusproxy

[Maschga]

🖼 visualize modbusproxy section
💪 use TypeScript

TODO:

• handle both yaml and json in database
• outsource some FormRows (?)
• add tests
• add/remove i18n strings

\cc @naltatis

[naltatis]

Nice PR.

I'm not convinced with the top-level network/serial split of the interface. My suggestion would be to keep it one list with a "+ add connection" button. Each entry must start with the port (follow the data flow, see below), then users must decide if the device is connected via network/serial and gets the appropriate input fields.

On large screens (lg modal) this should be a two column layout (left column port, →, network/serial connection). On small screens this folds into one column (no arrow).

I've added a small ascii diagram we can include to explain the individual parts of the configuration.

I think it's fine to not translate this.

[naltatis]

Suggested change

	v-model="connection.Settings.URI"
	v-model="connection.settings.uri"

Lower case. See other published structures.

[Maschga]

Die anderen Felder (Port, ReadOnly) sind aber auch Upper Case:
Oder geht es darum, dass Settings wiederum ein Objekt enthält und deshalb klein zu schreiben ist?

evcc/api/globalconfig/types.go

Lines 59 to 60 in 180145e

	Port int
	ReadOnly string `yaml:",omitempty" json:",omitempty"`

[naltatis]

generell published wir die Werte immer camelCase (bspw. json:readOnly). Siehe bspw. hier https://github.com/evcc-io/evcc/blob/master/api/globalconfig/types.go#L155C1-L156C1

[Maschga]

Didn't knew about the Switch and Modbus.vue. I like its UI and would like to reuse this file or at least some parts of it.
I thought about creating a Modbus-folder in which each FormRow of the Modbus.vue is stored. This way, we could put together the Modbus-forms depending on the topic (Chargermodal or Modbusproxy).
The other idea would be to add the props showIdForm and showReadonlyForm to Modbus.vue.

[naltatis]

The other idea would be to add the props showIdForm and showReadonlyForm to Modbus.vue.

Give it a try. The logic is non-trivial, but currently I dont see a reason why this should be different here.

[naltatis]

Find ich keine gute Idee. Die innere Komponente sollte nichts vom äußeren Kontext wissen müssen. Dann zieh das readonly lieber raus: Komposition.

Host+Port find ich generell besser in zwei Feldern. Lass uns das im Modbus Proxy Kontext einfach transparent zerlegen bzw wieder zusammenbauen split(":").

[Maschga]

Die innere Komponente sollte nichts vom äußeren Kontext wissen müssen.

Inwiefern passiert das hier?

Dann zieh das readonly lieber raus

Dann haben wir wieder ein Kuddelmuddel, was die ModbusFormRows angeht.

Host+Port find ich generell besser in zwei Feldern

Das führt dazu, dass auf kleinen Bildschirmen zweimal ein Port-FormRow angezeigt wird. Auch nicht schön, finde ich.

[CiNcH83]

Also wenn man bei den Begrifflichkeiten korrekt sein will... Die abfragende Instanz ist der Master. Und da es nur einen Master geben kann gibt es Proxies. Das abgefragte Gerät ist demnach der Slave. Mit Client und Device (oder Server) kann ich auch gut. Aber dass in dem ASCII Diagramm das abefragte Gerät der Client ist, finde ich befremdlich.

[PhilippHaefele]

Also wenn man bei den Begrifflichkeiten korrekt sein will... Die abfragende Instanz ist der Master. Und da es nur einen Master geben kann gibt es Proxies. Das abgefragte Gerät ist demnach der Slave. Mit Client und Device (oder Server) kann ich auch gut. Aber dass in dem ASCII Diagramm das abefragte Gerät der Client ist, finde ich befremdlich.

https://www.modbus.org/news/modbus-organization-replaces-master-slave-with-client-server

Der Client im ASCII ist der externe client welcher dann mit dem evcc Server (Proxy) eine Verbindung aufbaut.

Daher würde ich schon sagen, dass das so gut passt

[Maschga]

@naltatis This is the current state of the UI. It is not yet finalized and only works on large screens.
Is this what you had in mind?

(Please do not discuss the terminology. This is only about the UI.)

[naltatis]

@Maschga Looks good.

• v alignment: I't stick top top alignment. The first thing the user should fill out is the source port, but with center alignment this might not the first thing he sees. I'd keep the arrow at form element height: aligned with the source port text field and the network/usb select
• boxes/box-headlines: I'm unsure. it does not feel right, but I dont have a concrete alternative right now. If it's ok for you I'll play with some variants later.
• Delete icon feels a little lost (and close to box). Since the form entry is quite large I'd use a text button here "Remove connection"
• We likly need a divider line (similar to subheadline style wise but without text) after the last connection entry to give the "add network connection" it's own space

[Maschga]

Thank you for your feedback.

If it's ok for you I'll play with some variants later.

Feel free to rearrange the entire UI.

[Maschga]

Large screens:

Small screens:

[Maschga]

@naltatis No pressure, but it would be great if you could review the UI when you get a chance.