Tesla 2.5 binding

billfor · November 14, 2019, 3:18am

Is there a doc on the config of the refactored Tesla binding? I wanted to try testing the 2.5 binding, but couldn’t figure it out easily by looking at the code.

Thanks.

Udo_Hartmann · November 15, 2019, 3:59pm

I would expect that https://www.openhab.org/addons/bindings/tesla/ is the current version (right upper corner… latest version)

Or is there another tesla binding?

hilbrand · November 15, 2019, 4:03pm

There is a pull request pending:

liko · December 16, 2019, 4:40am

I tried the refactored binding with my Model S after upgrading to 2.5 (non-milestone, but stable release). After adding the account via smarthome:tesla login, I received the Tesla Account in my Inbox. After that point, it wouldn’t detect my vehicle. I received an NPE in the log:
15-Dec-2019 22:27:04.250 [ERROR] [binding.tesla.internal.handler.TeslaAccountHandler] - An exception occurred while connecting to the Tesla back-end: ‘null’ java.lang.NullPointerException: null at org.eclipse.smarthome.core.thing.ThingUID.(ThingUID.java:54) ~[?:?] at org.openhab.binding.tesla.internal.discovery.TeslaVehicleDiscoveryService.vehicleFound(TeslaVehicleDiscoveryService.java:87) ~[?:?] at org.openhab.binding.tesla.internal.handler.TeslaAccountHandler.queryVehicles(TeslaAccountHandler.java:227) ~[?:?] at org.openhab.binding.tesla.internal.handler.TeslaAccountHandler.lambda$0(TeslaAccountHandler.java:439) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_232] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:1.8.0_232] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_232] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:1.8.0_232] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]

I’ve deleted the account and retried with the same result. Any ideas? Should I try again with DEBUG on the binding? Would that be useful?

rwes · December 16, 2019, 8:12pm

Just upgraded to 2.5 stable and failed to add my vehicle.
I first deleted the old thing/item and then successfully added the new Tesla Account through the GUI, showing online.

I proceeded by searching for my vehicle, but nothing would show. The console showed the following warning at the moment i started searching:

21:03:51.442 [WARN ] [ommon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.eclipse.smarthome.core.thing.ThingUID.(ThingUID.java:54) ~[?:?]
at org.openhab.binding.tesla.internal.discovery.TeslaVehicleDiscoveryService.vehicleFound(TeslaVehicleDiscoveryService.java:87) ~[?:?]
at org.openhab.binding.tesla.internal.handler.TeslaAccountHandler.queryVehicles(TeslaAccountHandler.java:227) ~[?:?]
at org.openhab.binding.tesla.internal.handler.TeslaAccountHandler.lambda$1(TeslaAccountHandler.java:153) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_232-ea]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_232-ea]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_232-ea]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_232-ea]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232-ea]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232-ea]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232-ea]

Also, trying to manually add the verhicle gives an issue: Paper UI shows twice the model X, but no model S.

Hope you can help. Let me know if you need more logs.

wborn · December 16, 2019, 8:52pm

I think you ran into this issue:

rwes · December 23, 2019, 1:50pm

I am sure i dont have that Cybertruck!
My car is a 2018 model S, so should be recognized without any issues.

Paul_Smedley · April 5, 2020, 6:25am

Hi All,

As some might be aware, I’ve been working on a binding using the local API for the Tesla Powerwall battery. I reached a point today where I figured i might be best using the non-local API, and when thinking about it, realised that that is the API that the tesla binding already uses.

Does anyone have any thoughts on extending the current tesla binding to include Powerwalls as well as Vehicles? I’ll try looking at this over the next few days myself.

Cheers,

Paul

Paul_Smedley · April 9, 2020, 9:21am

Well I’ve started looking at this… Not sure my java is good enough to make TeslaAccountHandler.java generic enough to handle vehicles and powerwalls.

I think the code needs to be adapted to call:
https://owner-api.teslamotors.com
/api/1/products instead of https://owner-api.teslamotors.com
/api/1/vehicles

