- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Sprachsteuerung / Aw: alexa-fhem test version mi...
Letzter Beitrag von fz55 - 02 Oktober 2025, 22:59:21Hallo,
ich hatte bei der Migration von Raspberry Pi3 auf Pi5 auch dieses Problem mit alexa-fhem und ModeController-Devices. Nachdem ich den Ordner /usr/local/lib/node_modules/alexa-fhem/lib vom Alt- auf das Neusystem kopiert hatte, lief wieder alles.
Der Inhalt des Ordners ist im Anhang. Du kannst ja Mal probieren, ob es bei dir auch das Problem löst.
ich hatte bei der Migration von Raspberry Pi3 auf Pi5 auch dieses Problem mit alexa-fhem und ModeController-Devices. Nachdem ich den Ordner /usr/local/lib/node_modules/alexa-fhem/lib vom Alt- auf das Neusystem kopiert hatte, lief wieder alles.
Der Inhalt des Ordners ist im Anhang. Du kannst ja Mal probieren, ob es bei dir auch das Problem löst.
#2
Solaranlagen / Aw: Nutzt jemand Ecoflow Power...
Letzter Beitrag von Gunther - 02 Oktober 2025, 22:39:52Ich musste aufgrund meiner Wallboxen umsteigen, da EcoFlow zu geschlossen war.
#3
Solaranlagen / Aw: Nutzt jemand Ecoflow Power...
Letzter Beitrag von MarioS1969 - 02 Oktober 2025, 22:31:05Hallo,
ich habe inzwischen auch eine Ecoflow PowerOcean Anlage.
Konntet ihr die Ecoflow PowerOcean inzwischen schon in FHEM auslesen?
Ich wäre sehr daran interessiert.
Viele Grüße
Mario
ich habe inzwischen auch eine Ecoflow PowerOcean Anlage.
Konntet ihr die Ecoflow PowerOcean inzwischen schon in FHEM auslesen?
Ich wäre sehr daran interessiert.
Viele Grüße
Mario
#4
Sonstige Systeme / Aw: [NUKI Smartlock] Neuer Thr...
Letzter Beitrag von Damian - 02 Oktober 2025, 18:49:51Hier mal zur Info, falls sich jemand ein NUKI-Schloss der aktuellen 5er Serie kauft.
Kurz zur Vorgeschichte:
Nachdem sich schon das zweite HM-Keymatic-Schloss durch ausgebrochene Zähne eines Zahnrades verabschiedet hat, habe ich beschlossen einen adäquaten Ersatz zu beschaffen. Da Homematic für mich ein Auslaufmodell ist, habe ich mich für ein NUKI-Schloss entschieden.
Heute ist der "Nuki Smart Lock Go 2025" bei mir angekommen (ohne WEB-Anbindung für zusätzliche 49 Euro).
Die aktuelle 5. Serie kommt ohne NUKI-Bridge aus, das WLAN ist neben Matter schon in den NUKI-Schlössern verbaut.
Nach der Einrichtung und der WLAN Aktivierung (per Handy-App über Bluetooth), habe ich das MQTT eingerichtet (FHEM-Server, User, ggf. Passwort angeben) und schon wurde über den FHEM-Mqtt2-Server ein neues Device erzeugt.
Neben den aktuellen Informationen des NUKI-Schlosses, lassen sich problemlos Aktionen zum Öffnen, Aufschließen oder Abschließen ausführen.
Der publish-Befehl lautet:
zum Öffnen:
zum Abschließen
zum Aufschließen
Meinen alten Fingerprint konnte ich damit einfach über eine DOIF-Zeile an das NUKI-Schloss zum Öffnen der Tür koppeln.
Und ja, das funktioniert alles ohne "Nuki Remote Access" (Cloud), welches man bei diesem NUKI-Schloss sogar noch zusätzlich erwerben müsste.
Es stellt sich jetzt noch die Frage, wie lange die Akkus halten werden, vor allem da das Schloss WLAN aktiviert hat und nicht das sparsamere Matter über Thread. Wer weiß, vielleicht werde ich irgendwann noch auf Matter umsteigen, wenn die Zeit dafür gekommen ist.
Kurz zur Vorgeschichte:
Nachdem sich schon das zweite HM-Keymatic-Schloss durch ausgebrochene Zähne eines Zahnrades verabschiedet hat, habe ich beschlossen einen adäquaten Ersatz zu beschaffen. Da Homematic für mich ein Auslaufmodell ist, habe ich mich für ein NUKI-Schloss entschieden.
Heute ist der "Nuki Smart Lock Go 2025" bei mir angekommen (ohne WEB-Anbindung für zusätzliche 49 Euro).
Die aktuelle 5. Serie kommt ohne NUKI-Bridge aus, das WLAN ist neben Matter schon in den NUKI-Schlössern verbaut.
Nach der Einrichtung und der WLAN Aktivierung (per Handy-App über Bluetooth), habe ich das MQTT eingerichtet (FHEM-Server, User, ggf. Passwort angeben) und schon wurde über den FHEM-Mqtt2-Server ein neues Device erzeugt.
Neben den aktuellen Informationen des NUKI-Schlosses, lassen sich problemlos Aktionen zum Öffnen, Aufschließen oder Abschließen ausführen.
Der publish-Befehl lautet:
zum Öffnen:
Code Auswählen
set MQTT2_FHEM_Server publish nuki/<deine ID>/lockAction 3zum Abschließen
Code Auswählen
set MQTT2_FHEM_Server publish nuki/<deine ID>/lockAction 2zum Aufschließen
Code Auswählen
set MQTT2_FHEM_Server publish nuki/<deine ID>/lockAction 1Meinen alten Fingerprint konnte ich damit einfach über eine DOIF-Zeile an das NUKI-Schloss zum Öffnen der Tür koppeln.
Und ja, das funktioniert alles ohne "Nuki Remote Access" (Cloud), welches man bei diesem NUKI-Schloss sogar noch zusätzlich erwerben müsste.
Es stellt sich jetzt noch die Frage, wie lange die Akkus halten werden, vor allem da das Schloss WLAN aktiviert hat und nicht das sparsamere Matter über Thread. Wer weiß, vielleicht werde ich irgendwann noch auf Matter umsteigen, wenn die Zeit dafür gekommen ist.
#5
FHEM Development / Aw: Problem: fheminfo / ipv6 /...
Letzter Beitrag von betateilchen - 02 Oktober 2025, 18:19:30Bei mir gibt es ein notify, das auf global:INITIALIZED triggert und dann "fheminfo send" ausführt.
Deine Theorie würde zu dem Effekt passen, den ich jetzt beim letzten FHEM restart hatte:
Da hat es wohl funktioniert.
Falls es wirklich ein timing Problem sein sollte, könnte ich das ja testweise durch einen längeren timeout verifizieren.
Edit: Warum das jetzt erst seit dem heutigen OS-Wechsel auftritt, verstehe ich deshalb immer noch nicht.
Deine Theorie würde zu dem Effekt passen, den ich jetzt beim letzten FHEM restart hatte:
Code Auswählen
2025.10.02 17:59:31 1: https://fhem.de/stats/statistics2.cgi: HTTP response code 200Da hat es wohl funktioniert.
Falls es wirklich ein timing Problem sein sollte, könnte ich das ja testweise durch einen längeren timeout verifizieren.
Edit: Warum das jetzt erst seit dem heutigen OS-Wechsel auftritt, verstehe ich deshalb immer noch nicht.
#6
Homematic / Aw: Selbstbau HM_WDS10_TH_O mi...
Letzter Beitrag von ritchie - 02 Oktober 2025, 18:02:31Hallo Zusammen,
so, ich habe ein kleines Testprogramm geschrieben, welches die LED blinken lässt
und das arbeitet korrekt.
Seltsamerweise hat mir der Sensor vorher immer Low Batterie mitgeteilt, als der noch mit der
alten Software lief. Ich habe mehrmals die Batterien gewechselt und selbst bei voller Ladung
kam die Meldung low Batterie.
Jetzt habe ich ein Labornetzteil dran und geben genau 3,2 Volt auf die Schaltung, welche ich auch
an dem Pin 18 (3 Volt) des Atmel messen kann. Ebenso am Pin 4 des MAX 1724+ liegt diese Spannung an.
Laut Quellcode geht die CPU in Stop, wenn die Spannungsversorgung kritisch ist
Wo kann ich noch weiter nach dem Fehler suchen?
Kann es sein, das eine Lib. noch auf 5V steht und ich das einstellen muss.
Viele Grüße
R.
so, ich habe ein kleines Testprogramm geschrieben, welches die LED blinken lässt
und das arbeitet korrekt.
Seltsamerweise hat mir der Sensor vorher immer Low Batterie mitgeteilt, als der noch mit der
alten Software lief. Ich habe mehrmals die Batterien gewechselt und selbst bei voller Ladung
kam die Meldung low Batterie.
Jetzt habe ich ein Labornetzteil dran und geben genau 3,2 Volt auf die Schaltung, welche ich auch
an dem Pin 18 (3 Volt) des Atmel messen kann. Ebenso am Pin 4 des MAX 1724+ liegt diese Spannung an.
Laut Quellcode geht die CPU in Stop, wenn die Spannungsversorgung kritisch ist
Code Auswählen
if (hal.battery.critical()) {
// this call will never return
hal.activity.sleepForever(hal);
}
Wo kann ich noch weiter nach dem Fehler suchen?
Kann es sein, das eine Lib. noch auf 5V steht und ich das einstellen muss.
Viele Grüße
R.
#7
FHEM Development / Aw: Problem: fheminfo / ipv6 /...
Letzter Beitrag von rudolfkoenig - 02 Oktober 2025, 17:40:16Keine direkte Idee, aber womoeglich hilft es bei der Suche:
Mein Browser-Plugin sagt, dass https://fhem.de vollstaendig ueber IPv6 geladen wurde.
Ich hatte vor ca einem Jahr eine Weile das Problem, dass ich IPv6 Webseiten nur sehr zoegerlich laden konnte.
Das Problem war weg, nachdem ich IPv6 global deaktiviert hatte: vmtl. hat mein Provider bei der IPv6 Routing was falsch gemacht.
Edit: http => https
Mein Browser-Plugin sagt, dass https://fhem.de vollstaendig ueber IPv6 geladen wurde.
Ich hatte vor ca einem Jahr eine Weile das Problem, dass ich IPv6 Webseiten nur sehr zoegerlich laden konnte.
Das Problem war weg, nachdem ich IPv6 global deaktiviert hatte: vmtl. hat mein Provider bei der IPv6 Routing was falsch gemacht.
Edit: http => https
#8
MQTT / Aw: MQTT2+Shelly: erste Konfig...
Letzter Beitrag von theotherhalf - 02 Oktober 2025, 16:13:09Hallo, ich habe seit einigen Tagen einen Shelly L1 Gen3 in Benutzung, den ich gerne in FHEM integrieren würde.
Leider sind die passenden Templates in FHEM nicht dabei. Hat jemand dieses Modul ebenfalls im Einsatz? Oder kann mir einen Hinweis geben, wie ich einige der vorhandenen Templates "verbiegen" kann ? Danke!
Leider sind die passenden Templates in FHEM nicht dabei. Hat jemand dieses Modul ebenfalls im Einsatz? Oder kann mir einen Hinweis geben, wie ich einige der vorhandenen Templates "verbiegen" kann ? Danke!
#9
Sprachsteuerung / Aw: alexa-fhem test version mi...
Letzter Beitrag von hapege - 02 Oktober 2025, 15:44:02Hallo,
ich verzweifle gerade am modeController...
Ich habe das Beispiel von vorne 1:1 definiert:
Irgendwie fehlt aber doch der "alexaName"?
Wenn ich den noch hinzufüge
und dann alexa-fhem neu starte
... dann wird die SSH Verbindung immer wieder kurz aufgebaut und fällt dann wieder runter (
Readings:
Im log finde ich nichts dazu, keine Fehlermeldung.
Wenn ich das attr homebridgeMapping lösche, dann läuft alexa-fhem sofort wieder stabil...
Was mache ich falsch?
(System und fhem sind aktuell)
ich verzweifle gerade am modeController...
Ich habe das Beispiel von vorne 1:1 definiert:
Code Auswählen
defmod kino dummy
attr kino devStateIcon on:control_on_off: off:control_home:
attr kino genericDeviceType mode
attr kino homebridgeMapping ModeController:mode,cmd=mode,mode=status,values=start;;play;;pause;;stop On=state,cmdOn=on,cmdOff=off
attr kino readingList mode
attr kino setList on off mode:start,play,pause,stop
attr kino webCmd on:off:mode
Irgendwie fehlt aber doch der "alexaName"?
Wenn ich den noch hinzufüge
Code Auswählen
attr kino alexaName kino
und dann alexa-fhem neu starte
Code Auswählen
set alexa restart
... dann wird die SSH Verbindung immer wieder kurz aufgebaut und fällt dann wieder runter (
Readings:
Code Auswählen
alexaFHEM stopped
alexaFHEM.ProxyConnection stopped
Im log finde ich nichts dazu, keine Fehlermeldung.
Wenn ich das attr homebridgeMapping lösche, dann läuft alexa-fhem sofort wieder stabil...
Was mache ich falsch?
(System und fhem sind aktuell)
#10
FHEM Development / Problem: fheminfo / ipv6 / Deb...
Letzter Beitrag von betateilchen - 02 Oktober 2025, 14:41:20Gegeben ist:
Wenn ich nun "fheminfo send" ausführe, passiert folgendes:
Entferne ich das Attribut useInet6 aus global, sieht das so aus:
Vor dem Umzug auf Debian13 sind mir diese Fehlermeldungen nicht begegnet.
Hat jemand eine Idee, was da schiefgeht bzw. wie ich diesen Fehler weiter eingrenzen/debuggen kann?
- FHEM frisch umgezogen von Debian12 auf neuaufgesetztes Debian13
- attr global useInet6 1 ist gesetzt, sonst funktioniert MQTT2 nicht
Wenn ich nun "fheminfo send" ausführe, passiert folgendes:
Code Auswählen
2025.10.02 13:40:44 5: Cmd: >fheminfo send<
2025.10.02 13:40:44 4: fheminfo send (nonblocking): {... <infoData> ...}
2025.10.02 13:40:44 5: HttpUtils url=https://fhem.de/stats/statistics2.cgi NonBlocking via https
2025.10.02 13:40:44 4: IP: fhem.de -> [2a01:4f8:221:1b5a::2]
2025.10.02 13:40:48 1: fheminfo send: Server ERROR: connect to https://fhem.de:443 timed out
Entferne ich das Attribut useInet6 aus global, sieht das so aus:
Code Auswählen
2025.10.02 14:17:01 5: Cmd: >fheminfo send<
2025.10.02 14:17:01 4: fheminfo send (nonblocking): {... <infoData> ...}
2025.10.02 14:17:01 5: HttpUtils url=https://fhem.de/stats/statistics2.cgi NonBlocking via https
2025.10.02 14:17:01 4: IP: fhem.de -> 188.40.131.57
2025.10.02 14:17:01 5: HttpUtils request header:
POST /stats/statistics2.cgi HTTP/1.0
Host: fhem.de
Accept-Encoding: gzip,deflate
User-Agent: FHEM
Content-Length: 1121
Content-Type: application/x-www-form-urlencoded
2025.10.02 14:17:02 4: https://fhem.de/stats/statistics2.cgi: HTTP response code 200
2025.10.02 14:17:02 5: HttpUtils https://fhem.de/stats/statistics2.cgi: Got data, length: 6
2025.10.02 14:17:02 5: HttpUtils response header:
HTTP/1.1 200 OK
Date: Thu, 02 Oct 2025 12:17:01 GMT
Server: Apache/2.4.52 (Ubuntu)
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Type: application/x-www-form-urlencoded; charset=ISO-8859-1
Connection: close
2025.10.02 14:17:02 4: fheminfo send: Server RESPONSE: ==> ok
Vor dem Umzug auf Debian13 sind mir diese Fehlermeldungen nicht begegnet.
Hat jemand eine Idee, was da schiefgeht bzw. wie ich diesen Fehler weiter eingrenzen/debuggen kann?