Louwrentius

Before Chat-GPT caused a sensation, big tech companies like Facebook and Apple were betting their future growth on virtual reality. But I'm convinced that virtual reality will never be a mainstream thing. If you ever used VR you know why:

1. A heavy thing on your head that messes up your hair
2. Nausea

The focus on virtual reality felt like desperation to me. The desperation of big tech companies trying to find new growth, ideally a monopoly they control¹, to satisfy the demands of shareholders.

And then OpenAI dropped ChatGPT and all the big tech companies started to pivot so fast because in contrary to VR, AI doesn't involve making people nauseated and look silly.

It's probably obvious that I feel it's not about AI itself. It is really about huge tech companies that have found a new way to sustain growth a bit longer, now that all other markets have been saturated. Flush with cash, they went nuts and bought up all the AI accelerator hardware², which in turn uses unspeakable amounts of energy to train new large language models.

Despite all the hype, current AI technology is at it's core a very sophisticated statistical model. It's all about probabilities, it can't actually reason. As I see it, work done by AI can't thus be trusted. Depending on the specific application, that may be less of an issue, but that is a fundamental limitation of current technology. And this gives me pause as it limits the application where it is most wanted: to control labour. To reduce the cost of headcount and to suppress wages.

As AI tools become capable enough, it would be irresponsible towards shareholders not to pursue this direction.

All this just to illustrate that the real value of AI is not for the average person in the street. The true value is for those bigger companies who can keep on growing, and the rest is just collateral damage.

But I wonder: when the AI hype is over, what new hype will take it's place? I can't see it. I can't think of it. But I recognise that the internet created efficiencies that are convenient, yet social media weaponised this convenience to exploit our fundamental human weaknesses. As shareholder value rose, social media slowly chips away at the fabric of our society:

trust.

Introduction

Victron Multiplus-II inverter/charges are configured with the veconfigure¹ tool. Unforntunately this is a Windows-only tool, but there is still a way for Apple users to run this tool without any problems.

Tip: if you've never worked with the Terminal app on MacOS, it might not be an easy process, but I've done my best to make it as simple as I can.

A tool called 'Wine' makes it possible to run Windows applications on MacOS. There are some caveats, but none of those apply to veconfigure, this tool runs great!

I won't cover in this tutorial how to make the MK-3 USB cable work. This tutorial is only meant for people who have a Cerbo GX or similar device, or run VenusOS, which can be used to remotely configure the Multipluss device(s).

Step 1: install brew on macos

Brew is a tool that can install additional software

1. Visit https://brew.sh and copy the install command
2. open the Terminal app on your mac and paste the command
3. now press 'Enter' or return

It can take a few minutes for 'brew' to install.

Step 2: install wine

Enter the following two commands in the terminal:

brew tap homebrew/cask-versions
brew install --cask --no-quarantine wine-stable

Download Victron veconfigure

1. Visit this page
2. Scroll to the section "VE Configuration tools for VE.Bus Products"
3. Click on the link "Ve Configuration Tools"
4. You'll be asked if it's OK to download this file (VECSetup_B.exe) which is ok

Start the veconfigure installer with wine

1. Open a terminal window
2. Run cd
3. Enter the command wine Downloads\VECSetup_B.exe
4. Observe that the veconfigure Windows setup installer starts
5. Click on next, next, install and Finish
6. veconfigure will run for the first time

Click on the top left button on the video to enlarge

These are the actual install steps:

How to start veconfigure after you close the app

1. Open a terminal window
2. Run cd
3. Run cd .wine/drive_c/Program\ Files\ \(x86\)/VE\ Configure\ tools/
4. Run wine VEConfig.exe

Observe that veconfigure starts

Allow veconfigure access to files in your Mac Download folder

1. Open a terminal window
2. Run cd
3. run cd .wine/drive_c/
4. run ls -n ~/Downloads

We just made the Downloads directory on your Mac accessible for the vedirect software. If you put the .RSVC files in the Downloads folder, you can edit them.

Please follow the instructions for remote configuration of the Multiplus II.

Introduction

The other day I was supporting a customer with an Elixir-based platform that would make use of Elixir libcluster, so messages on one host can be passed to other hosts. This can - for example - enable live updates for all users, even if they are not communicating with the same application server.

Encryption

Elixir's libcluster does support encrypted communication using TLS certificates however I was struggling with the help of an application developer to make it work.

"severity":"warn","message":"[libcluster:example] unable to connect to :\"app@Host-B\"

I'm absolutely open to the idea that we did something wrong and certificate-based encryption will work, but we were time-constrained and we decided to opt for another solution that seemed simpler and easier to maintain.

Wireguard as the encrypted transport

I deployed a Wireguard mesh network between all application servers using Ansible, which was straight forward. We just provisioned all hosts into the /etc/hosts file to keep things simple.

In the table below, we show a simplified example of the setup.

The Elixir applications would only know about the Host-A|B-wg hostnames and thus communicate over the encrypted VPN tunnel.

The problem with wireguard and libcluster

The key issue with libcluster is that when Host-A connects to Host-B, it uses the DNS hostname Host-B-wg hostname. But the actual hostname of Host-B is - you guess it: 'Host-B'. This means there is a mismatch and for reasons unknown to me, the libcluster connection will fail.

So the target hostname as configured in libcluster must match the hostname of the actual host! Since libcluster seems to make usage of domain names mandatatory, using IP-addresses was not an option.

If we would point Host-B to it's Wireguard IP-address (192.168.0.2), the problem would be solved. However, in that case, Wireguard doesn't know about the external 10.0.11.231 IP address and also tries to connect to the non-existing 192.168.0.2 address. So the Wireguard tunnel would never be created.

The solution

The solution is not that elegant, but it works. We still point the Host-B domain name to the wireguard IP address of 192.168.0.2 but we create an additional DNS record specifically for Wireguard, pointing to 10.0.1.231, so it can setup the VPN tunnel.

This is what /etc/hosts looks like on Host-A:

10.0.10.123 Host-A
192.168.0.2 Host-B
10.0.11.231 Host-B-wg

And this is what /etc/hosts looks like on Host-B:

10.0.11.231 Host-B
192.168.0.1 Host-A
10.0.10.123 Host-A-wg

Evaluation

Although all choices are a tradeoff, for us, the Wireguard-based solution makes most sense. Especially now that we have an encrypted tunnel between all hosts and any future communication between hosts can thus be encrypted without any additional effort.