It looks like for vehicles (Based on the sample responses for https://www.teslaapi.io/products/list & https://www.teslaapi.io/vehicles/list), the response is the same to both, however with the former, it will also list powerwalls that are present in the account.

FWIW: the response here to https://owner-api.teslamotors.com/api/1/products is:
{“response”:[{“energy_site_id”:1234567,“resource_type”:“battery”,“site_name”:"Home Energy Gateway","id":"STEYYYYMMDD-00046","gateway_id":"1118431-01-K--TG1111111111DF","energy_left":8574.210526315788,"total_pack_energy":12010,"percentage_charged":71.39226083526884,"battery_type":"ac_powerwall","backup_capable":true,"battery_power":480,"sync_grid_alert_enabled":true,"breaker_alert_enabled":false}],"count":1}

If someone is able to help me with this, I reckon I can handle creating a TeslaPowerwallHandler.java handler - I already have a skeleton along with a powerwall2.xml to allow create of an item…

Logos · April 10, 2020, 9:04am

@Paul_Smedley

Just tried to install Tesla binding (2.5). There are several issues, I came across:

Whenever I reboot openhab, the binding is not installed any more, I have to reinstall it
the discovery of the refresh token via console does not work (following the lastest documentation)
Textual configuration does not work, I can only do it with paper UI, but this does not seem to be stable. In addition in the documentation there is only textual configuration of the bridge (Tesla account) described, but I receive in the paperui another thing (I guess the car), of which the textual configuration is not described in the documentation

Can anybody help me on that?

Many thanks in advance

dastrix80 · October 21, 2020, 6:56am

Hi All

Is anyone maintaining the binding? it seems to work fairly well.

Although I see these like messages:

17:55:19.440 [WARN ] [core.internal.thing.ThingTypeResource] - Cannot find channel type: tesla:ispreconditioning

thigger · October 24, 2020, 4:34pm

I’m struggling with this binding. It seems to work brilliantly for a few minutes, but when I open the Tesla app on my Android phone I get a message (on the Tesla app) about needing a new authentication token, and the Tesla binding loses connection and stays off.

Any ideas? The Tesla is a lease car so my account is presumably an “authorised account” rather than the owner’s one if that makes any difference. Car is a Model 3.

2020-10-24 17:15:16.265 [ERROR] [ersey.server.ServerRuntime$Responder] - An I/O error has occurred while writing a response message entity to the container output stream. org.glassfish.jersey.server.internal.process.MappableException: org.eclipse.jetty.io.EofException at org.glassfish.jersey.server.internal.MappableExceptionWrapperInterceptor.aroundWriteTo(MappableExceptionWrapperInterceptor.java:92) ~[?:?] at org.glassfish.jersey.message.internal.WriterInterceptorExecutor.proceed(WriterInterceptorExecutor.java:162) ~[bundleFile:?] at org.glassfish.jersey.message.internal.MessageBodyFactory.writeTo(MessageBodyFactory.java:1130) ~[bundleFile:?] at org.glassfish.jersey.server.ServerRuntime$Responder.writeResponse(ServerRuntime.java:711) [bundleFile:?] at org.glassfish.jersey.server.ServerRuntime$Responder.processResponse(ServerRuntime.java:444) [bundleFile:?] at org.glassfish.jersey.server.ServerRuntime$Responder.process(ServerRuntime.java:434) [bundleFile:?] at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:329) [bundleFile:?] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [bundleFile:?] at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [bundleFile:?] at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [bundleFile:?] at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [bundleFile:?] at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [bundleFile:?] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [bundleFile:?] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [bundleFile:?] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [bundleFile:?] at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [bundleFile:?] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [bundleFile:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [bundleFile:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [bundleFile:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [bundleFile:?] at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [bundleFile:?] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813] at java.lang.Thread.run(Thread.java:834) [?:?] Caused by: org.eclipse.jetty.io.EofException at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:283) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:378) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.ChannelEndPoint$3.run(ChannelEndPoint.java:132) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:298) ~[bundleFile:9.4.20.v20190813] ... 6 more Caused by: java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[?:?] at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) ~[?:?] at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:113) ~[?:?] at sun.nio.ch.IOUtil.write(IOUtil.java:58) ~[?:?] at sun.nio.ch.IOUtil.write(IOUtil.java:50) ~[?:?] at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:466) ~[?:?] at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:261) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:422) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.WriteFlusher.completeWrite(WriteFlusher.java:378) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.io.ChannelEndPoint$3.run(ChannelEndPoint.java:132) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) ~[bundleFile:9.4.20.v20190813] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:298) ~[bundleFile:9.4.20.v20190813] ... 6 more 2020-10-24 17:20:10.986 [WARN ] [internal.handler.TeslaVehicleHandler] - Got an unsuccessful result, setting vehicle to offline and will try again 2020-10-24 17:20:10.988 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: java.lang.NullPointerException: null at org.openhab.binding.tesla.internal.handler.TeslaVehicleHandler.checkResponse(TeslaVehicleHandler.java:564) ~[?:?] at org.openhab.binding.tesla.internal.handler.TeslaVehicleHandler.queryVehicle(TeslaVehicleHandler.java:709) ~[?:?] at org.openhab.binding.tesla.internal.handler.TeslaVehicleHandler.queryVehicleAndUpdate(TeslaVehicleHandler.java:737) ~[?:?] at org.openhab.binding.tesla.internal.handler.TeslaVehicleHandler.lambda$0(TeslaVehicleHandler.java:941) ~[?:?] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?] at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?] at java.lang.Thread.run(Thread.java:834) [?:?]

