Health = Problem

[MadsBen]

Hi

I'm using the integration for my Skoda Octavia. A couple of weeks ago, the "Health" entitlement started to report "problem". I got no warning lights or issues reported by the car or the "MinSkoda" app.
I have enabled debug logging for this and can see this in the "Got vehicle data" call:
"health": {"ok": false, "recommendation": null}

[jnxxx]

Hi

With this info it seems like the API reports the health is not ok.
The inverted value of OK is translated directly to the Health sensor.
The recommendation seems to be deprecated, and probably the reason it has no content.

I cannot say why the API reports false.
The integration also reads some lampStates. How many and which depends on the type of car. These are also represented by a binary_sensor, but you will have to enable them yourself (or find it in the JSON debug data). I included these just in case they could give a clue in such a case.
The ones reported by my car are not so interesting though.

Instead on the recommendation it seems there is now some lead information under health.
Mine report null though, so I have no idea what it can report here.

If you want to experiment with the API, you try it here: API Explorer
For example starting out with a query like this:

query HealthTest {
  viewer {
    vehicles {
      primary
      vehicle {
        health {
          ok
          recommendation
          lead {
            severityScore
            type            
            status
          }
        }
        lampStates{
          type
          time
          enabled
          source
          lampDetails {
            title
            subtitle
          }
        }
      }
    }
  }
}

[jnxxx]

What is the service status?
I believe mine lit up last time it was up for service.

[MadsBen]

What is the service status?
I believe mine lit up last time it was up for service.

It had service about 4 weeks ago, as I recall it was before the "service" warning appeared in the car. Could be that the service timer has not been reset in the backend. In the MinSkoda app, the countdown till next service is correct.

I will try to fiddle around with the API or maybe contact connectedcars.io.

[Kjagd]

Hi, in general you should rely on leads now.
For example for service you could pull something like this:

  vehicle {
    leads(types: [service_reminder]) {
      id
      status
      dismissed
      context {
        ... on LeadServiceReminderContext {
          serviceDate
          sourceData {
            type
            value
          }
        }
      }
    }
  }   

Note that pulling leads directly on vehicle will give you a list of all the different leads, and not just the health trigger. (I would recommend this, since health essentially is priority-list of leads, but it's probably more useful to fetch all). See LeadType enum for a list of all the different types, though I don't believe all of them are currently in use. Feel free to ask away.

Best regards Kristian from Connected Cars

[jnxxx]

Thank you @Kjagd.
This is very helpful.

Can I assume there is a relation between these leads and health { ok } status?
Meaning if not ok, is there one or more open leads explaining the cause.
And vice versa, if ok, then there are no open leads.
Or can there be open leads while ok is true?

[jnxxx]

@MadsBen, if you still have the health issue indicated, please try the pre-release v1.1.0.
(redownload if you already had the pre-release)

On the Health sensor, you should now get an additional attribute named Leads.
This will be an array of leads where the state is open.
Ideally it should be empty, but if an issue is indicated there may be one or more.

I did not have any currently open leads, but for testing purposes I made it temporarily list the historic ones.
These are some examples of leads it can show:

Leads:
  - type: error_code
    createdTime: '2023-07-30T14:54:33.000Z'
    updatedTime: '2023-08-24T18:09:26.000Z'
    severityScore: 10
    context:
      errorCode: U113800
      ecu: central_electrics
      provider: VAG
      errorCodeCount: 16
      description: Sensor for Anti-Theft Alarm System - Implausible Message
  - type: service_reminder
    createdTime: '2023-04-09T00:02:51.000Z'
    updatedTime: '2023-04-27T12:20:43.000Z'
    bookingTime: '2023-05-11T00:00:00.000Z'
    lastContactedTime: '2023-04-25T07:00:09.000Z'
    severityScore: 10
    value: 5000 DKK
    context:
      serviceDate: '2023-05-09T00:00:00.000Z'
      oilEstimateUncertain: false
      interval_service_days: '2023-05-09T00:00:00.000Z'
  - type: poor_battery
    createdTime: '2022-07-22T02:15:15.000Z'
    updatedTime: '2022-07-23T10:05:25.000Z'
    severityScore: 10
    value: 1500 DKK
    context:
      sourceMedianVoltage:
        voltage: 11.947

But as @Kjagd wrote, there are even more types than this, although some might not be used currently.

[MadsBen]

@jnxxx Thanks for the update. I got some leads in there, like this one that might be the culprit.

The next question is then whether this is a "real" warning or a bug. I do not get any warning lights for this in the car or the MinSkoda app. But that's unrelated for this integration. We now have an explanation for the status of the health indicator.

description: Databus - Received Error Message
- type: error_code
  createdTime: '2023-06-20T05:12:12.000Z'
  updatedTime: '2023-09-01T04:43:22.000Z'
  severityScore: 10
  context:
    errorCode: P20EE00
    ecu: engine
    provider: VAG
    errorCodeCount: 193
    description: NOx Catalyst Efficiency Below Threshold Bank 1

[Kjagd]

@jnxxx Yes, it sounds like your understanding of health is good. But I would like to point out that we are not really using health ourself, since as we support more leads it would often happen that even a minor lead would make health not ok.

@MadsBen Looks like a real warning, but error codes are something which is quite normal to get, and will most likely not trigger a lamp in the car itself. Currently, only lamp_engine_lamp should accurately match a lamp seen. So Error codes is not something we show to the app users, since there is a lot of harmless warnings, and it's not useful to make users scared or contacting the workshop about them. But they can be useful for the workshop to look at, if something is actually wrong.

[jnxxx]

Yeah, I was thinking it might be a bit too sensitive to let it light up in case of a service reminder, as it is after all something planned and not a health issue.
Now with this data available I consider making it controlled by open leads of one or more types.
Perhaps lamp_* or error_code_high.

[Kjagd]

Sounds good, I would add the poor_battery as well, that's a quite useful one :)

[jnxxx]

@MadsBen, there is now a version 1.1.1 which sets health state based on the leads above a certain severity threshold.

You can configure how sensitive you want it to be:

It is based on the assumption that the type string in the response, will be the same values as in the request type filter.
If mistaken, it will have to be adjusted as examples appear.

[xShteff]

@MadsBen, there is now a version 1.1.1 which sets health state based on the leads above a certain severity threshold.

You can configure how sensitive you want it to be:

It is based on the assumption that the type string in the response, will be the same values as in the request type filter. If mistaken, it will have to be adjusted as examples appear.

I think this is a great addition - as well as seeing exactly what causes the "problem" without jumping into the logs :). I spent a day debugging it as well and could see that it returns null, I assumed it was an issue with the connectedcars.io API (to be fair it did take half a day for it to go away, after clearing the code... it complained of my car key battery being low but it triggered a long overthinking process 🙃)

Just installed the update, I'm enjoying the new values as well, thanks a lot!

[jnxxx]

Closing this as it should be solved with release v1.1.1