MyToyota Dashboard

[manjh]

I added several new mqtt sensors which you can enable in the settings.

The address sensor doesn't seem to work yet, it's being send, but domoticz is ignoring it. All other sensors work though, including long/lat location.

Screenshot_20250813-235755.png

I can have a look tonight. I can set up a Node-Red node that catches all incoming data using a wildcard, this allows me to see what comes in.
Will let you know.

[manjh]

Have you released the changes to git? I updated and restarted, but still only see the 7 fields in the MQTT list on the settings page!

Tip: add an "about" phrase somewhere, so we can see the version number.

[mxpwr]

Yes, you should see the same sensors as in my screenshot

https://github.com/stone17/mytoyota-das ... 1d392764cb

[manjh]

I removed the existing directory and re-installed from scratch, that has helped. New version is now running.

Checked if the address comes through: yes it does.
I set up a listener in Node-Red with a wildcard, it shows everything coming in from the toyota-dashboard, so it is very easy for me to check the msg coming in.

[mxpwr]

That's good. The message is send on my end as well, but domoticz logs only shows all the other sensors and does not create the sensor for the location address. Maybe it's just my domoticz installation that is scrambled.
Does the location address sensor get created for you?

[manjh]

A few findings after a quick test, some unexpected values:

• score comes in with value 69, on the Toyota appI see 85
• highway distance comes in with value 0
• total ev distance shows 23

[mxpwr]

It will send the data that is stored in the vehicle_data.json which is also what is shown on the dashboard statistics panel.
You can cross check those, they should be identical.
If not, perform a refresh and check again.
At least on my end the numbers match up, but maybe something is different with the your type of car.

[manjh]

Found the reason for the strange values.
Although the trip history stull shows all, I needed to backfill all trips in order to get the value calculations OK.
So I'll have to re-examen and check again.

[mxpwr]

I investigated a bit more and for some reason it doesn't work if I name the sensor location_address. Even sending the discovery message manually via mqtt_pub wouldn't create the sensor in domoticz. Any other name works fine. So I changed the name now and all sensors are working properly through mqtt now.

[manjh]

Re-tested latest version, all is OK except for lock status. In my case it always comes back with `Locked`.

[mxpwr]

Re-tested latest version, all is OK except for lock status. In my case it always comes back with `Locked`.

There should be a detailed log on the api response for the lock status? If you send that to me, I can see if I can find the problem.

[manjh]

Hmmmm. when I click the"Logs" page, the app shows the message "Connecting to log stream..." and the freezes. I cannot move to another page anymore. Closing the browser helps, I can the access the main page again.

[mxpwr]

Depending on your server you night have to wait 10 seconds or so until it connects to the log stream. I haven't had the time up optimize that part. You could also run the server outside the docker, then you get the logs in the terminal.

[manjh]

Re-tested latest version, all is OK except for lock status. In my case it always comes back with `Locked`.

There should be a detailed log on the api response for the lock status? If you send that to me, I can see if I can find the problem.

I think this may be an error in the Toyota part, when I unlock the car the original Toyota app also shows all doors as "locked". And I am 100% sure they are unlocked. So I guess this is not an error in the plugin!

[mxpwr]

That's interesting, for me the app is usually is correct.
But I noticed that pytoyoda sometimes doesn't return a true or false, but a none, and it's not consistent if the none is open or closed. It should look like this (locked is actually none, but I added logic to set the status to closed if the individual items are set to closed):

Code: Select all

2025-08-20 05:35:45,614 - app.fetcher - DEBUG - last_updated=datetime.datetime(2025, 8, 19, 18, 8, 33, tzinfo=TzInfo(UTC)) doors=driver_seat=closed=True locked=True driver_rear_seat=closed=True locked=True passenger_seat=closed=True locked=True passenger_rear_seat=closed=True locked=True trunk=closed=True locked=True windows=driver_seat=closed=True driver_rear_seat=closed=True passenger_seat=closed=True passenger_rear_seat=closed=True hood=closed=True locked=None
2025-08-20 05:35:45,615 - app.fetcher - DEBUG - Processing door 'front_left': raw closed=True, raw locked=True
2025-08-20 05:35:45,615 - app.fetcher - DEBUG - Processing door 'front_right': raw closed=True, raw locked=True
2025-08-20 05:35:45,615 - app.fetcher - DEBUG - Processing door 'rear_left': raw closed=True, raw locked=True
2025-08-20 05:35:45,615 - app.fetcher - DEBUG - Processing door 'rear_right': raw closed=True, raw locked=True

[manjh]

Python plugin for interacting with Toyota vehicle data or services.

What are to trying to say here?

[manjh]

Depending on your server you night have to wait 10 seconds or so until it connects to the log stream. I haven't had the time up optimize that part. You could also run the server outside the docker, then you get the logs in the terminal.

Connecting to the log stream took a very long time, then one page displayed, and agsain a very long wait.
So I decided to reduse the log size to 100 and did a full restart. Then it was OK again.
After that reset to the default value 200, problem did not come back. So I guess I'll keep an eye on it.

[manjh]

I have a request/suggestion for change.
One of the things I use the output of the plugin for, is to control charging of the battery of my PHEV.
Among the parameters are solar panel production (from my PV plugin), current power consumption in house (from the P1 meter plugin), and battery level from the toyota-dashboard plugin.
To get the most accurate value for battery level, I would want the refresh rate to be low, e.g. every 5 minutes.
But when the battery is fully charged, the refresh rate can be higher, like 30 or 60 minutes.

Is there a way to control this setting through an API? WOuld it be difficult to make?
There may be other settings as candidates, but battery level is the first that comes to mind.

[mxpwr]

That's not a problem at all. I have that on my to-do list.

Not sure how feasible a dynamic polling interval for the battery charging is, as we don't know when you are charging, but I'll add it and you can see if it works for you.

[manjh]

I know when I'm charging, since I control it from my Domoticz server.

Charging will start when there is sufficient power from my solar panels, the battery level is smaller than 100%, and I am sure the car is parked on the driveway (GPS). If these conditions are met, I switch on the power to the charge cable.

So if I can somehow set the polling frequency, I could implement that in the logic for charging.

BTW, I have a selector switch with more rules:

• always off
• always on
• time driven
• power price driven
• excess power driven (due to solar panel production)

So I can use the solar setting during the summer, and choose another when PV power is not as good.
The logic is similar as described above, based on location of the car and battery level.