First of all, huge thanks to the Hudiy team for this amazing project!
I installed it on my Seat Leon 5F. As you can see in the picture, I used 3D printed parts to mount the screen.
The Raspberry Pi and everything else were placed inside the glove box.
My Build Seat Leon 5F
My Build Seat Leon 5F
You do not have the required permissions to view the files attached to this post.
Re: My Build Seat Leon 5F
You’re very welcome! Great to see you were able to use Hudiy in your project — it looks fantastic. Very clean setup.
Hudiy Team
Re: My Build Seat Leon 5F
**Hudiy Project Update – Steering Wheel Controls and Vehicle Status Widget**
Hi everyone,
I wanted to share a new update on my Hudiy project.
The factory steering wheel buttons are now decoded from the CAN bus and mapped to Hudiy API commands. This means I can control the interface directly from the original steering wheel buttons without using any external controller.
**Vehicle Status Widget**
I also added a custom car status widget to the Hudiy dashboard.
This widget shows real-time vehicle information decoded from CAN, including door states. The car graphic updates depending on which door is open or closed. For now, I have confirmed the CAN data for the four doors and mapped them into the widget.
The widget is designed to be expanded further with more vehicle data such as speed, RPM, outside temperature, coolant temperature, oil temperature, fuel consumption and other useful information.
Another improvement is automatic brightness and theme control. The system now reads the brightness information from the vehicle’s instrument cluster over CAN. Based on this value, Hudiy can automatically adjust the screen brightness and switch between dark and light mode, similar to the original vehicle behavior.
Since the beginning of the project, I have also worked on:
* Hudiy API communication
* Steering wheel button decoding
* Dashboard layout customization
* Automatic brightness control from the instrument cluster
* Automatic dark/light mode switching based on vehicle brightness data
* Vehicle status widget
* Door state decoding from CAN
* Outside Temp from CAN
* Clock/Date info from CAN
The next steps will be improving the visual design, making the vehicle status screen more polished, adding smoother brightness/dimming behavior, and decoding more CAN signals.
I’m still actively developing and testing the system, but it is already becoming much more usable and integrated with the car.
https://www.youtube.com/shorts/NfhEbyzc ... ture=share
Hi everyone,
I wanted to share a new update on my Hudiy project.
The factory steering wheel buttons are now decoded from the CAN bus and mapped to Hudiy API commands. This means I can control the interface directly from the original steering wheel buttons without using any external controller.
**Vehicle Status Widget**
I also added a custom car status widget to the Hudiy dashboard.
This widget shows real-time vehicle information decoded from CAN, including door states. The car graphic updates depending on which door is open or closed. For now, I have confirmed the CAN data for the four doors and mapped them into the widget.
The widget is designed to be expanded further with more vehicle data such as speed, RPM, outside temperature, coolant temperature, oil temperature, fuel consumption and other useful information.
Another improvement is automatic brightness and theme control. The system now reads the brightness information from the vehicle’s instrument cluster over CAN. Based on this value, Hudiy can automatically adjust the screen brightness and switch between dark and light mode, similar to the original vehicle behavior.
Since the beginning of the project, I have also worked on:
* Hudiy API communication
* Steering wheel button decoding
* Dashboard layout customization
* Automatic brightness control from the instrument cluster
* Automatic dark/light mode switching based on vehicle brightness data
* Vehicle status widget
* Door state decoding from CAN
* Outside Temp from CAN
* Clock/Date info from CAN
The next steps will be improving the visual design, making the vehicle status screen more polished, adding smoother brightness/dimming behavior, and decoding more CAN signals.
I’m still actively developing and testing the system, but it is already becoming much more usable and integrated with the car.
https://www.youtube.com/shorts/NfhEbyzc ... ture=share
You do not have the required permissions to view the files attached to this post.
-
Polonium84
- Posts: 1
- Joined: Fri Aug 07, 2026 4:32 am
Re: My Build Seat Leon 5F
Could you share more information about this project? I would be interested in building a similar system and possibly helping you develop this.
Re: My Build Seat Leon 5F
I am reading the CAN data with mcp2515 directly from the vehicle's original multimedia/head unit wiring, using the CAN lines available behind the factory multimedia unit. From there, the CAN interface is connected to the Raspberry Pi and exposed through SocketCAN.
On the software side, I am mainly using Python 3 with `python-can` to capture and decode the CAN traffic. Communication with Hudiy is handled through the Hudiy API/protobuf interface, so the decoded vehicle data can be translated into Hudiy actions or displayed in the UI.
For finding the CAN signals, I mostly use a before/after logging method.
For example, if I want to identify a steering wheel button, door state or brightness value, I first record the CAN traffic while the vehicle is in a known state. Then I perform only the action I want to identify — such as pressing one button, opening one door or changing the instrument cluster brightness — and record another CAN log.
After that, I compare the logs and look for CAN IDs and byte/bit values that changed during that specific action. By repeating the same test several times, it becomes much easier to eliminate unrelated traffic and confirm which bytes actually belong to that function.
So the general reverse-engineering workflow is something like:
**Record baseline CAN traffic → perform one specific action → record again → compare the logs → identify changing CAN IDs/bytes → repeat the test to confirm → implement the decoder**
Once a signal is confirmed, I add it to the Python decoder and then either map it to a Hudiy API command or use it as a data source for the custom UI.
For the steering wheel controls, the decoded CAN messages are translated into Hudiy navigation commands. For vehicle information, the process works in the other direction: the CAN decoder continuously updates the current vehicle state and sends that information to the Hudiy interface.
The integration scripts run as systemd services, so SocketCAN and the CAN/Hudiy bridge start automatically when the Raspberry Pi boots.
The overall architecture is roughly:
Factory multimedia CAN wiring → CAN interface → Raspberry Pi / SocketCAN → Python CAN decoder → Hudiy API → Hudiy UI
The project is still under active development, and I am continuing to decode additional signals and improve the integration.
If you are working with a Seat Leon 5F or another MQB-based vehicle, I would definitely be interested in comparing CAN logs and findings.
And to be completely fair Im not a developer
I've been using ChatGPT a lot throughout this project, especially for the coding and debugging side.
On the software side, I am mainly using Python 3 with `python-can` to capture and decode the CAN traffic. Communication with Hudiy is handled through the Hudiy API/protobuf interface, so the decoded vehicle data can be translated into Hudiy actions or displayed in the UI.
For finding the CAN signals, I mostly use a before/after logging method.
For example, if I want to identify a steering wheel button, door state or brightness value, I first record the CAN traffic while the vehicle is in a known state. Then I perform only the action I want to identify — such as pressing one button, opening one door or changing the instrument cluster brightness — and record another CAN log.
After that, I compare the logs and look for CAN IDs and byte/bit values that changed during that specific action. By repeating the same test several times, it becomes much easier to eliminate unrelated traffic and confirm which bytes actually belong to that function.
So the general reverse-engineering workflow is something like:
**Record baseline CAN traffic → perform one specific action → record again → compare the logs → identify changing CAN IDs/bytes → repeat the test to confirm → implement the decoder**
Once a signal is confirmed, I add it to the Python decoder and then either map it to a Hudiy API command or use it as a data source for the custom UI.
For the steering wheel controls, the decoded CAN messages are translated into Hudiy navigation commands. For vehicle information, the process works in the other direction: the CAN decoder continuously updates the current vehicle state and sends that information to the Hudiy interface.
The integration scripts run as systemd services, so SocketCAN and the CAN/Hudiy bridge start automatically when the Raspberry Pi boots.
The overall architecture is roughly:
Factory multimedia CAN wiring → CAN interface → Raspberry Pi / SocketCAN → Python CAN decoder → Hudiy API → Hudiy UI
The project is still under active development, and I am continuing to decode additional signals and improve the integration.
If you are working with a Seat Leon 5F or another MQB-based vehicle, I would definitely be interested in comparing CAN logs and findings.
And to be completely fair Im not a developer
I've been using ChatGPT a lot throughout this project, especially for the coding and debugging side.