1.62-docker-compose up error and Range Difference about teslamate HOT 36 CLOSED

Yes, something is messed up in their backend. The next release will use the vehicle_config endpoint to identify vehicles like you suggested, @jun3280net. I'm a bit nervous about releasing this change because I couldn't test with many different models. Let's see how this turns out ...

from teslamate.

from teslamate.

Not to throw this off further, but here are my codes:
"AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0"

I own: 2019 (Raven) Model S, black exterior, white interior, 19" carbon slipstream, non-performance

It is definitely not a Model 3 (MDL3), it has more than 75 kWh (BT37), it does not have the Model 3 wood decor (ID3W), does not have the Model 3 glass roof (RF3G) - although, they could go to a single code for the glass roof, it is not RWD (DV2W), I hope it is better than AP firmware 2.0 (APF0) and actually AP HW3 which apparently has a code but seems I have hardware 2.5 (APH3), claims I have the Model 3 48amp charger (CH07), no HEPA filter (AF00).

Yes. I went through all my codes. ¯_(ツ)_/¯

from teslamate.

@adriankumpf awesome stuff! Really appreciate your responsiveness in maintaining this project. Will load this up when I get home from work.

from teslamate.

I don't know think you should share your auth code here. I would suggest editing your message and deleting that.

Hi @bahree thanks for looking out. That example I provided was just a modified version of what @adriankumpf had provided. The auth code is made up. I only provided the example for others to check their data.

Cheers
J

from teslamate.

Neither the range (ideal / estimated) on the web interface nor the range measurments in the dashboards are affected by this. It only has an influence on the consumption / kWh values. You can fix that by manually updating the efficiency value in the database table "cars". But it will be overwritten with every restart of TeslaMate.

@adriankumpf would it be possible to add conditional logic to set the efficiency value based on the following :
"trim_badging":"90d"
"car_type":"models2"

Thanks

I'm not sure if that is enough information to identify all the different models. I found this issue timdorr/tesla-api#146 where someone reported the same option codes for Model S/X. I guess we have to wait for Tesla to fix their data ...

from teslamate.

For what it's worth, my car is also a 90D. When I pull all the option codes, it shows:

AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00

My car is definitely a 2017 model 90D (MCU1, AP2, refreshed front nose) and the badging and other indicators in the api all show that. I suspect that MDL3 is not indicative of Tesla Model3s...or maybe it means something else but there are definitely Model S 90Ds out there that have that option code in the API. I believe that this is actual a reflection of a Model S, AP2 (new fascia) car...but someone else can correct it.

