Plugwise core and custom_component

[herwinjs (Herwin)]

First 30 minutes looks stable now!! Keep it running for few more hours als let you know.

[herwinjs (Herwin)]

@brefra this more like it!!

Thanx for the effort!

[bouwew (Bouwe)]

@herwinjs And what is the status of the memory after a few days of testing? Still OK?

[herwinjs (Herwin)]

@bouwew @brefra Here is the update:
I think still a little memory leak, but much more usable.

[jwestra]

Is anyone running this component stable with 20+ plugs and using the usb stick?
Looking at the existing issues it appears multiple people are having similar problems. I my case I never get more than 10 plugs detected.

[CoMPaTech (Tom)]

Announcement with breaking-changes for USB users

TLDR;

• If you are using a USB Stick *) do not update to the latest version of the custom_component (see bottom of post for breaking change note if you do). Remain on v0.34.10 or switch to the new custom_component.

• If you are using Plugwise available within Home Assistant core, nothing really changes for you

• If you are using a Smile (P1/Anna/Adam) or Stretch, nothing (really) changes for you

_{*) Using it directly, i.e. plugged in to your Home Assistant device. This does not apply to the Zigbee USB device attached to your Adam or Stretch}

In short:

Using the USB stick directly in your Home Assistant device? You have two options:

• Remain on plugwise-beta v0.34.10
• Install plugwise_usb-beta v0.40.1 (or above) using github.com/plugwise/plugwise_usb-beta in HACS as a repository.

Using a Smile either in Core or through the custom_component? Just update when we release new versions. There are no (breaking) changes and there is no need to install the new component.

Background

We have recently worked on our (custom_component) code an started refactoring some of the code. As time goes by code from HA Core goes into the custom_component and tested new functionality flows back to HA Core.

We cleaned up thoroughly in preparation to make a new attempt at upstreaming the USB code and asking the Core team how we would best approach this. Back in 2020 there was no proper way to have multiple ‘different products’ from a single vendor, hence the request to combine forces and proved Smile and Stick support from a single integration. Currently there is no requirement for this anymore and having separate integrations makes a lot of sense (e.g. there is not much ‘shared code’ between the components from our side).

We have recently worked on ‘splitting’ the code again, after our merge back in the days. This provides a cleaner visibility of things we have in beta and/or are not ready (or eligible) for upstreaming + it paves the way for finally supporting USB Stick directly from HA Core. (Though that is still a work in progress and will take time)

Breaking changes (USB users only)

Versions of the beta custom_component above v0.34.10 are not supporting USB anymore. Likewise for the backend module python-plugwise v0.27.10. Again, if you have a Smile based product (P1, Adam, Anna, Stretch), there is nothing changing for you an no breaking changes.

If you are using plugwise and use USB, please refrain from updating and stick to v0.34.10 or better yet; add https://github.com/plugwise/plugwise_usb-beta as an additional repository in HACS. (See the readme on te repository for more information).

There is no new functionality - but having a new component does unfortunately mean that your existing sensors (and data) will not ‘transfer’ to the new component.

If you updated to v0.40 or above and lost connectivity, just use the ‘three dots’ in the top right in HACS (i.e. HACS → Integrations → Plugwise-beta then click the three dots) and choose ‘Download again’ and select v0.34.10 and after the mandatory restart you should have USB working again.

Testers (of the USB functionality)

Again thanks for all your time, testing and creating issues and feature requests. Issues that we not closed have been moved to the new repository. To prevent backscatter in e-mails we decided not to move closed issues to the new repository.

[Michel]

FYI the link to https://gitHub.com/plugwise/plugwise_usb-beta` is incorrect, it has an extra backtick at the end. Should be https://github.com/plugwise/plugwise_usb-beta

[CoMPaTech (Tom)]

Tnx, I actually forgot to close the backtick on the version, reworded and fixed accordingly

[Getslow]

Hi all,

I’ve got a question and I’m not sure if it is a bug in the integration:

Previously I had a setup with Adam/Anna and Lisa’s/Tom’s. Now I’m switching to a setup where I replace the Anna with a Lisa (due to a renovation in our house).
So I use Adam without an Anna.

I’ve removed the Anna from the Plugwise app and setup the integration from scratch, but the integration keeps adding an Anna entity that seems available and also provides (static) sensory data:

(other Lisa’s still to be added)

(data for Office Tom is empty due to the addition of the Lisa recently, still need to update the graph)

Anyone familiar with this?

[bouwew (Bouwe)]

Delete the Plugwise integration in HA, restart HA, and add the Plugwise integration again.
That should completely “refresh” the scope of the Plugwise integration in HA.

[Getslow]

I just followed your steps (didn’t do a restart between deleting and adding the integration before), but without success:

Is there any debug info that I can provide that might be helpful?

[bouwew (Bouwe)]

