Devlog

I don’t know if I mentioned it before, but for now the Content-Type checks are disabled. I need to learn more about them and implement better validation.

• Created an updated OAuth2 settings page and a car selection screen (with Tailwind CSS, of course).
• Started experimenting with a new dashboard. It’s still a work in progress, but it will most likely become the main design. I’m also thinking about adding a second dashboard style, although I’m not sure if I’ll do that before the first release.
• I definitely want to clean up the HTML/Tailwind code by moving repeated styles into reusable classes or something similar.
• I’m also thinking about using more HTMX so that more pages can update data without needing a full page reload.
• Wrote more documentation. I still need to verify the fuel endpoint because I don’t remember whether it handles different engine types correctly.

( The new OAuth2 settings page and the car selection screen. For next develop I think I will make a video of how everything works)

Devlog

Companion app

I said it was finished for now, but I forgot to add one more thing (the one on the left in the screenshots): a dashboard redirect.

Main app

• I’m still investigating the Content-Type problem. I verified that the official Volvo API behaves correctly, so I’m working on matching that behavior.
• Added work-in-progress Content-Type checks.
• Started reworking the CSS using Tailwind CSS. It’s still mixed with some plain CSS for now.
• Enabled support for the reduced guard lock command. You have to manually mark it as supported, and for now it behaves the same as the normal lock command.

Let me know which design you like more: the new one (center) or the old one (right).

Devlog

I’m mainly focused on finishing the companion app.

I started working on the CSS. Most of my time was spent learning Tailwind CSS (so I didn’t track it). I think it’s a better fit for me than writing plain CSS.

• Added Tailwind CSS to all pages of the companion app. (I think I need to redo the main app now. 😅)
• Added a small README with information about the main app.

I think it done now but I will come back to it before first ship

Main app

While working on the companion app, I found another issue.

The Content-Type: application/json behavior doesn’t match the official API. I verified that the official API works as expected, checks for it mine doesn’t (I think)

Devlog

Companion app

• Added manual mode for comparison.
• Engine start/stop now works in normal mode.

Before pushing, I forgot to fix one thing:

{"error":"Failed to retrieve data from unofficial API.","detail":{"detail":[{"type":"dict_type","loc":["body"],"msg":"Input should be a valid dictionary","input":"{ \"runtimeMinutes\": 10}"}]}}

The fix was simple: I forgot to use json.loads().

I pushed a quick fix commit right after.

The photo shows the manual comparison page. I’m still working on the comparison logic, which is why it doesn’t have any CSS yet.

Sorry for not adding Volvo API keys so you can see the differences between both APIs, but that would have taken too much time today.
Its also the reason why Im creating this app

Main app

• Worked on the documentation.
• The notifier now supports more than one updated attribute at the same time. It’s not the best implementation, but I’ll improve it after the first ship.
• Fixed snapshot loading and added exception handling.
• Scenario loading now reports malformed JSON files.
• Fixed a dashboard bug where tire information was shown three times. I think I planned to add more data there… and then forgot.

I should probably test everything before making a devlog or committing, but I also don’t want my devlogs to have to much time.

A public online demo!!!!!

The project is finally available online!

https://playground.kls.hackclub.app/internal/welcome

Please don’t be the bad guy and fight with other people over access. ❤️

That’s all I wanted to say because this is a really big milestone for me.

There will also be another commit today to make sure everyone can run their own instance of the project.

I found a few issues that only appeared outside of my local environment:

• Some WebSocket features break when using HTTPS.
• The dashboard had problems when the instance wasn’t running on the same computer.

Those should be fixed in today’s commit.

If you find any errors please comment or contact me on slack

Also thanks to nest hackclub for hosting

Devlog

Authorization was my mistake. It should have been accessToken, not Authorization. Why I thought that? I have no idea. No it was good before I was sleepy I think when I did that

The snapshots system now works.

Why it didn’t work as expected:

• I forgot to use copy(deep=True).

• One of the small dictionaries was written incorrectly.

• Added saving and loading snapshots from a file.

