Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plugwise Lisa thermostat bad attributes #67687

Closed
sophof opened this issue Mar 5, 2022 · 8 comments
Closed

Plugwise Lisa thermostat bad attributes #67687

sophof opened this issue Mar 5, 2022 · 8 comments

Comments

@sophof
Copy link
Contributor

sophof commented Mar 5, 2022

The problem

Summary

Lisa climate entity attributes for min_temp too low (0) and max_temp too high (99.9) and can not be changed. step is 0.1, before was 0.5. Setpoint reverts to original setpoint after changing and will only update after a minute.

Longer explanation

I've only started using a plugwise Adam + Lisa for a little over a week. Since the climate card was using the way I liked it, I didn't check exactly what it was before the change, but I do know it was easy to set the temperature, the step change was reasonable and half a degree was a significant enough change that it was easily done by hand in the interface. Right now it is essentially impossible to accurately change the temperature due to the current settings, it requires pixel perfect control, which is not possible on a touch screen.

In addition, after changing the setpoint, the entity reverts back to the old setpoint. Only after a minute or so, I assume after polling the device after it received the new setpoint command, will it update to the new setpoint. This is very confusing, especially for other users, since they think it is not working. It was also working fine before the update.

All in all, this feels like a regression. I saw several changes in the changelog, but couldn't find anything that indicates this was intentional.

What version of Home Assistant Core has the issue?

core-2022.3.0

What was the last working version of Home Assistant Core?

core-2022.2.7

What type of installation are you running?

Home Assistant Container

Integration causing the issue

Plugwise

Link to integration documentation on our website

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

Diagnostics information

config_entry-plugwise-76bc6a4cf4aa2bf80d178188b174ef4c.json.txt

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

@probot-home-assistant
Copy link

plugwise documentation
plugwise source
(message by IssueLinks)

@probot-home-assistant
Copy link

Hey there @CoMPaTech, @bouwew, @brefra, @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!
(message by CodeOwnersMention)

@CoMPaTech
Copy link
Contributor

Hi @sophof - we'll definitely look into this - as an explanation (not as an excuse) we used to have the lower and upper limits hardcoded but decided to use the values the Plugwise devices themselves indicate in the API/xml accordingly to be more 'transparent'. I've noticed the 0.5 => 0.1 resolution change myself as well.

As for the resolution change, @frenck is that something that warrants an ConfigFlowOption or also something that should be triggered by an automation?

@sophof Just to break it down, and please correct me if making the wrong assumptions: in order of prio

  • Lisa not sticking to set temperature: recalling something about frontend debouncing and waiting for the next interval, but the other's might be able to chip in/clarify further - to be sure, you do see the change on the Lisa and/or in the app, right?
  • Resolution change: intentional, but we might make it configurable
  • Min/max values: intentional, something the devices indicate themselves (again, might be made adjustable)

@sophof
Copy link
Contributor Author

sophof commented Mar 5, 2022

Yeah, I concur with what you say, including the order of prio. And don't worry, I wasn't blaming anyone, I was already expecting this to be an unintended sideffect. I just hope the debounce is easy to solve, that sounds potentially problematic.

My preference would also be to make it user configurable, with more sensible defaults of course. I don't think Plugwise allows for it at least and I assume there will always be people for whom 'sensible' defaults will not work (for instance if they also want to use it for cooling or something). And in my case I expect I want the range to be quite narrow.

@bouwew
Copy link
Contributor

bouwew commented Mar 5, 2022

When I change cooldown to 3.0 in coordinator.py the setpoint-value shown on the climate-card keeps showing the new set value.

@frenck is this something we could implement?

@ScepticOnion
Copy link

Hi, I'd like to pitch in on the prio order. Interesting is that the rooms where the plugwise Tom is used still have the old behaviour, only the rooms with the Lisa have this new temp range. In our house we see that this old temp issue is not occuring that often, mostly depending on the busyness of the Adam I suppose. Therefore I'd like the min/max values configurable a priority, as it can prevent my kids from blasting the system to 100% open (with current price levels...)

Been using Plugwise for 5 months or so now. Where does it need to be configured if we would make it configurable?

@bouwew
Copy link
Contributor

bouwew commented Mar 8, 2022

The Tom has a lower_bound of 7 and an upper_bound of 30, very different from the Lisa (0, 99.9).

Do you know the Simple Thermostat Card? https://github.com/nervetattoo/simple-thermostat
I have been using it for ages, much more convenient than the Core climate card. That one has it's own resolution setting, I did not notice the change in resolution at first because this card hid it for me.
I'm happy to share my configuration of this card.

image

@sophof
Copy link
Contributor Author

sophof commented Mar 8, 2022

You know, you might be correct that I/we are confusing interface and device properties. Although in that case I would still suggest that the standard climate card needs to be configurable as well in this respect (and use the reported min, max and resolution as defaults).

I know even less about GUI programming however, so with the free time I have I can't see myself creating a PR for that.

And of course the debounce issue is still there.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants