Missing access points.

[nerixs]

Hello to all the community,

It's official, on July 15, 2021, access to the old API keys will no longer be possible.
Some data points that were accessible through the old API client are not accessible through the new API client, including:

heating*burner*modulation
heating*burner*automatic
heating*burner*statistics (hours) and (starts)

heating*circuits*N*heating*curve (shift) and (slope)

heating*gas*consumption*dhw (total), (year), (month), (week) and (day)
heating*gas*consumption*heating (total), (year), (month), (week) and (day)
heating*power*consumption (total), (year), (month), (week) and (day)

Can we hope to see them added?
All the clients that I have tried use them.
Best regards

[nerixs]

Entry points that could be added:

Error entries and maintenance period (activeMonthSinceLastService, serviceIntervalMonths, lastService).

[phildaub23]

Also:
heating.solar.power.production
which is only one single number but the most important one for the solarthermic system.

[MichaelHanna]

Hi @nerixs ,

Please find my answer to this topic in the related thread: https://www.viessmann-community.com/t5/The-Viessmann-API/Fehlende-Datenpunkte/m-p/180340#M20

@phildaub23 , the respond to your specific request you can find here: https://www.viessmann-community.com/t5/The-Viessmann-API/API-Datenpunkt-Solarthermie-Energieprodukti...

[nerixs]

Hello @MichaelHanna,
Your answer does not answer our question.
You will cut off access to third-party customers on July 15.
The few access points mentioned above are requested by most home automation application users (Jeedom, Home Assistant, Domoticz, openHAB, Mozilla WebThings Gateway, etc.).
Will these points be available by July 15th?
If not, will they be one day and within what time frame?
If not, should we start working on a local processing solution via the different communication buses?
Sincerely

[upset]

"If not, should we start working on a local processing solution via the different communication buses?"

Right question!

[MichaelHanna]

Hi @nerixs @upset ,

about the "missing" data points compared to the old / unauthorized client, we are happy to receive your feedback and are currently working on a solution to support you on your requests. I hope you and the other developers / API enthusiasts can have a bit more patience.

However, pressuring with using on local processing solutions is what I believe not the right approach. We are aware that there are other solutions available that work directly via the communication buses. But please be aware that is not supported by us, whereas with the API, we want to provide an authorized, supported and secure way of system integration.

So, let's work together on a great developer and API experience 🙂

[upset]

Okay, thank you for the info! I be patient.. by the way.. i don't like the term "unauthorized client" ...
This term creates an invisible border between the smart users, that are able to understand the system and create sth. new, and Viessmann..
i prefer "not considered client"..

[MichaelHanna]

@upset I appreciate your feedback! That was not the intention with the formulation of "unauthorized". But I like your formulation and will consider it 🙂

[nerixs]

Hello @MichaelHanna ,
You are asking us to be patient, but it was you, “Viessmann”, who gave an ultimatum on July 15.
Why close something that satisfies many users before bringing alternatives?
The loss of interest of the api in comparison to what we were exploiting on the bakend Vicare is consequent.
We expected a lot from this API, including adherence to the openapi/swagger standard and ease of use for the end user by relying on the yaml open API.
We agree, everyone hopes that the API will meet our needs and a good collaboration with Viessmann, provide a system integration means «authorized», supported and secure is honorable, But our boilers are ours and it’s frustrating that we can’t use the data we have.
Sincerely

[MichaelHanna]

Hi @nerixs ,

as already mentioned in my other post, 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.

Best,

Michael

[phildaub23]

@MichaelHanna yay thats very good news! Thanks a lot guys for the quick reaction to the needs of your customers!

[nerixs]

Hello @MichaelHanna,

Thanks for the additions.

Give you meaning in the use of our data, a guarantee of performance, savings and longevity.

You added "heating.power.consumption", but forgot to document it under IoT => Data points.

I have one last request:

Maintenance information.

"heating.service.timeBased: activeMonthSinceLastService, serviceIntervalMonths, lastService, serviceDue"

The display of error messages.

"heating.errors.active: ErrorListChanges"

"heating.errors.history: ErrorListChanges"

Thank you again for this work.

cordially

[SebHH]

Dear Viessmann team,

Dear Michael,

i was forced to switch to the new API today and have to notice that there really is no relevant data for VITOVALOR - kind of liturally nothing... not even the operating status

hopefully I can help the team to determine most relevant data points:

heating.fuelCell.operating.phase.value

--> essential...

other values I have been finding extremyl valuable in the past have been:

heating.fuelCell.statistics.operationHours

heating.fuelCell.statistics.productionHours

heating.fuelCell.statistics.productionStarts

heating.fuelCell.power.production.month

heating.gas.consumption.fuelCell.month

--> I noticed you made gas consumption available for water and heating on heating systems... thank you!

heating.power.production.current.value

--> showing the current wattage of power being generated

heating.fuelCell.sensors.temperature.return.value

--> key value for vitovalor as it determines if the fuelcell can work or not based on 50°C being reached

heating.fuelCell.sensors.temperature.supply.value

also what has been very insightful is total consumption of my house:

heating.power.purchase.current.value

heating.power.sold.current.value

in terms of values for the heating system, most values I have been utilizing do already exist - THANK YOU

I would additionally be looking for (with priority in order of my list)

heating.sensors.pressure.supply.value

heating.circuits.0.sensors.temperature.supply.status

Thanks and looking forward!

Sebastian

[SebHH]

@MichaelHanna - would you have any insight on the plan to address the missing data points?

[MichaelHanna]

Hello @SebHH ,

thanks for the patience and sharing your case!

We are still in the trial / initial stage with the public API. Therefore, individual systems, such as fuel cells, are not yet supported by this.

We do not plan to make all the features that were available before the public API available again in the same form and without a clear purpose. However, your list helps us identifying the need more precisely. I'm happy to take your request for additional features, even though for the time being, I cannot tell you if/how additional features will be made available.

@nerixs , for errors and other events, you can check our "Events" endpoint, which is documented here: https://developer.viessmann.com/en/doc/events-mw-iot/v1

Best regards,

Michael

[nerixs]

Hi, @MichaelHanna
I don't see where I didn't understand how with the "Events" endpoint I could retrieve the information related to :
"heating.errors.active: ErrorListChanges"
"heating.errors.history: ErrorListChanges"
Can you please elaborate or give an example?
Sincerely

[MichaelHanna]

@nerixs ,

if you use the endpoint https://api.viessmann.com/iot/v1/events-history/events?gatewaySerial={{gatewaySerial}}&eventType=dev..., you will get a response similar to this:

{
    "data": [
        {
            "eventType": "device-error",
            "gatewaySerial": "{{gatewaySerial}}",
            "body": {
                "errorCode": "05",
                "deviceId": "0",
                "modelId": "CU401B_S",
                "active": false,
                "equipmentType": "Boiler",
                "errorEventType": "Error",
                "errorDescription": "Fault EEV"
            },
            "createdAt": "2019-09-19T08:40:42.807Z",
            "eventTimestamp": "2019-09-19T08:40:27.000Z",
            "editedBy": "system",
            "origin": null
        },
        {
            "eventType": "device-error",
            "gatewaySerial": "{{gatewaySerial}}",
            "body": {
                "errorCode": "05",
                "deviceId": "0",
                "modelId": "CU401B_S",
                "active": true,
                "equipmentType": "Boiler",
                "errorEventType": "Error",
                "errorDescription": "Fault EEV"
            },
            "createdAt": "2019-09-19T08:40:15.038Z",
            "eventTimestamp": "2019-09-19T08:39:59.000Z",
            "editedBy": "system",
            "origin": null
        }
    ],
    "cursor": {
        "next": ""
    }
}

Notice that I filtered the response by eventType = device-error to only receive specific events. You receive the errorCode and the attribute "active" determines an an active or not active error. As the same error (05) was first active and then changed to not active, this shows that the error has been solved.

For further infos please check the documentation: https://developer.viessmann.com/en/doc/events-mw-iot/v1

[nerixs]

Hello @MichaelHanna,

Thanks for the example with the events-history endpoint, it works.

The downside with Event is that it generates an extra call to APIs.

Can we retrieve the maintenance information?

"heating.service.timeBased: activeMonthSinceLastService, serviceIntervalMonths, lastService, serviceDue"

In France, the legislation requires that the boilers be checked every year (12 months).

This information is very useful and allows you to anticipate an appointment, and to find the date of the last interview quickly.

If Event does not allow it, adding features is hoped for.

[nerixs]

Hello @MichaelHanna,

Can you give us an answer regarding the maintenance data?

Does the eventType: device_message_service work in this direction?

Best regards