• The scenarios system now works and has been tested.

Difference between snapshots and scenarios

• Snapshots copy all data about a car. They are persistent and can be saved to a file.
• Scenarios only change selected attributes. They are designed to be created and edited manually in a JSON file.

Main app

The main app is mostly ready. Before the first release, I still need to:

• Finish the documentation.
• Add a roadmap with future updates.
• Verify error responses against the real API.
• Finish the comparison feature in the companion app.
• Add more ready-to-use scenarios and API keys.

Companion app

• Manual login now works, so only the comparison logic is left.
• I found a bug where api_key_p was None because one endpoint redirected using api_key instead.
• Started working on the comparison feature.

PS: A photo of why the api_key_p was none

Devlog

Writing documentation is a good way to check whether the code you wrote actually works. I already found four bugs while documenting the project.

For example, I forgot to pass the redirect URI in a function in main.py, even though it was already implemented in internal.py.

I also fixed a bug where notifications could sometimes contain an older value.

The dashboard has been moved into a separate file.

Snapshots currently have a problem. They are very similar to the Car class, so I’ll debug it and explain what the issue was in the next devlog.

Companion app

The companion app is meant to showcase the differences between my implementation and the official Volvo Demo Car Sandbox. It also makes testing easier, since you don’t have to write your own application just to try the API.

I had a problem with the built-in LibreSSL because one of the dependencies didn’t support it. I had to reinstall Python so that uv would detect the new OpenSSL installation.

After that, I was finally able to start the app and get it working.

Auto-login and automatic creation of a test car are now working.

There’s is no css but I will do it after logic works

One more thing: the reason the devlogs have been quieter recently is that I’ve been dealing with some administrative paperwork. I’ll get back to posting them more regularly once that’s sorted out.

Devlog

I’m building an 9-button macropad with a rotary encoder (including the encoder button) and an OLED screen. Later, I plan to add LEDs.

In the first timelapse, I built everything on my own without following any tutorials. After that, I watched a tutorial to learn better practices, then decided to start over from scratch. Although it meant redoing my work, I now have a much better understanding of how everything fits together, and the new version is built on a much stronger foundation.

It’s also my first hardware project. I always wanted to make a hardware but I didn’t have the money or goal to what to make.

Devlog

How I don’t like web development… did I already say that? I’ll say it again.

I’m working on the OAuth2 settings, and I had a problem where one of the query parameters wasn’t reaching the backend. I still don’t know what actually fixed it.

Then I had another problem. I have a function that changes values in the backend, but only one button worked while everything else didn’t.

It turned out to be because I debugged the first problem with AI. Always trust your own mind before trusting AI. The problem was hx-trigger.

I also had problems applying CSS through HTMX. In the end, I solved it by using hx-redirect.

But in the end everything works (you can see it one the phtoto)

I also worked on the scenario system, which loads scenarios from a JSON file. It isn’t tested yet, and I still need to work on state snapshots. The idea is that you’ll be able to save a moment in time and restore it later, so you can test the same scenario as many times as you want without setting up all the data again.

I also started working on a companion app to showcase the differences between my implementation and the official demo car sandbox.

I’ll write more about it in the next devlog.

Devlog

A small error from the last devlog: it’s PKCE, not PCKE. I had to rename a lot of variables because of that.

More customizable data

• Gearbox
• Model year
• More diagnostic data for lights (hazard, fog, brake, high beam, low beam, and more)

Other additions

• Added a new default API key with 3 cars, each having different values.
• Wrote more docs.
• Started working on scenarios (templates for new or existing cars to make setup faster). I’m thinking about loading them from a file so users can create their own.
• Started working on setting up OAuth2 through the dashboard.
• Fixed most command responses because when I first created them, I forgot to wrap everything inside { "data": {} }.
• Added light options to the dashboard.

Working:

PKCE

How does it work?

1. The application generates a random secret.
2. Before redirecting the user to the login page, it sends only a hashed version of that secret.
3. After the user logs in, the application receives an authorization code.
4. When exchanging the code for tokens, it sends the original secret.
5. The server checks whether it matches the previously received hash. If it does, the tokens are issued.

