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

@ravanimi thank you for the response.
One thing we definitely want to pursue with the Developer Portal is the opportunity to co-create new solutions with our users who are already very passionate in building own solutions for their use cases. That's why the Developer Portal is aiming to provide everything that is needed to enable this.
We are always happy to hear from your suggestions, as this helps us in providing a better service. However, we also have to check with the possibilities we have.

Best regards,
Michael

Hi @schueli86, thank you for your response! Your connection will be back as soon as the time limit stated above is reached. Just make sure to adapt the frequency of the requests of your current solution to avoid reaching the limitation.
I'm for happy to hear that you are interest in the Developer Portal. You can find the link for registration here: https://forms.gle/kMpJ1i573absQWHn6

Hi Michael

I appreciate you have to operate within the guidelines given by your management and company, but what you are saying in this thread and how the company is behaving is not aligned. People lose their connectivity (even the 'official' one over the app) and have no clue when they will get it back or how they have to behave in order not to lose it again. This unclarity is anything but friendly and collaborative and give a look of 'showing who is in charge' to the whole thing.
I hope a very clear statement about thresholds, times etc. will follow very quickly

Kind Regards
Michele

@thetrueavatar I'm happy to provide you and all other user more concrete information on how the current restriction 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 request until the time window ends. Then, with the next user request, a new time window opens.
Currently, we have two limits active:
120 calls for a time window of 10 minutes
1450 calls for a time window of 24 hours
We see these limitations reasonable, also based on your great explanation concerning cloud based services. So thank you for that!
Also, we decided against HATEOAS as it is deprecated and will sooner or later be switched off.

Hi,

first I need to say, I fully understand this and what the most "nerds" forget, if you find a way to use an API, this don't mean you are legaly allowed to use it.

So I'm really thankful that Viessmann don't focus only on the non tech guys who use only the App. It is great that you planning an official API for the SmartHome users.

**bleep** all these good words, the big BUT. IoT system should be build in a way that you can easily scale the system and it should be no problem to add more servers to your IoT cluster. Why you don't spend the money till you are done with the developer API and provide us directly with a solution?

A good release schedule would be to implement the threshold **bleep** 2 months of the release of the new API. So everyone have time to move the programming over to the new API.

Perhaps you could remove the threshold again and add it **bleep** you released the new API.

 

Also something that would cool down the situation a little bit, would be to give us an ETA for the start of the BETA testing also for the official release. Already with the "working" beta, most of us could bring systems up and running again.

 

Also remove the english word A F T E R from your filter of the forum.

 

Hubert

@MichaelHanna
That is an information I can work with. I will now check the libs I am using and see what has to be adjusted to not hit those limits. 120 calls in 10 minutes means about one call in 5 seconds which should be enough for all use cases. It seems most of the limits are hit because features are polled one by one. So maybe this can be adjusted by @thetrueavatar and other libraries.

How about fixing this thread also ? I can't see half of the message sometimes and it's quite difficult to understand why. Sometimes my response appears in the feed, sometimes as comment to others.. Pffou this is quite a mess to deal with...

@thetrueavatar
When clicking a notification in an email only the thread with comments is displayed. Above the box is a link "Gesamtes Thema betrachten" or "See full thread" or something similar. This will switch the view (although this is really quite a mess). When vieweing a single post or comment the reply will only end up in this subthread. When viewing the full thread and replying below it will end up as a new post.

Thank you @Croydon for giving the explanation 🙂

@MichaelHanna
Indeed since the old api was designed to be discovered bit by bit with it's HateOAS approach my client was implemented in this way.Moreover feature were added/updated quite often and since I didn't had a full spec documentation I couldn't test most of the feature available. That's why I have started by a "one call per information" approach. However, I could switch to a kind of graphql approach where every user give as input the list of data they want and I will do only one call and parse it to provide the data asked.


I could indeed update my client as soon as I get my access back 😛 

Dear Micheal,
thanks for the EDIT, it clarifies a bit how the limits are incooperated.
For further clarification please confirm that the use of any API function does count to that limit. In other words, the calls for several data-points in one go are not counted as one call.
If that is not the case I can not understand why my account tripped the limit (a call for several data-points every five minutes).

Hello Michael and all Viessmann Team,

 


@MichaelHanna  schrieb:

> 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.


Could you please specify this a bit more clearly, what the limits are? I don't think it is very constructive if everyone tries to figure out this individually via try&error.
Does 15 minutes mean, you only can have one request per 15 minutes, 96 per day? And if you do one automatic request every 15 minutes, you will not be able to use the "original" ViCare app any more, because you already used up all of your "quota"?

Question answered while I wrote this post, thank you!

 


@MichaelHanna  schrieb:

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.


In order to allow a seemless handover for the users, it would be great if you can provide an overlap of at least one week, so everyone has the opportunity to implement the changes necessary without totally loosing the service in the mean time. (Not ultra viable for logging-only users like me, but for those who also remote-command their heating system.)

 


@MichaelHanna  schrieb:

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.


Could you give us a small hint, what are the big issue with a local API?

