Others on dotnet.work

Use Claude AI in Home Assistant Studio

dotnet@oles.cloud (Ole Albers) — Wed, 04 Feb 2026 18:17:00 +0100

Sometimes you have to configure stuff in Home Assistant the “painful” way: Working with Yaml-Files instead of using the UI. Therefore Studio Code Server is the first choice for most of us. But Yaml isn’t fun. Yaml in hass.io especially isn’t fun.

But there is ai for the rescue. AI isn’t always the solution, but working with ugly configuration formats is exactly where it is good at. So let’s add claude to the Studio Code Server

Studio Code Server

I assume you already have installed the Studio Code Server. If you haven’t: It is a simple Add-On. Just follow the official instructions: https://github.com/hassio-addons/addon-vscode/blob/main/vscode/DOCS.md

Studio Code Server will then be installed as a docker container. (Don’t worry. No need to know anything about docker. This works in the background)

Preparing

Claude needs NodeJs which isn’t in the studio code server docker. But don’t worry, this is easy to solve. You could connect to the docker and install the required packages using app-get. But while this works this has two disadvantages. First it is a bit more complicated if you are not at home with Linux Systems and most important: Any update of the Addon would kill NodeJs and you would have to do this all over again.

Thankfully the Add-On devs thought of an easy way to do that for you. Just go to Settings - Add-Ons - Studio Code Server. There go to Configuration and in the “packages” enter “npm” and then “nodejs”. Do not enter both at the time. Each one of them by enter. After that there should be two bubbles on top:

If you prefer editing in yaml, here is your content:

packages:
  - nodejs
  - npm
init_commands: []

Save and restart the addon. Don’t be alarmed if this takes a LONG time. There will have big packages to be downloaded and installed into that container. This will take minutes even on a fast machine and especially if using a Raspberry Pi.

Adding Claude

Now you can switch to the code server. Select Extensions on the left side, enter “Claude” into the search and install “Claude Code for VS Code”. After that you should have that typical “Claude Star” on the top right corner. You will be greeted with the authentication method. Select the one that matches your account. (Most likely Claude.ai Subscription)

If after using the Login clicking “Open” does not work because you get redirected to a local url use the url instead that is shown in the textbox:

Just copy paste that url manually and paste the returning code into Studio Code.

Using Claude

Now you can open Claude using the star and let him do the work

That is it. Now you can use claude in Home Assistant Config Files

Grafana - Notifications for Mastodon

dotnet@oles.cloud (Ole Albers) — Tue, 14 Oct 2025 12:28:00 +0200

Grafana is a very useful tool for monitoring your own programs, discovering silly bugs, or simply looking at beautiful graphs :)

Another feature is “Alerts”. These can be configured arbitrarily, whether high CPU load, too many errors in the log, or similar should trigger an alarm.

This post won’t be about the alerts themselves, but rather about sending already configured alerts to Mastodon. These are called Contact Points in Grafana and initially don’t offer Mastodon integration. However, this can be worked around with a few simple steps.

Mastodon

First, we need some preparation, because of course not just any random application can post to Mastodon under our name (thankfully).

Therefore, we log into the instance of our choice, select Settings and then Development. This should look something like this:

(If the list is empty, it means you haven’t created any applications yet. If it’s not empty, you don’t need this part of the tutorial at all, because you’ve already done this before 😀)

Click on New Application here and choose a name. Leave the other two text fields as they are:

For permissions, you only need “write:statuses”.

You should now see a page showing the secrets. You only need the access token (bottom value) from this.

Grafana

Now we can switch to Grafana. There’s a menu item called Contact points under Alerting. At least Email should already appear in the list. We now add a new destination with "+ Create contact point":

The name is of course freely selectable, for integration choose Webhook

For the URL, enter the following:

https://chaos.social/api/v1/statuses?access_token=<Secret>

Instead of , enter the access token from Mastodon. If you now click on Test (and leave the default values as they are), a new entry will already be created in Mastodon under your name:

Getting Down to Business

That’s nice for starters, but we obviously can’t do much with just “firing”. We want to see the actual error. Also, we probably don’t want to inform the whole world. It makes more sense to simply mention ourselves and set the visibility to “direct”.

To do this, we open Optional Webhook Settings, set HTTP Method to POST and click the “Edit Payload Template” button next to Custom Payload. A new window pops up and after we’ve selected Enter custom payload template there, we can enter the following content:

{
  "status": "Alert: {{ .CommonLabels.alertname }}\nStatus: {{ .Status }}\n{{ range .Alerts }}{{ .Annotations.summary }}{{ end }}"
}

Now the alert is already a bit more meaningful:

Still missing the private mode. This can be set via Visibility. Additionally, it’s best to mention yourself. (I’ve modified my name slightly here so you don’t make a copy-paste mistake :) )

While we’re at it, I’ve also used the spoiler-text.

