- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#41
MQTT / Aw: [MQTT_GENERIC_BRIDGE] FHEM...
Letzter Beitrag von rudolfkoenig - 28 Januar 2026, 18:03:12Jemand hat was getippt order geklickt auf der FHEMWEB Oberflaeche, um ein Attribut zu modifizieren, das hat GENERIG_BRIDGE abgefangen, und hat bei MQTT2_CLIENT eine Verbindung mit einer (neuen) subscription Liste bestellt.
Was bestellt wurde, kriegt man raus, indem man in MQTT2_CLIENT.pm, vor der Zeile 713 diese ausgibt mit z.Bsp.
Was bestellt wurde, kriegt man raus, indem man in MQTT2_CLIENT.pm, vor der Zeile 713 diese ausgibt mit z.Bsp.
Code Auswählen
Log 1, $topicMsg;Alternativ kann man auch verbose fuer die MQTT2_CLIENT Instanz(!) auf 5 setzen, und die Liste aus der Debug-Ausgabe, die SUBSCRIBE enthaelt, rausfischen. #42
Sonstiges / fhem-mcp - FHEM-Steuerungs-Spi...
Letzter Beitrag von Pati_Alpha - 28 Januar 2026, 17:23:23Hey! 
Ich wollte mal ein kleines Experiment teilen, das ich kürzlich umgesetzt habe – vielleicht gibt es ja abseits von vermutlich üblichen ,,braucht doch keiner"-Reflexen trotzdem etwas Interesse oder eine Diskussion.
Kurzfassung:
Ich habe einen MCP-Server als Brücke zu FHEM gebaut, der es einem lokal laufenden LLM erlaubt, FHEM-Devices strukturiert abzufragen und zu steuern. Das Ganze läuft ohne Cloud, komplett lokal, und greift letztlich nur über die bekannten FHEM-Mechanismen (in meinem Fall via verschlüsseltem Telnet) zu.
Etwas ausführlicher:
Der praktische Test war dann banal:
Ein natürlicher Sprachbefehl (,,na dann schalte doch mal meine Schreibtischlampe ein") => Tool-Intents liefen los => Modell ermittelt passendes Device => prüft verfügbare Commands => führt den Befehl aus => Lampe geht an, sauber nachvollziehbar im FHEM-Log.
Mir ist völlig klar, dass jetzt direkt Fragen kommen wie
,,Warum nicht einfach Alexa/Google/HomeKit?" oder
,,Was bringt mir das gegenüber einem normalen Sprachassistenten?"
Fairer Punkt – für viele vermutlich gar keinen Mehrwert. Habe ich natürlich auch alles mit AlexaFhem und Homebridge laufen.
Für mich ist der interessante Teil aber:
Ob das am Ende Spielerei bleibt oder ob sich daraus sinnvolle Anwendungsfälle ergeben (z. B. komplexere Zustandslogik, Kontext, Kombination mehrerer Geräte), wird sich zeigen.
... aber ziemlich sicher kann ich jetzt sagen ,,Ich hab grade beim Kacken kalte Füße" und das Reasoning würde das Device ,,FussbodenheizungBad" finden und anschalten.
Ich wollte es hier einfach mal teilen – vielleicht hat ja jemand Lust, das technisch einzuordnen oder weiterzudenken, statt nur zu erklären, warum man das nicht braucht.
Vielleicht erweitere ich es auch mal und packe es in ein GitHub Repo oder so.
Viele Grüße
Patrick
Ich wollte mal ein kleines Experiment teilen, das ich kürzlich umgesetzt habe – vielleicht gibt es ja abseits von vermutlich üblichen ,,braucht doch keiner"-Reflexen trotzdem etwas Interesse oder eine Diskussion.
Kurzfassung:
Ich habe einen MCP-Server als Brücke zu FHEM gebaut, der es einem lokal laufenden LLM erlaubt, FHEM-Devices strukturiert abzufragen und zu steuern. Das Ganze läuft ohne Cloud, komplett lokal, und greift letztlich nur über die bekannten FHEM-Mechanismen (in meinem Fall via verschlüsseltem Telnet) zu.
Etwas ausführlicher:
- MCP-Server stellt u. a. Funktionen wie list_devices, get_device_commands, execute_command bereit (mehr ERSTMAL für den ersten Durchstich nicht)
- LLM läuft lokal (LM Studio, GPU-beschleunigt, in diesem Fall einfach gpt-oss 20B auf meinem M2 Max MacBook Pro)
- Das Modell bekommt keine Sonderrechte, sondern nutzt exakt die definierten Schnittstellen via Telnet
- FHEM selbst bleibt unverändert, es kommt nur eine zusätzliche, klar abgegrenzte Steuerschicht dazu
Der praktische Test war dann banal:
Ein natürlicher Sprachbefehl (,,na dann schalte doch mal meine Schreibtischlampe ein") => Tool-Intents liefen los => Modell ermittelt passendes Device => prüft verfügbare Commands => führt den Befehl aus => Lampe geht an, sauber nachvollziehbar im FHEM-Log.
Mir ist völlig klar, dass jetzt direkt Fragen kommen wie
,,Warum nicht einfach Alexa/Google/HomeKit?" oder
,,Was bringt mir das gegenüber einem normalen Sprachassistenten?"
Fairer Punkt – für viele vermutlich gar keinen Mehrwert. Habe ich natürlich auch alles mit AlexaFhem und Homebridge laufen.
Für mich ist der interessante Teil aber:
- freie, lokale Interpretation natürlicher Sprache
- kein festes Skill-/Intent-Modell
- keine Cloud, kein Vendor-Lock-in
- nachvollziehbares Reasoning (welches Device warum angesprochen wurde)
Ob das am Ende Spielerei bleibt oder ob sich daraus sinnvolle Anwendungsfälle ergeben (z. B. komplexere Zustandslogik, Kontext, Kombination mehrerer Geräte), wird sich zeigen.
... aber ziemlich sicher kann ich jetzt sagen ,,Ich hab grade beim Kacken kalte Füße" und das Reasoning würde das Device ,,FussbodenheizungBad" finden und anschalten.
Ich wollte es hier einfach mal teilen – vielleicht hat ja jemand Lust, das technisch einzuordnen oder weiterzudenken, statt nur zu erklären, warum man das nicht braucht.
Vielleicht erweitere ich es auch mal und packe es in ein GitHub Repo oder so.
Viele Grüße
Patrick
#43
Unterstützende Dienste / Aw: Neues Modul für clever-tan...
Letzter Beitrag von sven.luebke - 28 Januar 2026, 17:21:45Zitat von: rabehd am 28 Januar 2026, 13:27:14Kann ich die Spritsorten konfigurieren? Ich brauche nur eine Sorte.Dass man die Spritsorte konfigurieren kann, habe ich gerade eingebaut. Die Tabelle wird dadurch schmaler und zeigt z.B. nur noch E10 an.
Wird der beste Preis hervorgehoben?
Kann man den Ort auch anzeigen lassen oder nur die Straße?
Der beste Preis wird noch nicht hervorgehoben, dafür müsste ich mir etwas bei den Readings überlegen. Setzt man das Reading des besten Preises per HTML z.B. auf "bold", dann kann man die Preise nicht mehr vernünftig in einer Datenbank ablegen. Es müsste also ein zusätzliches Reading für den besten Preis definiert werden, sollte aber kein Problem sein.
Den Ort kann man auch anzeigen lassen, auch die PLZ wird herausgefiltert. Das hab ich aber bisher noch nicht in die Readings übernommen. Frei konfigurierbar ist es aber derzeit noch nicht. Wie die Angabe der Tankstelle definiert ist, steht direkt im Sourcecode.
#44
MQTT / Aw: [MQTT_GENERIC_BRIDGE] FHEM...
Letzter Beitrag von drhirn - 28 Januar 2026, 17:20:57Finde ich irgendwie raus, was, wohin und warum da was schreiben will?
#45
Anfängerfragen / Aw: MATTER im FHEM? Schon was ...
Letzter Beitrag von GeZi3560 - 28 Januar 2026, 17:10:18 #46
MQTT / Aw: [MQTT_GENERIC_BRIDGE] FHEM...
Letzter Beitrag von rudolfkoenig - 28 Januar 2026, 17:07:47Da will GENERIC_BRIDGE Subscriptions per MQTT_CLIENT_WRITE setzen.
Ob man das wegoptimieren koennte, weiss ich nicht, die Funktion in MQTT2_CLIENT prueft nicht, ob dabei was Neues ist.
Ob man das wegoptimieren koennte, weiss ich nicht, die Funktion in MQTT2_CLIENT prueft nicht, ob dabei was Neues ist.
#47
Heizungssteuerung/Raumklima / Aw: VALVES und die Fritz DECT ...
Letzter Beitrag von JoWiemann - 28 Januar 2026, 16:51:52Zitat von: elektron-bbs am 28 Januar 2026, 14:45:54Das Schreiben der Logdatei sollte m.E. auch optional sein, entweder nur mit einem get oder per Attribut wählbar.
Ebenso würde ich auch die Readings ".*_RXItem" nur optional schreiben.
Steht schon auf der ToDo-Liste.
Grüße Jörg
#48
Unterstützende Dienste / Aw: Neues Modul für clever-tan...
Letzter Beitrag von sven.luebke - 28 Januar 2026, 16:47:58Zitat von: betateilchen am 28 Januar 2026, 12:54:33Und wenn man so ein device mal fertiggestellt hat, kann man es ja einfach mit "copy" duplizieren und muss meist nur die Station-ID im DEF anpassen.Eine Tankstellendefinition hat bei mir genau 19 Zeilen (ohne UUID und DbLogInclude). Die Station-ID anzupassen ist wirklich nicht weiter schwer. Mich haben dann eher die Änderung der ganzen Attributnamen für jede einzelne Tankstelle genervt. Klar, es gibt Search/Replace. Außerdem störte ich mich an den ewig gleichen Definitionen für jede einzelne Tankstelle. Da ändert sich ja nichts dran. Ich hatte kurz gesucht, ob es eine Art Template gibt, oder ob man diese Definitionen als Konstante definieren kann. Bei der Idee bin ich aber irgendwie wieder abgestorben. Kennt Ihr eine Möglichkeit für so etwas?
Um zu beurteilen, ob Dein Modul wirklich etwas grundlegend anderes macht, reicht ein Screenshot vom Ergebnis nicht aus. Dazu müsste man schon den Code selbst sehen.
Summa summarum sind wir für 10 Tankstellen bei 200 Zeilen Config, mit meinem Modul liege ich bei 7 Zeilen Config. Damit ist mein Ziel schon erreicht
. Bei mir läuft FHEM auf einer Fritzbox, ich hab nicht so viel RAM 
.Mein Modul macht nicht viel anders. Es holt sich auch nur die HTML-Seite und parsed die Daten. Einzig allein die Suche nach den Daten ist etwas anders und fokussierter. Das kann Vorteile, aber genauso auch Nachteile mit sich bringen. Das HTTPMOD sucht ja global nach den Ausdrücken. Mein Modul nutzt HTML::TreeBuilder und "steuert" die Elemente/Informationen fokussierter an.
#49
MQTT / Aw: [MQTT_GENERIC_BRIDGE] FHEM...
Letzter Beitrag von drhirn - 28 Januar 2026, 16:43:27Stacktrace:
Mein Mosquitto läuft als Docker Container. Die Verbindung von FHEM zu Mosquitto läuft noch über einen Reverse Proxy. SSL (8883) zum Reverse Proxy, dann unverschlüsselt weiter (1883) zum Mosquitto Container. Mosquitto loggt also seine Container IP, FHEM aber die vom Reverse Proxy. Deswegen der Unterschied.
Code Auswählen
2026.01.28 16:39:02 1: stacktrace:
2026.01.28 16:39:02 1: main::MQTT2_CLIENT_Disco called by ./FHEM/00_MQTT2_CLIENT.pm (713)
2026.01.28 16:39:02 1: main::MQTT2_CLIENT_Write called by fhem.pl (1073)
2026.01.28 16:39:02 1: main::IOWrite called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (1862)
2026.01.28 16:39:02 1: MQTT::GENERIC_BRIDGE::UpdateSubscriptions called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (1799)
2026.01.28 16:39:02 1: MQTT::GENERIC_BRIDGE::UpdateSubscriptionsSingleDevice called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (1706)
2026.01.28 16:39:02 1: MQTT::GENERIC_BRIDGE::_RefreshDeviceTable called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (1735)
2026.01.28 16:39:02 1: MQTT::GENERIC_BRIDGE::RefreshGlobalTable called by ./FHEM/10_MQTT_GENERIC_BRIDGE.pm (2691)
2026.01.28 16:39:02 1: MQTT::GENERIC_BRIDGE::Attr called by fhem.pl (4007)
2026.01.28 16:39:02 1: main::CallFn called by fhem.pl (3224)
2026.01.28 16:39:02 1: main::CommandAttr called by fhem.pl (1285)
2026.01.28 16:39:02 1: main::AnalyzeCommand called by ./FHEM/01_FHEMWEB.pm (2860)
2026.01.28 16:39:02 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (991)
2026.01.28 16:39:02 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (614)
2026.01.28 16:39:02 1: main::FW_Read called by fhem.pl (4007)
2026.01.28 16:39:02 1: main::CallFn called by fhem.pl (789)
2026.01.28 16:39:02 5: Mosquitto: discarding DISCONNECT (224)(0)
2026.01.28 16:39:02 1: mqtt.example.com:8883 disconnected, waiting to reappear (Mosquitto)
2026.01.28 16:39:02 5: HttpUtils url=https://mqtt.example.com:8883/ NonBlocking via https
2026.01.28 16:39:02 4: IP: mqtt.example.com -> 192.168.2.16
2026.01.28 16:39:02 5: Mosquitto: sending CONNECT (16))(0)(6)MQIsdp(3)(194)(0)(30)(0)(4)FHEM(0)(9)username(0)(10)password
2026.01.28 16:39:02 5: DevIo_SimpleWrite Mosquitto: 102900064d514973647003c2001e00044648454d00096d6f7371756974746f000a4d307371756974746f21
2026.01.28 16:39:02 1: mqtt.example.com:8883 reappeared (Mosquitto)
2026.01.28 16:39:02 4: Mosquitto received CONNACK
2026.01.28 16:39:02 5: Mosquitto: received CONNACK (0)(0)
2026.01.28 16:39:02 5: Mosquitto: sending SUBSCRIBE (130)G(0)(25)(0)(30)fhem/set/Tedsen_SKX2xx_1F10110(0)(0)!fhem/set/hmThermostatWz_Climate/+(0)
2026.01.28 16:39:02 4: Mosquitto received SUBACK
2026.01.28 16:39:02 5: Mosquitto: received SUBACK (0)(25)(0)(0)
Mein Mosquitto läuft als Docker Container. Die Verbindung von FHEM zu Mosquitto läuft noch über einen Reverse Proxy. SSL (8883) zum Reverse Proxy, dann unverschlüsselt weiter (1883) zum Mosquitto Container. Mosquitto loggt also seine Container IP, FHEM aber die vom Reverse Proxy. Deswegen der Unterschied.
#50
Multimedia / Aw: [82_LGTV_WebOS.pm] Modul f...
Letzter Beitrag von locodriver - 28 Januar 2026, 16:23:43Zitat von: grappa24 am 27 Januar 2026, 15:16:31@Uwe: Du kommst also mit dem LG-Modul noch auf deinen TV? Älteres Modell, älteres WebOS?
Ja, ohne Probleme mit aktuellstem WebOS, TV ist 3 Jahre alt.