Plugwise: KeyError: 'setpoint'

[Mariusthvdb]

The problem

seeing below error in logs after updating to September beta and restarting consistently

number.opentherm_domestic_hot_water_setpoint no longer being available

What version of Home Assistant Core has the issue?

2023.9 beta 0

What was the last working version of Home Assistant Core?

2023.8.4

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Plugwise

Link to integration documentation on our website

https://rc.home-assistant.io/integrations/plugwise/

Diagnostics information

config_entry-plugwise-474a410dc55f45ad8124f87f62baa412.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.components.number
Source: components/plugwise/number.py:107 
Integration: Nummer (documentation, issues) 
First occurred: 08:11:33 (2 occurrences) 
Last logged: 08:11:33

Error adding entities for domain number with platform plugwise
Error while setting up plugwise platform for number
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 752, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 989, in add_to_platform_finish
    await self.async_added_to_hass()
  File "/usr/src/homeassistant/homeassistant/components/plugwise/entity.py", line 81, in async_added_to_hass
    self._handle_coordinator_update()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 473, in _handle_coordinator_update
    self.async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 726, in async_write_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 826, in _async_write_ha_state
    state, attr = self._async_generate_attributes()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 767, in _async_generate_attributes
    state = self._stringify_state(available)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 732, in _stringify_state
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/number/__init__.py", line 320, in state
    return self.value
           ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/number/__init__.py", line 358, in value
    if (native_value := self.native_value) is None:
                        ^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/plugwise/number.py", line 107, in native_value
    return self.device[self.entity_description.key]["setpoint"]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'setpoint'

Additional information

[home-assistant[bot]]

