Upgrade 3.0 sentry mode switch missing

[drlauridsen]

After installing the new 3.0 integration, it seems the sentry mode switch is missing?

[shred86]

This is another feature I wasn't able to test unfortunately. Some checks were added to only add the sentry mode switch if the vehicle actually has sentry mode. Is there any chance you would be able to turn on debug logging for teslajsonpy and share the response when the vehicle_data endpoint is called?

To turn on debug logging, in your HA configuration.yaml, you set:

logger:
  default: info
  logs:
    teslajsonpy: debug

Restart HA and open your logs. There's a lot of entries but if you search for "vehicle_data", I'm just looking for the response after that which is going to be a lot of data. It should look something like:

2022-10-22 20:45:49.284 DEBUG (MainThread) [teslajsonpy.connection] 200: {"response":{"id":1... with a bunch of text after.

I'm really just looking for two specific keys, "sentry_mode_available" and "sentry_mode". If you can find those and let me know what their values are set to, that would help.

I made the assumption that "sentry_mode_available" was a key that specifies whether the vehicle has sentry mode because there's another one called "sentry_mode".

[drlauridsen]

It might not be related to the integration at all. Earlier today I had 34 entities, and suddenly four of those were disabled (rear seat heating x3 and sentry mode), so I removed the integration and reinstalled, and had a lot of problems doing that tonight, it failed a lot of times. Then suddenly it finished installing without errors, and I am back to 34 entities, including sentry mode.

I have had some issues with connecting to the car tonight, one time it said 403 error, and an update that was being downloaded earlier today, suddenly disappeared, so maybe Tesla servers has some issues?

Lets put this issue on hold for a day or two, and see if it is resolved..

I will however hijack my own thread and ask for something a little bit related..😀 In version 2.x there was a Max range switch (setting charge to 100%), has this been removed?

[alandtse]

I think the key detection is fine. I think the issue is that random entities break and we're not cleanly accounting for that. I also had to remove and readd to re-enable my sentry and some of my seat heaters. I didn't have logging enabled, but if it was a 403 or or other error, we should gracefully handle that state and create the entity if it ever appears.

[shred86]

I will however hijack my own thread and ask for something a little bit related..😀 In version 2.x there was a Max range switch (setting charge to 100%), has this been removed?

Yeah there's no max range switch anymore but you should be able to just use the charger numbers entity and set it to 100%.

[shred86]

I think the key detection is fine. I think the issue is that random entities break and we're not cleanly accounting for that. I also had to remove and readd to re-enable my sentry and some of my seat heaters. I didn't have logging enabled, but if it was a 403 or or other error, we should gracefully handle that state and create the entity if it ever appears.

I'm thinking if we implement the idea of storing the data we get from the endpoint to a JSON file and just reference that when the car is asleep, connection issues, etc., it might resolve a lot of these issues. It would also fix the issue of not being able to restore the previous state after a restart.

[alandtse]

I'm not a fan of using out of band storage. If this is important, use what HA already has with recoverable state. It's simply a base class switch.

[purcell-lab]

I can confirm the sentry mode switch is functional for me with V3.

[drlauridsen]

I think the key detection is fine. I think the issue is that random entities break and we're not cleanly accounting for that. I also had to remove and readd to re-enable my sentry and some of my seat heaters. I didn't have logging enabled, but if it was a 403 or or other error, we should gracefully handle that state and create the entity if it ever appears.

I think you are spot on here.. 🙂 I am now back to all 34 original entities (with V3). Yesterday, when having connection issues also with Tesla App, it was suddenly 30, then 33, and today the last one showed up again (software update sensor).

[TheDK]

I can confirm I was missing four entities including rear seat heaters and sentry mode. After reloading the integration several times while driving and parked online with sentry active the entities appeared (total of 34). Here it seems that another logic for detecting these might be helpful (maybe static depending on the model?). I will monitor for stability...

[tmenguy]

Same here but I have it with sentry, homelink, in addition to the 3 rear seat heating. It is working sometimes, sometimes not ...very strange

[TheDK]

Just did a restart of HA, I’d say 30-40% of all entities are unavailable. Let’s see if they come back when the car wakes up by themselves or if a reload will be necessary…

[carleeno]

Same here, when the car goes asleep (offline), the sentry mode, homelink, and rear seat heaters become unavailable. When I wake the car with the app (turning sentry mode on), those entities remain unavailable until I reload the integration.

This is especially unfortunate with homelink and sentry, as you should be able to use them when the car is asleep as they send a wake first.

[tmenguy]

Ok so we have a common theme, perhaps at start of the integration (or HA reboot) a car wake up should be forced? I'll try to manually wake the car just before an HA reboot to see

[tmenguy]

ok tried again, all entities are ok if I wake up the car before I restart HA ( and so the Tesla integration)

[shred86]

Yeah, this is an issue because if the car is asleep and the integration is initialized, it’s unable to obtain the JSON response data from the vehicle data endpoint. Some of the keys we’re using to check whether or not a vehicle has a device is in the vehicle data endpoint, so without that data, the entities are not created which is causing this issue.

Originally, I had it setup where the vehicle is always woken up on HA restart but some users apparently restart HA a lot and didn’t want the integration waking up their vehicles on start (unnecessary use of energy). So by default, it only wakes up the vehicle when the integration is first added and does not when it’s re-initialized (i.e. HA reboot). There is an option, however, to force the vehicle to be woken up on re-initialization in the integration configuration options.

Ideally, we could use different keys like options codes which comes from an endpoint that we always have access to, whether the vehicle is awake or asleep. The problem is the option codes are apparently no longer accurate, so we’re kind of stuck. The other option would be to just create every entity for every vehicle, but now you have entities for vehicles that are not valid.

[tmenguy]

What is interesting for all those missing entities : they depend on a check the "car" object to be setup at startup: -rear seats:

            if "rear" in seat_name and not car.rear_seat_heaters:
                continue

-sentry

        if car.sentry_mode_available:
            entities.append(TeslaCarSentryMode(hass, car, coordinator))

-homelink

        if car.homelink_device_count:
            entities.append(TeslaCarTriggerHomelink(hass, car, coordinator))

to me clearly the car object is not fully initialised when entities are created, so we do miss an await or a block before we create those entities. I do think that this is the same as #297

[tmenguy]

Thanks @shred86 we cross posted :) yes the wake car on start is probably the one I'm looking for to solve this issue ...

[carleeno]

@shred86 While digging through this issue myself I also noticed a couple related suspects in teslajsonpy, notably that the TeslaCar._car dict is never updated after init (which means properties like .state is never updated), and _vehicle_state can be overwritten with an empty dict when generate_car_objects is called multiple times for a given controller (which it seems might be happening).

I finally got a dev HA container running and pointing to my own fork of teslajsonpy so I can play around with this, but I'm hoping the changes I have in mind will fix this issue. If so I'll have a PR for review.

[shred86]

@carleeno TeslaCar._car is coming from the vehicle list endpoint. I thought we were updating that object every time the endpoint is called, but it looks like I may have missed that. We’re definitely pulling from the vehicle list endpoint constantly as this is how we’re determining if the vehicle is online or offline. If we’re grabbing the latest data here, makes sense to just update the Controller._vehicle_list dict.

As for generate_car_objects, that’s only being called when the integration starts. It’s being called from this integration, not within teslajsonpy, so it should only be occurring once on HA start or if you reload the integration. If you’re restarting HA, we’re starting teslajsonpy from scratch so there is no vehicle data yet so it shouldn’t be an issue. However, if you reload the integration (so teslajsonpy hasn’t been “restarted”), then I suppose it would be an issue if the car is asleep. This area definitely needs to be reworked. I think one solution was to use some existing HA functionality that allows you to persist data between restarts.

Unfortunately I haven’t had time to really work on any updates since this was released so there’s definitely a lot of changes/updates that are needed.

[carleeno]

@shred86 thanks yep I realized that it's only being called once after some debug logging. I'm making some progress however, I've fixed the rear seat heater availability by updating the dicts in vehicle_list whenever we call the list api, and pointing all references to vehicle_config to self._car.get instead of self._vehicle_data.get since that information persists even when the car is offline.

As for sentry mode, steering wheel, and homelink, those are using values that only exist in _vehicle_data, so I'm looking at using option codes instead for entity creation.

There's another option I'm looking at: in v2 when I added homelink, we always created the homelink entity, but updated the entities available() method dynamically. If we do something like this for these new entities, they would be added and hidden upon first install or reboot if the car is asleep, but if they ever become available later, they'll show up magically without having to reload the integration.

[shred86]

Option codes would be ideal but they are not reliable, according to this Tesla JSON API site. I compared it with my option codes and I found some references to Model 3 related codes when I have a Model S. I’m not sure why Tesla would keep this in their API if it’s bogus data but I haven’t had a chance to look into it further.