frndc.saschaschroeder.eu

gehrke_test menu
Germany
Mein kleines Refactoring-Projekt der heimischen Infrastruktur zieht immer größere Kreise.

Wenn ich den fetten Server nachts abschalten will, brauche ich 24x7 Ersatz in klein. Dafür habe ich gestern eine APU 1D4 mit # 13 bestückt.

Stellt sich raus, dass ich vor 10 Jahren einen # ebenfalls auf einer APU 1D4 installiert habe, der alle 5 Minuten 24x7 die Zählerstände des digitalen Stromzählers und vom # in eine Datenbank protokolliert. Ach ja, langsam erinnere ich mich wieder.

Die Software dafür läuft im wesentlichen seit dieser Zeit ununterbrochen (ausser Stromausfällen) in meinem hinterletzen Subnetz. Zum Glück hatte ich damals in einem # dokumentiert, was ich damals verbrochen hatte.

$ grep PRETTY /etc/os-release
PRETTY_NAME="CentOS Linux 7 (Core)"


Da muss ich dann jetzt wohl auch mal ran...

#
#Debian #Datenlogger #Wechselrichter #MediaWiki #EinmalMitProfis
Link zum Originalbeitrag
gehrke_test
gehrke_test menu
Germany
Der Tag ist doof!

Ich dachte mir, meinen Plan etwas voranzubringen, den fetten Server für Teile der Nacht runterzufahren, um Energie zu sparen. Dazu müsste ich Teile der dortigen Services auf einen anderen 24x7 Server migrieren, der weniger # schluckt.

Meine prädestinierte # dafür ist die PCEngines APU 1D4, davon habe ich hier noch einige rumliegen. Die sind sparsam und grundsolide, aber auch alt. Performancetechnisch sollten die aber noch ausreichen.

Meine naiven Versuche mit # 10 scheiterten ebenso wie mit Release 9, vermutlich wegen mangelnder Hardwareunterstützung:
* RHEL 9: Anhebung des x86_64-Baselines auf x86-64-v2
* RHEL10/CentOS Stream 10: x86-64-v3 vorausgesetzt

Schade, weil ich mit CentOS viel Erfahrung habe. Aber da kann man wohl nix machen. Ich will aber weder den Plan noch die vorhandene Hardware aufgeben, jedenfalls jetzt noch nicht.

Also gehe ich mal wacker auf die Suche nach einer anderen #.

Kriterien:
* möglichst langer Software-Support (Security)
* Support von #

Die KI sagt, dass vermutlich # 13 am ehesten zu empfehlen ist. Ich bin geneigt, dieser Bewertung zuzustimmen. Debian hatte ich auch schon mehrfach im Einsatz, ein gewisses Grundwissen ist also vorhanden.
Für Debian 13 wird aktuell ein Support bis 30. Juni 2030 genannt.

Entscheidungsmatrix der KI. Reihenfolge: Debian 13, Debian 12, Ubuntu, openSUSE Leap, Alpine Linux

# # # # #
#Strom #Hardware #CentOS #Distribution #Podman #Debian #PCEngines #APU1D4 #APU #EnergieSparen #GNU/Linux
Link zum Originalbeitrag
gehrke_test
13 Kommentare - Zeige mehr
gehrke_test menu
Die # misst die # mit 5,4 Watt. Das ist ein Bruchteil des abzuschaltenden Servers und somit IMHO völlig OK.

Screenshot Shelly Plug S - Verbrauchswerte

Screenshot APU 1D4 btop - hauptsächlich idle

War doch noch ein guter Tag...
Screenshot Shelly Plug S - Verbrauchswerte
Screenshot APU 1D4 btop - hauptsächlich idle
#Shelly #APU1D4
Link zum Originalbeitrag
gehrke_test
gehrke_test menu
@Pascal
Teile der dortigen Services sollen dauerhaft umziehen - diese werden 24x7 benötigt und sollen migriert werden.

Andere sind nachts verzichtbar. Die werden dann mit dem fetten Server abgeschaltet.
Link zum Originalbeitrag
gehrke_test
gehrke_test menu
Germany
Meine Journey mit # geht weiter, etwas Feinschliff ist angesagt. Bislang hatte ich immer nur das WebInterface als Admin-User genutzt, aber da nun auch der erste echte Nutzen im Raum steht, habe ich heute mal die App auf meiner Wanze installiert. Und mit ihrem Einverständnis auch auf der von der besten Ehefrau von allen.

Eigentlich nur ganz naiv, um etwas komfortabler das # steuern zu können.

Dann habe ich gesehen, dass man darüber serverseitig auch sehen kann, welchen Akkustand das Device hat. Und dann, dass es drölfzig Sensordaten gibt, die darauf warten, vom Besitzer des Smartphones aktiviert zu werden.

Normalerweise bin ich allergisch gegen solche Datenabflüsse aus der absoluten #, aber in diesem Fall ist es mein eigener Server im Keller mit Vollverschlüsselung und mein Fairphone ist im wesentlichen frei von # und die App wurde von # installiert und es ist #, also bin ich über meinen eigenen Schatten gesprungen und habe fast alles aktiviert.

Und zack, stehen für die Steuerung plötzlich sehr viele interessante Daten zur Verfügung. Einige davon wie Geo-Location, Nähe zum WLAN-Router, interne und externe IP sowie Traffic durchaus mit direkter Relevanz. Andere wie Anzahl Schritte eher für motivatorische Aspekte und für Gesundheitsdaten wie Blutdruck, Puls und BMI fehlen dem Smartphone wohl noch zusätzliche Sensoren, sonst würden die wohl auch noch geliefert.

Ich würde niemals solche Daten raus geben, aber beim eigenen Server habe ich durchaus etwas Experimentierfreude. Mal schauen, was daraus noch wird...


Screenshot HomeAssistant - App Rx

Screenshot HomeAssistant - wifi signal strength

Screenshot HomeAssistant - device overview

Screenshot HomeAssistant - Registirte Apps

Screenshot HomeAssistant - Anzahl Schritte
#HomeAssistant #SmartHome #Privatsphäre #DrecksGoogle #f-droid #OpenSource
Link zum Originalbeitrag
gehrke_test
3 Kommentare - Zeige mehr
Viper539 menu
achte drauf das du die richtige Version installiert hast. Das "-full" am ende der Versionsbezeichnung ist wichtig, sonst fehlen die Features. Ich bin mir nicht mehr sicher welche, aber für mich war das wichtig. Richte dir das von HomeAssistent vorgeschlagene Dashboard ein. Hätte ich das von Anfang an gehabt, hätte ich mir viel erspart.
Link zum Originalbeitrag
Viper539
gehrke_test menu
@Viper539
> Richte dir das von HomeAssistent vorgeschlagene Dashboard ein. Hätte ich das von Anfang an gehabt, hätte ich mir viel erspart.


Danke für den Tipp.
@Viper539
Link zum Originalbeitrag
gehrke_test
neuer älter