that would require me to load a Custom component? I use Hassio…
You can edit the file in the Docker, if you know how?
If not, then yes, use the custom_component, or wait until HA has updated to 0.14.2.
I will try to create the pull-request for this during the weekend.
installed as CC on 106b1:
2020-02-22 10:03:45 ERROR (MainThread) [homeassistant.components.climate] plugwise_dev: Error on device update!
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 312, in _async_add_entity
await entity.async_device_update(warning=False)
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 476, 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 "/config/custom_components/plugwise_dev/climate.py", line 276, in update
self._domain_objects
File "/usr/local/lib/python3.7/site-packages/haanna/haanna.py", line 165, in get_last_active_schema_name
last_schema_active = self.get_last_active_name(root, rule_id)
File "/usr/local/lib/python3.7/site-packages/haanna/haanna.py", line 552, in get_last_active_name
schema_time = datetime.datetime.strptime(corrected, date_format)
File "/usr/local/lib/python3.7/_strptime.py", line 577, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
File "/usr/local/lib/python3.7/_strptime.py", line 359, in _strptime
(data_string, format))
ValueError: time data '2020-02-20T19:16:34+0100' does not match format '%Y-%m-%dT%H:%M:%S.%f%z'
The required change is not in HA yet, so also not in the beta.
maybe confused here:
my first post was using the core integration, on Ha105.5
you then asked me to install the Hanna 0.14.2 in manifest, which I did installing the CC , on another HA instance (106.b1).
They both error out. So, 0.14.2 isn’t the solution for this issue as far as I can test now.
Does anyone see the climate with the latest Plugwise update at all?
Remind me, did you have a legacy Anna? Or not.
And do you have a weekschedule, maybe not active, or none?
new Anna, and a week schedule yes. It worked perfectly before without any further alteration
Ok, thanks.
You’re right, I am now looking in detail at the error, this is a new one, never seen this one before.
I will investigate.
1 Like
Haven’t updated to 106 as of the ‘trying to make climate+sensor’ things I’m working on still, but on 105 both dev and prod HA’s here don’t seem to have issues (on various versions of haanna).
Anna is on 3.1.11 btw
Also see the issue on 105.5 . But only appeared after updating the Plugwise firmware
Could it be useful to restart the Plugwise itself? Would have thought the update did that, but maybe a full restart could make a difference ?
The Anna is functioning correctly standalone and I do see internet connection ( can command the Anna remotely)
Looking more closely - this seems like the TZ python 3.6 vs 3.7 thing (again) - not able to dive into it till tonight I’m afraid (not behind a laptop this afternoon)
Line 548 of haanna is where something’s off - or maybe for some reason the time format in the xml did change
For those having the same issue, updated version available from https://github.com/laetificat/anna-ha
1 Like
thanks very much for the swift fix!
now let’s get this merged in core HA
https://github.com/home-assistant/home-assistant/pull/32109 is submitted and undergoing CI/CD checks
Plugwise Adam support is here!
With some help from https://hashop.nl I have been able to develop a Home Assistant custom_component for the Plugwise Adam HA.
Please go here for the files and configuration-info: https://github.com/bouwew/adam
Any questions, comments? Please post in this topic: https://github.com/laetificat/haanna/issues/1
HI, trying to fully understand the logic of the integration, I made template sensors for all attributes of the climate entity, and am still confused.
Not all naming is consistent, see below:
available Preset modes are listed, but neither Regulier nor Temporary are listed, while they show up as values for current preset mode, so I had to add these to the template. This is a different attribute than selected_schema, which is the correct naming for these to values. Since Temporary will be the schema displayed when using temp +/- on the Anna, it might be a good idea to add that per default to the available schemas?
kantoor_thermostat_current_mode:
friendly_name: Current preset mode
value_template: >
{{state_attr('climate.kantoor','preset_mode')}}
icon_template: >
{% set mode = state_attr('climate.kantoor','preset_mode') %}
{% set icon = {'Temporary':'mdi:gesture-double-tap',
'Regulier':'mdi:check-circle',
'away':'mdi:home-export-outline',
'vacation':'mdi:beach',
'asleep':'mdi:hotel',
'no_frost':'mdi:snowflake'} %}
{{ icon[mode] if mode in icon else 'mdi:home' }}
state of the climate entity is auto, but that is a value for Hvac modes, which is a bit confusing…
This is how it’s coded:
def preset_mode(self):
"""Return the active selected schedule-name.
Or, return the active preset, 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 self._presets:
presets = self._presets
preset_temperature = presets.get(self._preset_mode, "none")
if self.hvac_mode == HVAC_MODE_AUTO:
if self._thermostat_temperature == self._schedule_temperature:
return "{}".format(self._selected_schema)
if self._thermostat_temperature == preset_temperature:
return self._preset_mode
return "Temporary"
if self._thermostat_temperature != preset_temperature:
return "Manual"
return self._preset_mode
return None
self._thermostat_temperature is the set-temperature.
If you can’t “read” what this does, I will describe it in words later.
I did not like how the state was represented on the Climate-Card so I “abused” the preset-mode attribute to display the general status in an improved way.
In the Adam-component I have implemented it the correct way and I’m not liking it!
It shows that it is in auto-mode but also the corresponding preset that is set via the schedule. And when you set a custom temperature in the schedule the previous set preset stays.
So you can see auto=actived, preset=home and the set-temperature=20.5. How confusing is that!
thanks, confusing indeed, especially the difference between Temporary and Manual. Though understandable from a programmers pov, for the end user manual overriding a schedule (Temporary) feels the same as setting it manually (Manual)…
adapted the icon_template to include Manual:
icon_template: >
{% set mode = state_attr('climate.kantoor','preset_mode') %}
{% set icon = {'Temporary':'mdi:gesture-double-tap',
'Regulier':'mdi:check-circle',
'Manual':'mdi:gesture-swipe-vertical',
'away':'mdi:home-export-outline',
'vacation':'mdi:beach',
'asleep':'mdi:hotel',
'no_frost':'mdi:snowflake'} %}
{{ icon[mode] if mode in icon else 'mdi:home' }}
but still feel we should streamline the attribute names…
need to say no more. +1 to that.
consuming all off this, and made find a better way later on.