FHEM Forum

Ich habe mit Hilfe von KI eine neue Oberfläche für FHEM gebaut, das Projekt ist im Entwicklungsstadium, funktioniert aber bereits in einer echten FHEM-Umgebung

FHEM Next soll die Leistungsfähigkeit und Flexibilität von FHEM mit einer modernen, komfortablen Benutzeroberfläche verbinden. Bestehende FHEM-Installationen sollen möglichst ohne Änderungen weiterverwendet werden können.

Besonders interessant für langjährige FHEM-Nutzer ist, dass sie ihre Geräte, Automatisierungen, Module und Konfigurationen behalten können.

Die wichtigsten Funktionen im Überblick

• Moderne Weboberfläche    Zeitgemäßes Design statt klassischem FHEMWEB
• Bestehende Geräte übernehmen    Vorhandene FHEM-Devices ohne Neuanlage verwenden
• Kompatibilität mit FHEM-Modulen    DOIF, MQTT2_DEVICE, Shelly und andere Module weiterverwenden
• Grafischer Dashboard-Editor    Dashboards per Drag & Drop zusammenstellen
• Responsive Design    Optimierte Bedienung auf PC, Tablet und Smartphone
• Live-Aktualisierung    Reading-Änderungen über WebSocket ohne ständiges Polling
• Reading-Verläufe    Kleine Diagramme direkt in den Gerätekacheln
• Verbesserte Gerätedetails    Readings, Internals und Attribute übersichtlich darstellen
• Moderner DEF-Editor    Syntaxhervorhebung und komfortable Bearbeitung komplexer Definitionen
• Attribut-Editor    Attribute direkt in der Oberfläche ändern
• Mehrzeilige Befehlszeile    FHEM-Befehle ausführen und umfangreiche Ausgaben anzeigen
• HTML- und Widget-Unterstützung    Bestehende HTML-Ausgaben, beispielsweise DOIF-uiTable, darstellen
• Paralleler Betrieb    FHEM Next neben FHEMWEB verwenden und schrittweise umsteigen
• Lokaler Betrieb    Keine Cloud-Abhängigkeit für die grundlegende Bedienung

Im Anhang paar Bilder von der Live-Umgebung - es wurde keine einzige Zeile dafür in der Konfiguration der bestehenden Devices von FHEM geändert ;)

Aktuelle Struktur von FHEM-Next

Stand: 11. November 2026

FHEM-Next ist derzeit als moderne Weboberfläche für das bestehende FHEM aufgebaut. Die bisherige FHEM-Installation mit ihren Geräten, Modulen, Readings und Konfigurationen bleibt erhalten.

Die Architektur besteht aus drei Hauptkomponenten:

• FHEM (Perl) – bestehende Smart-Home-Logik und Geräteverwaltung.
• FHEM-Next Backend (Node.js/TypeScript) – Kommunikation, Datenaufbereitung und API.
• FHEM-Next Frontend (React/TypeScript) – moderne, responsive Benutzeroberfläche.

Architekturübersicht

FHEM-Next Frontend

React + TypeScript · Browser / Smartphone

Räume · Geräte · Readings · Dashboards · Editoren

REST API + WebSocket

FHEM-Next Backend

Node.js + TypeScript + Fastify · Port 3001

Gerätemodell · Adapter · API · Reading-Verläufe

WebSocket · Snapshot + Ereignisse

98_FHEMNext.pm

Nativer FHEM-Connector · Perl + DevIo

Interne FHEM-Funktionen

Bestehendes FHEM

Perl · FHEM-Module · fhem.cfg

Devices · Attribute · Readings · DOIF · MQTT · Automatisierungen


Wichtig ist die Kommunikationsrichtung: Das Perl-Modul 98_FHEMNext.pm baut die WebSocket-Verbindung zum Node.js-Backend auf.

Die Gerätedaten werden zunächst als vollständiger Snapshot übertragen und anschließend durch Ereignisse aktualisiert.

Interessanter Ansatz. Allerdings schlage ich eine Namensänderung vor, denn "FHEM-Next" ist doch sehr generisch. Wenn das breite Verwendung findet, wäre es eben nicht mehr "next", sondern "current". Und eine noch weiter in der Zukunft liegende Entwicklung müsste dann "FHEM-Nextnext" heißen, oder so etwas.

LG

pah

Über den Namen können wir hier gerne diskutieren. Ursprünglich sollte es eine Entwicklung sein, die ohne bisherige FHEM-Engine auskommen sollte. Allerdings habe mich entschlossen nur die Oberfläche mit bestehender Laufzeitumgebung zu entwickeln, damit die Akzeptanz des Projektes für die FHEM-Gemeinde leichter fällt.

Wer weiß, vielleicht wird der eine oder andere HA-Umsteiger wieder zurückkommen  ;)

Hi!

Ein interessantes Projekt und nicht ganz unwichtig, da das Retro-GUI wohl einer der Hauptgründe ist, warum Neueinsteiger bei Home Assistant landen, neben der ausgesprochen einfachen Einbindung von Geräten natürlich.

Bisher haben UIs immer auf FHEM selbst als Backend gesetzt. Welchen Vorteil siehst Du bei Nodejs?

Patrick

Zitat von: PatrickR am 12 November 2026, 10:12:44Bisher haben UIs immer auf FHEM selbst als Backend gesetzt. Welchen Vorteil siehst Du bei Nodejs?

Das kommt daher, dass es ursprünglich eine eigenständige Hausautomatisierung werden sollte. Das sind die Vor- bzw. Nachteile, wenn man node.js aus dem Spiel nimmt und ein entsprechendes FHEM-Modul entwickelt:

Vorteile:
Startzeit    Kein zusätzlicher Backend-Start
Arbeitsspeicher    Tendenziell geringer
Geräteaktualisierung    Kein zusätzlicher Backend-Hop
Synchronisierung    Einfacher

Nachteile:
Viele Browser    Belastung direkt im FHEM-Prozess
Aufwendige Auswertungen    Können FHEM blockieren
Ausfallsicherheit    UI und Automatisierung teilen einen Prozess

ZitatEin interessantes Projekt und nicht ganz unwichtig, da das Retro-GUI wohl einer der Hauptgründe ist, warum Neueinsteiger bei Home Assistant landen, neben der ausgesprochen einfachen Einbindung von Geräten natürlich.

Eine wesentliche Maßgabe des Projektes ist, dass man FHEM ohne Doku bedienen und vor allem anpassen kann. Es soll nicht erforderlich sein irgendwelche Config-Dateien zu editieren, um das Layout zu ändern.

Ich habe bereits einige Widget-Kacheln für das Dashboard im neuen Design erstellt. Für die liebgewonnenen FHEM-Devices, gibt es auch eine Kachel, die das jeweilige FHEM-Device der FHEM-Raumansicht in einer Kachel live anzeigt - ist zwar nicht so schön, aber für die Übergangszeit besser als nichts.

Natürlich wird es später für alle wichtigen Dinge wie Energie, Heizung, Wetter, usw. eigene Widget-Kacheln im neuen Design geben, damit alles aus einem Guss ist - es soll ja alles schöner aussehen und einfacher über die Oberfläche zu konfigurieren sein  :)

Eine Hellansicht und das Ausblenden der Menüleiste für ein Wandtablet ist auch schon drin.

Welchen Stil der Vorschläge für eine Energiekarte sollte ich nachbauen?