Viessmann Component

DrGrandios · March 6, 2019, 11:54am

I’d like to say thanks for this component, works like a charm on my newly installed Vitodens 300.

Although I’m in fact worried about cloud access (any hacker having access to Viessman servers would have too much possibilities…). But Viessman demands (permanent!) cloud access in exchange for extended warranty. Otherwise I would immediately switch to an offline solution (see https://github.com/openv/openv (in German)).

DrGrandios · March 6, 2019, 12:27pm

Just for information - the Github setup doc should be updated. Found this in my logs:

oischinger · March 6, 2019, 8:45pm

@DrGrandios Thanks for the hint.
I updated the Readme.

DrGrandios · March 8, 2019, 5:02am

I saw a flood of exceptions in the log this morning (sorry, don’t have them at hand, will provide them later…) which looked like the OAuth token exceeded but the component didn’t care and tried to access the (non-existing) data anyway. Restart of HA fixed this.

I remember that I used the ViCare app yesterday to check how often the burner (? in German it is “Brennerstart”) started, because this information is not (yet?) available in HA. Could this have invalidated the HA token?

Flo.C · March 8, 2019, 8:51am

Mine completely stopped working. This is only one of the errors which occurred:

2019-03-08 09:42:26 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.vicare_currentdesiredtemperature fails
Traceback (most recent call last):

My log is full of it. I also switched from the folder structure Climate/vicare.py and Sensor/vicare.py to vicar/climate.py & sensor.py

In this case I get an configuration error that the platform is not found. I changed nothing in the till today working configuration.yaml

oischinger · March 8, 2019, 10:54am

Hi @Flo.C
The rest of the Traceback would be interesting to debug the issue. Does a HA restart help?

@DrGrandios: I also noticed that the token seems to be invalidated once you use the ViCare app. This leads to errors in the HA component but the token is automatically recreated by PyViCare and the next requests (according to scan_interval) should work again.

I’ll see if I find the “Brennerstart” function somewhere in the API, then we can add it. What is it’s purpose? Shouldn’t the burner be started automatically :)?

DrGrandios · March 8, 2019, 11:03am

“Brennerstart” counts the number of times the heater switches from off to on. This number should increase only slowly - otherwise it is an indication of a bad heating system setup (e.g. it is cold but too many thermostat valves are closed and the heater can’t get rid of its hot water).

DrGrandios · March 8, 2019, 11:07am

the token is automatically recreated by PyViCare and the next requests (according to scan_interval) should work again

This seems to have failed for me - all sensor readings were not updated the whole night. I’ll check the logs when I’m at home…

DrGrandios · March 8, 2019, 2:25pm

It’s even worse and still failing for the whole day. More than 1000 occurrences over the morning…

edit:

Looks like it is PyViCare’s fault - I guess, if token expires and getNewToken fails, PyViCare stops working because self.oauth becomes None.

Flo.C · March 8, 2019, 4:12pm

Exactly the same here…

DrGrandios · March 8, 2019, 6:44pm

Worked for a while after restart but stopped again:

Screenshot_2019-03-08%20Home%20Assistant(1)

Of course there might be a chance that the Viessman server has problems atm…

oischinger · March 9, 2019, 7:30am

It’s weird. I had the same problem. When exactly did your component stop working?
Restarted it 12h ago and now it’s up and running since then.

SomethingAwful · March 9, 2019, 10:15am

I’m experiencing the same issues. It doesn’t necessarily seem related to usage of the ViCare app; it seems to happen randomly (or time-based?) as well. I also get the impression it’s starting to happen more frequently…

One issue might be that the sensor and climate component both fetch their own token instead of using a shared one?

DrGrandios · March 12, 2019, 5:10pm

Is set_operation_mode working for you guys? I can switch to ‘eco’ without problems. But i cannot switch back to ‘auto’ (nothing happens).

edit: Is it related to this breaking change?
https://github.com/home-assistant/home-assistant/pull/19242

BREAKING CHANGE
Change STATE_AUTO to STATE_HEAT and STATE_AWAY to STATE_ECO to conform to climate DOMAIN standards.

edit: Okay, this was a breaking change only for that component, not a general change.

Nevertheless, I can switch to “eco” and “heat” (party mode). But “auto” has no effect.

DrGrandios · March 12, 2019, 6:19pm

Finally found the reason:
a) the PyViCare API is not fully functional (but this is at least documented: activateProgram works only for “comfort”)
b) deactivateProgram in the PyViCare API seems to work (i.e. it is possible to switch from eco back to normal)
c) @oischinger the HA component has a bug:

github.com

oischinger/ha_vicare/blob/ace7fd4d6eefb8dfd3aeffa8f446dce05bb949d4/vicare/climate.py#L156


    elif self._current_program == VICARE_PROGRAM_REDUCED:
        return STATE_AUTO
    elif self._current_program == VICARE_PROGRAM_STANDBY:
        return STATE_OFF
    else:
        return VALUE_UNKNOWN

def set_operation_mode(self, operation_mode):
    if operation_mode in self._operation_list:
        """ 1st deactivate current mode """
        self._api.deactivateProgram(self._current_mode)
        """ 2nd: set new mode """
        if operation_mode == STATE_HEAT:
            self._api.activateProgram(VICARE_PROGRAM_COMFORT)
        elif operation_mode == STATE_ECO:
            self._api.activateProgram(VICARE_PROGRAM_ECO)
        elif operation_mode == STATE_AUTO:
            self._api.activateProgram(VICARE_PROGRAM_NORMAL)
        elif operation_mode == STATE_OFF:
            self._api.activateProgram(VICARE_PROGRAM_STANDBY)
        else:

The parameter has to be self._current_program instead of self._current_mode

Tried this locally and works for me

edit: This is still a bit buggy - works only when the climate component knows about the “real” current state which might be delayed a bit. When quickly toggling between eco and auto, the component won’t deactivate the correct program and the operation mode is not changed.

It might be necessary to generally call deactivateProgram for all possible programs and afterwards activate the selected program.

oischinger · March 13, 2019, 8:55pm

Thanks for the insights @DrGrandios.
I’m currently travelling and cannot fix that but I’ll definitely look into it asap.

oischinger · March 22, 2019, 8:28pm

@DrGrandios I fixed the issue you described. It seemed to work quite reliable for me.
I made one more change: I removed the deactivation of the “normal” program which seemed unnecessary.

Anyway: Calling self.async_schedule_update_ha_state(True) after self._api.activateProgram always returns the “old” state. It seems the Vicare cloud needs some time to update the status.
Let’s keep an eye on the behavior as it is now. Maybe it’s acceptable to get the status update a minute later. If not we could add an additional “programChange” state which gets overwritten with the new status at some point, but that might also result in weird behavior.

Flo.C · March 26, 2019, 12:09pm

guys I run into a problem again:

I had the above mentioned issues with the ViCare component. As my UI looked like a mess due not really showing anything but messy stuff I commented out the code in my config.

I wanted now to solve the issue but HA is telling me, that the platform is unknown. I created the custom_components folder, the subfolder vicare and put in there the climate.py and sensor.py.

Any clues what to do? Here is the log:

019-03-26 12:57:43 WARNING (MainThread) [homeassistant.loader] You are using a custom component for vicare.sensor which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant. 2019-03-26 12:57:45 ERROR (MainThread) [homeassistant.loader] Error loading custom_components.vicare.climate. Make sure all dependencies are installed Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/homeassistant/loader.py", line 166, in _load_file module = importlib.import_module(path) File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1006, in _gcd_import File "<frozen importlib._bootstrap>", line 983, in _find_and_load File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 677, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 728, in exec_module File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed File "/config/custom_components/vicare/climate.py", line 7, in <module> from homeassistant.components.climate import

DrGrandios · March 27, 2019, 11:39am

Thanks for your updates - unfortunately had no time yet to update my installation.

The Vicare component still fails from time to time, I guess it is still the token issue on the PyVicare backend.

I’ve also seen several timeouts (or rejections) when connecting to the Viessmann servers from time to time. Seems to be not the most reliable communication partner …

In every case I have to restart home assistant (which also currently fails for me from time to time - i.e. only a forced kill -9 of the HA application solves it )

Currently I’m not sure if I will rather switch to the non-Viessmann solution and build my own Optolink adapter to avoid alls this cloud mess…

oischinger · March 27, 2019, 4:18pm

@Flo.C if you update to master on the github repo you should not have to comment anything out. Can you check if the error persists?

@DrGrandios I didn’t have the connection issue anymore since the last 5 days but surely it can happen again at any time. I’m also not a fan of the cloud solution but I’m also not really fond of building some optolink hardware. I have very little time recently but I guess with some effort we could find good logic for all kinds of reconnection issues.
By the way: My Home Assistant instance restarts properly. No need to kill it.