Hauptmenü

Neueste Beiträge

#11
Anfängerfragen / Aw: FHEM auf welcher Hardware
Letzter Beitrag von Damian - 14 Januar 2026, 22:02:31
Zitat von: betateilchen am 14 Januar 2026, 21:43:28Was ich nicht verstehe: warum man den PBS auf eine zweite Hardware auslagert? Solange die Sicherung auf eine möglichst separate Platte erfolgt, ist ein PBS mit Zugriff auf diese Sicherungen in einer Proxmox VM in maximal 15 Minuten neu aufgesetzt, falls wirklich mal was unkontrollierbares mit dem PBS passiert.


Es sind die eher unwahrscheinlichen Gründe: Diebstahl des PC-Hosts incl. externer Platte, Wasserschaden, Feuer etc., wenn Host und Sicherung an der gleichen Stelle sind und man sich nicht wo anders ein aktuelles Backup hinterlegt hat.
#12
Anfängerfragen / Aw: FHEM auf welcher Hardware
Letzter Beitrag von betateilchen - 14 Januar 2026, 21:43:28
Zitat von: Bartimaus am 14 Januar 2026, 19:25:43Wenn man damit einfach und schnell wenigstens den PVE-Host sichern könnte....

Kann man doch?
Läuft bei mir jede Nacht ab 03:00 Uhr für die beiden PVE Hosts und den PBS selbst.

Die elegante Konfiguration über die Proxmox Oberflächen sind auch bei mir der Grund, mit dem PBS zu arbeiten.

Was ich nicht verstehe: warum man den PBS auf eine zweite Hardware auslagert? Solange die Sicherung auf eine möglichst separate Platte erfolgt, ist ein PBS mit Zugriff auf diese Sicherungen in einer Proxmox VM in maximal 15 Minuten neu aufgesetzt, falls wirklich mal was unkontrollierbares mit dem PBS passiert.


---
#13
Homematic / Aw: Debmatic nach jedem Update...
Letzter Beitrag von betateilchen - 14 Januar 2026, 21:35:40
Das "passende" Meta Paket ist vorhanden:

root@debmatic:~# apt install linux-headers-generic
Hinweis: »linux-headers-amd64« wird an Stelle von »linux-headers-generic« gewählt.
linux-headers-amd64 ist schon die neueste Version (6.12.63-1).

ii  linux-headers-6.12.63+deb13-amd64  6.12.63-1  amd64  Header files for Linux 6.12.63+deb13-amd64
ii  linux-headers-6.12.63+deb13-common 6.12.63-1  all    Common header files for Linux 6.12.63+deb13
ii  linux-headers-amd64                6.12.63-1  amd64  Header files for Linux amd64 configuration (meta-package)
#14
FHEM Code changes / Revision 30739: 73_Tide: Bugfi...
Letzter Beitrag von System - 14 Januar 2026, 21:30:27
Revision 30739: 73_Tide: Bugfix - Libaries and LogLevel

73_Tide: Bugfix - Libaries and LogLevel

Source: Revision 30739: 73_Tide: Bugfix - Libaries and LogLevel
#15
FHEM Code changes / Revision 30738: 73_Tide: Bugfi...
Letzter Beitrag von System - 14 Januar 2026, 21:30:27
Revision 30738: 73_Tide: Bugfix - libaries and loglevel

73_Tide: Bugfix - libaries and loglevel

Source: Revision 30738: 73_Tide: Bugfix - libaries and loglevel
#16
Anfängerfragen / Aw: FHEM auf welcher Hardware
Letzter Beitrag von Damian - 14 Januar 2026, 21:27:04
Zitat von: Bartimaus am 14 Januar 2026, 19:25:43Das war auch der erste Crash mit meinem ProxmoxSystem. Aber Ursache gefunden und beseitigt.
Einen N100 hatte ich testweise auch mal da, aber der hat mir Idle zuviel Strom gezogen (deutlich mehr als mein potenter 8/16Kerner)
Den Sinn von PBS verstehe ich nicht, meine Backups laufen über die interne Funktion täglich auf ne externe HDD und wöchentlich nochmal auf meine QNAPs per NFS. Wenn man damit einfach und schnell wenigstens den PVE-Host sichern könnte....

Mein N100 schläft ja die meiste Zeit :) Das ist bei mir mit den Backups etwas unkonventionell, um maximale Performance und etwas Sicherheit zu erreichen. Es werden zuerst Backups auf einem lokalen PBS auf einer SSD gemacht. Im zweiten Schritt werden beide PBS-System miteinander synchronisiert (ist in PBS implementiert). Da ja alles inkrementell abläuft, ist es ziemlich effizient. Ich habe damit alle Backups jeden Tag an zwei verschiedenen Stellen (immerhin sind es inzwischen fast 4 TB an Backup-Daten). Die Konfiguration lässt sich elegant über die Oberfläche von Proxmox/PBS vornehmen. Den Host selbst sichere ich nur vor einem Update über Clonezilla (ist schon etwas gewöhnungsbedürftig)
#17
Unterstützende Dienste / Aw: Neues Modul: Tide - Deutsc...
Letzter Beitrag von Sailor - 14 Januar 2026, 21:17:08
Moin tosammen

