How do you rate Teslamate? I've been using Teslafi since day one (3 years now), but it seems maybe Teslamate can be used directly with Hubitat?
I've been using this app with the cars GPS (long:Lat) for certain automations.
is_user_present is still current, but Tesla Connect 3.0 is using data.vehicleState.presence which I'm not seeing anywhere in the raw data. This should probably be updated because it seems like the current presence state isn't doing anything, unless I'm missing something, which is quite possible.
1 Like
You are incorrect and looking at the wrong field
That data is still there and i.use.it.all.the time to alert me if i forget to plug the car in.. turn on debugging and u will see it. Not sure where your data is coming from but it .is not in the vehicle state i am getting .
Odd. My Tesla device event history is not showing any presence changes and when I query the raw API data from Tesla, the only present data that I’m showing is the is_user_present Boolean. Maybe it’s the API version or the car (I have a Model Y).
I've been happy with Teslamate. When issues crop up due to Tesla changes (like when the changed the auth to tokens) it gets updated pretty quick. Most data issues I've had are due to issues with Tesla's API or with the vehicle itself disconnecting, so TeslaFi would have the same issue.
I run it on a Raspberry Pi 4 along with a bunch of other Docker containers. The basic install is fairly simple. If you want to expose it to the internet through a secure proxy, the install is a bit more complex, but still probably within the skillset of most Hubitat enthusiasts.
From what I've seen, TeslaFi might be a little more polished, but Teslamate is free other than whatever donations you want to send the developer. There is a function to import TeslaFi data into Teslamate but since I've never used TeslaFi I don't know how well that works. There are threads about it on the Teslamate Github page.
A local instance of Telsamate can be used directly with Hubitat because it publishes everything to MQTT. You can work with that yourself using a community MQTT app for Hubitat, which I did before discovering [BETA] Tesla Vehicle via TeslaMate MQTT in Hubitat Package Manager. Now i use that community app for the Teslamate -> Hubitat integration.
If you just want to try out Teslamate, you can set up Teslamate on (most) any machine that can host Docker while still running TeslaFi. If you want to do more than play with it, you need an always-on host, so a low-power SBC like a Pi is a good way to go.
4 Likes
Jave you installed this driver and turned on debugging as i said? Comparing with a different implementation is nonrelevent.
That works too, but Teslamate makes it so easy. In Teslamate you can create geofences on a map and set the radius with a click and drag. It publishes the name of the current geofence to MQTT whenever the car enters one. That's easier than dealing with the raw lat/long myself. All I need to do in Hubitat is write a rule that is triggered by the geofence attribute of the community Teslamate app.
The two apps make a good pair, using this one for control/commands and the Teslamate integration for streaming data updates.
3 Likes
@kahn-hubitat, is the maximum charge amperage something that could be updated with the Tesla Connect 3.0 integration?
This is what it looks like/where it is in the app. Not sure what is its “correct” name:
Some background on what I am looking to do:
I’d like to synchronize the charging start/stop (that I can do already) and rate of charge (would like to be able to do) with the availability of solar energy.
With my current provider, if I give them my extra solar capacity, they give me a credit, which I can use when I consume more than I produce. However, they charge me tax on that usage, where if I used it directly without going through my utility company, I would save that tax amount. (It’s not a lot, but it adds-up long term when it can be controlled with all appliances.)
Being able to control the charge rate would allow me to keep the charge going for as long as possible, while at the same time being able to adjust to use as much of what is being produced as I can.
1 Like
Despicable. They are essentially taxing you for generating electricity. This is probably because the utility simply doesn't have a way to deliver any services to you without applying tax, or they just don't want to make the effort to put that in place. I would submit that to my accountant and see if they could find a deduction for that tax paid.
1 Like
Right? So I am doing all I can to use energy during the day. What makes it difficult sometimes is that during cloudy days, the amount generated fluctuates a lot, so maximizing this use can be a challenge.
Ideally, I would like to synchronize this with my Fronius inverters, but I haven’t been able to make that device driver work… so I plan to use the illuminance reported by my weather station. Will see if it works!
1 Like
This is all in the charging data from Tesla, so just would need to be pulled and added. Assuming it’s charge_current_request_max since mine is set to 48 amps.
charge_state": {
"battery_heater_on": false,
"battery_level": 80,
"battery_range": 249.9,
"charge_amps": 48,
"charge_current_request": 48,
"charge_current_request_max": 48,
"charge_enable_request": false,
"charge_energy_added": 52.75,
"charge_limit_soc": 80,
"charge_limit_soc_max": 100,
"charge_limit_soc_min": 50,
"charge_limit_soc_std": 90,
"charge_miles_added_ideal": 220.5,
"charge_miles_added_rated": 220.5,
"charge_port_cold_weather_mode": false,
"charge_port_color": "<invalid>",
"charge_port_door_open": true,
"charge_port_latch": "Engaged",
"charge_rate": 0,
"charger_actual_current": 0,
"charger_phases": 1,
"charger_pilot_current": 48,
"charger_power": 0,
"charger_voltage": 2,
"charging_state": "Complete",
"conn_charge_cable": "SAE",
"est_battery_range": 214.43,
"fast_charger_brand": "<invalid>",
"fast_charger_present": false,
"fast_charger_type": "ACSingleWireCAN",
"ideal_battery_range": 249.9,
"managed_charging_active": false,
"managed_charging_start_time": null,
"managed_charging_user_canceled": false,
"max_range_charge_counter": 0,
"minutes_to_full_charge": 0,
"not_enough_power_to_heat": null,
"off_peak_charging_enabled": false,
"off_peak_charging_times": "all_week",
"off_peak_hours_end_time": 360,
"preconditioning_enabled": false,
"preconditioning_times": "all_week",
"scheduled_charging_mode": "StartAt",
"scheduled_charging_pending": false,
"scheduled_charging_start_time": 1688796000,
"scheduled_charging_start_time_app": 120,
"scheduled_charging_start_time_minutes": 120,
"scheduled_departure_time": 1608987600,
"scheduled_departure_time_minutes": 480,
"supercharger_session_trip_planner": false,
"time_to_full_charge": 0,
"timestamp": 1688734625126,
"trip_charging": false,
"usable_battery_level": 80,
"user_charge_enable_request": null
1 Like
more info .. got it working.. the field is not what you specified it is charge_current_request.. i believe the max field you specified is the max the charger supports..
ie
2 Likes
also got the set command working.. now adding a debugging option to limit the token refresh dubugging as request.. will post new version to github in a few..
1 Like
ok version 3.2 commited in github.. (rainy day at the lake and nothing else to do but watch tv) should be able to get via package manager.
new debug field to turn on or off token refresh notifications and also new attribute for current charge amperage and command to set it..
i am not sure the range that you can put in the request.. obviously between 1 and 60?
probably varies.. anyway for this reason and the fact i cannot find documentation on what is allowed i am not restricting it, so obviously if you put in bogus numbers is will raise an error.
I suppose i could query th other max field that your charger supports and do 1-that.. but seems overkill to protect you from yourself.
3 Likes
Thanks! Works perfectly. I wonder how it would react to invalid values… I will add a check in my rule to ensure it only sends valid ones.
@kahn-hubitat, I would have another ask if you are interested - Would it be possible to add the command to close the trunk? There is a command to open it, but not to close it. Thank!
Question - Is there a concern with the number of times the driver polls the car? If not, and assuming it doesn’t do this already, would there be value in adding an option to poll the vehicle when commands are sent? Ex.: lock doors, the driver updates showing they are locked.
BTW - What a great app! Thank you!
This is actually the same activate trunk command as the open command in the Tesla API with a which_trunk parameter to specify the front or rear. The rear command is a toggle which either opens or closes the rear trunk depending on current state. So the “openTrunk” command on the device is a bit of a misnomer.
The vehicle state data does include an ft and rt response of 1 or 0 to show front or rear trunk open or closed, but it does look like that isn’t currently being pulled into this app. If you had that, you could use the status in a condition to send the command if the current state doesn’t match the desired state. So for that purpose, it would be great to have it added in.
As for the poll after a command, I believe the app does this or at least waits for the response to provide an update, because I always seem to get an updated state soon after the command is issued. If you’re using in a rule, you can always add a short delay and a refresh. I have a couple rules that do this, and I’ve never noticed a rate limit.
1 Like
Also many cars like the older model 3s dont have powered trunks.
True! And I’ve just tested it and can confirm that using the “Open Rear Trunk” button will both open and close it.
1 Like
