Setup EEBUS by default

[DerAndereAndi]

Is your feature request related to a problem? Please describe.
In Germany at some point all households with a wallbox need to be connected to a SMGW or control box. They all need to setup EEBUS so the installation person will be able to scan a QR code for evcc (which is future requirement).

Describe the solution you'd like
To make this as seamless as possible, the end user should only have to show the QR code which is already generated. For that EEBUS already has to be working and setup.

Additional context
It is also critical that the EEBUS setup never changes. So the plantid, derived SHIP ID and certificate have to remain constant when moving to other devices, re-installation, etc. So having some kind of core-system-backup or other solution might be helpful. Because otherwise the SMGW will refuse further connections and the whole scanning and providing the QR code process with the MSB has to be done over and over again.

TODO

• simplify port config 8525922

[VolkerK62]

Must the SHIP ID be entered into the configuration?

[DerAndereAndi]

No. The SHIP ID is generated. The config option is only for development purposes

[CiNcH83]

Isn't it also necessary to select the controlbox inside evcc, e.g. via evcc.yaml?

hems:
  type: eebus
  ski: A46D9C217B8F335E921C4FAA087E615C9D2A73F0

So it would also make sense to scan for EEBUS devices via UI and select the box from there, no? How will you find out the controlbox's SKI otherwise?

Consolinno for example has such a facility for their Leaflet HEMS, see manual:

[andig]

These are different things. One is configuring the EEBUS service instance (providing all the use cases). The other is actually connecting and use cases to external devices.

OT: But it‘s interesting to see the auto discovery. Any idea how they do that? Looking for MDNS announcements?

/cc @DerAndereAndi

[DerAndereAndi]

The SKI of the SMGW is not known and can not be seen on the network until it is commissioned with the SKI of the connected device.

[CiNcH83]

It is also critical that the EEBUS setup never changes. So the plantid, derived SHIP ID and certificate have to remain constant when moving to other devices, re-installation, etc.

I don't really know how I got into this situation, but I do have a different plant ID in the evcc.yaml than in the evcc.db. I did set up EEBUS in the yaml. I don't know how the plant ID in the db got created and why it hasn't been migrated from yaml (probably I had EEBUS disabled when the plant ID has been created in the db).

This split yaml/db configuration is a pain IMHO. I don't see through the whole thing and I am afraid this could bite us in the ass with EEBUS config migration into the db. I guess I will start from scratch with db only config before ever connecting to a controlbox/SMGW.