Neue Version ist eingecheckt.
Sollte ab jetzt weder zu Fehlern aufgrund undefinierter Variablen kommen noch sollte das Log aufgrund fehlender Pegelstation zu falschen Log Einträgen kommen.

PS: Wer wissen will wie viel Deichreserve noch unter der Deichkrone ist, kann folgendes UserReading verwenden:
Die Deichhöhe (im unteren Beispiel 8.0m über NHN) bitte selbst erGoogeln.

DykeReserve {
my $Gauge_Value  = ReadingsVal($name,"Gauge_Value",0);
my $DeltaPNP2NHN = ReadingsVal($name,"D01-PNPu.NHN",0);
   $DeltaPNP2NHN =~ s/ //g;
my $DykeReserve = 8.0 - ($Gauge_Value + $DeltaPNP2NHN);
$DykeReserve
}
#18
MQTT / Aw: Verbindungsversuche von zi...
Letzter Beitrag von passibe - 14 Januar 2026, 20:51:38
Wieso gehst du über die externe IP des Servers und nicht intern übers Docker-Netzwerk? Würde mal testen, ob das was ändert. Weil eigentlich drehst du da unnötige Schleifen.

Den Namen des FHEM-Containers nach mqtt:// (+ :1883) eintragen dürfte reichen, solange die Container beide Teil desselben Docker-Netzwerks sind. Das passiert übrigens automatisch, wenn sie in ein und derselben Compose-Datei liegen (sofern darin keine externen Netzwerke definiert sind).
#19
MQTT / Aw: Verbindungsversuche von zi...
Letzter Beitrag von rabehd - 14 Januar 2026, 20:41:27
Ergänzend das Log von zigbee2mqtt.
[2026-01-14 20:34:39] info: z2m: Connecting to MQTT server at mqtt://192.168.31.60:1883
[2026-01-14 20:34:39] info: z2m: Connected to MQTT server
[2026-01-14 20:34:39] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"online"}'
[2026-01-14 20:34:40] info: z2m: Started frontend on port 8080
[2026-01-14 20:34:40] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0x00158d0008748115', payload '{"angle":11,"angle_x":3,"angle_x_absolute":87,"angle_y":0,"angle_y_absolute":90,"angle_z":87,"strength":10,"vibration":false,"x_axis":71,"y_axis":-10,"z_axis":1314}'
[2026-01-14 20:34:40] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0x187a3efffe395a82', payload '{"battery":100,"humidity":56.4,"temperature":23.6,"update":{"installed_version":8448,"latest_version":8704,"state":"available"}}'
[2026-01-14 20:34:40] info: z2m: Zigbee2MQTT started!
[2026-01-14 20:34:41] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/bridge/state', payload '{"state":"online"}'
[2026-01-14 20:35:41] info: z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/0x00158d0008748115', payload '{"angle":11,"angle_x":3,"angle_x_absolute":87,"angle_y":0,"angle_y_absolute":90,"angle_z":87,"linkquality":81,"strength":12,"vibration":false,"x_axis":71,"y_axis":-10,"z_axis":1314}'
#20
Anfängerfragen / Aw: FHEM goes Gemini
Letzter Beitrag von ch.eick - 14 Januar 2026, 20:13:25
Hallo nochmal,

für die, die sich wundern, dass hier jetzt noch Babble oder andes auftaucht.
Damit man etwas besser mit den Resourcen umgeht, denn die KI im RZ schluckt Unmengen an Energie, habe ich mich für ein mehrstufiges Konzept entschieden.
Die einfachen Anfragen sollen direkt lokal erledigt werden und nur wenn es zu komplex wird könnte man die KI noch hinzuziehen. Hier ist noch der Post von pah dazu.

Mein Ansatz sieht momentan so aus:

- Sprach oder Text Eingabe erfolgt über Signal mit den Handys
- signal-mqtt läuft im Docker Container
- Ein signal-receiver defindet sich im FHEM als MQTT2-Device
- Als ersten Test habe ich da bereits mit Perl Mapping einige direkte FHEM Kommandos umgesetz
- Wird dort nichts gefunden soll es zu Babble weiter gehen
- Mit RiveScript habe ich mich noch nicht befasst, was jedoch auch lokal laufen würde
- Erst ganz zum Schluss kann dann Gemini folgen

Ein Vorteil wäre auch, dass man nicht zuviele Gemini Aufrufe generieren würde, da die meisten Kommandos direkt vorher abgefangen werden.
Zusätzlich ist man so auch noch etwas unabhängiger vom Internet und dessen Dienste.

Der Status ist, wie pah schon so schön geschrieben hat: "Wär schön, das ist aber vorderste Front der Forschung."

VG   Christian