Climate Solutions Community

@adorobis: agreed. ... Mehr anzeigen

@bjanssen Da bin ich ja komplett deiner Meinung. Ich wollte nur sagen, dass Viessmann in dem Punkt noch einer der kooperativeren Hersteller ist, wenn ich an andere denke. Optimal ist die Lösung bei weitem nicht und iot ohne lokales Netzwerk mit Zwangscloud ist im Allgemeinen Müll. 100% agreed. ... Mehr anzeigen

@eweri I can understand that you are angry and I also think it would be best to allow some local unrestricted access to the data, but sadly this is common behaviour of all sort of companies that offer "iot" devices. Think about Somfy Tahoma, Gardena, Ewelink, etc pp. Each company develops it's own proprietary protocol and/or cloud solution that does not (officially) work without internet connection and using the cloud to control or read the data. It's somehow like all of them think "Oh, iot is a hype now. Let's get some share of the market fast" 😉 This said, Viessmann nonetheless is one of the user-friendlier companies regarding a (yet to finish) official api and a (inofficial) existing api the use of which is at least tolerated under specific conditions. ... Mehr anzeigen

@JueBag If it is a floating window than it can be the limit, indeed. If he reached the 24h limit 20:25 hours after the first call of the time window, then the lock should last 3:35h. ... Mehr anzeigen

@MichaelHanna I have had no further problems during the last 24 hours. The threshold seems to be working correctly now and the limits are high enough to allow a reasonable operation of the heating combined with PV, sensors and smart control. Thank you and the dev team for listening to the users' problems and fixing the threshold implementation fast. I am looking forward to see the Dev Portal once it is ready. ... Mehr anzeigen

@jpty I guess that was because of the bug in the system that MichaelHanna mentioned. ... Mehr anzeigen

As far as I understood the ban is not for 24h but for 24h starting from the first call. So let's say you made 1 call at 18:00 and 1449 at 19:00, the ban should last until 18:00 next day. ... Mehr anzeigen

Until now it seems fine @MichaelHanna. I have set polling time to 3 minutes and the connection seems to be still working. I'll watch it for the next days if the setting of values frequently might hit the rate limit, but it does not seem so. ... Mehr anzeigen

@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). ... Mehr anzeigen

@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. ... Mehr anzeigen

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

@MichaelHanna Just for information: I am still banned currently (08:47) and have not made any further requests. ... Mehr anzeigen

@MichaelHanna my account was banned yesterday (17.3.2020) at about 17:15. I then disabled all scripts and could open the ViCare app tonight at about 18:00 one time. Then I tried re-enabling the connection through ioBroker, but it failed with error 429 directly after login when calling GET https://api.viessmann-platform.io/general-management/installations … So this was only one or two requests (besides the ViCare App) that triggered the error 429 again. I disabled the ioBroker directly after that, but until now (21:12) the ViCare app still is not able to connect. So the ban is still in place. What about the suggestion to just enable MQTT to a second (local) server? This should be really easy to implement. Especially compared to a local api etc.   ... Mehr anzeigen

MQTT over TLS is working with server and client certificate. As far as I understood Azure requires the client to have a certificate that was issued by the same CA as the server certificate. Also the hostname has to be matching and the ca has to be trusted. So I see no way of doing a MITM for the MQTT connection of the Vitoconnect to Azure as you cannot alter the checks the client does nor alter the Vitoconnect truststore. ... Mehr anzeigen

@thetrueavatar You might be right, but I am not sure about that. They are using Azure MQTT IoT services for communication of Vitoconnect with their server. But the ips of the app API seem to belong to T-Systems (Telekom), so it might be that those are not routed to Azure at all. I was wrong about that. Checked the wrong ip. The API ip is indeed belonging to Azure, so your findings seem to be right. ... Mehr anzeigen

Yes that is the "problem". The communication takes place only outgoing to Azure MQTT via port 8883 using TLSv1.2 and client certificate. The hostname that is called has to be something like "xxx.azure-devices.com" or similar, but the client on the Vitoconnect seems to be very strict in checkings. ... Mehr anzeigen

I am not sure if the threshold is working correctly, either. Just was able to open the ViCare app once, but then trying a single(!) login via API in ioBroker resulted in error 429 and so the App is also not working anymore. Quite irritating. ... Mehr anzeigen

@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. ... Mehr anzeigen

@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. ... Mehr anzeigen

@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. ... Mehr anzeigen

@thetrueavatar while this is totally true, the de-facto-shutdown of the current API before having the new one ready is a real problem for home automation. To have the optimizations work and all the scripts for PV, Heating etc. working, I need to query regularly, i. e. at least about once a minute. And I have to change temperatures regularly, too. So there is still no information about how the threshold is working exactly. My access got locked, too, since yesterday. And that is quite a problem for the heating control. ... Mehr anzeigen

Dear Michael, thank you for the explanation which was really misleading in the mail sent. > The limit is set for both a larger (e.g. daily) and a smaller (<15 mins) time scale. Can you further explain what exactly is the limit of the larger and smaller time scale? This is important to know imho. Thanks and best regards ... Mehr anzeigen