{
  "status": "@guacamoleeeee {{ .CommonAnnotations.summary }}",
  "visibility": "direct",
  "sensitive": false,
  "spoiler_text": "🚨 {{ .CommonLabels.alertname }} {{ .Status }}",
  "language": "en"
}

The result is then as follows:

A complete list of Mastodon properties can be found here: https://docs.joinmastodon.org/methods/statuses/

Have Fun

Wishing you many alerts might be a bit strange, but I hope I could help with this.

Wayback Machine and 301 redirects

dotnet@oles.cloud (Ole Albers) — Tue, 15 Nov 2016 12:00:00 +0100

As you might know: the wayback machine from archive.org saves snapshots of websites. It does this automatically or can be forced to do so. However. If you ever had a 301 redirect on your site you are very much doomed.

Like browsers also the wayback-machine caches the redirect and does not continue to take snapshots from your sites. Even if you enter your url into the wayback-machine, you still will be redirected.

You can however force it to ignore the cache by manually store your site again:

https://web.archive.org/save/[YOURSITE]

for example:

https://web.archive.org/save/http://blathering.de

Et voílà: Everything works nice from now on.

[Image is CC-BY-NC-ND © David Baldingerhttp://www.dbaldinger.com/opinion_cartoons/second_page/wayback.html]

Getting rid of Proxy limitations using Fiddler

dotnet@oles.cloud (Ole Albers) — Fri, 16 Sep 2016 12:00:00 +0200

If you work in a company that uses Proxy authentication (aka forces you to enter a password to access websites) and are a developer you know my pain: Some Most applications just don’t really like proxies. Visual Studio itself for example does not like proxy authentication at all and responses with a wide variety of error codes (407 for example).

You can get rid of all these errors through different workarounds, but these are a real PITA.

In addition the application you code itself needs Internet access, for example if you develop Office365 AddIns, you are very much screwed.

After a long research I finally found a solution using Fiddler.

Most developers already use Fiddler for debugging reasons so there isn’t even any software that needs to be installed.

First of all:

Start your computer. You should not have been entered your Proxy credentials yet. Use Fiddler as proxy in your IE and enter your real Proxy in Fiddler:

Default Proxy-Settings to use Fiddler

Proxy-Settings in Fiddler

Do not select “System Proxy”. Otherwise. Fiddler will enter itself here, because Fiddler is the System Proxy right now.

Now open your favorite browser (except FireFox, as it uses its own proxy) and open any site that opens up the Proxy authentication window. Enter your credentials and load that site. In Fiddler you should now see (at least) one entry with response code 407 followed by a few entries with 200:

Select the entry with StatusCode 200 and display the Request Headers. Under “Security there now is a line with “Proxy-Authorization: “…

Copy that line.

Now Enter Ctrl-R in Fiddler to open the rules file. Look for

static function OnBeforeRequest(oSession: Session) {

in that file and add the following line directly at the top of the function:

oSession.oRequest[“Proxy-Authorization”] = “Basic DBDDHKPadasdkahsdasd=”;

where you replace the token behind “Basic” with the value you copied before.

Now save CustomRules.js and from now on no application has to enter any more Proxy passwords (as long as you use Fiddler as System Proxy)

If you are forced to change your Password, remove this line in the configuration file, and repeat the procedure from the beginning with the new password.

That’s it, mostly. For more comfort I would recommend to use the proxy switcher if you have to change the proxy more often.

It's because they at Microsoft hate web developers

dotnet@oles.cloud (Ole Albers) — Tue, 14 Jun 2016 12:00:00 +0200

That remark isn’t mine, it is from StackOverflow. :)

I had an issue that my Office365-App did not work correctly on the machine of ONE user. Sadly though that user was the Microsoft validation crew. I was unable to reproduce the error and did not even see any clue in the Server logs. Everything seemed to work fine.

Finally I managed to reproduce the error. It only happened under the following conditions: 1. Internet Explorer 11; IE - what else :) 2. Caching in IE has to be on “Automatic” 3. Developer Console MUST NOT be open 3.1. In fact: Even if you open it and close it afterwards, the error does not appear anymore 4. I had to retract/reinstall the app each time to check this behaviour which took about 10 minutes every time

I had issues with console on older IEs before, but at least angular uses some magic, so that issue is resolved. Nearly all questions in the web combining IE and console repeat the solution that you may not use “console.log()”.

But the real issue was: Caching. IE - in its wisdom - decided that the API-Call that returns the installation state should be cached. That cached value always responded that the app is not installed, even if it was. So the user kept receiving the “please install” - Page.

Any other browser (Chrome, Firefox, …) doesn’t cache these calls. And the IE doesn’t either when you open the Developer Console (what you do if you want to debug an application) which makes it really hard to track that error.

So the solution is to make sure the call isn’t cached using No-Cache-Headers or just by adding a random value to the target address. And of course resist the urge to display a reminder to use another browser. That could be bad for the validation results :)