New test version 2.1.1:
- Added API error ‘requested’ to whitelist.
@Jan_Penning FYI
If there are further errors, please send me a diagnostics report and (if helpful) a screenshot via PM
1 Like
Without sending commands indeed. I am using a flow to optimise charging costs and usually the charging command is given at the full hour when the hourly price becomes lowest (most often during the night). I noticed in the past week that the time between the moment the charging command is given and the car actually starts charging (checked via the energy use by the Tesla Wall Connector, also connected to Homey) varies; between about 1 and 10 minutes. And also the charging flow does not finish properly.
So this morning I tried to investigate what is happening and found out that the Start Charging card gets the error state but that, after a while, the car does start charging.
The commandAPI is currently not using the error whitelist. It needs another update.
The commendAPI still needs some love 
1 Like
New test version 2.1.2
- Added API error ‘completed’ to whitelist.
- Added whitelist to command API.
@Jan_Penning FYI
3 Likes
Hi @RonnyW !
Sorry for my late answer. It was perfect! Thanks a lot
What again do you need to do if you get an Email that you’re on 80% of the API usage?
And why does the app send hundreds of API calls per day?
Which API calls? Data requests? It depends on your interval settings. If the car is awake, on every interval a data request is done.
Sonif your car is awake the whole day (PV charging) you can increase the unterval to 5 or 10min to save some calls while charging.
Or add a subscription if you need the data.
PS: 80٪ at 26th of the month is in the limit so far.
1 Like
New test version 2.2.0:
- Added commands (commandAPI):
enable/disable schedule charging,
enable/disable scheduled departure,
seat heating control,
climate keeper mode,
media control.
1 Like
Yeah, I meant data requests. Fixed it by adjusting the settings
App crashed after update, had to restart it.
App already started crashing before I updated to the newest version. Is it related to the “reset” of the api call counter at 1AM today, 1st day of new month? Because that is exactly the time where I start to obtain high CPU
Hi Ronny, last week the app has worked perfectly. Charging started and stopped as expected, charging power was adjusted if needed.
Tonight version 2.2.0 was installed and the crashes are back. After restarting the app, the app crashes within a minute.
Anything you need to help debugging?
The current issue is caused by the timeout function in NodeJS. The counter reset timer is too big (1 month) for internally used data type 
And in this case, NodeJS is using a too small standard duration that’s causing the CPU limit crash again.
A fix will come soon…
1 Like
New test version 2.2.1:
- fixes timeout error
Thanks for the quick fix!
Thanks! Problem solved.
The live version is also affected by this issue. The app is in review state.I think it will take time until Monday to get approved.
1 Like
The new version is live.
If auto update takes too long, you can also install from app store again.
It works great here.
Any chances you could add support for opening frunk and trunk?
This option is already present and you need to enable it on your device under settings
