EEBUS: configure by default

[andig]

Fix #26596

TODO

• read/write userflow (read only mode)
• improve i18n strings
• add e2e tests

Out of scope

• show qr code

/cc @Maschga

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[andig]

Friedly ping regarding ui

[Maschga]

What needs to be changed here in the UI?

[naltatis]

@Maschga replace the yaml editor in ui with custom form based ui (json). relevant fields are shipid, certificate.public and certificate.private (masked). Since these fields are auto-generated on startup the user usually does not have to do anything there. that's why I'd show these values as readonly and make the user enter an explicit "edit mode". editing this may break existing integrations with established connection (grid operator).

If you like you can do this. Should follow our existing pattern of yaml>json conversions 😄

[Maschga]

Thanks for the instructions. Will create a PR for the UI.

[naltatis]

Suggested Order:

shipid
certs
-- advanced --
port
interfaces

[Maschga]

That's fine with me. I wasn't sure how to arrange them, thought that changing ports or interfaces might happen a little more often.

[naltatis]

My assumption would be that a regular user touches non of this - ever 😄

[naltatis]

Suggested change

	return ["accessToken", "refreshToken", "identifiers", "interfaces"].includes(
	return this.array || ["accessToken", "refreshToken"].includes(

[naltatis]

Do we want to add QR Code as part of this PR as well? See #26882 (comment) by @CiNcH83

This could solve the user flow issue. When opening the eebus modal we could show only the description text and the QR-code - no form, delete and edit options. If the users confirms that he really wants to manual configure (I know what I'm doing) he enters edit-mode (the regular edit form).

@andig do we have the qr-code string (see comment) at hand? If we would publish this along side the config (see Status discussion above) generating the QR code in ui is easy.

[andig]

Do we want to add QR Code as part of this PR as well?

No. Our library version doesn't support that.

[naltatis]

Ok, that let's save that for a later pr.

[andig]

Added config/ski to published values

[Maschga]

@naltatis Do we already have such a read/write user flow elsewhere?

[naltatis]

@naltatis Do we already have such a read/write user flow elsewhere?

Do you mean my suggestion that fields are read-only at start?

I just look at how we implemented SMA/SEMP. There we decided to make all fields advanced since no manual configuration should be required for most people. We could keep it simple and do exactly the same here.

• Make all fields advanced.
• Add a danger-disclaimer-box "No changes required. Only change if you really know what you're doing" to the top of the advanced section.
• Expand the above description and add required system info as above the "show advanced" block. Once we have the QR-code we could also add it there.

@DerAndereAndi What text info should we present the user in this dialog? ship id, ski, fingerprints, brand? What is the eebus recommended or commonly used end-user naming? QR-code will follow later.

[Maschga]

Do you mean my suggestion that fields are read-only at start?

Yes. :)

There we decided to make all fields advanced since no manual configuration should be required for most people. We could keep it simple and do exactly the same here.

I like this idea. It is simple and follows a pattern that is already used. I'll create a PR.