Support reading configuration values from devices

[iseeberg79]

Is your feature request related to a problem? Please describe.

Currently, device configuration requires users to manually configure values that are already available from the devices themselves (e.g., from modbus registers). This creates redundant configuration work and potential for errors when the values could be read directly from the hardware.

Describe the solution you'd like

I'd like a feature that automatically reads configuration values from device registers (e.g., modbus) and uses them as internal defaults. This would be particularly useful for parameters such as:

• maxchargepower
• maxacpower
• maxdischargepower
• minsoc
• maxsoc

These values could be read from inverters, batteries, or other hardware devices. The registers could be read either once at startup or periodically at regular intervals if the values change dynamically during operation.

Describe alternatives you've considered

Currently, these values must be statically configured via UI or YAML. While templates can be used, they still require manually configuring values that the devices already provide, which doesn't eliminate the redundancy.

[andig]

We've recently added configuration "services" that can make default suggestions from the backend. We could add such a service for reading from modbus. This is however not entirely trivial since modbus parameters are kinda special. Feel free to take a stab at this.

See viessman or homeassistant for a service example:

auth:
  type: viessmann
  params: [clientid, redirecturi, gateway_serial]

and

  - name: uri
    description:
      de: Home Assistant URI
      en: Home Assistant URI
    example: http://homeassistant.local:8123
    help:
      en: " " # overwrite default
      de: " " # overwrite default
    service: homeassistant/instances
    required: true

[iseeberg79]

Sounds great to retrieve better defaults on configuration time at least.

I've an idea about and will give it a try.

[iseeberg79]

I would also like to implement this approach for HTTP templates. Since this should be implemented as a separate service, I would like to wait until the above changes have been merged. The approach that follows this service logic has already proven itself locally, and an additional PR is in preparation to enable the transfer of device-specific default settings/proposals for HTTP-based templates as well.