Fehlende Datenpunkte

[andreas13]

Hallo,

ich bin der Autor des FHEM Moduls für die Viessmann API. In der neuen API vermisse ich etliche Datenpunkte, die es in der alten API nocht gegeben hat. Z.B.

• Abgas
• Sensoren
• Brenner (Starts, Modulation, ....)
• Fehlereinträge
• Gas- und Stromverbrauch
• und Heizkurve

Ist es geplant die Datenpunkte auch in der neuen API zur Verfügung zu stellen und wenn ja, wann?

Und noch eine zweite Frage, wird an der Dokumentation der API noch gearbeitet? Gefühlt hat sich an der Dokumentation seit Wochen nichts mehr getan und die Dokumentation ist noch sehr rudimentär, was sehr ärgerlich ist zumal die alte API ja schon bald abgeschaltet werden soll.

Viele Grüße
Andreas

[phildaub23]

Ich schließe mich an, die Datenpunkte für Brennermodulation und -starts sowie Verbrauch wären schon wichtig zu bekommen.

PS: vielleicht könnt ihr auch die Dokumentation der Features etwas prominenter verlinken, ich hab sie zu Anfang gar nicht gefunden. Wen es interessiert die ist hier zu finden:

https://developer.viessmann.com/en/doc/iot

[JueBag]

I'm going to second this request.
I'm missing the statistic datapoints (burner-houres and -starts).
I do not see any logical reasoning for that, those are only values, no commands. There can be no harm to the system.
IMHO the removal of such informations from the API, datapoints that are available using the ViCare App, could drive people to extract such data from the app. And this something Viessmann does not want to happen.

[AndreasP]

Hallo,

ich habe zu diesem Thema schon bei Viessmann via Mail nachgefragt und keine Antwort bekommen.

Ich nutze PyVicare mit einer eigenen Anpassung and die neue API.

Es fehlen die wirklich wichtigen, verbrauchsbezogenen Datenpunkte und auch solche für einen sicheren Betrieb wie z.B der Anlagendruck.

Es fehlen:

device.timeseries      

device.timeseries.monitoringIonization      

device.zigbee      

heating.boiler.sensors.temperature      

heating.burner.demand      

heating.burner.demand.modulation      

heating.burner.demand.temperature      

heating.burner.modulation      

heating.burner.statistics      

heating.burners.0.modulation      

heating.circuits.0.circulation.schedule      

heating.circuits.0.geofencing      

heating.circuits.0.heating.curve      

heating.circuits.0.operating.programs.screedDrying      

heating.circuits.1.geofencing      

heating.circuits.1.heating.curve      

heating.circuits.1.operating.programs.screedDrying      

heating.circuits.2.geofencing      

heating.circuits.2.heating.curve      

heating.circuits.2.operating.programs.screedDrying      

heating.circuits.3.geofencing      

heating.circuits.3.heating.curve      

heating.circuits.3.operating.programs.screedDrying      

heating.configuration.bufferCylinderSize      

heating.configuration.centralHeatingCylinderSize      

heating.configuration.dhwCylinderSize      

heating.configuration.houseHeatingLoad      

heating.configuration.houseLocation      

heating.configuration.houseOrientation      

heating.configuration.regulation      

heating.dhw.pumps      

heating.dhw.sensors.temperature      

heating.errors      

heating.errors.active      

heating.errors.history      

heating.flue      

heating.flue.sensors      

heating.flue.sensors.temperature      

heating.flue.sensors.temperature.main      

heating.gas      

heating.gas.consumption      

heating.gas.consumption.dhw      

heating.gas.consumption.heating      

heating.gas.consumption.summary      

heating.gas.consumption.summary.dhw      

heating.gas.consumption.summary.heating      

heating.gas.consumption.total      

heating.heat      

heating.heat.production      

heating.heat.production.dhw      

heating.heat.production.heating      

heating.heat.production.summary      

heating.heat.production.summary.dhw      

heating.heat.production.summary.heating      

heating.heat.production.total      

heating.power      

heating.power.consumption      

heating.power.consumption.dhw      

heating.power.consumption.heating      

heating.power.consumption.summary      

heating.power.consumption.summary.dhw      

heating.power.consumption.summary.heating      

heating.power.consumption.total      

heating.sensors.pressure      

heating.sensors.pressure.supply      

heating.solar.power      

heating.solar.power.production      

heating.solar.statistics      

heating.solar.summary      

heating.solar.summary.power      

heating.solar.summary.power.production      

heating.valves      

heating.valves.diverter      

heating.valves.diverter.heatDhw

[MichaelHanna]

Hello @andreas13, @JueBag , @AndreasP ,

with the availability of the Developer Portal, we simultaneously look at which features of the API we can make available and in what form. Our API offers various options for obtaining certain data points.

