Read till the end PLEASE 🥺

Devlog 

A lot of changes  from the last devlog only 5 hrs
Mostly bc I add stuff on top of but I will suffer in the future
(See dev branch for these changes)

• Change all connectivity API to start with /connected-vehicle/v2/ to make room for different APIs

  • After that I fixed pytest to reflect that

• I added a location API with a ONE endpoint 

  • There were few iterations 
  • Added scopes for this API location:read If I remember correctly 
  • Unique error responses (because location error look like old (v1) connectivity API

• Fixed that operationID could be a constant 

• Added a config option to use longer API keys

• About here I Fixed the url for location api because it used the connectivity scheme

• Started working on energy API

  • I added all data from it to this project
  • In short one endpoints says what this car is capable of 
    And the other says the values 
  • TODO: add its unique error its half done
  • Scopes corresponding to energy API
  • Fixed that some values and capabilities had the same name (bc of that some bool values where number so a it was important)

WIP

Oauth2 update:

• JWT tokens for access tokens
• WIP token can expire!

what are JWT token?

There consist of three parts header payload and signature
The two first is important for my project the 3 isn’t .
They store info about issuer, when token is active, scopes…
A lot of useless data for this project or useful? We will see

Life

Bc of school I didn’t have a lot of time to write devlog (and write code) but I try to do my best before the end of stardance
The next ship is planned for 28 September

BIRDAY

TODAY (16 September)
Im celebrating my birthday 😄
If you write me a few good words It would be motivating for me. 

Devlog

MAIN

• added a startup baner
• fixed snapshots not saving if website was used

scope

If you didn’t follow from start this branch contains the experimental scope support
which is mostly done but I can guarantee stability that’s why it isn’t pushed to main in fist ship

• made the scope page work
• added a back button
• added button to scope on main page
• fixed snapshots loading/saving

Long time no see…

The school started aaand I didn’t have time I had low motivation

The only thing to do before first ship is docs but I could find time to finish them.

Buut I back now. AND I promise to ship it before 7 of September.

If you are voting on this project PLEASE do not skip.

I have my birthday coming and if the shipwrights doesn’t have a long list it could mean this project payout could be my birthday gift.
If I ofc ship it 😅

devlog

• Small marketing changes everywhere to say that this project doesn’t have any ready code to use
• Added info about error logger on the landing page

Scopes

A long way from last devlog

• Fixed pytest ( A second time)
• TEMPORARY FIX  added so the scope error doesn’t - throw just internal error 
• FIXed the Oauth2 endpoint at least 3 times
• Added a WIP endpoint to edit scope data from API
• Fixed how cars are created so they work with both - Oauth and scopes stuff
• Only looking dashboard page for scopes

compare

I think I forgot to say something in last devlog

• config file if you would like to use different instance
• Toml
• oillevel to oilLever
• AI disclaimer that I used this project to learn tailwind
• Make the doors have different statuses

in mean time

Untracked

WIKI

• Redo the home page
• Started working on stardance path
• A lot of misc that I don’t remember 

other

 I created a small modified volvo example app to show that my app works like the real one

Devlog

Error logger

• added colors to the terminal print out using:
  • \033[31m
  • \033[0m
    Good to know that it is so easy to add colors to text
• added timestamps to log file and - between errors
• Changes how it reads body once again and fixed url encoded requests logging
• My additional information I put in detail in the json response (the real API can send it like that buttty I didn’t see it. info from docs )

additional changes:

• New scenarios mostly about service warnings
• You can add notes to the website thru config files

Scopes

I started working on scopes.
What are they? They are really permissions (you can know them from discord bots or if you login thru GitHub etc.)
I don’t want to put them in this first ship but I needed to work on something (while I work on wiki) and I CAN’T guarantee every thing works after adding them.
You can see it in the scopes branch.

what is done:

• I have made preparation so the additional database (dict) I use for OAuth can store more data
• have updated website func to work with changes and also pytest
• added all possible conve (connectivity API) scopes

WIKI

when I add everything to them I will finally try making a ship

• added the error logger page
• updated the sidebar
• scenario and snapshots page
• a lot of misc

Bonus photos from vacation on baltic sea

Devlog

There was a small (or big) problem in my playground.
If an error was returned in the response, you could only see it if your app handled it or by printing the response.

That’s why I added an error logger.
It can show errors in two ways:

• Terminal
• Log file

How it works

There were two ways of doing it (from what I learned):

• Middleware that captures all responses (this could be helpful in the future).
• Exception handlers (this is what I chose).

I use two handlers:

• @app.exception_handler(RequestValidationError)
• @app.exception_handler(HTTPException)

It was a horrible time searching for why it didn’t work.

At first, I worked in a separate file, but I couldn’t get the (fastapi) app variable into those functions.
So I copied them into main file to make them work first.
I had to change some JSON responses to HTTPException to make the second handler work.

After I captured the first request and printed it, I worked on one function that writes a log and another that prints to the terminal. I also created a class to store useful data.

It works like this:

Exception handler->
        
 ->Put data into class ->

  ->Create response ->
        	 ->Return response
        	 ->Create a background task that logs the error

I create a background task so the response doesn’t wait or even worse fails

In the end I found that I can wrap these func with this simple func to make them work in different file
def setup_error_logging(app: FastAPI):

Added a config option:

• To disable it completely.
• To disable only the log file.
  It also bypasses all internal endpoints to make the logs more readable.

The best fail… 😅

I returned an exception instead of raising it.
I spent a good 15 minutes wondering why the response had status code 200 with a JSON body saying status code 400.

response changes

I also checked how the authorization errors look and added two new ones:

• Missing Authorization header.
• Invalid vcc-api-key header.

WIKI (not counted)

I focus on making a GitHub wiki (new docs)
After ending them and the error logger.

Its time for the first ship !!!!!!!

Nest instability:

I made a backup server : https://frog01-21185.wykr.es/
Its not ideal one, bc some asian countries are blocked but its shouldn’t have any downtime (I hope so)

If an Admin read it why I must copy enter from different text input 😭

Devlog

SITE changes

• I found that some number inputs didn’t use the utility classes. I gave them inputText because they are really the same; the only difference is the HTML type.
• I also forgot to update the reloadable fuel section. It now uses the shorter utility class.
• Made sure that all text in the header is the same size (they weren’t).
• I copied all changes back to the main branch.

config changes

• Then I added a config file using the configparser library.
• also added an option to disable the FastAPI docs.

I started working on

• Wiki: reworking docs.md into a GitHub Wiki with up to date information.
• Error logger, so you can see what’s wrong without printing the API response in your code.

I had some problems with catching the fastapi automatic response but I will leave it for next devlog

Devlog

I forgot to add that I worked on the tests in the test branch, not the main one.

• OAuth2 PKCE testing.
  • Helped me find an error where, if the code was used (it was reset to ""), it was accepted as "".
      Now it correctly returns an error.
• OAuth2 flow testing.
• Warnings and diagnostics now have some simple checks too.

And I merged it into main.

Then I started cleaning up the Tailwind CSS.

NOTE: they are in new branch dashboard/cleanup

Why? Because I used the Play CDN in the past, so I couldn’t create utility classes in a CSS file.

Soooo I didn’t. Andddd there were a lot of Tailwind classes that didn’t fit on my screen.

Now that I started precompiling it, I could add them.

I added 5 unique utility classes. All of them combined are used around ~120 times across all HTMLs.

The longest one:

@utility inputSelection {
   @apply w-full px-4 py-2.5 bg-zinc-950 border border-zinc-800 rounded-xl text-zinc-100 focus:outline-none focus:ring-2 focus:ring-blue-300 focus:border-transparent transition-all appearance-none text-center [text-align-last:center] cursor-pointer;
}

I also minified the CSS file. If I understand it, it removes anything the browser doesn’t need to understand the CSS (new lines, unnecessary spaces…). It’s better because those characters are still sent over the network, and fewer bytes mean less traffic.

While using the new utility classes, I tried to preserve the layout, so everything should look the same as before.

Devlog

Working hard on pytest tests.
I learn how assert works and how to name .
I never used or created test in any language so I think they aren’t perfect (not like they should),but they work😄.
I looked like AI made few and how other people and read some stuff online

Tests created for these endpoints

Around 25 of them

• List cars
• About car
• Engine info
• Engine start/stop
• Climate start/stop
• Windows
• Doors
• Lock/Unlock
• Reduced Guard Lock
• Flash, Honk, and Combination
• Tyres
• Statistics
• Fuel
• Odometer
• Engine diagnostics
• Brakes
• Command accessibility

Still to do 

• Warnings and diagnostics
• Commands

More changes

The tests helped me find and clean up several issues:

• Documentation updates.
• The honk endpoint was ../horn but should be /honk.
• Some values (odometer, fuel) are int, just like in the OpenAPI specification, not as described in the official docs.
• Fixed spelling mistakes:
    - oillevel to oilLevel
    - coolantLever to coolantLevel

Want to help and has access to volvo with active VOC

I need to test engine and climate endpoints but I don’t have an access to a car with it. Soooo if you can contact me on slack

Devlog
Tracking headers implemented :
There are two

• vcc-api-operationId - UUID

• traceparent - W3C traceparent (for now only sends it back)

• dashboard should look good on small screen (its very long but I don’t want to redesign it now)
  This is the reason why I there is much time in this devlog. It was a lot of try and error before something looked good both on mobile and desktop and I liked it . But at least it works know 🙃.

• some small cleanup of comments

• I worked again on internal updates endpoint (hopefully works now)

• started working on pytests (but I will talk about in next devlog (I gave my self 2 days for it)

I really want to get the first ship out, so it isn’t going to be perfect. I still have a lot of features and improvements I’d like to add.

Devlog

I had a problem when I wanted to rewrite the scenario system. It only changed the local version of the Car (It means it really didn’t update anything).
I wanted to update a backup version first, and only if everything was correct, replace the original with the backup.
In the end, I used an already created function to first test and then apply to the car.

Main

• PKCE misspelling fixed.
• Added a landing page with an option to disable it and redirect directly to the login screen (like in the last devlog I have photos of making it).
• Worked on the lights section.
• Fixed the docs URLs.
• Dashboard and WebSocket toggles now work.
• Rewrote and enabled the updates endpoint.
• Validation now catches values that can’t be converted to int.
• Scenario loading into a car instance should now be more consistent with the other functions.
• Improved mobile responsiveness (and then fixed the desktop one). Some elements were outside the screen on mobile (nothing important, but it didn’t look good).
  NOTE: the dashboard with car attributes still needs to be adapted.
• Added windows (because I forgot to 😅) to the dashboard and organised the lighting section.
• OAuth2 and Snapshots buttons should now always be centred.

TODO

• Debug and tracing headers (from the real API).
• Additional instructions.

Then I think it’s finally ready for the first ship.

There are still a lot of things I want to add, but I can’t work indefinitely.

Compare

• The compare app now has the Content-Type fix enabled (like the official API).
• Compiled the Tailwind CSS for the compare app.

NOTE: I will add here more screenshots as link later

Also thinking about adding it frictionless mission but I’m not sure.

Devlog

• Snapshots loading page (screenshots while I worked. I had more but the limit was 4).
• As suggested by the Tailwind CSS tools, changed some classes to more canonical ones.
• You can now delete cars through both the API and the dashboard.
• Snapshot corruption (when the app is force quit) should be fixed.
• Started working on the landing page, but I’ll leave it for the next devlog (mostly because I have on my other laptop).

Fixes to do

• Sometimes the new OAuth2 and Snapshots buttons are off-center.
• Compare app needs fixing (need to enable the Content-Type fix from the official API).
• PKCE spelling in the internal API.

Devlog

The Content-Type problem is SOLVED……
What was the problem? (My reading skills? 🫩) there are two headers with application/json:

• Content-Type (POST)
• Accept (GET)
  The Accept header isn’t required  ( can be */*, application/* or application/json).
  So the Content-Type mystery is mostly FIXED but I still need to check with a real Volvo car if Content-Type is actually required. (I’ll do it tomorrow.)

Changes:

• Accept is now handled by my API like in the official API.
• Added Content-Type checks (like the docs say, meaning it’s required).
• While proofreading the docs, I found that PKCE is written as PCKE in one internal endpoint. (Not fixed yet.)
• Small README update (I try to keep it up to date).

Scenario page:

• You can now load a scenario using the GUI.
• Recompiled the Tailwind CSS.

I attached screenshots showing it (you can also see snapshot button but its not implemented YET)

The comparison app is now online! 

Comparison app:  https://compareplay.kls.hackclub.app/

I also updated the main app with the new dashboard
design: https://playground.kls.hackclub.app/internal/welcome

devlog

• Tailwind CSS is no longer loaded from the CDN. I think its now precompiled.

Note to others: 

Remember to update your banner to feature your app (see #stardance on Slack). Otherwise, your ship will be rejected.

EDIT: A lot of bots try to connect to my apps do you think I should make a honeypot?

Devlog

I found another way to hide the fuel stat when it isn’t useful for a particular type of car: the HTML hidden attribute.

At first, I thought I should add or remove the element hidden, but that turned out to be more complicated than I expected. I think using hidden is still a cleaner solution but I still using templates files.

While working on the dashboard, I wanted to add units like km, L, and % to some values. Instead of handling that in Python, I added another div with some margins and, in a few places, used flex so everything stays on the same line without adding more backend logic.

• Added more page changes thru HTMX (nearly all pages use it).
• Creating a new car now refreshes the page.
• when an error occurs, I use HX-Reswap and the HX-Retarget response header (when creating new car as proof of concept).
• Added HTMX transitions to the OAuth2 settings page.(all pages have transitions)

What to do before the first release

(Mostly a checklist for myself 😅)

• Content-Type checks.
• Scenario and snapshot system support in the dashboard.
• Main showcase page.
• Finish the remaining documentation.
• Two READMEs: one for the main repository and one for the companion app repository. I’m thinking about having one technical README and another one that’s easier to understand for people who don’t code.
• Better error handling in the dashboard. Right now, most errors are just displayed as plain text instead of being part of the page.
• deploy updated version on nest

I wanted to add a video but MacOS made me a half gig and I don’t think stardance would handle

Devlog

Most of my time was spent working on the dashboard with Tailwind CSS. It took a lot of experimenting to find a design I actually like.

I also changed how HTMX updates the dashboard through WebSockets.

Before:

• A dedicated template was rendered every time to update that part of the dashboard.

Now:

• Only the text containing the updated value is replaced.

That said, in the future it won’t always be just text. For example, if the fuel type changes from hybrid to electric, the fuel level should disappear from the dashboard instead of just changing its value.

While working on this, I found a bug caused by HTMX sending boolean values as strings. This caused climate settings to be marked as invalid. I need to distinguish between an invalid value and an invalid attribute instead of always treating the entire attribute as invalid.

Note to myself

• Add transitions.
• Make all HTML pages use the same CSS file from now on.
• Update the version on nest server and make a public companion instance

Aaand that’s all. Making websites is painfully slow.

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

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 :(