- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
FHEM Development / Aw: Header-basierte Authentifi...
Letzter Beitrag von Sidey - 03 April 2026, 20:39:07Kurzes Update zum Stand von WebAuth:
Das Modul ist inzwischen grundlegend funktional und läuft bei mir in der Praxis.
Aktuell liegt es aber noch nur auf GitHub und ist noch nicht in SVN, obwohl ich schon kurz vor dem Checkin stand:
https://github.com/fhem/WebAuth
Der Hauptgrund ist nicht die eigentliche Funktion, sondern dass ich bei zwei Punkten vor einer Veröffentlichung noch unsicher bin:
Die Sprache für headerAuthPolicy:
Aktuell ist das eine JSON-basierte Policy-Beschreibung für Header-Matching. Das funktioniert technisch gut und vermeidet direkt ausführbaren Perl-Code, aber ich bin unsicher, ob das im FHEM-Kontext als passend/intuitiv genug empfunden wird, weil an anderen Stellen ja durchaus auch Perl-Ausdrücke als Eingabe erlaubt sind.
Das Zusammenspiel mit allowed:
Mit strict=0 kann WebAuth bei fehlenden relevanten Headern an einen nachgelagerten Authentikator wie allowed mit basicAuth erlauben, mit strict=1 wird direkt abgelehnt. Das ist technisch umsetzbar, aber ich bin unsicher, ob dieses Verhalten aus Nutzersicht wirklich intuitiv genug ist.
mit strict=0 und ohne nachgelagertes allowed steht die Instanz wieder offen, daher ist default natürlich strict=1
Warum das ganze? Ich habe eine FHEMWEB Instanz, wenn ich dort über meinen Proxy zugreife, dann soll die headerauth verwendet werden. Wenn ich meinen Proxy umgehe, will ich keine offene FHEMWEB Instanz haben.
Lösbar wäre es natürlich, indem getrennte FHEMWEB Instanzen verwendet werden.
Bevor ich das nach SVN bringe, hätte ich deshalb gern noch etwas Feedback, ob noch etwas grundlegend anders aufziehen sollte. Und ich wollte jetzt auch nicht einfach ein faules Ei in die Osternester legen
Grüße
Sidey
Das Modul ist inzwischen grundlegend funktional und läuft bei mir in der Praxis.
Aktuell liegt es aber noch nur auf GitHub und ist noch nicht in SVN, obwohl ich schon kurz vor dem Checkin stand:
https://github.com/fhem/WebAuth
Der Hauptgrund ist nicht die eigentliche Funktion, sondern dass ich bei zwei Punkten vor einer Veröffentlichung noch unsicher bin:
Die Sprache für headerAuthPolicy:
Aktuell ist das eine JSON-basierte Policy-Beschreibung für Header-Matching. Das funktioniert technisch gut und vermeidet direkt ausführbaren Perl-Code, aber ich bin unsicher, ob das im FHEM-Kontext als passend/intuitiv genug empfunden wird, weil an anderen Stellen ja durchaus auch Perl-Ausdrücke als Eingabe erlaubt sind.
Das Zusammenspiel mit allowed:
Mit strict=0 kann WebAuth bei fehlenden relevanten Headern an einen nachgelagerten Authentikator wie allowed mit basicAuth erlauben, mit strict=1 wird direkt abgelehnt. Das ist technisch umsetzbar, aber ich bin unsicher, ob dieses Verhalten aus Nutzersicht wirklich intuitiv genug ist.
mit strict=0 und ohne nachgelagertes allowed steht die Instanz wieder offen, daher ist default natürlich strict=1
Warum das ganze? Ich habe eine FHEMWEB Instanz, wenn ich dort über meinen Proxy zugreife, dann soll die headerauth verwendet werden. Wenn ich meinen Proxy umgehe, will ich keine offene FHEMWEB Instanz haben.
Lösbar wäre es natürlich, indem getrennte FHEMWEB Instanzen verwendet werden.
Bevor ich das nach SVN bringe, hätte ich deshalb gern noch etwas Feedback, ob noch etwas grundlegend anders aufziehen sollte. Und ich wollte jetzt auch nicht einfach ein faules Ei in die Osternester legen
Grüße
Sidey
#92
FRITZ!Box / Aw: 72_FRITZBOX.pm wird zu 72_...
Letzter Beitrag von JoWiemann - 03 April 2026, 20:38:06Hallo,
ich würde jetzt das Thema Rufumleitung ohne die LuaQuery-Abfrage Diversity abändern. Die Abfrage gibt nur Rufumleitungen zurück, während die DataLua-Abfrage zusätzlich auch die Rufbehandlungen bereit stellt. Somit können dann beide auch Ein/Aus geschaltet werden. Bei Bedarf können auch weitere Parameter verändert werden.
Gibt es noch jemanden, der eine Uraltversion des FritzOS benutzt, bei der DataLua noch nicht vorhanden ist, dann müsste ich hierfür eine weitere Ausnahme einbauen.
Grüße Jörg
ich würde jetzt das Thema Rufumleitung ohne die LuaQuery-Abfrage Diversity abändern. Die Abfrage gibt nur Rufumleitungen zurück, während die DataLua-Abfrage zusätzlich auch die Rufbehandlungen bereit stellt. Somit können dann beide auch Ein/Aus geschaltet werden. Bei Bedarf können auch weitere Parameter verändert werden.
Gibt es noch jemanden, der eine Uraltversion des FritzOS benutzt, bei der DataLua noch nicht vorhanden ist, dann müsste ich hierfür eine weitere Ausnahme einbauen.
Grüße Jörg
#93
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 03 April 2026, 20:28:44Hallo Heiko,
ja, die Abregung wird über das Vergleichsergebnis <Regex>="true" erkannt.
Jetzt kommt es darauf an welchen Regex du als Test angegeben hast. Mit diesem Beispiel erreichst du das Verhalten 0->keine Abregelung, 1->abgeregelt:
Mit Version 2.5.0 (im contrib) habe ich die Hilfe augebessert:
reductionState
SolarForecast nutzt diesen Parameter, um den aktuellen Abregelungsstatus der PV-Anlage auszulesen (optional).
Die Syntax ist eine <Device>:<Reading>:<Funktion>-Kombination. Möglich als <Funktion> sind:
<Regex> - Der Regex wird auf den Wert von <Device>:<Reading> angewendet. Boolesches Ergebnis: true'->abgeregelt, 'false'->nicht abgeregelt
<{Perl-Code}> - Das Ergebnis des Perl-Codes wird ausgewertet. Boolesches Ergebnis: 'true'->abgeregelt, 'false'->nicht abgeregelt
Der Perl-Code darf keine Leerzeichen enthalten. Der Wert von <Device>:<Reading> wird dem Code
mit der Variable $VALUE übergeben.
Ich hoffe damit ist es klarer geworden.
LG,
Heiko
ja, die Abregung wird über das Vergleichsergebnis <Regex>="true" erkannt.
Jetzt kommt es darauf an welchen Regex du als Test angegeben hast. Mit diesem Beispiel erreichst du das Verhalten 0->keine Abregelung, 1->abgeregelt:
Code Auswählen
reductionState=<Device>:<Reading>:1
Mit Version 2.5.0 (im contrib) habe ich die Hilfe augebessert:
reductionState
SolarForecast nutzt diesen Parameter, um den aktuellen Abregelungsstatus der PV-Anlage auszulesen (optional).
Die Syntax ist eine <Device>:<Reading>:<Funktion>-Kombination. Möglich als <Funktion> sind:
<Regex> - Der Regex wird auf den Wert von <Device>:<Reading> angewendet. Boolesches Ergebnis: true'->abgeregelt, 'false'->nicht abgeregelt
<{Perl-Code}> - Das Ergebnis des Perl-Codes wird ausgewertet. Boolesches Ergebnis: 'true'->abgeregelt, 'false'->nicht abgeregelt
Der Perl-Code darf keine Leerzeichen enthalten. Der Wert von <Device>:<Reading> wird dem Code
mit der Variable $VALUE übergeben.
Ich hoffe damit ist es klarer geworden.
LG,
Heiko
#94
Sonstige Systeme / Aw: Netatmo Modul - 38_netatmo...
Letzter Beitrag von Dirk070 - 03 April 2026, 20:28:15Lief super bis heute.
Jetzt im Account ,,recovering timeout" und ,,delayed update" bei den Devices.
Jetzt im Account ,,recovering timeout" und ,,delayed update" bei den Devices.
#95
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von HeikoE - 03 April 2026, 20:00:05Hallo Heiko,
ich habe ein Verständnisproblem mit plantControl - reductionState. In der Hilfe steht:
Damit wird allerdings die Anzeige im Header gelb.
Du darfst diesen Dateianhang nicht ansehen.
Mit "1" ist die Anzeige grün.
Du darfst diesen Dateianhang nicht ansehen.
Ich verstehe die Erklärung so, dass der Zunstand "Abgeregelt" über ein (wahr) - also 1 - erkannt werden müsste.
Ist das so gewollt?
Frohe Ostern,
Heiko
ich habe ein Verständnisproblem mit plantControl - reductionState. In der Hilfe steht:
Code Auswählen
reductionState Liefert einen Status an SolarForecast wenn die PV-Anlage abgeregelt wird bzw. abgeregelt ist (optional).
Device - Device welches den Abregelungsstatus liefert
Reading - Reading welches den Abregelungsstatus liefert
Die Prüfung des gelieferten Wertes kann als regulärer Ausdruck oder als in {..} eingeschlossener Perl-Code formuliert sein:
Regex - regulärer Ausdruck der für einen Abregelungsstatus (wahr) erfüllt sein muß
{Perl-Code} - der in {..} eingeschlossene Perl-Code muß 'wahr' für einen Abregelungsstatus liefern. Er darf keine Leerzeichen enthalten. Ich habe also ein Userreading angelegt und es mit "0" gefüttert.Damit wird allerdings die Anzeige im Header gelb.
Du darfst diesen Dateianhang nicht ansehen.
Mit "1" ist die Anzeige grün.
Du darfst diesen Dateianhang nicht ansehen.
Ich verstehe die Erklärung so, dass der Zunstand "Abgeregelt" über ein (wahr) - also 1 - erkannt werden müsste.
Ist das so gewollt?
Frohe Ostern,
Heiko
#96
Server - Linux / Aw: Offizielles FHEM Docker Ba...
Letzter Beitrag von heigu - 03 April 2026, 19:56:45Guten Tag ans Forum,
ich habe heute versucht meinen FHEM Docker Container von 5.2.5-bookworm auf 5.2.6-bookworm zu aktualisieren. Was sonst immer problemlos klapp, scheiterte diesmal am Modul I2C_BME280 bzw. dem dahinter liegenden I2C_RPII2C mit folgendem Fehler:
Was kann ich da machen, damit der I2C Bus auch in der neuen Version wieder läuft?
Danke für alle sachdienlichen Hinweise.
ich habe heute versucht meinen FHEM Docker Container von 5.2.5-bookworm auf 5.2.6-bookworm zu aktualisieren. Was sonst immer problemlos klapp, scheiterte diesmal am Modul I2C_BME280 bzw. dem dahinter liegenden I2C_RPII2C mit folgendem Fehler:
Code Auswählen
I2C_RPII2C: Error! no library for Hardware access installed
setuuid: Please define I2C_RPII2C first
0
Was kann ich da machen, damit der I2C Bus auch in der neuen Version wieder läuft?
Danke für alle sachdienlichen Hinweise.
#97
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von Starkstrombastler - 03 April 2026, 19:55:16Zitat von: Jörg am 01 April 2026, 19:05:24Ich versuche bei meinem Shelly EM Gen3 mit get KG_Waermepumpe_sg_ready_1_WWKI300 status den Gerätestatus zu aktualisieren. soweit funktioniert das auch, aber der /rpc/EM1.GetStatus und der /rpc/EM1Data.GetStatus werden nicht aktualisiert.Im nächsten Update ist die Abfrage experimentell enthalten, sie erfolgt vorläufig nur über die Fhem-Kommandozeile:
Code Auswählen
get <name> EMdataDamit werden die EnergyMeter Werte unabhängig von Intervall-Einstellungen abgeholt.Wenn das so einigermaßen passt, kann ich das nach Ostern fertig implementieren.
Zitat von: Jörg am 01 April 2026, 23:39:02Die eigentlichen Abfragen kommen durch ein Shellyscript, das auf allen Devices läuft.Was ist das für ein Script, kannst du weitere Info teilen?
#98
FHEMWEB / Aw: [Voicecontrol] Button für ...
Letzter Beitrag von schwatter - 03 April 2026, 18:46:05Hallo zusammen,
das voicecontrol.js liegt jetzt im contrib. Das ist die Version für PushToTalk oder kurz AlwaysOn.
Außerdem hat das notify jetzt eine zentrale Mappingtabelle. Mit der ist es möglich, ein Hauptkeyword mit
diversen Filtern zu setzen. Ich hoffe damit ist es Userfreundlicher.
Beispiel:
Aufschlüsselung:
Ich habe dazu das Wiki weiter angepasst:
https://wiki.fhem.de/wiki/FHEMWEB/VoiceControl:_Web-STT_%26_Hardware-Wakeword
Mh, anpassen muss man da eigentlich nichts? Das Javascript kopieren und laden. Das notify erstellen und los gehts.
Edit:
Ganz vergessen. Mit dem notify können jetzt auch mehrere Befehle kombiniert werden:
Gruß schwatter
das voicecontrol.js liegt jetzt im contrib. Das ist die Version für PushToTalk oder kurz AlwaysOn.
Außerdem hat das notify jetzt eine zentrale Mappingtabelle. Mit der ist es möglich, ein Hauptkeyword mit
diversen Filtern zu setzen. Ich hoffe damit ist es Userfreundlicher.
Beispiel:
Code Auswählen
"esszimmer:licht|lampe|deckenlampe" => { dev => "Lampe01_Ez", label => "Licht Esszimmer", cmdOn => "on", cmdOff => "off" }Aufschlüsselung:
Code Auswählen
"hauptkeyword:Filter1|Filter3|Filter3" => { dev => "Devicename", label => "Übersichtname", cmdOn => "on", cmdOff => "off" }Ich habe dazu das Wiki weiter angepasst:
https://wiki.fhem.de/wiki/FHEMWEB/VoiceControl:_Web-STT_%26_Hardware-Wakeword
Zitat von: Beta-User am 03 April 2026, 11:27:30Zitat von: schwatter am 30 März 2026, 22:15:53Ja kann ich machen. Dann können sich interessierte User das Script aus dem contrib nach /fhem/www/pgm2 kopieren.Thx. Vielleicht dann noch die dynamischen Teile (insbes. $FW_id?) vorher anpassen, so dass das etwas weniger manueller Anpassung durch interessierte User braucht?
Mh, anpassen muss man da eigentlich nichts? Das Javascript kopieren und laden. Das notify erstellen und los gehts.
Edit:
Ganz vergessen. Mit dem notify können jetzt auch mehrere Befehle kombiniert werden:
Code Auswählen
Ich: James!?
James: Ja?
Ich: Schalte das Licht in der Küche aus und schalte das Licht im Esszimmer an.
James: Erledigt!
Gruß schwatter
#99
FRITZ!Box / Aw: 72_FRITZBOX.pm wird zu 72_...
Letzter Beitrag von JoWiemann - 03 April 2026, 18:28:57Zitat von: elektron-bbs am 03 April 2026, 16:44:15Ich habe jetzt den betroffenen Abschnitt ab Zeile 9966 um eine Überprüfung, ob in dem Array ein Hash ist, erweitert:
Ob das der richtige Weg ist, überblicke ich nicht so ganz, aber zumindest funktioniert es jetzt mit meinen Fritz-Geräten.
Hallo electron-bbs,
vielen Dank für den guten Vorschlag. Übernehme ich gerne.
Grüße Jörg
#100
Bastelecke / Aw: ESP RGBWW Wifi Led Control...
Letzter Beitrag von vbs - 03 April 2026, 17:56:29So, Mosfets von Ali angekommen und hab ich vorhin eingelötet. Funktioniert jetzt sogar wieder. Also war offenbar nicht völlig falsch das Teil: https://de.aliexpress.com/item/1005008829362618.html?spm=a2g0o.order_list.order_list_main.5.21e51802Xwme0E&gatewayAdapt=glo2deu