After Server Restart all settings fields are unusable

[JustantherMe]

Hi everyone,

I am using an enhanced version of powerworld_pw58410_waterheater.yaml and I will share my updates once it is stable.

After a Home Assistant restart, the settings do not disappear, they just are not loaded at startup. Until I change any random setting, the parameter groups are not present. That means I cannot reliably read or write those values and automations depending on them fail.

Right after an HA reboot, the entity attributes look like this and the parameter groups are not loaded:

`min_temp: 0
max_temp: 99
target_temp_step: 1
operation_list:

• "off"
• heat_pump
  current_temperature: 53
  temperature: 46
  target_temp_high: null
  target_temp_low: null
  operation_mode: heat_pump
  power_statistics (ID 140): >-
  AAAAAAAAAAAAAAAKAAAA6wAAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAfqAAAAAQAAAAYAAAAQAAAAIQAAADIAAAAAAAAAAAAAAAA=
  friendly_name: Water heat pump
  supported_features: 11
  `
  As soon as I change any random setting, the parameter groups get loaded and show up again:

`min_temp: 0
max_temp: 99
target_temp_step: 1
operation_list:

• "off"
• heat_pump
  current_temperature: 53
  temperature: 46
  target_temp_high: null
  target_temp_low: null
  operation_mode: heat_pump
  parameter_group_1 (ID 118): >-
  AAAAAwAAAAQAAAAuAAAAFgAAABcAAAABAAAAHgAAAA0AAAAeAAAAQQAAAEEAAAABAAAAGgAAAAYAAAAA////+wAAAB4AAAAEAAAAAAAAAB4=
  parameter_group_2 (ID 119): >-
  AAAAAgAAAEEAAABGAAAALf////0AAAAIAAAADwAAAAUAAAAFAAAAEQAAAB4AAAAjAAAAKAAAAC0AAAAyAAAANwAAADwAAABBAAAARgAAAEs=
  parameter_group_3 (ID 120): >-
  AAAAUAAAAFUAAAAoAAAAUP////sAAAAAAAAAXQAAAH0AAAB9AAAAfQAAAH0AAAB9AAAAfQAAAH0AAAB9AAAADwAAADwAAAAKAAAAPAAAADw=
  parameter_group_4 (ID 121): >-
  AAAAZAAAADIAAAAKAAAABQAAAB4AAAAHAAAABgAAAAYAAAAFAAAABAAAAAQAAAAEAAAABAAAAAYAAAAEAAAACAAAAAgAAACvAAAAlgAAAH0=
  parameter_group_5 (ID 122): >-
  AAAAZAAAAEsAAABGAAAAPAAAADIAAADhAAAArwAAAJYAAACWAAAArwAAAJYAAABkAAAASwAAADIAAAAyAAAALQAAAC0AAAAtAAAAKAAAAB4=
  parameter_group_6 (ID 123): >-
  AAAAHgAAAFoAAADhAAAAKAAAAAIAAACvAAAABQAAAAEAAAAAAAAArwAAABcAAAAGAAAAAQAAAAYAAAABAAAAFAAAAF8AAAA8AAAASwAAAAo=
  parameter_group_7 (ID 124): >-
  AAAAAAAAAAUAAAAAAAAAPAAAADz////7AAAABQAAAAoAAAAPAAAAFAAAAB4AAAAeAAAAAAAAALQAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEs=
  parameter_group_8 (ID 126): >-
  AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
  power_statistics (ID 140): >-
  AAAAAAAAAAAAAAAKAAAA6wAAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAfqAAAAAQAAAAYAAAAQAAAAIQAAADIAAAAAAAAAAAAAAAA=
  friendly_name: Water heat pump
  supported_features: 11
  `
  Does anyone know a good way to force an initial read on startup so these parameter groups get populated automatically. For example a refresh or poll service call, or a safe dummy action that triggers the device to send its full state.

Thanks!

[make-all]

There is not a generic answer here. Different devices behave differently, some have a dp for turning updates on and off, others require some dps to be explicitly requested (implemented as force: true by this integration) but others crash when that is done so we cannot blindly use it for all devices. Some will return dps when a related (or sometimes even unrelated) config dp is updated (sometimes the update can be the same setting it already has, other times it actually has to change something).

[JustantherMe]

Hi Thanks for the quick response.
I've tested this in two different configurations, but unfortunately neither has resolved the issue:

Configuration 1: Using base64 type with masking

- entity: number
  name: Heating setting temperature (App)
  category: config
  class: temperature
  dps:
    - id: 118
      type: base64
      optional: true
      force: true
      name: value
      unit: C
      range:
        min: 15
        max: 70
      mask: "00000000000000000000000000000000FFFFFFFF00000000\
        000000000000000000000000000000000000000000000000\
        000000000000000000000000000000000000000000000000\
        0000000000000000"

Configuration 2: Using string type
```

• id: 118
  type: string
  optional: true
  force: true
  name: parameter_group_1 (ID 118)

I've tried both with and without the optional: true parameter, but neither approach has made a difference. Any suggestions on what else I could try or am i applying it wrong?

[make-all]

This is not surprisng. force: true has really only been known to work for power/current/voltage readings on some smartplugs. It is not a general solution for missing dps.