It normally protects from having the tokens stolen
 

New promoting picture I made in canva have a look

Devlog

• Small additions to the new documentation.
• changes how the api handles errors

BIG ADDITION

OAuth2 without PKCE.

I started working on PKCE, but I thought I should write a devlog before adding it.

• Added a login website (I know I mentioned it last time).
• Added a way to enable and disable OAuth2.
• Authentication now checks whether OAuth2 is enabled. If it is, requests are authenticated using OAuth2. Tokens don’t expire yet, but that will be added soon.
• Added endpoints for refreshing tokens and exchanging an authorization code for tokens.

How does OAuth2 work?

1. The app redirects the user to a login page.
2. After logging in, the website redirects the user back to the callback URL provided by the app.
3. The app receives an authorization code, which it exchanges for two tokens: a long-lived refresh token and a short-lived access token.
4. When the access token expires, the app can use the refresh endpoint to obtain a new access token.

What is PKCE?

I’ll write more about it once it’s added to the project. In short, PKCE protects the authorization flow by ensuring that only the application that started the login process can exchange the authorization code for tokens.

The application first generates a random secret (called a code verifier). Before the login request is sent, a hashed version of that secret (the code challenge) is sent to the server. Later, when exchanging the authorization code for tokens, the application sends the original secret. The server verifies that it matches the previously received hash before issuing any tokens.

I’ll explain the complete flow in the next devlog.

Devlog

This devlog will be a short one because I’ve been focusing on implementing OAuth 2.0. I’ll cover that in more detail in the next update but I will add photo of a “login” screen that I created for it (it looks bad on purpose).

What’s new

• The terminal now works with more than one static car.
• The dashboard can (once again) create new cars.
• The codebase has been split into multiple files instead of a single large file:
  • main still contains the public API endpoints.
  • internal contains the dashboard logic and internal API endpoints.
  • database will contain multiple predefined car scenarios.
• I also started writing a new manual that documents the quirks of the Volvo API and my implementation ( and edge cases). I will write more about in next 2 devlogs

What’s left before the first ship

• An example application demonstrating the differences between the official Volvo Sandbox and this project.
• OAuth 2.0 with PKCE (it would be great to have before the first ship).
• Documentation.
• A major code cleanup and refactoring.

Devlog

• I added two static (for now) endpoints: statistics and warning. The statistics endpoint mostly returns data, so there isn’t much to test. The warning endpoint has a very large response that would require a lot of new code, and for now I don’t want to implement all of it.
• I started working on adding cars through the dashboard (you could already see part of it in the last devlog), but I found out it doesn’t work, so I need to fix it before the next devlog.
• Climate and engine STOP commands now respond correctly. In the last invoice update, they incorrectly returned RUNNING.
• Added checks for the new command endpoints to verify whether the car supports a given command.
• Added a small terminal page that outputs changes. In the future, you’ll be able to choose whether to display only Volvo changes, all changes, or all information (for example, if you checked whether the windows status). I also used it to verify that the normal WebSocket status works.
• Added the foundations for disabling WebSockets on startup. Only a configuration file is left to implement.
• Added UNAVAILABLE reason invoice logic mostly something like this:
  • If the reason is NO_INTERNET, the invoice becomes CONNECTION_FAILURE.
  • If the reason is POWER_SAVING_MODE, the invoice becomes VEHICLE_IN_SLEEP.
• Made some improvements to the dashboard’s appearance.

Devlog

A funny story: I built the invoice system but didn’t always assign values correctly, so the values got mixed up. I spent a long time debugging before realizing that was the cause.

{
    "error": {
        "message": "VALUE_ERROR",
        "description": "\"Car\" object has no field \"123\""
    }
}

I also spent a lot of time on CSS. Most of that time went into learning:

• classes
• IDs
• box shadows
• CSS Grid

The reason it took so long since the last devlog is CSS. As I said before, I don’t really like web development, so my motivation was pretty low.

