Climate Solutions Community

@MichaelHanna they are not showing up in the viCare aoo either 😞 Only on the heater it self... ... Mehr anzeigen

Yes it ONLY works when commanding directly from the control station of the heating system. ... Mehr anzeigen

@JueBag thanks for your response here. I take this as well as I should now be able to report this as a bug to Viessmann.   You did understand it correctly the pink line is the reading of the outside temperature from the boilers external sensor. And the blue is from "another source". And I see the same issue both on the API as well as the vicare app.   It is really strange and I wonder if it is: 1. Vitodens 300W specific (as others has reported missing burner statistics as the rest of you get as well) 2. My installation (which I wiped completely now and got a new installationId. and in the installation stil has the issue - and I can set temperature operations mode etc both in vicare and API... but as mentioned outside temperature readings and onetimecharge commands is not working) 3. API gateway of Viessmann that has "dark holes" in certain combinations 😕 @MichaelHanna could you please report this as a bug now it seems to be fair to do now. And I guess I have confirmation now that the outside temperature reading via API should reflect the true reading from the outside attached sensor of the boiler, but at least for me it is stuck and useless in the API and vicare...   ... Mehr anzeigen

@JueBag thanks for taking the time to confirm it works as expected. Seems like what you achieve with your Vitodens 333F is exactly what I would have expected with my Vitodens 300W as well. This also means that I should now be able to say this is a bug not just a misunderstanding. So I will ask Viessmann to consider it a bug - also supported by the fact that the vicare app does the exact same thing (no errors and no onetime charge starting on the boiler). Could you confirm you also get the response to the POST CALL ?         "reason": "COMMAND_EXECUTION_SUCCESS" I am happy to paste what you ask, but I am not quite sure what you are asking? Is it the POST CALL and its response for the activate call or? Or is it the GET CALL and its reponse for the feature? (Btw I have done this both via postman, via pyViCare and the vicare app... all of them are unsuccesful..).   ... Mehr anzeigen

@MichaelHanna so did I understand you did confirm that the manual and displays "One-off cylinder heating" is equal to using the api for onetimecharge? So no reason not to expect this to do the same - correct? (It really is not clear as two different terms are used so at least mentioned that in the feature in the developer portal that it is the same 🙂 ).   You asked for the payload of the feature (GET) request, I assume you refer to the response payload aka body? No payload is provided when doing the GET call for the feature (not possible).         {             "apiVersion": 1,             "isEnabled": true,             "isReady": true,             "gatewayId": "xx",             "feature": "heating.dhw.oneTimeCharge",             "uri": "https://api.viessmann-platform.io/iot/v1/equipment/installations/yy/gateways/xx/devices/0/features/heating.dhw.oneTimeCharge",             "deviceId": "0",             "timestamp": "2021-08-13T15:54:07.647Z",             "properties": {                 "active": {                     "type": "boolean",                     "value": false                 }             },             "commands": {                 "activate": {                     "uri": "https://api.viessmann-platform.io/iot/v1/equipment/installations/yy/gateways/xx/devices/0/features/heating.dhw.oneTimeCharge/commands/activate",                     "name": "activate",                     "isExecutable": true,                     "params": {}                 },                 "deactivate": {                     "uri": "https://api.viessmann-platform.io/iot/v1/equipment/installations/yy/gateways/xx/devices/0/features/heating.dhw.oneTimeCharge/commands/deactivate",                     "name": "deactivate",                     "isExecutable": false,                     "params": {}                 }             },             "components": []         },   And in both the API and vicare app no errors are given!   However I can clearly see in the event API that the calls has been made! And where I can also see temperature changes made etc... so the API clearly notes and accepts the requests... and the temperature change and mode change request are received and executed on the boiler... but the onetimecharge is just not! 😞           {             "eventType": "feature-changed",             "gatewaySerial": "xx",             "body": {                 "featureName": "heating.dhw.oneTimeCharge",                 "commandName": "activate",                 "commandBody": {}             },             "createdAt": "2021-08-09T07:55:44.609Z",             "eventTimestamp": "2021-08-09T07:55:44.000Z",             "editedBy": "zzzzz",             "origin": "API"         },   So to me this looks like another bug 😕   What would be next steps to take? Having the event logs to show what happens from the boiler it self and its response codes would be a natural thing as I see it. Right now it looks like the events just means "received and sent to boiler" in a fire and forget mode. It would make sense to also have a confirmation from boiler.... ? And to me it looks like it is almost there but I can not trust COMMAND_EXECUTION_SUCCESS (ref first post in this thread).   What to do ?   ... Mehr anzeigen

