The problememhab turned out to be org.open.core.model.script-2.5.0 missing. After manually adding the add-ons, there are no more bugs and everything works. Thanks.
Following all the API instructions and using Andreas code I’m still struggling with following error message when running the rule to update the values:
[ERROR] [hab.core.model.script.viessmann.rules] - Cannot get values from Viessmann IoT API. Error: {“viErrorId”:“req-8d…ef71”,“statusCode”:404,“errorType”:“INSTALLATION_NOT_FOUND”,“message”:“INSTALLATION_NOT_FOUND”,“extendedPayload”:{}}
The AccessToken rule runs without error.
I have used the deviceID as well as the serialNb from my communication device.
Any suggestions where I should look into?
The deviceID is in most cases 0, you do need your installationID and gatewaySerial.
gatewaySerial: ok have it
installationID: where to look into?
Look onto the Viessmann developer portal, there you will find the required curl commands to obtain your IDs.
If you are using Postman, create an GET comand with https://api.viessmann.com/iot/v1/equipment/installations?includeGateways=true and your actual Token and send it. That way you will get all your needed IDs.
…got installationID
Thanks
Hello Everyone,
I am trying to set ECO (reduced) or PARTY (comfort) program through the API. Through those program I can reduce the consumption when I am away (reduced program). As far as I understand the API and the commands available to me, I can define the target temperature of those two programs but not directly enable them. Anyone already tried this ?
Additionally, is anyone using a different mechanism to reduce consumption while away ? Through mode maybe ?
Thanks
Jonathan
IMHO the Holiday mode is meant for such.
I’m using the OneTimeCharge via the API, that is working. For the other “quick selections” (from ViCare) I can’t tell.
[Edit] According the API documentation the mode comfort can be set.
Also provides the commands to enable/disable it and change the Comfort temperature value.
I am not certain but I think the reduced temperature is used according the timeschedule, iaw this one is selected only by the schedule.
Thanks for the code @AndreasBerz! That saved me quite some efforts and I guess it’s more a basis than just an inspiration for many of us 
After some weeks I figured out that there are issues with the API calls. The reason was, that HEAT1_AccessToken was like
"{"access_token":" long_base64_string " ,"refresh_token":" hex_value " ,"token_type":"Bearer","expires_in":3600}"
instead of just a hex value.
I have no idea how that could happen and were not able to reproduce it. No other rule is accessing this item…
Just to be sure it does not block updates for many days again, I updated the first IF condition like this in order to correct this issue automatically next time:
if (HEAT1_RefreshToken.state != NULL && HEAT1_RefreshToken.state.toString().contains("\"access_token\"") == false )
Maybe it helps someone…
Hi matthiast,
it seems, that the whole JSON data received by sendHttpPostRequest()-call was assigned to item HEAT1_AccessToken (or HEAT1_RefreshToken) instead of the solely token value.
The token value is extracted from JSON data via calling transform(“JSONPATH”, “$.access_token”, jsonData).
I have no idea why (in your case) this transform()-call returns the whole JSON data instead of the requested field 
In my OP above I showed the possibility how to get only some (desired) values from the API, that stopped working ( for me only?) on Dec 2nd 10:27 CET.
Although the REGEX statement is in the request as before, the API returns ALL datapoints (currently 170).
According to Viessmann nothing has changed on the API side ( believe it or not).
[Edit:]
Sometimes you have to write something down in order to “make” it happen! Viessmann corrected the API return today!
If I get it right the RefreshToken is only valid for 1h? Did anybody extend the rule so that it automatically recreates the RefreshToken with UserName, Password, ClientId and CodeChallange once it is invalid?
My code doesn’t wait until the token expired, it is called every hour. However I hab occasions (power loss, update etc) where the refresh was performed in time, running the code in this case was no problem at all, it always gets the new token.
Do not mistake the Refresh Token and the Token. The Refresh Token NEVER changes nor expires, the Token does!
Ok, I thougth the Refresh Token expires, too. So if this is not the case, then a powerloss for several hours is no problem. How did you set the Viessmann_RefreshToken item. I’m using a string item, but didn’t figure out how to set a default value?
I did the initial steps manually via the browser, instead of having the RefreshToken hardcoded in a rule I set it manually to an Item. How I did that, I don’t recall at the moment.
Initially Viesmann stated that the RefreshToken never changes, that is WRONG. After 180 days it simply turns invalid and you have to do the authentification AGAIN.
Updated in post #1.
The Viessmann-Api of @thetrueavatar was also working with the new IOT api, but now it seems to be broken.
I get following error:
result: Message: Unable to get data for feature Reason: Internal server errorCode: 1
Can anybody confirm this issue? Or is it an issue on my side.
IMHO this change was several month ago. Are you observing a recent change?
I switched to the Smarhome/j Viessman Binding without a recent problem. Using that one even the regular update of the RefreshToken is working handsoff.
It is working again. Somehow the cloud service was down, as the APP also didn’t work. It seems that this happens quite often in the last time.
I already tried the Smarhome/j Viessman Binding some time ago but I didn’t like the polling behaviour and that it is not listed in the Openhab Marketplace.
after adding https://download.smarthomej.org/addons.json to JSON third party addons in settings area you can search/watch for bindings/addons provided by Smarthome/j via the marketplace area.
1 Like