To make things clear: I would be totally satisfied if the local API only provides a READOUT of current STATE (all measured temperatures, modulation, pumps, current program active - preferrably also active settings like heat curve, set temperatures, but that's not so important) and for anything you want to SET on the heating system you would have to go over your servers.

People who have integrated it in their home automation may think different, as they also want to reduce dependency on cloud services. But I can imagine, that consolidating commands from two sources may be an issue. So this could be a second step somewhen in the future.

But giving a local access that only gives you information but does not allow to modify anything could be easier to implement. This would satisfy all users who do logging, and it takes off much traffic and server load on your side (what you will keep in any way with "just" a new, different API). It can be a totally simple interface, just every time you query data from the heating, put it out to the local interface as well.

Also if limited CPU power and/or memory in the VitoConnect is the issue, keep it simple. For example, make a telnet port that routinely outputs the data as it arrives. No need for compicated API server software.

 

Best regards,
an engineer that is also working on embedded systems and therefore know about those limitations.

Hi @didy, concerning the the first part of your response I added a short description about how the current threshold is defined in the very first post of this thread.
Also, I hope you understand I cannot go in details about the local API. This was also not my intention by opening this thread.
At the same time, your opinion and suggestions of course help us in developing new solutions for the future. With the Developer Portal, we intend to give everyone the opportunity to co-create new solutions in a way that is reliable and sustainable. So, we hope to hear more suggestions from you in the future and appreciate it a lot!
Best regards,
Michael

@MichaelHanna
I know that the local api is not something that can easily be done short-term.
BUT as far as I see from my research, the Vitoconnect sends and receives all data by using a "simple" MQTT connection to Microsoft Azure servers.
So maybe it would be a very easy approach just to be able to define a second MQTT broker/server that the Vitoconnect sends the data to and receives updates from. Most Home Automation systems are capable of MQTT and it would possibly not require anything special to be done apart from documenting the MQTT scheme.
This approach would possibly reduce the load on your remote API by lots of queries. The azure MQTT with remote API could then mainly be used for what it was set up for: the Viessmann Apps.

This is great news. Or maybe there would be a way to put "a man in the middle" and redirect the DNS of microsoft servers to local ip address of MQTT broker in LAN? Could you share more details about that? If not here please use one of the forums where we are trying to address those new limitations:
https://github.com/oischinger/ha_vicare/issues/27

Dear @JueBag,
I'm not sure what you mean by "in one go". In general, every request is counted.

Dear Viessmann,

This is a direct consequence of enforcing users to use cloud only solution. Clearly, you are completely unprepared for such solution. Allow developers and users access over LAN and problems will be solved!

This is crazy that in order to read temperature from the boiler 10 meters away I need to send data back and forth across the globe especially that both are on the same network.

Not only I am struggling with Vitodens 200-W B2HE problems that according to local Viessmann support are because of software bugs, now this. This is becoming a joke.

Looks like you are giving me no choice but consider steps to return the product or at least file complain to local government consumer centre.

Regards,

Lukasz

@MichelHanna
Sorry, I understood the technique created by @thetrueavatar would allow to get several values in one call (on go). But as he posted that was a missunderstanding on my side. Sory for that.

@MichaelHanna: I didn't want to have DETAILS, just a ROUGH idea why you think a local API will not be possible any time soon? Is it hardware limitations, is it open security questions, is it "would need complete refactoring of existing software"?
Or even - what do you understand under "near future" - are we talking about months or about years?
As far as I understand, there is no decision yet if you want to provide that some time at all?

@adorobis: man in the middle would be the most ovious way to do, but the communication is encrypted. Maybe, man-in-the-middle on the Optolink interface is the way to go. Again, a not official documented interface - but currently the only viable "non-cloud" option. We will see, how the official API will look like when it is released.

PS: The forum software is confusing me. You can add comments to postings, that are different from normal postings, and you cannot directly answer those comments, only postings? Never seen this in any other forum, and I'm in multiple forums since at least 20 years now.

@thetrueavatar The thing I don't get: If the billing by throughput is the driving point, why do they make another cloud-based API for the "power users" and not go for a local API in the first round? Just making a new cloud-based API still means throughput on the bill. Sure, you can make the protocoll smaller, as the current API has crazy much of redundant information - but eliminating the need would be the more effective aproach when reducing server throughput.

@MichaelHanna @JueBag
About the "in one go": At first, I was looking at your existing API manually with postman. When you retreive an URL there, you got a big bunch of data where all information was contained. I would expect this as "one access", so with "one access" or "one go" you could get all data currently available (all temperatures, states....).
Therefore, a 24h-Limit of 1450 would be sufficient for once-per-minute logging (24h=1440min).

However, I have the same issue: I reduced my interval to 5 minutes on the weekend. Nevertheless, I obviously hit the limit before 9am today.
But I have to admit: After I found out there is a ready-to-use module on the internet, I didn't develop an own solution but just used that; I currently don't know how exactly this interacts with your servers.

Hi Michael,

 

I have limited my requests to a frequency of 20 minutes. That is 1440/20=72 requests in 24 hrs. To me, I'm not brekaking the lilit. Nevertheless my Vicare app still doesn't work...

Kind regards

 

Johan

Hi @johandb, reaching the limit will prevent you to execute any further requests with your account in that time. Changing the frequency of calls will help in not reaching the limit, but you need to wait until the time frame is over to be able to perform requests again.
Best,
Michael

Hello,

two questions concerning the Developer Portal (Pre-)Registration.

Does the email address there need to match the credentials used for the server registration?

What is the intention about giving the postal address - oh I just see, this is not mandatory, so nevermind.

Hi Michael,

I think I understand : I will stop requests from my Openhab for 24 hrs. That would restore connection for my Vicare after 24 hrs.
After that I could safely restart my Openhab request with a frequency of every 20 min. Is that correct ?

Kind regards

Johan
Top-Lösungsautoren