Display Home Assistant Values on Kraken AIO
While our PC is still not OK with the CPU being the way it is, the NZXT Kraken AIO solution is cooling the CPU well. It managed to knock down the temperatures by almost a half. I am very satisfied. I guess we had to switch to the water cooling eventually. The modern components require robust solutions. They get very hot.
For a long time I was a fan of silent monolithic closed cases that I never have to see, but having one with transparent sides looks cool. The only issue I have with it is that it's bulky. And heavy. No matter how many components I remove, the ones that remain get heavier.
The AIO features a 640x640 px circular display and the good folks at the NZXT allowed users to display a web page on it. They also added the NZXT API access so we can query the CPU, GPU, fluid temperatures etc. The NZXT developer documentation details the available variables.
Since it's a web page in itself, there have already been some interesting solutions made by the community such as Google Photos slideshow, YouTube video display or Spotify album art. While I had the Spotify integration active for a couple of days, I wanted to have something more useful because I am not listening to Spotify all the time.
Our apartment is full of smart devices, although still not up to the level of the old apartment, but getting there. I decided to roll up my sleeves and make an integration that would display the local Home Assistant instance data on the Kraken AIO LCD. I had to keep stopping myself from overthinking and overengineering the thing. The integration was supposed to be a short showcase project. I had to consider several things:
Kraken display
The dimensions of it are 640 pixels in width and height. NZXT shows the width and height dynamically, but only in JavaScript (window.nzxt.v1.width and window.nzxt.v1.height respectively) and I still needed to account for it being circular. Pretty much, the browser window is in kiosk mode so a 100% should be okay, however, making sure that the interface fits in a circle was something that constantly had to be on my mind.
Web page configuration
The displayed page is shown all the time. If the query string parameter ?kraken=1 is present, the configuration is not shown. Without the parameter, it is shown next to the interface. I already mentioned the backendless part so it's parsing the parameter by using the URLSearchParams capability of the browser.
The configuration is a simple form that shows several text fields. The styling is done with DaisyUI and Tailwind. Upon the form save, the information is not POSTed, but saved to localStorage instead. The fields are:
- The long lived access token for the Home Assistant. You make it once in the Home Assistant UI from the Security section of your profile. Once created, the token is shown once and the security is on the user not to share that token further. It is like a quick password so you need to make sure that it's not exposed publicly anywhere ever.
- The Home Assistant instance URL, where to ask for the data, in our case, it is the Nabu Casa provided URL since I'm not exposing the service manually to the world, but if you do, make sure the necessary security is in place and the page must be served over HTTPS.
- The information for the three gauges which are showing the temperatures from -20 to 35 in form of three fields per entity
- Label (what to display)
- Home Assistant Entity (where to query the data)
- Home Assistant Entity Attribute (not really mandatory if the number is exposed on the entity, but it can be drilled into)
- The forecast Home Assistant Entity and Attribute
I didn't go for the dynamic picker because that would make the project blow out of the scope. I also didn't put in any validation because that would quickly lead to the overengineering.

Web page display
Once the parameters are saved on the configuration page to the local storage, they persist and are available in the second window that is not for the configuration, but for display only. It is the same browser, after all. The Home Assistant REST API is queried for the initial data via regular endpoints, then a reconnecting websocket is established on the Home Assistant Websocket API and it listens to the data changes and updates them if necessary. Home Assistant uses that way to interact with its dashboard. I used Apache eCharts gauge because it let me build something good quickly enough. I was toying with the raw SVG, but opted for a library in the end. No need to reinvent the wheel. I can live with the performance hit because the service is not meant to be super fast. To describe it a bit, it's three gauges like a concentric circle cut out on the bottom quarter. The temperatures are from -20 to 35 which is common for the area I'm in. The textual display is in the middle. Below, in that cut-out, there's the forecast icon.

GitHub IO page
Basically, the repo is configured to build a page on the GitHub so it needs to contain the index.html file for it to work without some extra long URL. Enabling the pages is done via repo settings. The GitHub pages are accessed via HTTPS, as it should be, so you have to make sure that Home Assistant instance is also accessed via HTTPS. The mixed communication is not working because they both need to be on the same protocol. That's why Nabu Casa can solve the certificate if you don't have it exposed yourself. You also can't POST due to the CORS, so you need to enable CORS for the page explicitly in the configuration.yaml of the Home Assistant. This ensures the app is pretty much static and no back-end is needed.
The result is actually pretty neat and I'm happy with it.

I am not sure if I will play more with it. Possibly yes if I wanted to expand on it, but for now, the repo is public under Kraken Home Assistant and you can use it directly via Kraken Home Assistant Github IO page. You can also drop me ideas or make improvents yourself. The application is a bit niche since not everyone uses Home Assistant and not everyone has Kraken AIO, but there it is.