The Developer Portal is ongoing development, you can always state your concrete feedback in the respective section in the developer forum area 🙂

Also, keep in mind that there is a difference between the offering and use of ViCare and the API. We are not planning to 1:1 all functionalities of ViCare through our API.

@AndreasP , your list of features is quite exetensive. As they were only accessible through an unofficial / unauthorized way, we cannot offer the same functionality through the Developer Portal. What would be more interesting is a more concrete explanation of use cases that come with certain functionalities.

To sum it up, the Developer Portal and the offering is in an ongoing development. My recommendation is to first consider the currently available features, however we are happy to take the requests (based on use cases) with us for further investigation.

Best,

Michael

[JueBag]

@MichealHanna
I am missing data points that would allow monitoring/logging how often and how long the burner is on.
With such a history I could see if my used settings for desired HotWaterSupply temperature and desired RoomTemperature are causing unwanted prolonged burnerhoures/ -starts.

[AndreasP]

Thanks for the answer (and the parallel e-mails),

I understand that the developer portal is still under development and the change to new auth methods and registered clients is out of the discussion. I also respect the decision not to allow any local access to the API as other vendors allow. Even the rate limit is something that i can deal with.

What I don't understand is why should there a difference between data points the ViCare app can show to the system owner and the API which seems to be widely used in the "unofficial / unauthorized way". 

Exactly the consumption parameters and burner stats are the most useful data points.

Since i have my new Vitodens300 installed back in May i was always impressed from the stability of your API and the value that it gives to me. Never used the "set" part, only reading data-points.

Please see the attached graphs build with weewx (yes the weather system) using PyVicare showing me the burner for heating and dhw plus the temperature values and consumption. BTW, I'm doing such graphs as well for my photovoltaic system based on a local api (Solarwatt Energy Manager)

 

 

 

 

 

 

[Isi]

Ich kann mich nur anschließen,

Abgastemperatur, Modulation, Brennerstarts und Brennerstunden sind für mich die wichtigsten Daten aus der alten API die jetzt leider fehlen.

Somit ist der Mehrwert einer Visualisierung durch eine Gebäudesteuerung zur Analyse des effektiven Betriebs dahin.

Schade dass die API inhaltlich so verschlechtert wurde dass sie jetzt für mich nutzlos wurde...

[upset]

Ich schließe mich an. Die Abgastemperatur, Brennerlaufzeit/ Modulation wurde von mir ebenfalls verwendet, um das System zu optimieren (Energieeffizienz, Taktung, Laufzeit,..) ..
Die Abgastemperatur ist nach wie vor in der App vorhanden.
Ich sag's ganz ehrlich.. die App ist schön und gut. Aber diese Volatilität und ständiges nachjustieren meiner Lösung an den Viessmann Server führt vermutlich dazu, dass ich nach Ablauf der Garantie auf eine Lokale Lösung umbaue... Eine eigene "Fernwartung" und Push Nachrichten zu programmieren ist ja das geringste Problem.

[prior_philip]

Yes well... Im owner of a Vitocal200S HeatPump and I could send out a list of missing features from V2 API. But I understand that this API is still WIP.

Nevertheless its hard to understand and accept why most important features like "heating.errors.active" or  "setActiveMode" should not be part of public available information.

[AndreasP]

Hi,

just yesterday I changed from the old to the new API in "production".

I think Viessman was hearing our concerns and was putting back some important data points.

Compared to the first look at v2 API the following is back in the game:

heating.burners.0.modulation
heating.burners.0.statistics
heating.circuits.0.heating.curve
heating.circuits.1.heating.curve
heating.circuits.2.heating.curve
heating.circuits.3.heating.curve
heating.gas.consumption.dhw
heating.gas.consumption.heating
heating.power.consumption
heating.solar.power.production

(Under curve you can find slop and shift, under statistics teh hours and starts)

Still missing:

heating.valves

heating.valves.diverter

heating.valves.diverter.heatDhw

(to distinguish between burner is heating or dhw)

heating.sensors.pressure

heating.sensors.pressure.supply

I need to thank MichaelHanna with the hope getting the remaining things back over time.

[nerixs]

Hello @AndreasP,

"heating.power.consumption" is functional? There is no information in the documentation.

Hello @MichealHanna,

Could you have the maintenance information and error message display added?

cordially

[MichaelHanna · Accepted solution]

Hi @AndreasP @nerixs ,

we recently added some features that were missing to the basic version of the API. The information we just shared on the Change Log within the Documentation: https://developer.viessmann.com/de/doc/changelog

This is especially to provide you with a smooth transition switching from the old API client to the Developer Portal with your own personal API keys.

[Isi]

Danke,

