This script provides an easy way to switch the mainsail release to different zip.
wget -O ~/switch-mainsail.sh https://gist.githubusercontent.com/ammmze/3243dd878ccde5d0c486e3650e0daa49/raw/switch-mainsail.sh
chmod +x ~/switch-mainsail.sh
Note
Update
PR to address this cause for Timer Too Close has been merged. Will leave this gist here for reference, but this should no longer be an issue.
Note
tl;dr Look at klippy memory usage. Higher memory usage (yes 140MB is high in this context) can cause garbage
Most VPS solutions have a pretty limited selection of OS's that are available to install on your VPS. Talos is unlikely to be one of the options. While some VPS providers may allow you to open a ticket and receive help installing from a custom ISO, I didn't want to do that. I wanted a way to self-serve and get this installed. This took a bit of digging to learn some of these tools a bit more than I had in the past, but I think this is in a good place.
I haven't permanently put these nodes in my cluster yet, but did verify that I could get an installation done successfully.
#!/usr/bin/env sh | |
# Workaround for https://github.com/swc-project/swc/issues/7315 | |
DIR="${1}" | |
if [ -z "${DIR}" ]; then | |
echo "Missing path to search" | |
echo "Usage: ${0} ./path-to-search" | |
exit 1 |
package com.github.gist.ammmze.handlebars.helpers; | |
import com.github.jknack.handlebars.Options; | |
import com.github.jknack.handlebars.helper.IfHelper; | |
import java.io.IOException; | |
import java.text.NumberFormat; | |
import java.text.ParseException; | |
import java.util.ArrayList; | |
import java.util.List; | |
import java.util.regex.Matcher; |
--- | |
apiVersion: apps/v1 | |
kind: DaemonSet | |
metadata: | |
name: chrony | |
namespace: host-system | |
spec: | |
selector: | |
matchLabels: | |
app: chrony |
--- | |
apiVersion: helm.toolkit.fluxcd.io/v2beta1 | |
kind: HelmRelease | |
metadata: | |
name: external-dns-public | |
namespace: network | |
spec: | |
interval: 5m | |
chart: | |
spec: |
This is a quick documentation on how I've setup akri in my kubernetes cluster to make my Conbee II stick available to zigbee2mqtt as a remote device. This allows zigbee2mqtt to run on any node in the cluster. The advantage to using Akri over node-feature-detection and node affinity rules to run zigbee2mqtt on a given node is that when a device is unplugged Akri will automatically remove the pod. So I can move the stick from one node to another and less than a minute later the stick is ready to be used again.
Eventually Kubernetes plans to add requiredDuringSchedulingRequiredDuringExecution
affinity rules which in theory could
give us a similar effect where zigbee2mqtt could connect directly to the device rather than connecting remotely, but we could
simply move the stick and the zigbee2mqtt pod would follow it.
package com.example.csv; | |
import com.opencsv.bean.ConverterDate; | |
import com.opencsv.exceptions.CsvDataTypeMismatchException; | |
import java.lang.reflect.InvocationTargetException; | |
import java.time.LocalDate; | |
import java.time.LocalTime; | |
import java.time.format.DateTimeFormatter; | |
import java.time.temporal.Temporal; | |
import java.util.Locale; |