No response in home app when car is asleep

[sarg3nt]

I'm a little confused on how this is supposed to work. I've installed everything with the simple goal of wanting to be able to start the climate control with Siri, however, when my Model 3 is asleep siri replies within a couple seconds that it is not responding. The "Time in minutes to wait . . " settings seems to not affect this at all. The Switch in the home app also says "not responding". If I go into the Tesla app and let the car wake up, then go back to the home app, it is now responding. Is this a bug or am I missing something?

I have the plugin set to run as its own bridge. Here are my settings minus the vin and key of course, nothing special.

{
    "name": "Model 3",
    "vin": "<redacted>",
    "refreshToken": "<redacted>",
    "waitMinutes": 2,
    "sentryModeSwitch": true,
    "_bridge": {
        "username": "<redacted, though I don't know what this mac address looking thing is>",
        "port": 33845
    },
    "accessory": "Tesla"
}

I've tried removing the bridge from the home app and re-adding it, same results. What am I missing?

[nfarina]

So there are some fundamental limitations of HomeKit that this (and all) plugins have to contend with. The one you’re running into here is that “Siri” (HomeKit) only allows accessories 10 seconds to respond to any command.

That means that, more often than not, when you ask Siri to warm up the car, it will respond with “The Model XYZ is taking a while to respond” because the car almost never wakes up within 10 seconds.

Meanwhile, the command will most likely eventually go through! Because the plugin itself will wait as long as you’d like before giving up - this is the timeout setting in the config. But Siri won’t “know” about it because it’s moved on.

[sarg3nt]

Ahh, gotcha @nfarina, that makes sense. Have you thought of using a local state machine? Cloud services that talk to IoT devices tend to use state machines to solve this very problem. It complicates things a bit on the code side but would drastically improve the user experience and solve the "The device is not responding" issues in the Home app and with Siri.

There are a ton of resources online that will give you the basics of state machines if you are not familiar with them already but in a nutshell, here's what I'm thinking.

1. Set up local in memory variables that will hold the last known value (state) of each object. For example, one var would be the last known state of the HVAC system, another the state of the door locks, etc. You can use a backing store to save these values to local storage if you want to avoid waking the car when HomeBridge restarts.
2. When HomeKit sends a command to the plugin, to say, unlock the doors, the plugin changes the state of local var (state machine) and immediately returns success/fail on the state change back to HomeKit / Siri. Then the plugin calls the Tesla API to sync the local state with car. If this fails, you have a retry loop until your timeout. If you are still in a fail state after the timeout, you revert the local state to the previous state and report an error to HomeKit (if that is a thing, sounds like it might not be for voice commands)
3. The Home UI will be a little tricky as you need to show the state of the local state machine which will not always match the actual state, such as cabin temperature if the vehicle is asleep. I wouldn't worry about this for a first release of a state machine version. If there is a way to tell the home app to display an updating status with the last known state, that would be ideal, but not necessary. You'll have to be careful with this as you don't want to wake the car up each time the user opens the home app.

Note: You might be able to use a pre-existing library, but I don't know if that would be more complicated for you or less

Does that make sense? What are your thoughts?

[TeslaOwnerTips]

@dsargent3220 see if the TeslaFi plugin works for you. TheslaFi acts as a buffer. homebridge-teslafi by loftux_peter

[nfarina]

So I've been thinking about this quite a lot. From early on, I didn't want HomeKit to show you "wrong" data, which is why I never kept any internal "last known" state for the car (this is the state machine you describe). So I preferred the Home app to show you "error" states if it didn't know for sure that the car was unlocked, for instance.

Similarly, if you tell Siri to turn on the climate, and it takes too long to wake up the car (which is nearly always), I preferred Siri to timeout and say "I'm sorry, I'm having trouble connecting" instead of just accepting the command immediately and pretending it worked.

However. After using this plugin for quite a while, I find the current behavior just kind of irritating. It's annoying to have the car nearly always shown as the "no response" error state in the Home app. And every time I tell Siri to turn the climate on, she comes back 10 seconds later with "I'm sorry". Even though the command nearly always works.

This behavior is technically "correct" because we never lie to you about the car's state, but it's also just a lousy user experience.

So I'm contemplating changing it to be more like you describe. You tell Siri to turn the climate on, and we just say "ok it's on!" and show it as "on" in the Home app, until we eventually hear back from the API and decide otherwise. And perhaps we could have some default fallback if it's been too long since we heard from the car - like, we default to showing the car as locked unless we've heard otherwise in the last hour or something.

Would this be better overall? It would require a lot of reworking to do well, so want to make sure it's the right path forward.

[TeslaOwnerTips]

Moved this comment to #90

[sarg3nt]

That sounds great to me and I think would be worth the effort. In the Home app, would the reported values eventually update once the API comes back with the newest real data after the car wakes up? If so, I think that is fine. Users would just have to learn that if the car was asleep the data might be old.

On Mon, Jan 24, 2022 at 5:09 PM Nick Farina @.***> wrote:

So I've been thinking about this quite a lot. From early on, I didn't want HomeKit to show you "wrong" data, which is why I never kept any internal "last known" state for the car (this is the state machine you describe). So I preferred for the Home to show you "error" states if it didn't know for sure that the car was unlocked, for instance.

Similarly, if you tell Siri to turn on the climate, if it takes too long to wake up the car, I preferred Siri to timeout and say "I'm sorry, I'm having trouble connecting" instead of just accepting the command immediately and pretending it worked.

However. After using this plugin for quite a while, I find the current behavior just kind of irritating. It's annoying to have the car nearly always shown as the "no response" error state in the Home app. And every time I tell Siri to turn the climate on, she comes back 10 seconds later with "I'm sorry". Even though the command nearly always works.

This behavior is technically "correct" because we never lie to you about the car's state, but it's also just a lousy user experience.

So I'm contemplating changing it to be more like you describe. You tell Siri to turn the climate on, and we just say "ok it's on!" and show it as "on" in the Home app, until we eventually hear back from the API and decide otherwise. And perhaps we could have some default fallback if it's been too long since we heard from the car - like, we default to showing the car as locked unless we've heard otherwise in the last hour or something.

Would this be better overall? It would require a lot of reworking to do well, so want to make sure it's the right path forward.

— Reply to this email directly, view it on GitHub https://github.com/nfarina/homebridge-tesla/issues/85#issuecomment-1020707663, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZXLRVPRXPHNSRJXNKJ2A3UXXZ57ANCNFSM5KPGZUIA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

-- David L. Sargent @.***

"I shall be telling this with a sigh Somewhere ages and ages hence: Two roads diverged in a wood, and I -- I took the one less traveled by, And that has made all the difference." -Frost

[TeslaOwnerTips]

moved comment to #90

[TeslaOwnerTips]

Moved to #90

[deepin125]

I agree, every time I have asked Siri to turn on my car's climate it has worked, but it always makes me sad that she says things are unresponsive and also it confuses my wife. lolz

[nfarina]

I spent the weekend rewriting this plugin and it should no longer give a "no response". It caches the vehicle state and updates all services automatically anytime the state is successfully refreshed.

Would appreciate any testing and feedback! sudo npm install --global homebridge-tesla@beta

[nfarina]

Note that the configuration options have changed - I haven't updated the README yet but config.schema.json should reflect everything new.