I used some AI, but I worked hard to remove most of the generated code. At this point, most of the site’s design looks the way I want it to and will probably stay that way until the end of the project.

Made invoices have some logic instead of always sending the same value.

That means:

• If no invoice status is set, it sends COMPLETED or RUNNING depending on whether the engine or climate is running.
• Loc like actions can’t have a RUNNING invoice status.
• Added a distinction between successful and failed invoices.

PS: Always remember to stop the server with Ctrl+C, not Ctrl+Z, because Ctrl+Z can leave the process running and keep the port blocked.

Devlog

It has been a long time since my last devlog, but I was more focused on learning than adding new stuff.

• Right now, I am focusing on learning HTML, htmx, and Jinja.
• The welcome page logic is mostly working. I had some problems with it because I used htmx to add new code, but the JavaScript from the is not reloaded with that. Now, I use the HX-Redirect response.
• I also learned how WebSockets work with FastAPI and htmx.
• I also designed how the dashboard will look (I attached my drawings. Good luck reading them!).

Devlog

• centralLock is called carLocked in the docs. The docs seem to be outdated. I think the OpenAPI specification is more accurate and contains fewer errors.
• I added a way to validate data using class functions.
• Implemented timestamps. Using datetime function from python
• Added tyre endpoints.
• Added a way to generate new API keys and create new cars (I used python secrets). 
  (getting ready to make first public running version)
• Roadmap.md file with status of this project

What is next to do

• Start using the updated method for changing data.
• Update the dashboard to reflect and modify the new data.
• Add WebSocket support.
• Add the remaining 2 vehicle and warning endpoints.
• Create an example app for testers.
• Redesign dashboard. It looks awful

I had a 2 days off because I was on school trip but I back. Next thing on my list is an updated dashboard 

Devlog

1. You can edit data through the dashboard now. It’s not the best solution, and I want to change how it works (probably start from scratch), but not now.

2. Diagnostics endpoints.

I had a very good time with them today. Why? Because of the “/diagnostics” docs. I attached a screenshot showing an example from the official website and data from a real car (left: real API, right: docs).

If you look at them, you can see two errors and one very small issue that you would only notice if you read the whole documentation:

• In serviceWarning, you can see the value is NORMAL, but NORMAL is not a valid value for it. It should be NO_WARNING. This is the small one.

• In engineHoursToService, the API response contains a unit, but the docs don’t mention it at all.

• And the worst one (and the only real error): there is no information about washerFluidLevelWarning in the docs, but it appears in the data from the car.

What do you think I should do? Should I write to them about it? I think you can comment on the post, so let me know what you think.

Devlog

1. Added odometer and fuel endpoints.

Funny thing is that Volvo sends in what unit the data is, but the docs say that only metric units are valid, so it really sends always the same unit. Most likely they wanted to add imperial later, or they left it like this for simplicity.

1. Added first version of dashboard.

For now, it’s using polling every 5 seconds (I have planned to change it to WebSocket). It only displays some information and can’t edit anything.

Also, I wrote some HTML and JavaScript. I never liked web development, so I don’t know a lot (I’m learning while I code 😅). It could be that it will look very rough till the end because I don’t have any patience for HTML and CSS.

I “will” do it when I have a very good day, or AI will do it? I would like not to use AI in this way, but I will see.

Edit: Forgot to push the updated version to GitHub I will do it tomorrow because it’s late (it’s tomorrow )

Devlog

1. Added a command accessibility endpoint (it tells if the car can receive commands).
2. I refactored duplicate code in the climate endpoint.
3. Added engine endpoints (they aren’t perfect, but this isn’t the final code).

It was also a frustrating day because I repeatedly forgot to save my code before testing (my bad).

A photo of the error that cost me way too much time today. (I changed it to “/vehicles/{VIN}/engine-status”, but I didn’t save the file.)

I setup my codespace and started working on first few endpoints. Additionally I looked how most of Volvos apis looks that gave me direction to go. That was all time I had today. Also I could add screenshot here because of macOS :(