Please see the docs: https://www.home-assistant.io/integrations/plugwise/
And yes, I would assume that the Anna must be connected to the Smile to show up in HA, once you have updated configuration.yaml.
Also, FYI, there are some bugs, see https://github.com/laetificat/haanna/pull/27
If you want, you can create a custom_component using the updated code.
Yes, thanks, Iāve seen and configured as per the documentation. No issues there.
It would be nicer though if the component would show a notice, just like the app does, if no heater has been detected yet.
That would be more useful to the end user than the current situation of not initializing the component and showing the yellow line as a consequence.
This is what the app shows:
The ānoticeā is most likely there, in Developer Tools --> Logs.
But the message there might be a very technical one.
Also, in my opinion, that is not what Home Assistant is about.
I personally have no need for such a notice. More so, I would not know how to create such functionality.
But, itās open-source software, feel free to add to the code creating this functionality.
can confirm the moment I snapped the thermostat on the baseplate, Anna became visible in the frontend beautifully (even without a connection to the heater yet)
Will watch closely for the development of the updated code, and thanks for that!
very nice indeed, and hassle free, as I had hoped forā¦ 
spoke too soon I fearā¦
today updated the system to HA 101.2 and about the only thing not working is the Anna Plugwise thermostat, showing this in the log:
2019-11-25 17:50:23 ERROR (MainThread) [homeassistant.components.climate] plugwise: Error on device update!
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 292, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 450, in async_device_update
await self.hass.async_add_executor_job(self.update)
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/usr/src/homeassistant/homeassistant/components/plugwise/climate.py", line 281, in update
self._domain_objects
File "/usr/local/lib/python3.7/site-packages/haanna/haanna.py", line 373, in get_schedule_temperature
return float(measurement)
TypeError: float() argument must be a string or a number, not 'NoneType'
I can see my thermostat in the web interface via a browser, and the Plugwise app just fine.
Does the HA update contain a bug?
edit
didnt realize this was the bug you described above, and discussed on the Github. Can confirm creating a schedule brought back the Thermostat.
Havent tried your temporary fix yet, guess no need for that, and will wait for this to be in the next HA update.
thanks for your effort, beautiful component.
HI @bouwew
would it be correct that the target and current temp are displayed differently (theyāre switched ) in the Anna app and the HA thermostat card?
In the App, the central larger figure is for the target temp, and below the line is the current temp (next to the flame icon).
On the HA thermostat card, the big number is the Current temp, while the target temp is below in smaller numbersā¦
A bit confusing this isā¦
Secondly, let me ask if the flame in the HA interface ought to change color or not depending on the state heating or idle. I can see the flame when Idle and heating but always grayed. While in the Plugwise interface, there is no flame when not heating and if heating is activated the flame is dark showing it is active.
Thanks for having a look and see if this is all correct.
I get the confusion you are pointing at from the app perspective 
Never looked at it that way, but itās the way all HA-climate works. Pascal (pvizeli) put in a lot of effort during the summer to standardize all the things that are climate. If you really want it different there should be some (custom)card available via HACS or likewise that might be more representing. Personally I only use the plugwise app to set schedules or do development/testing work when Bouwe or myself are changing things - otherwise I use HA which looks like:
As for the coloring, if I recall correctly the ring changes behaviour pending on āabove/belowā set and also colors when heating/cooling.The āflame vs thermostat (vs cooling, we have one user who has thatā is about the states climate controller is in. So the left (calendar) icon lit like on your screenshots means that itās on auto-mode (scheduled). The flame is about manual control (heating-only), the flake would be on colling mode). Does that make it (a little) clearer?
Couple of screenshots of what ādevā looks like for me:
Inactief/Normaal meaning, not heating(/cooling) and on schedule āNormaalā (which is active as per the calendar icon)
āInactief/Temporaryā meaning, not heating, on schedule -> but currently manual override (to 21.5 instead of 20)
āVerwarmen/Temporaryā meaning, heating, still on schedule but manual override (to 21.5)
a little
thanks, and yes, I have the HA interface too:
though i cant seem to find the place in the HA interface, being the thermostat card or the entities card, where to set the schedule. I now clicked the calendar icon a few times, and it finally snapped to āRegulierā, which I have defined in the Anna Web interface. Itās not in the HA interface is it?
update
on the above:
think there is a serious issue/bug. When selecting a temp change in the app/web interface, this is reflected in the HA integrations some 10 seconds later, or even a bit more. Though this is annoying, it finally changes.
What is really buggy, is when after that, one selects one of the preset scenes again, so to turn on the regular schedule, this isnt updated in the HA interface. It simply remains in the temporary state, which is then truly out of sync.
One must then first click the flame, as to set to manual, and then back to the calendar. Awkwardly enough that brings up the sleep scene, and a second click turns on the regular sceneā¦
all in all not very robust I must conclude unfortunately. Please let me know if I can assist in debugging this
Iām back online now
On the numbers displayed on the Anna, yes, Plugwise has opted to be different from the rest of the world: they show the setpoint in a larger font. Every one else, inclusing HA, shows the actual (measured) temperature in a larger font. I already complained to Plugwise about thisā¦
If I remember correctly, the flame icon will turn orange when the schematic is turned off. The color of the flame icon is not connected to the heating-status. Again, if I remember correctly.
You seem to run into the same issues that I didnāt like but have come to accept, or have tried to change myself
The function of changing the schematic is not available in HA. Weāve talked about but didnāt find time / have the required knowledge to add this.
About the delay, this is inherent to how HA works. You can lower the scan_interval value in configuration.yaml if you want a faster response, but then youāll load your HA server more.
About not showing the selected preset state, Iāve noticed this too, sometimes it works, sometimes not. I havenāt found out why this happens. Please create an issue on the laetificat-github.
thanks. about style, I can accept the differences 
but this:
is about controlling the thermostat. I fear, that when the 2 interfaces (HA and the Anna app itself) are not in Sync, different commands are sent to the Thermostat. I had the HA interface set to manual override, while the Ana app was in auto mode.
If anything, the HA interface should always follow the true state of the thermostat.
That no issue, we can edit the schemes in the app, or the web interface just fine. Most likely a set and forget thing.
We should however be able to easily switch between existing schedules?
will do Done! HA interface not not showing the selected preset state Ā· Issue #29 Ā· laetificat/haanna Ā· GitHub
Iāve learned to look at whatās on the display of the Anna, that is the ātruthā. When there is something else on the App or on HA, then thereās a bug.
Changing or switching between, thatās the same for me 
. Maybe it is easy to realize, I donāt know, Iāve worked mainly on adding more attribute values(some were not accepted by the HA reviewers) and improving the status shown on the climate-card.
Also, it will take a while before Iām back to coding. My HA system is offline, I first need to install a wired network in my new house, there are no dedicated pipes available for thisā¦
update posted on the issue tracker, repeat it here for reference:
maybe it is a bug in the Anna appā¦ selecting a preset after a manual override on the app,doesnt show on the Anna thermostat itself either. One needs to click 2 or 3 times before it is displayed. To be more precise, one needs to click the snowflakeā¦
Filed a bug for this at Plugwise, the app seems rather buggy (changed name isnt displayed, several other setting in the deeper config arenāt sticky etc etc)
almost feel I should return the thing and buy a Honeywell after all. Especially since we have to open the Anna to the producer for several settings when Awayā¦
seems only touching the top of the thermostat works as is supposed to?
please let me know if you see this too.
also, I now notice thereās auto and manual, and there are scenes.
I take it Auto meant the schedule, which can incorporate the scenes.
So, if on auto, what happens when one clicks a scene. Would that mean Manual override? It is some setting between auto and manualā¦
not very self-explanatory tbh
whats the official plugwise anna support topic, my legacy anna stopped working and thats it. I added legacy_anna: true but still nothing.
its the update from couple weeks back that screwed it up for me.
EDIT:
Please can someone tell me why home assistant is not loading the plugwise component?
I switched over to the latest plugwise_dev by manually getting the files from github and placing it in custom_components and it works fine.!
edit edit:
manually installing the latest official version also seems to be working.
It has something to do with HACS that I used before to run plugwise I think.
Ok folks, Iām back, the move has been completed and my HA-system is finally up and running.
I do plan to reinstall HA so that will take some time too.
Now, first some celebrations and then during the coming days I will try to get back to solving all the issues that have popped up, among which is a firmware update to 3.1.10ā¦
Happy New Year!!
@Mariusthvdb
Yes, Auto means that the schedule is active.
When you select a scene/preset, this one stays active until the next change in the schedule happens.
Thatās why āTemporaryā is shown on the Climate-Card when this situation is active.
And, yes, I noticed too that sometimes a preset is not shown on the Climate-Card and on the Anna-screen and needs to be pressed a 2nd time to become active. This is probably a bug in the Plugwise custom_component. Itās on my todo-list, with low priority.
cool. take your time
would it be possible to have the little watertap icon displayed in the HA card also? It shows when the heater is in hot water mode vs heating mode. Would make it very instructive to see in Ha also, knowing why the heater symbol isnāt on while the temp difference would suggest otherwiseā¦
btw: Gelukkig nieuwjaar!
Again, you must be my twin
I had the same ideas.
Turns out adding the tap-icon requires a feature request and then there must be enough upvotes to get it in as an update to the Climate-Card.
Also, I added a dhw-indication message but it was not accepted by the moderators. The plan is to do a full overhaul of the code, turn the Plugwise custom_component into a climate- plus sensor- plus water-heater-part, then the dhw-active message will be displayed as an action. And several of the attribute-values will become sensors.
have you started the FR already, Ill +1 immediately
No. The Climate-card will most likely not be updated as there are not many other custom_components that show the state of water-heating.
I personally use https://github.com/nervetattoo/simple-thermostat to show the status of the Anna in HA.
I think this one will be much easier to get the tap-icon in, somewhere in the future.