@MichaelHanna I tried the https://api.viessmann.com/iot/v1/events-history/events?gatewaySerial={{gatewaySerial}}&limit=1000&eventType=device-error API and the latest error I have in there was from 2016 ( a lot of  "errorCode": "3e" and a few "ee"/""a3 from the installation, nothing since then, which seems weird. And to me looks like a bug.     I am fine to call upon local viessmann if you think it makes sense... but I would expect the device by itself be able to send errors and also do oneTimeCharge which still is a mystery.... another thread... ... Mehr anzeigen

Just for completeness on the event API:   I have tried a few options: 1. https://api.viessmann.com/iot/v1/events-history/events?installationid={{installationId}}&limit=1000 {     "data": [],     "cursor": {         "next": ""     } } Reflection: Based on how the API is organized I would have expected the installation to be level 1, and hence show stuff for anything under the installation - since that is not the case I would recommend to document more clearly what is expected. What I am saying is if it can be misunderstood it will be misunderstood 🙂     2: https://api.viessmann.com/iot/v1/events-history/events?gatewaySerial={{gatewaySerial}}&limit=1000 I see a lot of different eventType, but I have no full list of eventType values. Could one please be documented? The most relevant ones seems to be device-error and feature-changed (and then noisy gateway-online), and if I do that one I do not see for instance the E0 I have raised  in another thread. Even though I see errors dated back to 2015 so sure there is things logged and device-error is the one shown in the viCare app.   3: https://api.viessmann.com/iot/v1/events-history/events?gatewaySerial={{gatewaySerial}}&limit=1000&eventType=feature-changed This does only seem to create a record whenever it is the API that is used to make a change, not if if happens on the panel or vicare. I have only seen origin=API. But if this API was changed to show ALL events, and if this was possible to stream through a websocket you could avoid a lot of pulls on the API for sure.... but even better allow a local mqtt is even better you could still stream the events back to viessmann for your datalake.... But if this was treated well then this might be one of the things that could be used instead of pulling the whole feature every minute or so....  Which direction should we expect viessmann to go in on this?     ... Mehr anzeigen

@MichaelHanna glad to hear about the intentions with the events endpoint however nothing in there that showed the issue, so maybe another bug that nothing is there?   @MichaelHanna about what "mode" the boiler is in that is easy sure. However that is not what I and I think a lot of others are after, it is more about is it heating dhw or building right now (not the mode). And the age of IoT and potential of saving energy for the climate that is actually rather good to know on making a decision both about what changes makes sense to ask the heater for and what other devices in the house should react accordingly. I could go on about use cases here, but the main message here I think is that Viessmann needs to step into this age of IoT with a more open approach to ensure you are part of providing innovative and help optime to save resources for the sake of the environment. I hope this will be taken into considerations in future responses and thinking about what a community can help you Viessmann being part of - I do believe this is high on your business agenda and trust it is with commitment not just buzz words... but then it is important to listen to the users and make it a priority 🙂   Looking forward to the requested endpoints, all of them and more to come I am sure 🙂   Jørgen ... Mehr anzeigen

@MichaelHanna just for completeness here is also two screenshots. 1: before doing the manual one-off charging (as oneTimeCharge API call does not work) 2: after it started (with 34% modulation and one increase on burnerstart 14446 to 14447 as it is in danish) The API still shows nothing about stats, so the information is passed to your central server but not available in the API. @MichaelHanna I guess first thing here is confirmation that this is now a validated bug  - agree? ... Mehr anzeigen

