Open addisonjames opened 1 year ago
Thanks for reporting this and so sorry you had this experience!
I've been trying to figure out how this could have happened and I still haven't come up with anything. It's normal for the Home app to go and query the current state of all accessories, but it should never write data without explicit request by the user.
Do you have any Automations set up in the Home app?
I'm with you. Yes I have TONS of automations, but 0 related to your plugin or the "Tesla room" I had created. The fact it happened at the exact minute when my router restarted is hard to ignore. Trust me, I understand how weird this sounds lol
No I think it was definitely triggered by the network coming back up! Just not sure what mechanism would cause HomeKit to change a bunch of state without user request - especially secure state that normally requires FaceID or an unlocked Apple Watch (door locks are like this). I'll keep thinking…
If it’s helpful, I do wear an Apple Watch, and I was sitting at my desk with all my devices unlocked.
Well, I’m doubtful it will work, but it would be interesting to see if resetting your router caused this to happen again?
It's not the exact scenario but I named the doors on my MYP to "car doors" and found that saying "hey Siri lock the car doors" had unlocked and opened the doors, trunk and frunk. Since then I haven't tried it out of fear but can do it tomorrow when I'm out of the garage to help.
Hi. I also had a similar experience, where the opposite of my request was executed. I had lock doors and trunk and start sentry mode in a “go to bed” scene, but in fact the trunk opened. Then, running the same scene a 2nd time caused Sentry Mode to be turned off.
I’m looking at the logs now. I see “Opening the Trunk”, “Closing the Trunk” and “Actuating the Trunk”. Does Actuating mean it is opening? It’s a little confusing. @nfarina when you have a moment can you let me know what these log entries mean specifically? I may try to reproduce the issue tonight. I'm starting to wonder if there is some check to see if the door or trunk are already open before issuing the request, which is either incorrect or out of date info causing the plugin to issue the opposite request to Tesla...
Ok, I took a look at the code and the comments make it pretty clear that Tesla has a single "Actuate" function that either opens or closes the lift gate, I guess depending on the current state. Is it possible a response (or API failure) is being misinterpreted as "open" when the trunk/frunk is in fact closed?
Running Homebridge on Pi, with Eero router, plugged in via ethernet. My Eero DNS has always been set to 1.1.1.1, and i was having DNS issues, so I reset my Eero DNS to default. After the internet+Pi came back online, I instantly got notifications from Home.app that my Tesla Trunk and Frunk have been locked/unlocked, 3x over (6 notifications total).
I checked the Tesla app, my trunk was literally open, out in the street in a huge city. Thankfully i noticed right away and nothing bad happened.
I uninstalled the plugin, as it scared the hell out of me and I actually wasn't even using the plugin very much.
This plugin worked great otherwise, hats off to the dev on an awesome concept that generally worked great. Just wanted to pass along the bug.
homebridge-config-ui-x v4.50.2 Node.js Version | v16.16.0
I managed to grab a screenshot of a couple of the notifications (not all of them):
I also looked thru logs, and found a ton of stuff, but no idea if it's relevant. You can see I had it on a child bridge before removing.
[20/01/2023, 10:28:21] [homebridge-tesla] This plugin slows down Homebridge. The read handler for the characteristic 'On' didn't respond at all!. Please check that you properly call the callback! See https://homebridge.io/w/JtMGR for more info.
Many of these logs were repeated 10x in a row, but i only pasted them once.
TeslaJS error while executing "vehicleData": undefined Error response: 408 TeslaJS error while executing "vehicleData": undefined Error response: 540 [20/01/2023, 10:28:21] [Tesla] Vehicle data updated. [20/01/2023, 10:28:21] [Tesla] Vehicle data updated. TeslaJS error while executing "vehicleData": undefined Error response: 408
[20/01/2023, 10:28:30] [Tesla] Tesla reports vehicle is awake. [20/01/2023, 10:28:30] [Tesla] Getting latest vehicle data from Tesla… [20/01/2023, 10:28:31] [Tesla] Vehicle data updated. [20/01/2023, 10:28:37] [Tesla] Tesla reports vehicle is awake. [20/01/2023, 10:28:37] [Tesla] Getting latest vehicle data from Tesla… [20/01/2023, 10:28:38] [Tesla] Vehicle data updated. [20/01/2023, 10:28:50] [Tesla] Tesla reports vehicle is awake. [20/01/2023, 10:28:50] [Tesla] Getting latest vehicle data from Tesla… [20/01/2023, 10:28:53] [homebridge-tesla] This plugin slows down Homebridge. The read handler for the characteristic 'On' was slow to respond! See https://homebridge.io/w/JtMGR for more info.
[20/01/2023, 10:31:32] [Tesla] Tesla reports vehicle is awake. [20/01/2023, 10:31:32] [Tesla] Getting latest vehicle data from Tesla… [20/01/2023, 10:31:32] [Tesla] Vehicle data updated. [20/01/2023, 10:31:47] [Tesla] Tesla reports vehicle is awake. [20/01/2023, 10:31:47] [Tesla] Getting latest vehicle data from Tesla… [20/01/2023, 10:31:49] [Tesla] Vehicle data updated. [20/01/2023, 10:31:49] [SwitchbotBluetoothPlatform] Current power state of the switch is: OFF [20/01/2023, 10:32:55] [Homebridge UI] Changes to config.json saved. [20/01/2023, 10:32:55] [Tesla] Stopping child bridge (will not restart)... [20/01/2023, 10:32:55] Got SIGTERM, shutting down child bridge process... [20/01/2023, 10:33:00] [Tesla] Child bridge process ended