Hey there @compatech, @bouwew, @frenck, mind taking a look at this issue as it has been labeled with an integration (plugwise) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `plugwise` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign plugwise` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

plugwise documentation plugwise source _{^{(message by IssueLinks)}}

[bouwew]

@Mariusthvdb can you please add the diagnostics info?

[Mariusthvdb]

done, sorry I looked in the wrong place before...

[bouwew]

Thanks! The problem clearly shows, the key "setpoint" is indeed missing in the related number-dict. We'll investigate.

[bouwew]

Hmm, I'm not sure what could be wrong. Can you please check the xml-data on your Smile? http://<smile-ip>/core/appliances please look for:

<actuator_functionalities>
   ...
            <thermostat_functionality id='d9455c3ba0b0412cb264b8b33f4e3849'>
                <updated_date>2020-04-08T19:24:38.964+02:00</updated_date>
                <type>domestic_hot_water_setpoint</type>
                <setpoint>53</setpoint>
                <lower_bound>35</lower_bound>
                <upper_bound>60</upper_bound>
                <resolution>0.01</resolution>
                <regulations/>
                <thermostat id='5e49f223e7224c3f93552db2c63881f6'/>
            </thermostat_functionality>

How does this bit of xml look like on your Smile?

[bouwew]

I did some more investigation last evening, couldn't find anything wrong in both the backend and the Core plugwise files. I'm now suspecting a malformed xml-line in the Plugwise database on the Smile to be the cause of the issue.

[Mariusthvdb]

really sorry but had to roll back twice now, since Wave keeps crashing in the 2023.9 beta cycle (now b01)

dont see the message in 2023.8.4 so dont think I will be able to contribute further until 2023.9 fixes zwave

the xml looks like:

<actuator_functionalities>
<toggle_functionality id="1d50391fc5be480aa1cc250bd0e1f9ee">
<cooling_toggle id="ca4c4795600742bfb9112ed2a02a579a"/>
<updated_date>2023-08-08T03:34:07.076+02:00</updated_date>
<type>cooling_enabled</type>
<state>off</state>
</toggle_functionality>
<thermostat_functionality id="6ca0fce8e7704b278708aa14373a8ff2">
<updated_date>2023-08-08T03:34:48.317+02:00</updated_date>
<type>maximum_boiler_temperature</type>
<lower_bound>50</lower_bound>
<upper_bound>60</upper_bound>
<resolution>0.01</resolution>
<setpoint>60</setpoint>
<regulations/>
</thermostat_functionality>
<toggle_functionality id="7f9a003d63ca4eb0b1c5f889485bea44">
<domestic_hot_water_toggle id="9d5c3ea23b6542dab2c8c55c05e8d574"/>
<updated_date>2023-08-31T08:21:55.879+02:00</updated_date>
<type>domestic_hot_water_comfort_mode</type>
<state>off</state>
</toggle_functionality>
<thermostat_functionality id="9d0a8a45f4964de39a351d098a57348e">
<updated_date/>
<type>domestic_hot_water_setpoint</type>
<lower_bound>30</lower_bound>
<upper_bound>60</upper_bound>
<resolution>0.01</resolution>
<regulations/>
<thermostat id="7380e1795d5e46aaafa9d5f2fcc41438"/>
</thermostat_functionality>
</actuator_functionalities>

[bouwew]

Thanks! The relevant part doesn't look correct:

<thermostat_functionality id="9d0a8a45f4964de39a351d098a57348e">
    <updated_date/>
    <type>domestic_hot_water_setpoint</type>
    <lower_bound>30</lower_bound>
    <upper_bound>60</upper_bound>
    <resolution>0.01</resolution>
    <regulations/>
    <thermostat id="7380e1795d5e46aaafa9d5f2fcc41438"/>
</thermostat_functionality>

The updated_date-key is not complete and the setpoint-key is missing.

Looks like your Plugwise xml-database is indeed malformed. I would suggest to reset your Smile via a 15-second press on the small black reset-button. Such a reset should lead to a renewal of the Plugwise xml-database. I've tested this on my Adam, it worked for me.

I am a bit surprised that this does work on the 2023.8.4 version...

[bouwew]

Or, maybe you can try changing the DHW-setpoint via the Plugwise App.

I remember another Plugwise owner having a similar problem, when he made a change via the Plugwise App, the malformed keys became corrected.

[Mariusthvdb]

Thanks! The relevant part doesn't look correct:

<thermostat_functionality id="9d0a8a45f4964de39a351d098a57348e">
    <updated_date/>
    <type>domestic_hot_water_setpoint</type>
    <lower_bound>30</lower_bound>
    <upper_bound>60</upper_bound>
    <resolution>0.01</resolution>
    <regulations/>
    <thermostat id="7380e1795d5e46aaafa9d5f2fcc41438"/>
</thermostat_functionality>

The updated_date-key is not complete and the setpoint-key is missing.

Looks like your Plugwise xml-database is indeed malformed. I would suggest to reset your Smile via a 15-second press on the small black reset-button. Such a reset should lead to a renewal of the Plugwise xml-database. I've tested this on my Adam, it worked for me.

I am a bit surprised that this does work on the 2023.8.4 version...

there was another section in the xml which I posted shortly after you copied my first edit I believe.

Would that still be incomplete?

[bouwew]

Yes, the short xml section I'm showing in my last post above was copied from the larger xml section you had posted. I had added the indentation to improve the readability, to be able to show more clearly that there is one line missing, the one with the setpoint-value.

[Mariusthvdb]

really sorry but I can't find that setting in the app, would you have a screenshot of that?

just to be sure you know: I have disabled the 'Tapwatercomfortstand' as I dont want the heater to warm my connected solar boiler.

since the domestic hotter entity in the opening post still was unavailable, (and no longer available on the integration) I deleted it, and restarted, hoping that might make a difference.

It doesnt however, and the unavailable entity gets recreated....

I also toggled the switch, and changed the max temp in that settings card, but no changed unfortunately

restarting the gateway now also made the other number entity go unavailable

[Mariusthvdb]

btw, I just updated to the last beta 2023.9.0b6 whihc changed the error into:

Logger: homeassistant.components.number
Source: components/plugwise/number.py:100 
Integration: Nummer (documentation, issues) 
First occurred: 17:28:41 (1 occurrences) 
Last logged: 17:28:41

Error while setting up plugwise platform for number
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 359, in _async_setup_platform
    await asyncio.shield(task)
  File "/usr/src/homeassistant/homeassistant/components/plugwise/number.py", line 78, in async_setup_entry
    PlugwiseNumberEntity(coordinator, device_id, description)
  File "/usr/src/homeassistant/homeassistant/components/plugwise/number.py", line 100, in __init__
    self._attr_native_max_value = self.device[description.key]["upper_bound"]
                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^
TypeError: 'float' object is not subscriptable

still seeing this though:

not sure about the outdoor air, but that is not very accurate (currently being 30 C or so) ;-)

[bouwew]

In the Plugwise App the relevant settings are under Settings --> Heating system --> Heating --> Advanced settings. On my Adam I see there this:

I only have the Number Maximum boiler temperature. What do you see there?

[bouwew]

I see that both Numbers are grayed out, and looking at how the error has changed, I'm thinking (the memory of) your Smile T is dying. You could try the 15-seconds (factory)-reset, maybe that will temporarily remedy the problem.

[Mariusthvdb]

I only have the Number Maximum boiler temperature. What do you see there?

[Mariusthvdb]

I am a bit reluctant to reset to factory because re-setting all is a bit of a hassle, given the specific settings I have, not being very default...

there is not a single clue my device is dying, besides the now not appearing entities in HA. In the app, and on the wall, all seems fine. Ive even restarted and updated (wasnt necessary but still) the firmware, and all went without a hitch.

Wouldn't you think some error would have arisen in the app/thermostat in the process when Smile would be on the verge of dying?

I could power-cycle the device completely? that would not erase the settings, but maybe rewrite them correctly (assuming the xml is incorrect)

for the record: I did power cycle, had it off power for a minute, and then powered on. No change. still only those 2 entities are created, but unavailable (as they are non existent in the app, that would be correct in fact ;-) )

[bouwew]

They do exist, the two settings under "Ketel temperaturen" are the two Numbers in HA Plugwise. I'm referring to the "Min. ketel temperatuur" and "Max. aanvoertemperatuur" settings. I think there will be more information about these when you click the "i"-icon.

Try changing both setpoints in the Plugwise App to a different number. This should restore the relevant xml-keys to the correct format. After performing the changes in the App, restart HA to see if the problem has disappeared.

[Mariusthvdb]

ok I did that, nothing happened. I seemed to recall we could set that max temp to higher than 60, but the select box wont show me more.

I removed the unavailable once more, hoping they would be re-writtten: again, no. They are completely gone now, not even show as unavailable.

the error persists.

Powered down once more, waited over a minute, repowered. Nothing..

I also checked the web interface, and oddly enough there is no selector on the 'max aanvoer'

even changing the values in that Min ketel temperatuur and restarting results in nothing.

so I now have this too....:

what happened between 2023.8 and .9 that broke the entities....? right: https://github.com/home-assistant/core/pull/98092

[bouwew]

No, that PR is not related, that should lead to number.opentherm_domestic_hot_water_setpoint not being available. Min. ketel temperatuur = number.opentherm_maximum_boiler_temperature_setpoint If you want to be sure, check the number in the xml-data on /core/appliances, the number 45 should show at the maximum_boiler_temperature key.

About what happened between..., it could be that we have changed how the backend updates dicts, and that before the previous values were never overwritten when there was no change in the value, and that now it does. And because of that the problem in the xml-data now shows.

Anyway, the root of the problem is on your Smile, as the picture with the disappeared arrow-down shows.

I would suggest you get in contact with the Plugwise Helpdesk, maybe they have some other ideas on how to fix the problem :)

[Mariusthvdb]

well I did, I sent them a message, and linked to this issue to, so Plugwise can read along.

So far, I dont understand what you say about

we have changed how the backend updates dicts, and that before the previous values were never overwritten when there was no change in the value, and that now it does. And because of that the problem in the xml-data now shows.

other than you actually say the error was there all along, but now it shows?

I did have the setpoint in the config, and it was functional though. So maybe the way you changed things isnt optimal/buggy

anyways, Ill report back when I hear from Plugwise.

[bouwew]

About "other than you actually say the error was there all along, but now it shows?" Yes that's what I mean.

About "maybe the way you changed things isnt optimal/buggy", I'll take a more in-depth look at this during the weekend.

[Mariusthvdb]

Thanks!

Your amazing support is highly appreciated.

[geijt]

I have the same issue and error. The number.opentherm_domestic_hot_water_setpoint is not avaiable.

Logger: homeassistant.components.number
Source: components/plugwise/number.py:107
Integration: Nummer (documentation, issues)
First occurred: 10:07:23 (2 occurrences)
Last logged: 10:07:23

Error adding entities for domain number with platform plugwise
Error while setting up plugwise platform for number
Traceback (most recent call last):
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity_platform.py", line 507, in async_add_entities
    await asyncio.gather(*tasks)
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity_platform.py", line 752, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity.py", line 1001, in add_to_platform_finish
    await self.async_added_to_hass()
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/components/plugwise/entity.py", line 81, in async_added_to_hass
    self._handle_coordinator_update()
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/update_coordinator.py", line 473, in _handle_coordinator_update
    self.async_write_ha_state()
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity.py", line 730, in async_write_ha_state
    self._async_write_ha_state()
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity.py", line 830, in _async_write_ha_state
    state, attr = self._async_generate_attributes()
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity.py", line 771, in _async_generate_attributes
    state = self._stringify_state(available)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/helpers/entity.py", line 736, in _stringify_state
    if (state := self.state) is None:
                 ^^^^^^^^^^
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/components/number/__init__.py", line 320, in state
    return self.value
           ^^^^^^^^^^
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/components/number/__init__.py", line 358, in value
    if (native_value := self.native_value) is None:
                        ^^^^^^^^^^^^^^^^^
  File "/srv/homeassistant/lib64/python3.11/site-packages/homeassistant/components/plugwise/number.py", line 107, in native_value
    return self.device[self.entity_description.key]["setpoint"]
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: 'setpoint'

The XML of my Adam also is missing the setpoint element and changing the values in the Plugwise app or restarting the devices doesn't make any difference. In the Plugwise app I have the 'DHW confort' switch and a 'Max. boiler temperature' but no 'Max temperature domestic hot water' (for which there is a description if I click the i button).

<thermostat_functionality id="fc9b922e14f44209b2c11678a49932ae">
    <updated_date/>
    <type>domestic_hot_water_setpoint</type>
    <lower_bound>35</lower_bound>
    <upper_bound>60</upper_bound>
    <resolution>0.01</resolution>
    <regulations/>
    <thermostat id="bd74ff97915248d6a8efd52248f3ce85"/>
</thermostat_functionality>

[bouwew]

@geijt Thanks for reporting this. Hopefully this is also noticed by Plugwise.

[geijt]

@geijt Thanks for reporting this. Hopefully this is also noticed by Plugwise.

No problem, let me know if you need more details

[bouwew]

@Mariusthvdb I have identified an issue in the plugwise-backend that would cause a certain entity disappearing to stay visible in HA Plugwise. Unfortunately this is NOT the case for Numbers and Selects. What you are reporting must have another cause. It could have to do with some changes in coordinator.py, with the typing of coordinator.data, from a Tuple to PlugwiseData.

[geijt]

@bouwew I don't know or it's helpful (or not related to it at all), but I've been snooping around in XML files of my Adam and found this in the /core/domain_objects:

<open_therm_boiler id="7725c07b6e8644fba8f07301e75c1126">
    <open_therm_gateway id="4ffa460c72de4a4bbf9256bb547fd2c8"/>
    <open_therm_version>2.01</open_therm_version>
    <is_modulating>true</is_modulating>
    <with_cooling>false</with_cooling>
    <with_domestic_hot_water>false</with_domestic_hot_water>
    <with_domestic_hot_water_storage>false</with_domestic_hot_water_storage>
    <with_master_low_off_and_pump_control>true</with_master_low_off_and_pump_control>
    <with_secondary_heating_circuit>false</with_secondary_heating_circuit>
    <smartgrid_control>smart_grid_off</smartgrid_control>
    <test_mode>off</test_mode>
</open_therm_boiler>

As you can see domestic hot water items are false. Is it maybe a possibility that the error occurs because my boiler doesn't have that feature?

Another unrelated question, in the /core/appliances XML of my Anna I also see items as temperature_offset, proximity_detection and illuminance for which it seems there is support (or traces in the code) in the python-plugwise project (as far as I understand Python). Why these are not exposed to my HA? There are also other more diagnostic items like burner_operation_time and open_therm_oem_fault_code that don't appear to have been exposed to HA, are there any plans to expose them into HA (maybe as a default disabled diagnostic item)?

[bouwew]

@geijt Nice find! Could indeed be that this key is the "key" :) I'll have a more detailed look later.

temperature_offset is coming to Core Plugwise (already implemented in the plugwise-beta custom_component) and illuminance is already supported. For others please issue a feature-request in https://github.com/plugwise/python-plugwise

[bouwew]

I'm looking in our userdata - adam_jip, I see the same false in open_therm_boiler for with_domestic_hot_water but there is a complete xml present: So I think something else is meant with this, like a built-in dhw-tank.

[Mariusthvdb]

in my case I have a single unit heater with a connected solar boiler. the comfort more is toggling the heater to extra-heat that solar boiler, not some built in small boiler.

also, and I am not sure here, could it be the heater itself is set to limit that max boiler temp (its a Remeha Quinta in my case) and not allowing the Anna to do anything with that.

Not that I changed anything on the heater...

it hasn't been doing anything for over 5 months almost now, so maybe changes that happened during those times have not been (over)written by the heater?

[Mariusthvdb]

well, fwiw updating to HA 2023.9.2 gives me my unavailable entity back (it had gone completely before). Still the same error in the log though, so no use:

I did give the gateway a restart after having changed the values inside the app for these entities. saw the integration lose connection and re-connect: no change.

[bouwew]

Just FYI, in 2023.9.2 Core Plugwise was updated to the latest backend v0.32.2, adding the Number temperature_offset. Also some changes to avoid that any removed entity (by Plugwise) stays available in HA in a "frozen" state. No specific changes related to the Number domestic_hot_water_setpoint.

Did you receive any response from Plugwise?

[Mariusthvdb]

yes, aware there was a bump, thats why I posted.

no, not a single response from Plugwise, they have a terrible customer service. not even a 'received' email. no temperature_offset in my settings, maybe that isn available on my Anna? I do have a calibration set on the temp, so if that is what the new entity should display, its not there.

[bouwew]

The temperature_offset corrects/offsets the (room) temperature reported by a thermostat. Some Anna's have this, some don't. All Lisa's and Tom's have this.

Which xml-key do you think is associated with this function in your system? The key should be present under <actuator_functionalities>.

[Mariusthvdb]

This is what we're talking about ?

If so, I'll check in the xml:

<actuator_functionalities>
<thermostat_functionality id="5b929a69bc704b68a0c9b4fe879cd944">
<updated_date>2023-09-13T09:50:24.676+02:00</updated_date>
<type>thermostat</type>
<lower_bound>4</lower_bound>
<upper_bound>30</upper_bound>
<resolution>0.1</resolution>
<setpoint>10.5</setpoint>
<regulations>
<ame_regulation id="26301b2863b744208f740687aba53785"/>
</regulations>
<thermostat id="c5cee432319d4e64a7029a3d834ba90b"/>
</thermostat_functionality>
<offset_functionality id="9cd6526b9e7b488e8c01c7955803f49f">
<temperature_offset id="1137c032c6ee4a22870d725c07093e02"/>
<updated_date>2023-09-13T09:50:24.762+02:00</updated_date>
<type>temperature_offset</type>
<offset>-0.7</offset>
</offset_functionality>
<toggle_functionality id="d77d8517efe74784a4288fb277c53b07">
<proximity_sensor_toggle id="9760c9388dab4f55a15cfc211417d256"/>
<updated_date>2023-09-13T09:50:24.806+02:00</updated_date>
<type>proximity_sensor_state</type>
<state>on</state>
</toggle_functionality>
</actuator_functionalities>

sorry for the missing indents, I just c&p from that xml and it loses formatting

[bouwew]

Yes, it's there:

<type>temperature_offset</type>
<offset>-0.7</offset>

So it should be shown for your Anna. Is the temperature_offset-dict present in the diagnostics-data?

[Mariusthvdb]

config_entry-plugwise-474a410dc55f45ad8124f87f62baa412.json.txt

I do believe so yes:

        "temperature_offset": {
          "lower_bound": -2.0,
          "resolution": 0.1,
          "upper_bound": 2.0,
          "setpoint": -0.7
        }

however:

however, this is not the original topic, and getting off topic? or would you accept this here btw is that firmware date current??

[bouwew]

Yeah, we're drifting a little off-topic :) I don't mind too much.

Not sure what's wrong, a browser-cache-issue? You could remove the Plugwise integration, restart HA and add it again, then it should show up. Normally a HA restart should fix this but I always end up doing the above :)

[Mariusthvdb]

just getting back to you that deleting integration, restart and new re-install didnt change anything, nor did it bring the new offset setpoint entity.

I did have to rename all of my object_ids..... had them in English, and now all was Dutch.... aargh

[bouwew]

@Mariusthvdb Ok, back to the original problem. Did the recent Plugwise App update have any impact on this issues? Meaning, does the Plugwise App still show the same as before? Or has the "Max. aanvoertemperatuur" option disappeared?

[Mariusthvdb]

Not aware of any app update tbh but this has not changed

[bouwew]

Yes, there was an update for Android on Friday.

Ok, I see that now the selection-arrow-down is back. Does this mean you can now change the setpoint?

[Mariusthvdb]

right, I use iOS...

well I can open that fold and select lower numbers than 60 yes. In the app. Not in the web interface:

also, if I change that to 59 in the app, nothing happens in the web interface and remains set to 60

and still no reply from Plugwise. their customer service is beyond bad..

[bouwew]

@Mariusthvdb did you in the recent past change your heating-system, did you recently connect your Anna to a new/different heating-device?

[Mariusthvdb]

No it's been like this for a few years now

[bouwew]

Ok thanks. Anyway, we're working on a solution...