MyToyota Dashboard

[mxpwr]

Yes, I'll add some debug options later tonight.
It might also be connected to some of yours values not being fetched. I'll look into it.

[mxpwr]

I added more debugging prints to the mqtt integration, and you can now select which "sensors" should be created and you can also send a test message from your cached data (requires that you have data in the cache file).

For me, this looks now like this when I enable all sensors (i included EV level and EV range, which does not exist for my car).

Listen to the mqtt stream:

Code: Select all

mosquitto_sub -h 192.168.1.200 -p 1883 -t "mytoyota/#" -v
mytoyota/car/odometer {"value": 11088}
mytoyota/car/lock_status LOCKED
mytoyota/car/fuel_level {"value": 67}
mytoyota/car/fuel_consumption {"value": 5.16}
mytoyota/car/total_range {"value": 449}

No data is published for the EV parameters.

If i check the mytoyota logs now, i can find this:

Code: Select all

2025-08-09 20:06:49,025 - app.mqtt - DEBUG - Skipping MQTT publish for 'battery_level' because its value is missing from the API data.
2025-08-09 20:06:49,025 - app.mqtt - DEBUG - Skipping MQTT publish for 'ev_range' because its value is missing from the API data.

My best guess is that the API is not able to get the values since you have a different type of car. I will now look into the logs you send me and try to fix that as well.

[mxpwr]

I added the missing battery stats to the dashboard. you can now select in the settings page what you want to display on there.
The only item missing is " EV consumption (kWh/100)". I couldnt find any information about this in your logs.

[manjh]

Some error messages when I do a git pull:

Code: Select all

sudo git pull
Updating dadc566..6f53759
error: Your local changes to the following files would be overwritten by merge:
        data/mytoyota_config.yaml
Please commit your changes or stash them before you merge.
Aborting

What am I missing here??

[manjh]

I removed the whole directory and installed from fresh. It seems your git clone line is mixed up somehow.
Also, I still find docker-compose, which does not work for me, I have to manually remove the "-" so it runs "docker compose".

Anyway, got there at some point and filled the mqtt parameters. topic as "toyota/out". Still nothing.
Then I tried to check the output of the broker, and I found the MQTT topic in the data to be "toyota/out/ev_range".
I had specified "toyota/out" as topic, so the name of the value was added...

Checked my Domoticz setup: all data comes in as "domoticz/out", for all individual values.

So I think the topic should not include the name of the value!
Add the name of the value in the payload as a field "name" for instance.

[mxpwr]

First of all, thanks for test and your patience, much appreciated.

1. I looked into the docker compose command. If you ran the older version of docker the correct command is

Code: Select all

docker-compose up -d --build

if you run docker compose v2 (rewritten in rust or something) the command drops the hyphen

Code: Select all

docker compose up -d --build

Ill see how I can add this to the readme better.

2. Regarding your merge message on the git pull.

Code: Select all

sudo git pull
Updating dadc566..6f53759
error: Your local changes to the following files would be overwritten by merge:
        data/mytoyota_config.yaml
Please commit your changes or stash them before you merge.
Aborting

this happens when you have made changes to the config file and git cannot merge them, because the conflict. I noticed a stupid typo in one of my earlier commits where the "Auto Discovery Prefix" was

homeassitant

instead of

homeassistant

. so when you tried a git pull, git didnt know what to do. In this case, you should do a

Code: Select all

git stash

which will dump your changes into a stash file and then do a git pull. You can than either manually try to enter the settings back directly into the yaml file or just restart the webserver and use the setting page. Your car history is still there, that is stored in the mytoyota.db file in the same folder (/data).

3. Regarding the MQTT topic. I'm no expert with MQTT, so i m not sure what the exact behaviour should be, but to my understanding you set the base topic to domoticz/car (or whatever), and then all sensors are created as domoticz/car/sensor_name. If you dont add the sensor_name, Domoticz does not know to which sensor it should add the value. How do the sensor in Domoticz look for you? Are they created at all? Or is just the naming off?