And now it is the 502 again.   {     "viErrorId": "req-cac6a423632c42afb1a880989e5e98bd",     "statusCode": 502,     "errorType": "DEVICE_COMMUNICATION_ERROR",     "message": "DEVICE_COMMUNICATION_ERROR",     "extendedPayload": {         "reason": "INTERNAL_SERVER_ERROR"     } }   @MichaelHanna Is there anything you and the team could do and reveal to make this more obvious ? Secondly ofcourse more resilient, and working 🙂   ... Mehr anzeigen

Q1 is solved, but it still means Q2 is very relevant - right now I am uncomfortable about trusting the warning/error features of the API until this is solved.   Longer story around why did it give the E0 error. The history is that Viessmann back in 2015 confirmed exactly I would be able to machine read(and write) settings from the new boiler. However it was oversold and a Vitocom100 was installed (that is a LON module and hence the boiler was reconfigured under 76 as a LON not LAN anymore). Now this year looking at the progress I took the chance and installed the LAN module again to be able to use the API rather than screen scraping. So I went back and changed the 76 to LAN and installed the module and it worked. Vicare worked again and so did the PyViCare (before 15. july) statistics etc got read out. But the unit started to show the E0 error after a few hours of being turned on, only way to get it removed was to turn it off and then on. Now to day I digged deeper into this and the E0 is a LON issue, and for some reason the 79-register does not get reset and hence the boiler now tries to talk both LAN as configured and LON as registered in a sub-register. I changed it back to LON did a recheck the LON list.. now the LON list is empty. And I am hoping not to see the E0 anymore! 🙂 However as stated still missing the *.errors.* flags and stil showing as workingproperly which was not the same as teh display says so looking forward to a response on that. @MichaelHanna I hope you are still having a look at the fact the device is not telling about errors. HOpe you have some news on this soon 🙂   ... Mehr anzeigen

@thetrueavatar I have to agree with you, either a proper openapi spec would be good - and expected anno 2021.   As some has already stated since Viessmann seems to be using mqtt anyway. Why not plan on giving the option to configure a local mqtt server in parallel to what you are already using Viessmann? If the concern is "security" I would suggest to set a hop-count to ensure it would only be local TCP packages, then this should not be to complicated you could even have the workflow to set it up on the developer portal rather than on the display if you like.... @MichaelHanna what would it take for making this consideration? The effort should be small on you and still safe... it would save all of us a lot of trouble/effort 🙂 ... Mehr anzeigen

@MichaelHanna Sorry the restart has no effect this is a persistent issues. I am pretty sure if you start digging you will see it is in the API gateway. Before the switch to the "new" API I got the numbers... so I know my boiler sends them....   Looking forward to getting the stats 🙂 And thanks for your support.   ... Mehr anzeigen

I am really missing values and errors too. looking forward to have them.   Justification: Valves: When is it dhw heating and circuit heating Errors: Rather see through the API the errors than finding a red flashing light on the heater. I do not expect to look at the heater that often, whereas the API could give me a push notification when needed.   ... Mehr anzeigen

Still does not work, however I now get a 200 with {     "data": {         "success": true,         "reason": "COMMAND_EXECUTION_SUCCESS"     } }   I have not changed a thing so I am guessing it was an "outage" on the API gateway... ?   But the question is still relevant in the sense that the INTERNAL_SERVER_ERROR is that the API gateway error? Or communication to my device? or execution at my device? Some more information would be good in case of these kind of errors going forward. Would that be possible?   ... Mehr anzeigen

@joeH68 you are not alone I have a Vitodens300W as well, and the same issue. @MichaelHanna you asked me to go to the forum so I did, and here you can see it looks like I am not alone something is missing to give the same information that was previously available for the Vitodens300W both in vitodata100 (using a vitocom100), and also the previous API. Looks like something is filtered out (or not added) specifically for Vitodens300W. Viessmann could you kindly have that added please asap 🙂   -Jørgen ... Mehr anzeigen