abbrechen
Suchergebnisse werden angezeigt für 
Anzeigen  nur  | Stattdessen suchen nach 
Meintest du: 

Q&A Viessmann API

Dear developer and smart home enthusiasts,

today, we want to contact you to talk with you about the recent activities that are taking place concerning the interface of the heating systems, also known as the Viessmann API. As most of you might have already received our Email in which we informed you about the upcoming changes concerning the use of the API, we would like to open this thread to continue the discussion openly and transparent with you and pick up on the discussions in this thread. Here is again a brief summary of the main points from our message:

> As Viessmann, it’s in our responsibility to provide our users with reliant and safe products, including features and services around those products

> We are impressed to see your interest in connecting and interacting with your heating system and that you found a solution for your specific use case without a description or support from our side

> However, it challenges us to check and channel the method and frequency of requests to our IoT Services in order to keep those stable and available for all our users

> What is even more important is that for these solutions, we as Viessmann currently cannot guarantee a safe and reliant operation of your heating system

This has the following steps that we have to take:

> In order to keep operation through our API safe and still give you the chance to interact with your system, we limit the use for all applications by setting a threshold for the requests. The limit is set for both a larger (e.g. daily) and a smaller (<15 mins) time scale. Reaching the limit will prevent you to execute any further requests with your account in the specific time frame. So please make sure to adapt the frequency of the requests of your current solution to avoid reaching the limitation.

> We are heavily working on providing a solution for all users that is 1) approved & safe to use, 2) properly explained and 3) gives you the functions and information you need for your specific use case. At the same time, this will also be moment when the solution is in place where we cannot allow any other ways of accessing our API. To make things clear: Your already built and currently used functions will still be able to use, it’s only that you will need a new API client provided through the Portal that can be self-managed by the user himself.

We also received a lot of questions via Mail and also in this forum, which we are going to answer for everyone individually. We also saw that the most common question among the responses was the demand for a local API. This is a reasonable request and we appreciate and take the demand very seriously. However, we will not able to provide you a solution for this in the near future. This feature (as all other features and requests by users) are permanently discussed and evaluated and brought together with all other strategic decisions that Viessmann is taking.

I again would like to encourage everyone to participate in the development and make sure to sign in here to get an early access to the Developer Portal. Also, we are hoping to have a constructive discussion here in this thread. We are really looking forward to work jointly together with you on ideas and co-create future solutions!

P.S.
As stated in the previous thread and in certain Emails we received, we are aware that some users might expect a communication in german from us, as Viessmann is of course a company with German heritage. However, since we are providing climate solutions all over the world and especially programming / APIs is natively described in english, there is no other option than communicating in english first. This has already been greatly explained by @thetrueavatar in the previous thread.

All the best!

Michael Hanna

Viessmann Developer Portal

EDIT:

In order to support you more on adjusting your current solutions according to the current limitation, here is how the threshold works:

We have a rate limit with sliding window. Whenever the first request arrives, we open a time window and count all request in that window. If the number of requests reach the limitation, we block all incoming user requests until the time window ends. Then, with the next user request, a new time window opens.
Currently, we have the following limits active:
120 calls for a time window of 10 minutes
1450 calls for a time window of 24 hours
Please take note that we are taking the right to adjust the limits if seen necessary. Information about adjustment of the threshold will be given with a reasonable amount of time in advance for all affected user.

EDIT2:

For all who experienced a ban after the limitation time frame with a few number of API requests: Our team fixed an issue with the limitation, which is taking effect since today and should solve this problem. We are still analyzing the behavior, but for now it looks ok.

172 ANTWORTEN 172

clientId/secretId(of the app) are more than likely different on IOS and Android... I'm using the secretId from Android ViCareApp in my client of the service...

@thetrueavatar I certainly wasn't aiming my comment at you !
I was just pointing out that there's no reason Android users should be disadvantaged.

Many thanks to you, thetrueavatar , for your work on this. You're doing what Viessmann aren't.

I didn't feel aimed by your comment, don't worry. I was just providing a plausible explanation. In fact, if someone could provide me the clientId/secretId of the IOS App this would help me to confirm/infirm my hypothesis.

Amazing, zero information from the company, blocked accounts and you guys are still debugging it ... 🙂 Kudos

And all of that on German forum. Good we have google translate in Chrome 🙂

Soon the forum servers will also be overloaded, leading to posting limits. :facepalm:

@thetrueavatar I appreciate your passion on this topic. However, right now we do not see any reason for suspending the limitation. As I already said, I forwarded all your issues and we see what we can do on our side.
@Tommmi, @ravanimi @adorobis your and all other responses and issues are taken seriously and we are looking closely to everything you provide us. We are trying our best to support you with your issues you are currently experiencing. However, please take into account that this limitation is a reasonable measure, but this measure also aims to still give you the opportunity to use your applications, which are not authorized in any way by us and since we have not yet officially allowed using our API, we are not responsible for the experience with your applications. That's just to be honest.
So please understand that we are working on is to provide everyone the opportunity to get official access to our API, since we are more than happy to co-create new solutions together with you.
Best,
Michael

@MichaelHanna sure, I understand this. We are working on adjusting our integration to respect the new limits as well and actually I'll be able to test it as soon as my daily limit is refreshed 🙂

aaaand there it is...the honest answer from the company : you, the customer, are not authorized to access your data which the company holds. But understand that the company is working on it.

FWIW : give me local access. End of.

@Tommmi unauthorized means that we are not able to guarantee a safe and responsible use of your applications since there is no official API provided by us. But as I say we are working on it change this.

@MichaelHanna we appreciate your effort and I see that everybody is ready to adapt to the revised access guidelines, but in order to do so they need a clear description of the implementation (the algo) and a clear statement on its status i.e. is what @thetrueavatar and the others are experiencing due to a bug or not and if yes when it will be fixed.
Co-development = transparency

Errors 400/429: Still can't login after suspending requests for a day.

Well MichaelHanna is partially right about this. We have hijack the server wich was designed to be used for a SPA application like ViCare with very little load planned. So they have indeed no obligation to do anything to support this.

However, I had to do this dev because during summer 2018 Viessmann broke it's own ViCare application by upgrading the server api without coordinatation with the app dev teams. ViCare was completely useless and since it was no more possible to get basic information through ViCare I have done this code. So that's not for the fun I have started my own dev but because there was no official way to access my own data.... After that, the api has been used(even by mysfelf) to keep track of data but indeed the service wasn't design for this.

So yes you don't have any obligation and I do appreciate you're tollerating our usage but don't forget we had to find a workaround due to Viessmann's failure during summer 2018...

BTW I have developped a version of my code that sould do caching and so reduce load on server.

Could you please share your code? Or at least some details on which APIs you are using. We'd like to also implement similar optimized API calls for the Home Assistant integration

Hm, yes, still banned. ViCare still not working although I have not made any more requests until now. *sigh*

Well I have reverse-engineered the current service behind ViCare and developped a low level client in php(what an idea....). If I had to do it once again then it would do an openapi rest interface wich is more than likeley what Viessmann will provide. So I think it will be more efficient to wait their dev portal tbh.

Ok I had my account back, check with ViCare, run one call and then boom 24hour ban. There is something else that cause the ban. Maybe that it's a problem with my way of coding the client. I wonder if it's possible that every user is using the same "credentials" to access the service leading to this situation.

That could explain the problem. I will investigate in that way.
Basically the request that cause the ban was :
https://api.viessmann-platform.io/operational-data/installations/<intallation_id>/gateways/<gateway_...
with those data
CONSUMERID = "79742319e39XXXX1d15ff4cac2a8";
CONSUMERSECRET = "8ad97acXXXXXb093c7c083fa";
x-api-key=token 38c97795ed8aXXXXX447bd1178c8

@thetrueavatar there must be something really wrong with the current ban. I still don't have my account back and the last call is already more than 24h ago. And I only checked via ViCare, NOT via script or something like that. So the "id" cannot be the cause here.

Maybe I am saying something really stupid here but, how are the accesses counted?
Based on the installation ID?
Are ViCare and straight API calls separated or do they fall in the same pot?
How often does ViCare call home to update its data when running?

@ravanimi as Michael said, all apps (so scripts, ViCare etc.) count against the same quota. So ViCare uses some of the accesses already. I think it is not based on installation id but on account (email/password).

@thetrueavatar:
If your assumption would be correct (all request using your code are using the same CONSUMERID and -SECRET), IMHO the ViCare app of those users should not be banned (at least based on those CONSUMERID and -SECRET).

My ViCare is still banned!

You receive a token after the authentication. This token grant you access to your date. ConsumerId and ConsumerSecret are supposed to be static credentials for the Vicare app.
I have the feeling indeed that the count could be shared among every user.
Maybe it's coming from my way of coding or from a problem with the viessmann's server

Similarly here. I was banned over 24 hours ago, my integration is disabled and I can't get access back on the mobile app.

Some update, maybe something that will work for you as well. I have logged out from the ViCare app on android, tried to register a new account with different e-mail address but this failed as the Vitoconnect device is still registered with the old account. After logging back to the old account bingo! Ban is lifted and I could use the service on the mobile app as well as on my Home Assistant. It is now set up to call the API every 15 minutes which should be good enough to get blocked again.
Top-Lösungsautoren