June 2023 Bits#

This page contains small entries about random technical stuff I have done throughout June 2023.

June 7 - Upload speed in Proxmox containers and VMs very poor#

Just struggled through watching a movie over my Plex. Tried a speedtest on my older server, which is not running Proxmox. Decent upload speed. Tried a speed test in a Windows VM and in an Ubuntu Docker container inside an LXC and got terrible results for the upload speed (3-4Mbps). I used the speedtest cli in Ubuntu and for the Windows VM I just used their website.

Someone had a similar problem. Something about this happening specifically on Ubuntu installs. There’s also some talk of the fact that you should really use an Intel NIC, but even that isn’t a for sure cause of the problem.

The solution? Reboot my Proxmox host? No. Reboot my router. Yeah. That fixed it.

Unrelated but#

Would be cool to install this in my suite of web apps: https://hub.docker.com/r/openspeedtest/latest. That is for running a speed test from your browser. Another cool app is this: https://registry.hub.docker.com/r/e7db/speedtest/ which from what I can tell runs a speed test on the server that program is running on.

Would also be cool if I made a speed test based on ubuntu:latest and installed speedtest using speedtest cli. I could publish it on ghcr.io .

June 17 - Installing Mosh#

I just wrote about getting my WireGuard setup: June 2023 WireGuard setup. Now that I have access to my local network, it makes sense to install mosh. I could run a simple apt install mosh, but I’m running Debian 11 at the moment, which won’t result in the latest mosh server. apt-get -s install mosh shows the version that would be installed is 1.3.2 - the actual latest is 1.4.0. The comparison between 1.3.2 and 1.4.0 shows quite a lot of changes. Luckily mosh can be installed with brew.

To install brew on Debian, just go to https://brew.sh/ to get the install command. Now I can run brew install mosh. Now I have the mosh and mosh-server binaries installed. When I run mosh on my local machine, I do have to customize how I call it so it starts with: mosh --server /home/linuxbrew/.linuxbrew/bin/mosh-server.

The only downside of mosh is that it does not have full OSC 52 support (support for copy-pasting). Looks like if issue 1104 would get merged it would be better.

June 18 - linuxserver.io docker images to try out#

Today I went through https://docs.linuxserver.io/ to see all the images they provide. I found these that I want to install and check out:

June 18 - Looking into Lemmy#

With the Reddit blackout still in effect on many subreddits, I have decided to look into Lemmy. I’m trying to be a part of the protest by not browsing Reddit even though some subreddits I follow are back up. I was looking at some instances here: https://join-lemmy.org/instances. I created accounts for lemm.ee, programming.dev, lemmy.world and lemmy.blajah.zone. I’m now giving Jerboa for Lemmy a shot.

June 18 - Thinking about SolarThing Data Retention#

A while back at Wild Mountain Farms, we had been running CouchDB and InfluxDB. I eventually got rid of InfluxDB because it was another database to maintain and I wanted CouchDB to be the source of truth. The solution for data retention in CouchDB was and still is this: update the database with new data frequently, but usually replace old data so that you only keep ~60 packets per hour. When we used InfluxDB, I had tried setting up differenet retention policies so that some packets would be kept forever and some would be deleted after a short period of time. I don’t believe either of those solutions is ideal. I ran into InfluxDB’s documentation on downsampling or the 2.7 downsample docs, InfluxDB’s approach to this is interesting. It basically seems to be aggregating data and keeping the aggregated data for much longer.

I want to eventually improve SolarThing’s retention, but I would really like to do it in a way that doesn’t require weird calculations on the client side. I remember the logic for the InfluxDB 1.X retention policies was so weird that when I had to create another handler for InfluxDB 2.0, I didn’t even port that logic over. I would also like to do this in a way that doesn’t require “nightly jobs” to remove data from the database. I think realistically, we can’t do some nice aggregation thing that InfluxDB does with the high resolution data, but we should at least be able to keep 1 packet per second for a couple of hours. It would make for some nice graphs and would allow for for accurate smoothing of graphs. High resolution data makes a lot of sense, especially for the past couple of days.

June 20 - Wireguard Connection on my laptop stopped working#

I just opened up my laptop and tried connecting to services on my local network, but I couldn’t access them. So, Wireguard must be down. Turns out, nope! Running just fine, but it seems my public IP address had changed, so it hadn’t updated to use the new IP my duckdns was pointing at. Looks like someone on Reddit had the same problem. A simple sudo wg-quick down wg0 and a sudo wg-quick up wg0 fixed the problem. I have my router restart on Monday mornings, and I didn’t notice this yesterday since I wasn’t on my computer then.

I think there’s a way to automate this fix, but that’s something for another time.

June 24 - Outback MATE 2 Configuring Generator Settings for FX#

At Wild Mountain Farms we have an Outback MATE 2 with 2 FXs and 2 MXs. The FXs can charge the batteries when a generator is running. SolarThing is setup to send a DROP command before sending an AUX OFF command, so that switching over to battery power should have minimal impact on electronics. However, unless the FXs are completely done will their absorb charge, the DROP command is not accepted.

We figured that even if the DROP command is not accepted, we could alter some configuration that would still make our networking equipment happy with the “dirty” power transfer. On the MATE we navigated to ADV/FX/GEN. We saw a couple of settings that we might want to alter. The lower limit was set to 108 vac. The transfer delay was set to 60 cycles. To figure out what these meant I tried looking at MATE Series Overview, but it only shows how to navigate the menus, not what each setting means. We have two VFX3524 Outback FX units, so I found FX Series, but that doesn’t say anything about what the Lower Limit or Transfer Delay does. I read AC Transfer switching time and Long transfer time causes system failure. One person even recommends setting it to 2 cycles or less, which I think is not what we should do, but hey, at least it gets the job done for someone. I think we likely don’t need to change “lower limit”. I will now change the “transfer delay” to 20 cycles. We won’t be testing this today (June 25), so hopefully it is fine the next time we run the generator.

Update (June 26): it worked!

June 29 - Unifi Access Point Stopped Working#

Back on June 25 we mounted one of our UAP-AC-M properly. We ran an ethernet cable to BatteryPi in the battery room. We assumed that it would work fine and essentially would just be like extending the wired network. This worked fine for a few days until today when the AP was failing to adopt. I tried factory resetting it. It worked for a bit, but since I had plugged the RPi back in after re-adopting it, the AP wasn’t happy for long.

We researched the problem and came across this unifi thread. We unplugged the Pi’s wired connection and the AP soon became happy again. There don’t really seem to be solutions for this online other than that this setup isn’t officially supported by Unifi.