[manjh]

Thanks, and I must apologize if I am a bit "pushy" or looking for details, I used to be software test manager for a major IT company, and I guess old habits never die...

As for the docker-compose: we got that clear. I guess it's now a matter of adding some words to the install instructions to point out the difference.

Speaking of instructions: the "git clone" line in the instructions is does not work, it looks like it was garbled somehow.

Then the issue about the MQTT topic.
When I look at the way it is setup for Domoticz, this is how I understand the setting should be:
Topic can be seen as a group name. So when I define "toyota/out" in the settings panel, all sensors will be sent to MQTT with exactly that topic. Nothing should be added or appended.
There is then a single listener in Node Red that picks up all sensor data coming in under that topic name.
The way to determine which sensor it is, can be done via a field in the payload.
For Domoticz there is usually a field "idx" with the unique key.
For toyota-dashboard it could be a field like "name"in the payload, with the name of the sensor as data.

Does this make sense?

The autodiscovery in Domoticz and Homeassistant are not used by me, so I cannot shed any light on that.

One last thing: data from my car is not read completely. For instance, I know for a fact that the car is fully locked, but in toyota-dashboard it show up as unlocked.
I will do a more detailed compare of the data.

[manjh]

I checked the data against the official Toyota app, looks OK (except for the lock status).

Fields "total fuel" and "time driven" don't make much sense to me.

[mxpwr]

No worries, I'm myself working in SW development for over a decade. This turned into a rather large project, and detail is important

I think I understand the issue now with your MQTT integration (with some help of Gemini ).

You're describing a common "manual" way to handle MQTT, where all data goes to one topic and requires a script to process it.

However, this application uses the modern "Auto-Discovery" method, which works differently and is an easier integration method with Domoticz and Home Assistant.

Manual Method (what you described): You send all data to one topic (e.g., toyota/out). You then have to manually create virtual sensors in Domoticz and write a script (in Node-RED) to read the payload, figure out which sensor it is (e.g., "odometer"), and then send a special command to Domoticz to update the device by its idx.

Auto-Discovery Method (what this app uses): The application sends data to a separate, unique topic for each sensor (e.g., mytoyota/VIN/odometer). It first sends a special "config" message that automatically creates the device in Domoticz with the correct name, units, and tells it exactly which topic to listen to for its values. No manual setup or scripting in Node-RED is needed for the Domoticz integration to work.

This method is fully automatic and requires zero scripting for the end-user in Domoticz.

Solution for your Node-RED setup:

If you still want a single entry point in Node-RED to get all the data, you can easily do this by using a wildcard. In your "MQTT In" node, set the Topic to:
mytoyota/#

This will subscribe to all sensor topics at once. You can then use a "Switch" node to route the messages based on msg.topic to handle the specific sensors. This gives you the workflow you want without breaking the automatic Domoticz integration.

This is how my domoticz setup looks like

Untitled.png (12.72 KiB) Viewed 660 times

[mxpwr]

I checked the data against the official Toyota app, looks OK (except for the lock status).

Fields "total fuel" and "time driven" don't make much sense to me.

There seem to be issues sometimes with the pytoyoda API and reading the lock status.
I had issues as well and it seems that pytoyoda sometimes fills door or lock status as None and sometimes as True/False, which makes it difficult to understand what is happening. I could add some debug prints to figure out what is happening in your case and then we can try to implement a better way to interpret the message.

Regarding the fields:
Total Fuel: Amount of fuel you used over the lifetime of your account on this car
Time Driven: Total time you drove your car over the lifetime of your account on this car
(data from previous owners is not available)

But you can disable those fields now in the settings page

[mxpwr]

I also updated the readme to address the other points you made

[manjh]

MQTT topic: OK, understood. I added the autodiscovery line in my domoticz hardware, and it now discovered and added the devices. So as you can see, learn something every day (even after 45 years in the ICT industry).

