openhab-addons
openhab-addons copied to clipboard
openhab
[tesla] Options to control polling frequency and sleep
Signed-off-by: bill [email protected]
[ tesla ] Options to control polling frequency and sleep mode
Description
These are just some changes to the polling that have been useful to me All of the changes in this PR have no effect on the binding unless the new options are set by the user. The new options are only exposed for the Model 3 but I would expect them to work in the others (I can only test on mine).
The current binding looks at geographic position to determine inactivity and does not consider other states to infer that the fast/slow state jobs should be continued (user in vehicle, dog mode, climate keep, camp, sentry etc...), albeit at a slower rate. All those should indicate the car is not going offline and the binding should continue to poll so that it does not miss any updates.
The current binding only gives 5 minutes before going into backoff mode to allow the vehicle to sleep. Often I take a short trip to the store and I come back to the car after 10 minutes and the binding does not know what is happening because the car has been stationary for more than 5 minutes. This 5 minute constant has been broken out into a binding parameter in case the user wants to adjust it. In the past I used the car position returned by the binding to trigger automation to disable and enable my alarm so I'de prefer a better probability of having reliable information from it.
In summary here are the specific additions:
- allow user to specify a threshold in seconds for inactivity when away from the house (homelink unavailable) and the resulting polling backoff that promotes sleeping The default is 5 minutes (current hardcoded setting). It will always be 5 minutes if the car is at home (homelink available) no matter what. This could give the user more time without missing updates if they take the car on short trips to the store. The parameter could better be named "Let me go to store for X minutes without missing updates when I get back"
- add a new flag to allow the binding to keep polling under the certain condtions described below. Defaults to false (current behavior)
- add "is_user_present" from the vehicle state and optionally allow binding to continue the polling at a slower rate if the vehicle is occupied and not in gear.
- if any "center_display_state" is not zero (modes: camp, dog, keep, sentry) optionally continue the polling at a slower rate because the car is not going to sleep
- add sentry state to the binding and make a decision to continue slower polling if this is on
- add new hardcoded timeout of 30 minutes for all the new "continue fastpoll" options above except camp/dog/climatekeep, after which the behavior is the same as before. The assumption being that the user is going to come back to the car when in one of these modes.
- allow user to optionally use the Drive State to determine inactivity rather than the location. Maybe this provides no added benefit but it works, and is a different approach than waiting for the gps to stabilize. Drivestate comesfrom the API and is used by other software to back off. In my case letting it use GPS results in the following occasionally:
28-Aug-2022 21:55:51.474 [DEBUG] [binding.tesla.internal.handler.TeslaVehicleHandler] - Calling parseAndUpdate from main Vehicle loop.
28-Aug-2022 21:55:51.476 [DEBUG] [binding.tesla.internal.handler.TeslaVehicleHandler] - Vehicle state is online
28-Aug-2022 21:55:51.477 [DEBUG] [binding.tesla.internal.handler.TeslaVehicleHandler] - Car is at home. Movemement threshold defaults to 5 min.
28-Aug-2022 21:55:51.477 [DEBUG] [binding.tesla.internal.handler.TeslaVehicleHandler] - Car has moved recently and can not sleep
28-Aug-2022 21:55:51.479 [DEBUG] [binding.tesla.internal.handler.TeslaVehicleHandler] - allowQuery set. Polling for charge, climate, gui, and mobile.
But the car has not moved. It has been sitting there. In my garage perhaps the gps is not as reliable and it bounces around too much. In any event this new flag/parameter breaks nothing and defaults to gps so there is no change unless somebody goes out of their way to set it. I think it is at least worth making available as an option to expirement with. Other web sites that use the API use this method to backoff.
I also commented out the parseAndUpdate() under queryVehicleAndUpdate() because I don't understand what it was doing. queryVehicle() calls parseAndUpdate(), so it seemed to be doing duplicate polling. This is probably my mistake but I didn't understand it correctly. Nevertheless commenting it out hasn't created an issue for me.
Thing example (everthhing default to current binding behavior. Inactivity 5 minutes, no drive state used for inactivity, and no console modes used to keep polling.)
Thing tesla:model3:car1 "Tesla Model 3" (tesla:account:bill) [ vin="XXXX" ]
Thing example (the way I drive):
Thing tesla:model3:car1 "Tesla Model 3" (tesla:account:bill) [ vin="XXXX" , inactivity=25, useDriveState=true, useAdvancedStatesForPolling=true ]
Testing
I can only test this on the model3. It probably works on other models. I can add the parameters to the other models if you want.
@kgoderis let me know if you don't want this or if the work in 13116 are going to make merging it difficult. I will just continue to maintain as patches.
In any event, the delay settings should be adjustable for short trips and some better intelligence around polling: see https://github.com/alandtse/tesla/wiki/Polling-policy for methods.
This pull request has been mentioned on openHAB Community. There might be relevant details there:
https://community.openhab.org/t/tesla-items-not-updated-after-some-time/138374/18
@kgoderis let me know if you don't want this or if the work in 13116 are going to make merging it difficult. I will just continue to maintain as patches.
@kgoderis : your feedback would be welcome.
By the way, this PR has now conflicted files, so @billfor you will have to fix them, in case this PR is not abandoned.
@billfor I only saw this PR now (through @lolodomo's comment) - If @kgoderis does not find the time to test/review/comment, I'm happy to do so! The additions all seem to make sense. Could you please rebase your PR, so that I can test it on the latest code base?
@kaikreuzer I will rebase it to main. Do you want me to expose these new options for models other than the "3". I can only test the 3 myself but I don't have any reason to believe it wouldn't work on the others.
@billfor Yes, we should add it to all models as I also think it will behave the same for all - after all, we are talking only to a cloud service and not to the cars directly. But it is ok if you leave it for the model 3 for the start - in case I have review comments, you then would only have to apply them once and copy the final result for the other models afterwards.
Thank you for all those! I have made all the changes and extended the new parameters to the other models. I made allowWakeup advanced but was not sure if you wanted allowWakeupForCommands to be advanced also, so I left it alone.
Many thanks, looks good like this! I was just almost pressing the merge button when I noticed that we still need to update the documentation as well. Could you be so kind and document these new config parameters in the README file, so that they end up in the official docs?
Sure. I didn't write the enableEvents. @kgoderis did you want me to add it? Also let me know if you want me to update the demo.items and demo.sitemap, since the one I use seems to have more stuff in it (attached).
tesla.items.txt tesla.sitemap.txt
Would be great if you could add all the missing parameters (I think I also missed to add allowWakeupForCommands at the time to the docs 🙄). Possibly it is time to move from prosa text to a small table to describe the params.
And yes: Feel free to also enhance the examples - this is imho always helpful for users!
I fixed the math for the expiration of the access token and added additional logging around tokens in general, in case it might help troubleshoot those folks that have been complaining that the binding times out after refreshing the token. At least the logs will make more sense. I can't seem to find the build artifact for this in jfrog but if is is not thrown away then it might be helpful for the people that have issues. All the documentation is updated as well btw.
I started playing with the binding few days back and I figured that the constants could be moved as bridge settings. Good that you're already onto it and I see also you will cover some new use cases. Great addition to the binding. Thanks a lot !
The math change that I buried in the last commit could be important. The existing logic does not calculate the expiration time on the access token properly. In some cases if the binding gets an intermittent error in the 8hr window it will look at the date and refresh even though it doesn't need to be renewed. With several people complaining about the refresh not working, it would be good to give this fix to them to try, but I don't see that the CI pipeline builds store the build for the PR anywhere, so I guess they can't test until this is merged. I agree maybe everything could be put into the bridge as long as you weren't expecting that to control a non-car like solar walls, etc...