Hi Michael, it has been roughly 4 months now since your announcement. Where are we with getting a client from the Developer Portal? And where are we with even providing access to Dev Portal? Also, I do not understand your refusal regarding local access to our own devices: "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." First of all, these are OUR devices. We are not renting nor leasing them from Viessmann, we have regularly bought them (and they are pricey, oh boy!). Restricting our access to the data of our own devices does not smell right - one could even ask what you are hiding. Especially very anoying is the veil of darkness you put over this topic - there is no explanation about why (too complex? too insecure? no skillset available?) you are not implementing this, there is just a "nope, we won't do this, and don't you ask!". Apart from the questionable morale of this approach and possible legal questions (I would be very curious about a legal decision on who owns this data and who is entitled for access to them), I am also worried about the aspect of what happens if Viessmann discontinues certain devices or even is affected too much by for example the Corona crisis and files bankrupcy. In that case, we would lose our entire access to our own devices. Also unanswered is the level of business security Viessmann are providing - in the B2B relations, a SOC1 report is typically provided by a service provider, where an independent trusted auditor (big players like EY, Deloitte etc. are providing this kind of service) examines and certifies business processes of a company, including their business continuity plans for catastrophic scenarios (which range from "broken water pipe floods the datacenter" to "thermonuclear weapon wiped out the whole region where the datacenter is located"). Does Viessman have such a certification? If not - could you please provide at least a high-level description of your DR strategy? Since you are forcing us onto your infrastructure and rigirously denying requests to bypass that infrastructure, I think it is a sensible request to you to provide materials undermining the trust into this infrastructure. Without information provided on "why", we can only guess why you are refusing local API requests. Two aspects coming to my mind are "misconfiguration protection" and "security". I do understand to a certain extent that you do not want to face an increased support call volume because people misconfigured their devices by calling the local API or even risk security breaches by providing a service on the devices. However, you still can misonfigure the devices by operating the local panel. As for security, yes, providing a local web server to serve the API calls would be an additional risk. Hopwever, my udnerstanding is that you are running an MQTT client on the devices anyway (which write the data to the cloud), so why can't you have the user enter an additional local broker via panetl and duplicate the topics you are posting to the cloud service? This shouldn't put any significant aditional load onto the control elements, and the software is already there, as far as I understand. Ideally, a config topic should also be posted (e.g. for Home Assistant discovery), but already without it, using an additional local MQTT broker would help much. Best regards DBa
... Mehr anzeigen
