Regulier is not a preset mode, but a schema…
I do understand that bit of code, but it simply isn’t correct.
Especially since it really should show Home, which is the currently selected preset mode.
Earlier you were with me, now not anymore? What happened?
well, tbh, nothing really. I am still with you 
also still with my easier findings. this little quote of mine was specifically meant for
my issue with the preset_modes still stands. I truly find these should be separated. Have a dedicated current preset mode sensor, which selects 1 of the 5 available presets. Next to that, have a sensor for Temporary, Regulier (+ possible extra user schedules) or Manual.
like this:
def preset_mode(self):
"""Return the selected Preset mode.
and
def active_schedule(self):
"""Return the Active schedule.
Or return Temporary in case of a manual change in the set-temperature with a weekschedule active.
Or return Manual in case of a manual change and no weekschedule active.
maybe even split the last 2, since I would think it very illustrative to see the active schedule in all circumstances.
that would be
def active_schedule(self):
"""Return the Active schedule.
and
def manual_setting(self):
Or return Temporary in case of a manual change in the set-temperature with a weekschedule active.
Or return Manual in case of a manual change and no weekschedule active.
If only that were possible. But for climate devices we have to adhere to the format defined by de HA Leaders.
Between the lines I read that you are looking for something looking nice on the HA frontend.
Why not use the Simple Thermostat Card, this is mine:
This has everything you may want, you can even change the texts on the buttons.
And it works really well with the present state of the anna-ha-code.
1 Like
which of my suggestions isn’t possible? Can’t imagine the presets_modes need to be be mixed with the schedules by the core HA team. They’re different beasts altogether?
why yes, I do think that is what it should look like…
care to share the code for that? seems a straight c&p is in order. .
(only change might be mdi:hotel…)
Do you use HACS? You can find it in the list.
When not, look here: Lovelace: Simple thermostat card
The link to the code is in the first post.
And my code in ui-lovelace.yaml:
- type: custom:simple-thermostat
entity: climate.living_room
name: Woonkamer
icon:
idle: mdi:radiator-disabled
heating: mdi:radiator
sensors:
- attribute: preset_mode
name: Mode
- entity: sensor.temperature_xyz
- entity: sensor.humidity_xyz
- entity: sensor.pressure_xyz
control:
hvac:
"heat":
name: Verwarmen
"auto":
name: Auto
preset:
"home":
name: Thuis
icon: mdi:home-circle
"asleep":
name: Nacht
icon: mdi:sleep
"away":
name: Afwezig
icon: mdi:clock-alert-outline
"vacation":
name: Vakantie
icon: mdi:airplane-takeoff
"no_frost":
name: Anti-Vorst
icon: mdi:snowflake-alert
On your first point: if you want to see certain changes, please create an issue in the anna-ha repository:
nice indeed, though an immediate eyecatcher is the Regulier in the preset mode field… In this card it I even less necessary, because it can show the Schema separately, which I very nice. All the more reason to separate the preset modes and schedule/schema
To get what you want, the quickest way is to install the Plugwise Anna as a custom_component and then modify the code to this:
def preset_mode(self):
"""Return the active preset."""
if self._presets:
return self._preset_mode
return None
yes thank you, I feel that should be it. Of course accompanied by the other extra sensors, because we shouldn’t leave them out completely.
I am in no hurry, and would rather stick to the ‘official’ component. Hope you might see the logic in this, and are prepared to consider this a FR/PR?
When we go for the simple solution as shown above, there will be no other climate_sensors of _states available. Just to clarify: all the attributes that are there now, will still be there, I’m not allowed to add more, and the preset_mode attribute will only show the active preset.
This simple solution is the way it is supposed to be according to the HA Leaders.
If you want anything more than that, the only way to do it is to abuse one more of the existing attributes for this, like I am doing now in the present code.
Haha sounds like a totalitarian state… the Great Angry Leader was a nickname we used sometime in the past for a certain politician, who shall not be named… sweet memories
you’re not allowed to add more? Why is that, I truly wonder. I’ve found the dev’s to be meticulous in state and attribute clarity, which is exactly my gripe with this solution: it mixes several attributes/modes/schemas into 1 single sensor.
Actually, they are. And they should be, it is the only way to keep HA stable.
You can deviate in a custom_component but not when you want your component to be accepted into HA.
Just leaving a note here … @bouwew and me are working on a (rather large) rewrite behind the scenes, both in our own and a (to-be) new set of repositories. We are trying to get everything both asynchronous to be better in line with HA-standards as well as limit the amount of traffic between HA and the devices.
I sure hope we can share the new things soon, but as things are now there is a lot of small and larger issues to squash. It also means moving our development and testing to a next level so we (again) prepared some new repositories on github. Just so we can have (you as) willing testers to test code before we push it upstream to HA-core.
Besides the great work from @bouwew to support adam and align adam/anna calls the updated version will also have the separate sensor entities that HA wanted, thus opening the way to monitor everything that is available from your thermostats 
This means the configuration/setup also changed in configuration.yaml but for those that fancy multiple (or a combination of) Annas & Adams you should be good - if there is someone reading that has multiple Anna’s in their (set of) homes, please let us know, we’d love to have you test-drive soon!
Thanks for your patience! It might also clarify why a PR against HA-core will take some time as it probably (once we are ready to PR it) will take some time (it’s not going to be ‘small commits’ as desired by the core team). Having some of you ready to help us test will definitely help.
To add to CoMPaTech’s note, we are planning to support the two Anna’s (legacy and present), the Adam, and the Smiles P1 v2 and v3 with one HA-component. The idea is to have a Plugwise-platform plugwise: under you place the IP-adresses of you various types of Smiles, and then the component detects the types present and automatically creates the relevant entities in HA.
would any of you know how to add the Anna climate (climate.kantoor in this case) entity to cloud: and have google assistant respond to: “Hey Google, turn on Kantoor to 20 degrees Celsius”
not sure if this available?: https://www.nabucasa.com/config/google_assistant/#climate-operation-modes
First I think you will need to expose the climate domain to google:
google_assistant:
project_id: some_id
service_account: !include SERVICE_ACCOUNT.JSON
report_state: true
exposed_domains:
- script
- switch
- light
- group
- media_player
- climate
Update: yes this works, I now see my thermostat in Google Home and can say: “Ok Google, set the temperature in the living room to 20 degrees”. And next the set temp changes to 20 on my Anna
Update: we have received the requested data, thanks!
Hi, we need help from someone with a legacy Anna (firmware 1.8).
1 Like
yes, thanks! I’ve added my climate entity to cloud: (using Nabucasa) and it works just perfectly!
kinda cool indeed. Especially since the Plugwise itself isn’t supporting Google Home (as far as I can see)
Just to give everyone here a little heads-up and an update on what’s happening. @bouwew and me have been able to get things going on a platform component. It’s almost ready to have the community pick up on this and get cracking so we know if it works as intended. Meanwhile we have a couple of people testing various hardware and setups so we can pick up early feedback.
We are hoping we can upstream this soon (where soon is a variable time of measurement, since we overhauled the original ‘anna-ha’ (HA component) and ‘haanna’ (python module) completely.
The new custom_component (indeed, we’re starting from scratch) will be also availble through HACS as a manual added repository. Once installed you no longer have (or can) configure it through the configuration.yaml file, you just add it as an integration!
Once release into the wild it should support the below hardware.
- (legacy) Anna and recent Anna’s
- Adam (v2.5 and up)
- (legacyP1v2 and P1v3
We haven’t tested adding in other languages than English and Dutch Dutch screenshots below
Adding the integration is as simple entering your IP-address and Smile-ID (knocks on wood). Have multiple devices? E.g. an Adam climate system and a Smile P1 for energy monitoring, add them one after another
Ending up with a nice couple of entities for further use in your Lovelace frontend
Again after some testing by some people we know have legacy hardware and we’re asked we’ll cross our fingers and enlighten all of you with the url to the beta custom_component.
Benefits of this new component, for those who like details, amongst others it:
- Works asynchronously (https://developers.home-assistant.io/docs/asyncio_101/)
- Has support for Smile P1 (gas & energy meters)
- Has more sensors available, our current approach needed more than just ‘climate’
- Has support for Adam devices including the (new!) plugs!
- Easy to configure (and remove) through integrations
- Aimed to be less data-hungry in terms of network connectivity to your Smile (partially because of the async, partially because of improvements to our code)
- Other things we already forgot we added/wrote
Depending on the Plugwise Smile devices/categories you have available you’ll get ‘climate’, ‘water_heater’, ‘sensor’ and ‘switch’ available as entities within your Home Assistant setup.
1 Like