I will still use the switch to split off some values, since I want to store them in a file. I use a spreadsheet to keep track of my fuel consumption, and I use several readings to do the calculations. The excel spreadsheet reads from the file.

Lock status: I already use pytoyoda and altered the script to write all output to a file. I checked that file and see that the lock status is not correct.
I guess I will simply disable it.

As for pytoyoda: since I started using it, I have seen two failures. Apparently Toyota changes the interface periodically. The pytoyoda author has fixed the problem, but it does take manual action to upgrade to a new pytoyoda versio.n

[mxpwr]

Great that we got it working now.

I can add an "export to CSV" option in the trips history page so you can export the data directly without domoticz in the middle.

The logs you provided, did not contain any trips log, so i dont know if and how pytoyoda fetches the fuel consumption for your car. If you can send me such a log, I can integrate it. If pytoyoda does not get that data, we can probably still solve it either by hooking directly into the response from the toyota server (pytoyoda is not storing all data it gets) or by closely tracking the battery level before and after each trip, though this will be more prone to errors.

I can also add specific fuel consumption calculations to the web server if you let me know, what you are missing.
You can also click the histogram symbol to get the per trip values.

Untitled.png (20.88 KiB) Viewed 859 times

[manjh]

I think I commented out that trip data request in my pytoyoda file, since it is quite a lot of data and I had no good use for it. What I can see now in your app is fine.
I'll give it some thought about what is missing, if anything.

As for the MQTT topic discussion: I found out I can still get all messages from one single listener by using the + wildcard. That is also a good way to discover in Node Red which data comes in.

[mxpwr]

I added the CSV export on the trips page under Filters&options.
I also addressed the issue with merge conflicts on git pull.
The user settings are henceforth saved in a separate user_config.yaml.
Before you do a git pull next time do this in the data folder:

Code: Select all

cp mytoyota_config.yaml user_config.yaml
git stash
git pull

After that, the problem should be gone as your settings will be stored into the user_config.yaml which is not part of the repo.

I added a lot of missing parameters from the API. You will need to do a "Fill Trip history" if you want to add them for your already synced trips.

[manjh]

You're on a roll! Good job.

On the update instructions: perhaps it is usefull to add a simple bash file to the install set, so the user can simply run the update procedure?

I do have a few nit-picking suggestions about the presentation on the dashboard. Keep in mind these are suggestions.

• combine "range left"and "EV range" into:
  • Range:
    • EV
    • Fuel
    • Combined
• combine "Fuel Level" and "EV level" into:
  • Level:
    • EV
    • Fuel
• Change title "consumption" into "Avg. consumption"
• Change title "Time driven" into "Total time driven"

Depending on what you use to display the information, this may be a slight challenge...
But the idea is to simplify the dashboard and still display as much info as possible.
Ordering of the information could also be changed, but that is the last step I guess, after all info is there.

[manjh]

I am looking into migrating from my own pytoyoda solution to your toyota-dashboard app.
Most of the data elements that I need are there: odometer, fuel level, battery level and battery range.

What's missing are lattitude and longitude.
Is there any chance of adding these two data elements to the MQTT feed?

[mxpwr]

I am looking into migrating from my own pytoyoda solution to your toyota-dashboard app.
Most of the data elements that I need are there: odometer, fuel level, battery level and battery range.

What's missing are lattitude and longitude.
Is there any chance of adding these two data elements to the MQTT feed?

Yes, no problem, I can add those. You want them in one sensor or 2 sensors, one for lat, one for long?

[mxpwr]

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 (175.84 KiB) Viewed 682 times

[manjh]

I am looking into migrating from my own pytoyoda solution to your toyota-dashboard app.
Most of the data elements that I need are there: odometer, fuel level, battery level and battery range.

What's missing are lattitude and longitude.
Is there any chance of adding these two data elements to the MQTT feed?

Yes, no problem, I can add those. You want them in one sensor or 2 sensors, one for lat, one for long?

separate or combined, does not matter for me. In all cases I will process in a node-red function node, so I can split or combine as needed.