This discussion also shows why the max range numbers appearing in Grafana are so high (mine show a max range of ~350miles. If the system is using Model3 power numbers, the range is being inflated.

Adrian, I think you need to check the code and key off something else. Clearly something is going on where Model S 90Ds are sending that option code to the API for some reason...

from teslamate.

This error [error] Mounting lv:phx-YAnm40fq failed while verifying session with: :invalid is nothing to worry about. There is probably a browser tab with the web interface open somewhere. Just reload it.

Regarding the the identification of you vehicle: that will affect a few measurements like kWh use. Do you have access to the Tesla API? I need the option codes of your car to fix the identification.

from teslamate.

This error [error] Mounting lv:phx-YAnm40fq failed while verifying session with: :invalid is nothing to worry about. There is probably a browser tab with the web interface open somewhere. Just reload it.

Regarding the the identification of you vehicle: that will affect a few measurements like kWh use. Do you have access to the Tesla API? I need the option codes of your car to fix the identification.

Hi Adrian. I closed all of my web sessions with Teslamate on all my computers on my LAN, and restarted the service and it appears that error message has now stopped. Thanks!

With regards to the Tesla API - I'm not familiar with what needs to be done. I've gone to the link you provided and drilled into the details.
1. I've installed Ruby (sudo apt install ruby)
2. I've installed tesla_api (sudo gem install tesla_api)
-however I get an error : Failed to build gem native extension

Any pointers on how to debug this?

from teslamate.

You could use curl instead:

• replace EMAIL and PASSWORD in the first command.
• And then replace the string after "Bearer" with the received access token

curl -X POST \
  -H 'Content-Type: application/json' \
  -d '{"grant_type": "password", "client_id": "81527cff06843c8634fdc09e8ac0abefb46ac849f38fe1e431c2ef2106796384", "client_secret": "c7257eb71a564034f9419ee651c7d0e5f7aa6bfbd18bafb5c5c033b093bb2fa3", "email": "EMAIL","password": "PASSWORD"}' \
  'https://owner-api.teslamotors.com/oauth/token'

curl --request GET --header 'Authorization: Bearer 32819532809859320539205djfdsjfkdsd' 'https://owner-api.teslamotors.com/api/1/vehicles'

from teslamate.

You could use curl instead:

• replace EMAIL and PASSWORD in the first command.
• And then replace the string after "Bearer" with the received access token

curl -X POST \
  -H 'Content-Type: application/json' \
  -d '{"grant_type": "password", "client_id": "81527cff06843c8634fdc09e8ac0abefb46ac849f38fe1e431c2ef2106796384", "client_secret": "c7257eb71a564034f9419ee651c7d0e5f7aa6bfbd18bafb5c5c033b093bb2fa3", "email": "EMAIL","password": "PASSWORD"}' \
  'https://owner-api.teslamotors.com/oauth/token'

curl --request GET --header 'Authorization: Bearer 32819532809859320539205djfdsjfkdsd' 'https://owner-api.teslamotors.com/api/1/vehicles'

Thanks Adrian. I think I got the information. Is it okay if I paste the option codes line here? Or is there sensitive information?

Thanks

from teslamate.

The option codes represent various options the car was built with. If you paste only that particular line of the output that's okay.

I will look similar to this:

    "option_codes": "MDLS,RENA,AF02,APF1,APH2,APPB,AU01,BC0R,BP00,BR00,BS00,CDM0,CH05,PBCW,CW00,DCF0,DRLH,DSH7,DV4W,FG02,FR04,HP00,IDBA,IX01,LP01,ME02,MI01,PF01,PI01,PK00,PS01,PX00,PX4D,QTVB,RFP2,SC01,SP00,SR01,SU01,TM00,TP03,TR00,UTAB,WTAS,X001,X003,X007,X011,X013,X021,X024,X027,X028,X031,X037,X040,X044,YFFC,COUS",

Edit: this page explains what the different codes mean

from teslamate.

thanks maintaining this Adrian

"option_codes":"AD15,MDL3,PBSB,RENA,BT37,ID3W,RF3G,S3PB,DRLH,DV2W,W39B,APF0,COUS,BC3B,CH07,PC30,FC3P,FG31,GLFR,HL31,HM31,IL31,LTPB,MR31,FM3B,RS3H,SA3P,STCP,SC04,SU3C,T3CA,TW00,TM00,UT3P,WR00,AU3P,APH3,AF00,ZCST,MI00,CDM0"

from teslamate.

Okay, that is strange ... your Model S has these option codes:

MDL3: Model 3
BT37: 75 kWh (Model 3)
ID3W: (Model 3) Wood Decor

WHAT? Are you sure you own a Model S? 😆 Tesla must have entered false information into their database ... ?

from teslamate.

Okay, that is strange ... your Model S has these option codes:

MDL3: Model 3
BT37: 75 kWh (Model 3)
ID3W: (Model 3) Wood Decor

WHAT? Are you sure you own a Model S? 😆 Tesla must have entered false information into their database ... ?

That is interesting. My vehicle is is a Model S, 90D, with Black Ashe Decor. So this is why my vehicle is getting very high range estimates - as the calculations are based on Model 3? Is there even a way to fix this?

from teslamate.

Neither the range (ideal / estimated) on the web interface nor the range measurments in the dashboards are affected by this. It only has an influence on the consumption / kWh values. You can fix that by manually updating the efficiency value in the database table "cars". But it will be overwritten with every restart of TeslaMate.

from teslamate.

@adriankumpf that means the range estimate on my car dashboard should match the range estimate (one of ideal/estimated) on the Teslamate web interface? Right now my car reads 271km, but on Teslamate it reads (ideal : 339.5km / estimated : 295.1km). Any idea what is causing this variance? This is a straight data pull right?

from teslamate.

Yep, it comes straight from the car / the API. You can check for yourself with the above mentioned curl commands (the API reports miles instead of km). https://tesla-api.timdorr.com/vehicle/state/data

from teslamate.

@adriankumpf . Thanks! I used the command you recommended

"curl --request GET --header 'Authorization: Bearer 32819532809859320539205djfdsjfkdsd' 'https://owner-api.teslamotors.com/api/1/vehicles/{id}/vehicle_data'

where id is replaced by 1234567.

I see
battery_level : 60
battery_range : 168.04
ideal_battery_range : 210.05
est_battery_range : 182.95

if I convert the above number by multiplying by 1.609634 km/miles
I get
battery_range : 270.4 km (matches car dashboard)
ideal_battery_range : 338.0 km (matches Teslamate)
est_battery_range : 294.4 km (matches Teslamate)

Would you be able to add battery_range as a measure to Teslamate, as this matches what the car is displaying?

Thanks again for all your help!

from teslamate.

I don't know think you should share your auth code here. I would suggest editing your message and deleting that.

from teslamate.

Neither the range (ideal / estimated) on the web interface nor the range measurments in the dashboards are affected by this. It only has an influence on the consumption / kWh values. You can fix that by manually updating the efficiency value in the database table "cars". But it will be overwritten with every restart of TeslaMate.

@adriankumpf would it be possible to add conditional logic to set the efficiency value based on the following :
"trim_badging":"90d"
"car_type":"models2"

Thanks

from teslamate.

@adriankumpf . Thanks! I used the command you recommended

"curl --request GET --header 'Authorization: Bearer 32819532809859320539205djfdsjfkdsd' 'https://owner-api.teslamotors.com/api/1/vehicles/{id}/vehicle_data'

where id is replaced by 1234567.

I see
battery_level : 60
battery_range : 168.04
ideal_battery_range : 210.05
est_battery_range : 182.95

if I convert the above number by multiplying by 1.609634 km/miles
I get
battery_range : 270.4 km (matches car dashboard)
ideal_battery_range : 338.0 km (matches Teslamate)
est_battery_range : 294.4 km (matches Teslamate)

Would you be able to add battery_range as a measure to Teslamate, as this matches what the car is displaying?

Thanks again for all your help!

Interesting. I think it depends which range is displayed in the car:

• Typical in the UI is mapped to "ideal_battery_range" in the API
• Rated in the UI is mapped to "battery_range" in the API

I'll add battery_range to the next release.

from teslamate.

@adriankumpf @drklain interesting. I checked the codes against the Tesla-API Issue thread #146. Does it make sense that the option codes that the entire string of option codes are identical between 3 users? Pretty interesting coincidence. Can you add one more special condition where that entire strange option string = Model S 90D so that the efficiency value is proper in the database table "cars"?

from teslamate.

This seems to affect more people than I initially thought. The next release with the improved vehicle detection will be out soon (if you can, please try out the master branch. I'd love to get some feedback on the updated detection mechanism!)

from teslamate.

Additionally, there is now a beta image available on Dockerhub.

To try it out temporarily update your docker-compose file:

replace

  teslamate:
    image: teslamate/teslamate:latest

with

  teslamate:
    image: teslamate/teslamate:1.7.0-beta

and

  grafana:
    image: teslamate/grafana:latest

with

  grafana:
    image: teslamate/grafana:1.7.0-beta

from teslamate.

@adriankumpf so far so good. Will keep you posted if I notice anything out of the ordinary. The "rated" range matches the car dashboard and Tesla app. Thank you very much for pushing this change in so quickly.

from teslamate.

Updated to 1.7.0-beta. Did this by updating docker-compose file as indicated above pointing to the two betas. Then I ran docker-compose pull (which pulled the two images) then ran docker-compose up -d which appeared to install them.

Result? Both Teslamater and Grafana appear broken.

Now when I run teslamate I get problem loading page.

When I run grafana, it runs but with no data and an alert:

Templating init failed
dial tcp 127.0.0.1:5432: connect: connection refused

Any ideas?

from teslamate.

And just to update - getting the beta, didn't work either. :(

from teslamate.

@drklain In those situations it's always essential to provide the logs (docker-compose logs -f teslamate) :) v1.7 adds elevation data to every position ever recorded which puts more load on the system. Maybe that was a bit too much ... on which hardware do you run teslamate?

from teslamate.

Pulled the logs. All I get is WARNING: no logs are available with the 'db' log driver

I'm going to try completely uninstalling everything and doing a fresh install. It may be that having a previous version of teslamate working is causing an issue (different database or something). I just tried upgrading with the pull and then the docker-compose up command with the new .yml file pulling version 1.7 beta. Let's see how a fresh install works....

from teslamate.

OK, did a complete delete and install. still can't connect to teslamate on port 4000. can connect to grafana on 3000 and see the screens, but no data and get the same "Templating init failed
dial tcp 127.0.0.1:5432: connect: connection refused" red alert box.

Ran logs and got:

My docker-compose.yml file is as follows:

version: '3'
services:
teslamate:
image: teslamate/teslamate:1.7.0-beta
restart: unless-stopped
environment:
- DATABASE_USER=teslamate
- DATABASE_PASS=secret
- DATABASE_NAME=teslamate
- DATABASE_HOST=db
- MQTT_HOST=mosquitto
- TZ=America/New_York # (optional) replace to use local time in debug logs. See "Configuration".
- VIRTUAL_HOST=192.168.1.169 # if you're going to access the UI from another machine replace
# "localhost" with the hostname / IP address of the docker host.
ports:
- 4000:4000
cap_drop:
- all

db:
image: postgres:11
environment:
- POSTGRES_USER=teslamate
- POSTGRES_PASSWORD=secret
volumes:
- teslamate-db:/var/lib/postgresql/data

grafana:
image: teslamate/grafana:1.7.0-beta
environment:
- DATABASE_USER=teslamate
- DATABASE_PASS=secret
- DATABASE_NAME=teslamate
- DATABASE_HOST=db
ports:
- 3000:3000
volumes:
- teslamate-grafana-data:/var/lib/grafana

mosquitto:
image: eclipse-mosquitto:1.6
ports:
- 1883:1883
- 9001:9001
volumes:
- mosquitto-conf:/mosquitto/config
- mosquitto-data:/mosquitto/data

volumes:
teslamate-db:
teslamate-grafana-data:
mosquitto-conf:
mosquitto-data:

Open to any ideas you have

from teslamate.

I think you can see the logs on the Docker UI: #108 (comment) (you're using a Synology NAS, right?) Without getting more information I cannot help :/

from teslamate.

Here's the teslamate log. It appears to be unable to connect to the database?

from teslamate.

I don't think that this is related to the v1.7-beta. Let's discuss it over here: #108. Like mentioned in this comment it could be an issue with the Synology Docker package.

from teslamate.

@adriankumpf I can confirm Teslamate is working great on my Ubuntu installation. Thanks again for getting this update up and running so quickly.

from teslamate.

Awesome. Thanks for reporting back!

from teslamate.