billfor · December 22, 2020, 11:17pm

fyi for whoever takes care of the binding, it looks like the binding occasionally stops scheduling updates after a while:

20-Dec-2020 12:31:08.843 [DEBUG] [binding.tesla.internal.handler.TeslaVehicleHandler] - Querying the vehicle : Response : 408:Request Timeout
20-Dec-2020 12:31:08.846 [WARN ] [binding.tesla.internal.handler.TeslaVehicleHandler] - Got an unsuccessful result, setting vehicle to offline and will try again

It never tries again.

openhab> bundle:list -s | grep -i tesla
244 │ Active │ 80 │ 2.5.10 │ org.openhab.binding.tesla

Restarting the binding fixes it.

billfor · January 10, 2021, 10:57pm

I made a few changes to the binding for 2.5.12, as I haven’t got around to installing 3.0 yet. If anyone thinks these are useful I can try submitting them into 3.0 if that’s allowed.

The changes are:

Don’t unnecessarily check for inactivity if the vehicle is asleep, because it is already asleep. Just exit the query request immediately.
For model 3, allow the user to change the interval during which the car is allowed to remain alive (see below).
For model 3, allow the user to use drivestate to determine inactivity, instead of location.
If homelink is available, use the default interval MOVE_THRESHOLD_INTERVAL_MINUTES (5 min.) to determine inactivity, regardless of what the user set.
If a user is in the vehicle, always mark the car as active. In other words, do not begin checking for inactivity until all occupants have left the car.

The reason for letting the user adjust MOVE_THRESHOLD_INTERVAL_MINUTES is because when going on short trips to the store, I’ve found that it is common for the inactivity timer to kick in after 5 minutes, since I’m usually in the store for 10-15 minutes. There are also a few other things that can be checked to more accurately start the inactivity checking, such as waiting for all occupants to leave the vehicle. Since I use the location setting of the Tesla to disarm my alarm, unfortunately the current binding would still be in the back-off period for trying to let the car sleep, and my alarm would never disarm.

Here is my general logic btw for using the Tesla location to do stuff, in case it is of any use:

rule "Parse Telsa Location2"

when
//Time cron “0 */1 * * * ?” //every x minutes
///or
Item TeslaLocation changed
or
Item Debug changed
then
// var PointType home = new PointType(“40.0,-72.0”) //no spaces after comma
val PointType home = new PointType(new DecimalType(40.0),new DecimalType(-72.0))
val PointType tesla = TeslaLocation.state as PointType
val int distance = tesla.distanceFrom(home).intValue()
val int radius = 160 // home in meters

// val Number TeslaLat=Float.parseFloat(TeslaLocation.state.toString.split(',').get(0))
// val Number TeslaLong=Float.parseFloat(TeslaLocation.state.toString.split(',').get(1))
logInfo("org.openhab","Tesla distance "+distance)
TeslaDistance.postUpdate(distance*0.0006213712) // to miles

if ((TeslaHome.state == ON) && (distance>radius))
{
 logInfo("org.openhab","Tesla leaving home")
 TeslaHome.postUpdate(OFF)            
}
else if ((TeslaHome.state == OFF) && (distance<=radius))
{
 logInfo("org.openhab","Tesla arriving home")
 TeslaHome.postUpdate(ON)
 if (TeslaDistanceSwitch.state == ON)
 {
    AlarmCommand.sendCommand(0) // disarm
    logInfo("org.openhab","Disarming alarm due to Telsa proximity.")
 }
}
else if (distance<=radius)
{
 logInfo("org.openhab","Tesla initialized to home position")
 TeslaHome.postUpdate(ON)       
}
else
{
 logInfo("org.openhab","Tesla initialized to away position")
 TeslaHome.postUpdate(OFF)       
}

end