Ok thanks for trying, I guess there is something going on that us Plugwise code-owners don’t know yet.
Are you using Plugwise-beta (via HACS) or the HA Plugwise integration?

[Getslow]

I used the Beta previously and switched to the internal integration. I will try some more when I get home (see if it happens on both integrations etc) and will raise an issue with all additional (debug) info. Do you have a preference on where to raise the issue (core/beta)?

[bouwew (Bouwe)]

Yes, that was the intent of my question. Best to raise an Issue in the HA Core github then.
So please create an Issue there and then we’ll continue our communication there.

[Getslow]

Small update; the values I saw in my graphs that were supposed to come from Anna (climate.anna), were the values that the Plugwise app showed for the ‘living room’ zone where it was located previously. The living room zone only had one Tom in it left (which had different measurements in climate.tom_living_room ).

I’ve removed the Tom from the living room zone, removed the living room zone as a whole and created a new living room zone and placed the Tom back into this new zone. It now works → I therefore think it is an issue on the Plugwise side rather than an issue on the integration side.

I can’t reproduce the issue anymore now, but now you know how it can be solved

[bouwew (Bouwe)]

Nice to read that you have solved it

Yes, I suspected the problem to be on the Plugwise side, I would have asked you to take the raw xml-data from your Adam, so we would know how to distinguish a connected Anna from a disconnected Anna.
But your action resulted in some extra “cleaning” of the raw xml-data, solving your problem in the process , good to know!

[bouwew (Bouwe)]

RELEASE Plugwise-beta v0.43.0

In this release the behavior for the Plugwise Adam has changed: a hvac_mode OFF has been added.
This mode means that the heating or cooling function has been switched off, the domestic-hot-water-heating, when present, is still working.
On the HA climate-card there is an additional Off-icon shown, next to the Heating-/Cooling icon(s) and optionally the Schedule icon.
Now you can click on these icons to change the mode of your heating system.

Please test this new feature and provide us with your feedback, thanks!

For Google Home users, the climate control will be improved: you will be able to click on the Power-icon in the thermostat-page and then you will be able to switch between modes. Please note, you can select auto-mode (= schedule mode) but there is nothing to change on that view.

[Mariusthvdb (Marius)]

not sure if posted before (did check up last posts, none found):

when using a thermostat card in dashboard, there seems so be miscommunication between HA and the Plugwise thermostat , as reflected in the app.

the + and - buttons work ok, and setting that is sent to the device and also seen in the app shortly after that.

the circle slider however is lagged terribly, and seems to go back to where it originally was before picking it up. after some time it then jumps to the setting one had tried to set before, but very inaccurately, because the initial slide was so unsuccessful

even worse is the usecase when controlling from the Plugwise app: setting a preset simply is not sent to the HA integration or card, meaning we can set to away in the app, but HA does nothing. even remains heating if it already was, so probably even overriding the actual Plugwise app itself…?

the + and - buttons in the app are correctly pulled in into the HA integration.

All in all, rather unreliably currently, using HA 2023.11.3 4.4.1 versie in the App

to be sure the integration listens to App changes I have set

but as described above that doesnt work for the home/away/holiday etc presets

[bouwew (Bouwe)]

@Mariusthvdb This is all caused on one hand by the Plugwise device sometimes responding slowly and on the other by HA not waiting long enough due to this setting in coordinator.py: cooldown=1.5.
When HA “misses” an update due to this, it takes another 60 seconds (default update interval time) before a change (e.g. made in the Plugwise App) becomes visible (in HA).

In plugwise-beta, I have the cooldown time set to 5 seconds and sometimes I still have to wait until a next refresh (30 secs, that is my update-interval setting) before a change becomes visible.

I myself don’t use the HA Climate card very much, I prefer the Simple Thermostat card set up specifically for my system. On that card I can see the result of all the changes I make in the Plugwise app, including the preset-changes, after waiting for max 30 seconds. But most of the time within 5 seconds.

[Mariusthvdb (Marius)]

yes, I can confirm it is not only the Plugwise having trouble. I have 3 Mill heaters where the thermostat card doesnt behave properly on either…
the new and shiny more-info is even worse somehow.

using a

    type: entities
    entities:
      - climate.[[id]]

card would seem to be the most ‘raw’ or ‘core’ possible, and even that changes only after a long wait on those presets.
As I noticed some odd behavior (heater starting t heat while I set preset to away) I wonder which control is the Master at what time. Given there is the big lag, this can be very important. Asking because when the heater started heating the Plugwise app still remained in away mode, and didnt get overridden by the HA interface…

Ill give the simple thermostat card another go, but given the fact it uses the same data as the core climate entity above, I can not see why that would make any difference?

Heaters need to be 100% reliably controlled, so finding the best interface here is very important…

would be a letdown if that meant to do away with the HA integration, and solely use the App