Das ist super wie ihr da reagiert habt!

Ich finde das einfach gut wenn man schon so ein Forum hat auch auf die Anforderungen der Mitglieder einzugehen. Da könnte sich manch andere Firma mal was abschauen.

Gruß Isi

[joeH68]

Hi @MichaelHanna ,  I'm new here and good impressed by your fast reaction. Thank you!

Only missing point for me now is   heating.burner.statistics.
It seems replaced by   heating.burners.N.statistics   but that's also missing.

Am I missing something?  thanks

[nerixs]

Example for circuit 0:

- "heating.burners.0.statistics","hours","value"

- "heating.burners.0.statistics","starts","value"

[prior_philip]

Hi Team and @MichaelHanna,

Im requesting system "error messages" and "HeatingRod" status for Vitocal200S.

Thanks and best regards

Oliver

[joeH68]

hi @nerixs, those are exactly the same data points I'm trying (using PyViCare 1.0). This is what I get when using the browser:

https://api.viessmann-platform.io/iot/v1/equipment/installations/xxx/gateways/yyyyyyyyyyyyyy/devices...

{"viErrorId":"req-575990325452489c915ec172c4ec64d9","statusCode":404,"errorType":"FEATURE_NOT_FOUND","message":"FEATURE_NOT_FOUND","extendedPayload":{}}

however the values I'm looking for (#starts, #hours) must be in the API according to the documentation and ViCare App (3.5.0 iOS) is showing them. The Vitodens 300-W was freshed booted for this test.

Additional investigation shows following heating features/components. "burners" is not one of them

https://api.viessmann-platform.io/iot/v1/equipment/installations/xxx/gateways/yyyyyy/devices/0/featu... 

{"data":{"apiVersion":1,"isEnabled":true,"isReady":true,"gatewayId":"yyyyyyyyyyy","feature":"heating","uri":https://api.viessmann-platform.io/iot/v1/equipment/installations/xxx/gateways/yyyyyyyyyyyyyy/devices/0/features/heating,"deviceId":"0","timestamp":"2021-07-22T08:50:50.253Z","properties":{},"commands":{},"components":["boiler","burner","circuits","device","dhw","sensors","solar"]}}

[nerixs]

Hi @joeH68 ,
Your order is good, I get this:

{
    "data": {
        "properties": {},
        "commands": {},
        "components": [
            "boiler",
            "burner",
            "burners",
            "circuits",
            "configuration",
            "device",
            "dhw",
            "operating",
            "sensors",
            "solar"
        ],
        "apiVersion": 1,
        "uri": "https://api.viessmann-platform.io/iot/v1/equipment/installations/xxxxxx/gateways/xxxxxxxxxxxxxxx/devices/0/features/heating",
        "gatewayId": "xxxxxxxxxxxxxxx",
        "feature": "heating",
        "timestamp": "2021-07-10T17:30:45.346Z",
        "isEnabled": true,
        "isReady": true,
        "deviceId": "0"
    }
}​

I can’t tell you any more!

[JueBag]

Please check the used URL, yours starts with:
https://api.viessmann-platform.io
It should start with:
https://api.viessmann.com

I made the same mistake before. 😉

[joeH68]

Hi @JueBag , thanks for the hint. Unfortunately the results are the same:

https://api.viessmann.com/iot/v1/equipment/installations/xxx/gateways/yyyyyyyyyyyyyy/devices/0/featu...

{"data":{"apiVersion":1,"isEnabled":true,"isReady":true,"gatewayId":"yyyyyyyyyyyyyyy","feature":"heating","uri":"https://api.viessmann-platform.io/iot/v1/equipment/installations/xxx/gateways/yyyyyyyyyyyy/devices/0/features/heating","deviceId":"0","timestamp":"2021-07-22T20:39:11.738Z","properties":{},"commands":{},"components":["boiler","burner","circuits","device","dhw","sensors","solar"]}}

I'll open a separate thread for this problem as it seems to be something else. I'm wondering if it has something to do with my registration and the software used at the time. It shows  "registeredAt":"2015-09-30T14:24:17.000Z","updatedAt":"2020-12-28T16:41:34.362Z","aggregatedStatus":"WorksProperly" when queried with   https://api.viessmann.com/iot/v1/equipment/installations

[jborup]

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.

[MichaelHanna]

@jborup, concerning the error messages, you can check our "Events" endpoint, which is documented here: https://developer.viessmann.com/en/doc/events-mw-iot/v1

If you want to know when your system is on dhw only and when it is on dhw and heating, you can use the operating mode features:

heating.circuits.N.operating.modes.active - Shows current active operating mode on the device and provides command to change it.

I do not think that for this, information about valves will be necessary.

[jborup]

@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

[jborup]

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?