- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...
Letzter Beitrag von stefanru - 28 November 2025, 16:39:59Ok, fix ist im Git und im SVN.
Morgen könnt ihr es aus dem SVN holen indem ihr FHEM updated.
Wollt ihr es schon heute müsst er es von GIT holen.
Neue Version ist: 1.0.0
Nicht weil ich denke es ist nun besonders, sondern weil die nummern 0.X.X aufgebraucht waren
Viele Geüße,
Stefan
Morgen könnt ihr es aus dem SVN holen indem ihr FHEM updated.
Wollt ihr es schon heute müsst er es von GIT holen.
Neue Version ist: 1.0.0
Nicht weil ich denke es ist nun besonders, sondern weil die nummern 0.X.X aufgebraucht waren
Viele Geüße,
Stefan
#92
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von KölnSolar - 28 November 2025, 16:36:55Danke Jörg.
Daher entweder weglassen oder wenigstens gleichmäßig editieren. Wobei möglicherweise Kenner von routine-play auch noch die Syntax prüfen würden/könnten.
Zitatdas - ist nur ein Überbleibsel des gekürzten Routine-Code.Wie Du jetzt gelernt hast, guckt man genau hin, um Deinen Fehler zu finden.
Im Original folgen dort noch ein paar Zahlen und Buchstaben.
Da ich mir nicht sicher war, ob man damit etwas anfangen kann oder nicht, habe ich den Aufruf gekürzt.
Daher entweder weglassen oder wenigstens gleichmäßig editieren. Wobei möglicherweise Kenner von routine-play auch noch die Syntax prüfen würden/könnten.
#93
Beleuchtung / Aw: Hue Bridge Pro (v3) - Migr...
Letzter Beitrag von Klaus.A - 28 November 2025, 16:32:28@Rene
Ja, bei einigen funktioniert es, bei vielen nicht. Was ich bisher weiß, auch aus anderen Foren: Es liegt an der Bridge Firmware, genauer ist es die Implementierung der Zertifikate. Mit der Original hue App funktioniert alles, nur die API hat ein Problem: Wenn die externe Anwendung (z.B. FHEM) die Validierung der Zertifikate auslöst (was standardmäßig erforderlich und sinnvoll ist) dann schlägt diese Validierung in den meisten Fällen fehl. Es liegt daran wie der Betriebssystem bzw. Browser-Komponenten diese Validierung durchführen. Ein bestimmtes Feld (SAN = Subject Alternative Name) ist nicht wie erwartet besetzt, daher das negative Ergebnis.
Andere Systeme versuchen zur Zeit die Validierung zu umgehen - ein Verfahren das äußerst problematisch gesehen wird, weil es "Man-in-the-Middle" Attacken ermöglichen kann.
Zur Migration, so wie ich es bisher getestet habe: Man kann die bisherige Bridge (v2) unverändert lassen und die neue hue Bridge Pro (v3) zusätzlich in FHEM definieren. Da passiert erst einmal nichts mit der bestehenden Installation. Dann sieht man ob die Einbindung erfolgreich ist.
Die Migration der Lampen von v2 auf v3 ist jederzeit später möglich. Man könnte sie auch nochmals auf Werkseinstellungen wieder zurück setzen und dann die Migration durchführen.
Richtig, wenn man die Migration im hue System macht dann wird die v2 Bridge am Ende zurück gesetzt. Wenn dann die Anbindung von FHEM nicht funktioniert dann hat man ein großes Problem: Zurück von v3 auf v2 geht nicht und die Bridge v2 ist dann auch "leer".
Ich konnte noch nicht eine komplette Neuinstallation meines gesamten Systems testen (bin zur Zeit noch aus gesundheitlichen Gründen blockiert). Es wird interessant was mit der neuesten Armbian OS Version (Trixie) passiert. Ich warte auch auf einen Firmware-Update von Philips/Signfy für die hue Bridge Pro. Das Problem liegt in der Firmware der Bridge, nicht im FHEM hue Bridge Modul - das kann das geforderte HTTPS (bereits für die Bridge v2) und wie ich gesehen habe läuft es auch mit ein paar OS-Varianten/Konfigurationen. Da kamen korrekte Daten von der neuen Bridge zurück.
Gruß Klaus
Ja, bei einigen funktioniert es, bei vielen nicht. Was ich bisher weiß, auch aus anderen Foren: Es liegt an der Bridge Firmware, genauer ist es die Implementierung der Zertifikate. Mit der Original hue App funktioniert alles, nur die API hat ein Problem: Wenn die externe Anwendung (z.B. FHEM) die Validierung der Zertifikate auslöst (was standardmäßig erforderlich und sinnvoll ist) dann schlägt diese Validierung in den meisten Fällen fehl. Es liegt daran wie der Betriebssystem bzw. Browser-Komponenten diese Validierung durchführen. Ein bestimmtes Feld (SAN = Subject Alternative Name) ist nicht wie erwartet besetzt, daher das negative Ergebnis.
Andere Systeme versuchen zur Zeit die Validierung zu umgehen - ein Verfahren das äußerst problematisch gesehen wird, weil es "Man-in-the-Middle" Attacken ermöglichen kann.
Zur Migration, so wie ich es bisher getestet habe: Man kann die bisherige Bridge (v2) unverändert lassen und die neue hue Bridge Pro (v3) zusätzlich in FHEM definieren. Da passiert erst einmal nichts mit der bestehenden Installation. Dann sieht man ob die Einbindung erfolgreich ist.
Die Migration der Lampen von v2 auf v3 ist jederzeit später möglich. Man könnte sie auch nochmals auf Werkseinstellungen wieder zurück setzen und dann die Migration durchführen.
Richtig, wenn man die Migration im hue System macht dann wird die v2 Bridge am Ende zurück gesetzt. Wenn dann die Anbindung von FHEM nicht funktioniert dann hat man ein großes Problem: Zurück von v3 auf v2 geht nicht und die Bridge v2 ist dann auch "leer".
Ich konnte noch nicht eine komplette Neuinstallation meines gesamten Systems testen (bin zur Zeit noch aus gesundheitlichen Gründen blockiert). Es wird interessant was mit der neuesten Armbian OS Version (Trixie) passiert. Ich warte auch auf einen Firmware-Update von Philips/Signfy für die hue Bridge Pro. Das Problem liegt in der Firmware der Bridge, nicht im FHEM hue Bridge Modul - das kann das geforderte HTTPS (bereits für die Bridge v2) und wie ich gesehen habe läuft es auch mit ein paar OS-Varianten/Konfigurationen. Da kamen korrekte Daten von der neuen Bridge zurück.
Gruß Klaus
#94
Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...
Letzter Beitrag von combog - 28 November 2025, 16:16:02Hallo Stefan,
wollte dir grad die gleiche Fehlermeldung schicken wie Aaameyer. Dann freue ich mich auf deine Problemlösung.
Gruß
Claus
wollte dir grad die gleiche Fehlermeldung schicken wie Aaameyer. Dann freue ich mich auf deine Problemlösung.
Gruß
Claus
#95
FHEM Development / Aw: Keine commits mehr unter F...
Letzter Beitrag von Otto123 - 28 November 2025, 16:12:44Das hat offenbar mit der Portumleitung (iptables) für IPv4 Port 443 zu tun.
Mit IPv6 gibt es keine Umleitung da funktioniert es, allerdings haben die meistens VMs keine IPv6 Adresse.
Wenn ich wget https://svn.fhem.de auf fhem2-wiki ausführe gibt es Fehler, wenn ich das auf fhem2-va ausführe funktioniert es.
Hat da jemand einen Tipp? Was ich ausführe:
Edit:
Lösung mit KI
zumindest mein Test funktioniert jetzt
Mit IPv6 gibt es keine Umleitung da funktioniert es, allerdings haben die meistens VMs keine IPv6 Adresse.
Wenn ich wget https://svn.fhem.de auf fhem2-wiki ausführe gibt es Fehler, wenn ich das auf fhem2-va ausführe funktioniert es.
Hat da jemand einen Tipp? Was ich ausführe:
Code Auswählen
/sbin/iptables -t nat -I PREROUTING -p tcp -d 188.40.131.57 --dport 443 -j DNAT --to 192.168.124.63:443
/sbin/iptables -I FORWARD -d 192.168.124.63 -p tcp --dport 443 -j ACCEPT
was daraus wirdCode Auswählen
sudo iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere fhem2-host tcp dpt:https to:192.168.124.63:443
DNAT tcp -- anywhere fhem2-host tcp dpt:http to:192.168.124.63:80Edit:
Lösung mit KI
zumindest mein Test funktioniert jetztZitat🛠� Lösung: Hairpin NAT aktivieren
Du musst zusätzlich eine SNAT/MASQUERADE-Regel setzen, damit interne Clients (VM2) über die öffentliche IP den Dienst in VM1 erreichen können.
Beispiel (ergänzend zu deinen Regeln):
# DNAT hast du schon:
iptables -t nat -I PREROUTING -p tcp -d 188.40.131.57 --dport 443 -j DNAT --to-destination 192.168.124.63:443
iptables -I FORWARD -d 192.168.124.63 -p tcp --dport 443 -j ACCEPT
# Jetzt Hairpin NAT hinzufügen:Code Auswähleniptables -t nat -A POSTROUTING -s 192.168.124.0/24 -d 192.168.124.63 -p tcp --dport 443 -j MASQUERADE��
✨ Wirkung
- Externe Clients: gehen wie bisher über DNAT → VM1.
- Interne Clients (VM2): wenn sie die öffentliche IP des Hosts nutzen, werden ihre Pakete durch die MASQUERADE-Regel so umgeschrieben, dass VM1 sie akzeptiert und die Antwort wieder korrekt zurückgeht.
#96
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von Knallfrosch - 28 November 2025, 15:39:14Achso, sorry!
das - ist nur ein Überbleibsel des gekürzten Routine-Code.
Im Original folgen dort noch ein paar Zahlen und Buchstaben.
Da ich mir nicht sicher war, ob man damit etwas anfangen kann oder nicht, habe ich den Aufruf gekürzt.
Grüße
das - ist nur ein Überbleibsel des gekürzten Routine-Code.
Im Original folgen dort noch ein paar Zahlen und Buchstaben.
Da ich mir nicht sicher war, ob man damit etwas anfangen kann oder nicht, habe ich den Aufruf gekürzt.
Grüße
#97
Beleuchtung / Aw: Hue Bridge Pro (v3) - Migr...
Letzter Beitrag von mystex - 28 November 2025, 15:27:39Hallo zusammen,
ich war wohl auch zu schnell und habe mir die neue Bridge bestellt ohne den gesamten Beitrag zu lesen. Sah ja erst ganz easy aus, die neue Bridge einzubinden und bei einigen scheint es ja auch tatsächlich ohne Probleme und Performance-Einbußen geklappt zu haben. Ich würde gerne erst testen, ob ich die neue Bridge "sauber" in FHEM anbinden kann. Wenn ich es richtig gelesen habe wird bei der Migration von v2 auf v3 die "alte" Bridge zurückgesetzt und so wäre es dann auch nicht mehr möglich ein FHEM Backup einzuspielen und die "alte" Bridge weiter zu nutzen, falls es mit der Neuen nicht funktioniert.
Weiß jemand, ob man die Migration von v2 auf v3 auch später durchführen kann? Aktuelle Idee ist "alte" Bridge "abschalten". Neue Bridge ohne Migration in FHEM einbinden. Vorher vielleicht noch über die HUE App eine Testlampe (hab noch ein bisher ungenutztes HUE Leuchtmittel) anlegen. Sollte die Anbindung der neuen Bridge dann reibungslos laufen, die Bridge auf Werkseinstellungen setzen und dann die Migration von v2 auf v3 machen. Bin halt nur etwas unsicher, ob die Möglichkeit der Migration weiterhin besteht, wenn die Bridge bereits im Einsatz war.
Vielleicht hat auch noch jemand einen anderen Lösungsansatz für mich. Hab keine Idee, wie ich es ansonsten testen soll, ohne mir die ganze HUE Integration zu zerschießen, falls es nicht läuft.
Gruß,
Rene
ich war wohl auch zu schnell und habe mir die neue Bridge bestellt ohne den gesamten Beitrag zu lesen. Sah ja erst ganz easy aus, die neue Bridge einzubinden und bei einigen scheint es ja auch tatsächlich ohne Probleme und Performance-Einbußen geklappt zu haben. Ich würde gerne erst testen, ob ich die neue Bridge "sauber" in FHEM anbinden kann. Wenn ich es richtig gelesen habe wird bei der Migration von v2 auf v3 die "alte" Bridge zurückgesetzt und so wäre es dann auch nicht mehr möglich ein FHEM Backup einzuspielen und die "alte" Bridge weiter zu nutzen, falls es mit der Neuen nicht funktioniert.
Weiß jemand, ob man die Migration von v2 auf v3 auch später durchführen kann? Aktuelle Idee ist "alte" Bridge "abschalten". Neue Bridge ohne Migration in FHEM einbinden. Vorher vielleicht noch über die HUE App eine Testlampe (hab noch ein bisher ungenutztes HUE Leuchtmittel) anlegen. Sollte die Anbindung der neuen Bridge dann reibungslos laufen, die Bridge auf Werkseinstellungen setzen und dann die Migration von v2 auf v3 machen. Bin halt nur etwas unsicher, ob die Möglichkeit der Migration weiterhin besteht, wenn die Bridge bereits im Einsatz war.
Vielleicht hat auch noch jemand einen anderen Lösungsansatz für mich. Hab keine Idee, wie ich es ansonsten testen soll, ohne mir die ganze HUE Integration zu zerschießen, falls es nicht läuft.
Gruß,
Rene
#98
Termine und Veranstaltungen / Aw: Stammtisch Leipzig
Letzter Beitrag von Otto123 - 28 November 2025, 15:26:16Liebe Grüße auch an die, die gestern leider nicht konnten. Trotz der kleinen (5) Runde war es ein interessanter Stammtisch mit 14 Wild-Würsten.
Wir haben
Also Schrottwichteln mit Powershell:
Edit: gehtnichtgibtsnicht zwar nicht einfacher, aber vielleicht braucht man es mal (Quelle):
Viele Grüße
Otto
Wir haben
- den Radar Presencemelder kennengelernt der bis zu 3 Personen im Raum ermitteln kann.
- wie so oft über Proxmox geredet
- etwas über Code verbessern mit Copilot angeschaut.
- Ohne MS Office hat Windows Update die Copilot App bei mir installiert
- Mit MS Office 2013 hat MS die Copilot 365 App installiert.
Also Schrottwichteln mit Powershell:
Code Auswählen
Get-AppxPackage -Name *MicrosoftOfficeHub*|Remove-AppPackage
Und dann im MS Store nach Copilot suchen und den installieren (habe es mit PS zunächst nicht hinbekommen)Edit: gehtnichtgibtsnicht
zwar nicht einfacher, aber vielleicht braucht man es mal (Quelle):- Im MS Store Copilot suchen und den Link teilen (ja hier kann man einfach auf installieren klicken)
- Hierher gehen und den Link dort einwerfen.
- Den Link zum Paket (appxbundle am Ende) kopieren und hier einfügen:
Code Auswählen
$uri = "http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/cee3b989-8f6c-455c-afaf-b0a11daa09c1?P1=1764346027&P2=404&P3=2&P4=SxxpSWNbDHlaoDIqQ7JtT3OIKZ%2fubQryq65Kb27V9s5VpUHvZ9bBf%2feLjJKqkPt5Iesk3536h%2fMA1LqiioD3Bw%3d%3d"
Invoke-WebRequest -Uri $uri -OutFile Copilot.appx -UseBasicParsing
Add-AppxPackage .\Copilot.appxViele Grüße
Otto
#99
DOIF / Aw: aktuelle Zeit in dummy sch...
Letzter Beitrag von matkoh - 28 November 2025, 15:17:16Zitat von: rabehd am 27 November 2025, 20:16:49Außerdem auf ein Event kann man mit mehreren Devices reagieren.
Das habe ich jetzt in Kombination mit zeitverzögerter Ausführung versucht. Im 2. DOIF, in dem eines der Radios eingeschaltet wird, habe ich folgende Bedingung formuliert:
Code Auswählen
## 5
DOELSEIF ([Fruehstueck] eq "Kueche" and [Matthias.Status_2:?SHORT] and [+0:15])
(set Sonos_Kueche Volume 13, set Sonos_Kueche PlayURI ...)Es kommt kein Fehler, aber Sonos wird auch nicht eingeschaltet. Habe ich das falsch verstanden?
Matthias
#100
FHEM Development / Aw: Keine commits mehr unter F...
Letzter Beitrag von rudolfkoenig - 28 November 2025, 15:15:26ZitatJetzt sieht das alles besser aus. Rudi, kannst Du bitte nochmal testen.Ich konnte keinen Unterschied feststellen.
Habe fhemupdate.pl nochmal gestartet, musste 2 Minuten warten, und dann kam die Fehlermeldung von oben.