- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...
Letzter Beitrag von Wurzelsepp - 05 Januar 2026, 04:55:46Da kann ich mich nur anschließen. Bekomme es einfach nicht zum laufen...
Die gesamte cfg wäre cool
Die gesamte cfg wäre cool
#2
Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...
Letzter Beitrag von dvdjimmy - 05 Januar 2026, 03:52:58Dachte das es eventuell Parameter gibt die das Abtauen hinauszögern. Kann sich jemand zudem erklären, wieso bei mir der Integralwert immer 0 bleibt? Die WP versucht irgendwie auch nicht, dass sie über den Sollwert mit dem Hysteresewert kommt um abzuschalten - max. 1-2 Grad über Soll bleibt sie hängen - obwohl die Hysterese bei 4K ist und die Asymmetrie auf 1
#3
Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...
Letzter Beitrag von stefanru - 04 Januar 2026, 23:42:45Naja ich habe das logging angepasst.
Bei der Version wird nun der Responce immer mit loglevel 2 ausgegeben nach Access Token: nicht definiert.
Für dich logge ich nun nur hart auch den Call.
Aber wenn du es in die andere Version eingebaut hast ist auch ok.
Beide sollten ok sein.
Naja das Problem ist das die API Antwortet und nicht direkt einen Error wirft.
Es kommt also eine Antwort und die Antwort ist:
{"error":"invalid-token-request"}
Darin sucht er das Token und weißt es zu.
Da er keins findet bleibt es undefined und das nächste IF führt zu der Warning.
Das kann ich verbessern sobald wir verstanden haben warum er bei dir hier den Request nicht mag.
Erstmal würde ich gerne sehen warum es bei dir zum Fehler kommt.
Bei mir wurde nun 14 mal der token refresh gelogged ohne probleme:
2026.01.04 17:54:21 1: VitoCal250AH - Refresh token request url: https://iam.viessmann-climatesolutions.com/idp/v2/token data: grant_type=refresh_token&client_id=xxx&refresh_token=xxx
Habe auch gesehen dass man hier v3 verwenden kann/soll.
Habe das mal angepasst und teste gerade.
Gruß,
Stefan
Bei der Version wird nun der Responce immer mit loglevel 2 ausgegeben nach Access Token: nicht definiert.
Für dich logge ich nun nur hart auch den Call.
Aber wenn du es in die andere Version eingebaut hast ist auch ok.
Beide sollten ok sein.
Naja das Problem ist das die API Antwortet und nicht direkt einen Error wirft.
Es kommt also eine Antwort und die Antwort ist:
{"error":"invalid-token-request"}
Darin sucht er das Token und weißt es zu.
Da er keins findet bleibt es undefined und das nächste IF führt zu der Warning.
Das kann ich verbessern sobald wir verstanden haben warum er bei dir hier den Request nicht mag.
Erstmal würde ich gerne sehen warum es bei dir zum Fehler kommt.
Bei mir wurde nun 14 mal der token refresh gelogged ohne probleme:
2026.01.04 17:54:21 1: VitoCal250AH - Refresh token request url: https://iam.viessmann-climatesolutions.com/idp/v2/token data: grant_type=refresh_token&client_id=xxx&refresh_token=xxx
Habe auch gesehen dass man hier v3 verwenden kann/soll.
Habe das mal angepasst und teste gerade.
Gruß,
Stefan
#4
Homematic / HM-LC-SW2-FM als Aktor für ein...
Letzter Beitrag von selfarian - 04 Januar 2026, 22:21:10Hallo zusammen,
ich habe seit geraumer Zeit einen HM-LC-SW2-FM für zwei Lampen im Einsatz gehabt. Das hat soweit gut funktioniert.
Nun habe ich das ganze "schön" gemacht (sprich die Affenschaukel durch einen Kabelkanal ersetzt) und dazu gewechselt, dass der Aktor eine der beiden Lampen (Paulman Urail mit vier Philips Hue Spots zu je 4,2 Watt) am Ausgang 2 und eine Steckdose am Ausgang 2 schalten soll.
So, nun passierte folgendes:
Unabhängig davon, ob die Steckdose an und/oder belegt ist, ging nach einem scheinbar zufälligem Zeitpunkt das Licht aus. Der Aktor ist/war dann nicht auffindbar.
Nach einiger Zeit konnte man den Aktor dann wieder finden und ihn auch über den gepeerten Taster wieder anschalten (oder die CCU3).
Dann ging das Licht aber irgendwann wieder aus... Ein ewiges hin und her.
Heute dachte ich mir dann einmal: Ich ziehe mal die Ader vom Ausgang 1 zur Steckdose ab (PEN habe ich nicht verändert). Interessanter Weise blieb das Licht dann an.
Meine Frage wäre: Habe ich ein Problem in der Verkabelung, das ich noch nicht gefunden habe (bei einem Kurzschluss dürfte das Licht ja gar nicht erst angehen), oder mute ich dem HM-LC-SW2-FM zuviel zu? Aber eigentlich dürfte doch eine Steckdose (mit einem Netzteil für eine GoPro) für ihn schaltbar sein?
Vor allem wundert mich aber: Solange die Steckdose Stromlos ist - sprich kein Verbraucher angesteckt ist und der HM-LC-SW2-FM den Ausgang 1 "aus" hat - dürfte das Doch den 2. Ausgang nicht beeinflussen?
Die Steckdose hatte ich schon durchgemessen, da schien alles ok zu sein. Daher wundert mich das Ganze etwas.
Vielen Dank schon einmal und beste Grüße,
Alex
ich habe seit geraumer Zeit einen HM-LC-SW2-FM für zwei Lampen im Einsatz gehabt. Das hat soweit gut funktioniert.
Nun habe ich das ganze "schön" gemacht (sprich die Affenschaukel durch einen Kabelkanal ersetzt) und dazu gewechselt, dass der Aktor eine der beiden Lampen (Paulman Urail mit vier Philips Hue Spots zu je 4,2 Watt) am Ausgang 2 und eine Steckdose am Ausgang 2 schalten soll.
So, nun passierte folgendes:
Unabhängig davon, ob die Steckdose an und/oder belegt ist, ging nach einem scheinbar zufälligem Zeitpunkt das Licht aus. Der Aktor ist/war dann nicht auffindbar.
Nach einiger Zeit konnte man den Aktor dann wieder finden und ihn auch über den gepeerten Taster wieder anschalten (oder die CCU3).
Dann ging das Licht aber irgendwann wieder aus... Ein ewiges hin und her.
Heute dachte ich mir dann einmal: Ich ziehe mal die Ader vom Ausgang 1 zur Steckdose ab (PEN habe ich nicht verändert). Interessanter Weise blieb das Licht dann an.
Meine Frage wäre: Habe ich ein Problem in der Verkabelung, das ich noch nicht gefunden habe (bei einem Kurzschluss dürfte das Licht ja gar nicht erst angehen), oder mute ich dem HM-LC-SW2-FM zuviel zu? Aber eigentlich dürfte doch eine Steckdose (mit einem Netzteil für eine GoPro) für ihn schaltbar sein?
Vor allem wundert mich aber: Solange die Steckdose Stromlos ist - sprich kein Verbraucher angesteckt ist und der HM-LC-SW2-FM den Ausgang 1 "aus" hat - dürfte das Doch den 2. Ausgang nicht beeinflussen?
Die Steckdose hatte ich schon durchgemessen, da schien alles ok zu sein. Daher wundert mich das Ganze etwas.
Vielen Dank schon einmal und beste Grüße,
Alex
#5
Einplatinencomputer / Aw: SSD für Raspi4 B Lebensdau...
Letzter Beitrag von Zrrronggg! - 04 Januar 2026, 21:42:10Ganz generell: SSDs halten ewig. Ich habe hier SSDs im Einsatz, die sind über 10 Jahre alt und zeigen keinerlei Probleme.
Das mir mal eine SSD verreckt ist liegt buchstäblich Jahrzehnte zurück, muss so um 2005 oder so gewesen sein - in der Frühphase.
Das mir mal eine SSD verreckt ist liegt buchstäblich Jahrzehnte zurück, muss so um 2005 oder so gewesen sein - in der Frühphase.
#6
Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...
Letzter Beitrag von binlan - 04 Januar 2026, 21:14:46Zitat von: stefanru am 04 Januar 2026, 16:41:13Ich habe nochmal ne Debug Version erstellt die auch den Call nun logged.
Ich habe sie zum Vergleich nun auch bei mir laufen.
Lade sie mal und schicke mir deine Calls dann vergleiche ich mit meinen.
Deine Version macht die Loglevel wieder auf die Ursprungsform. Deine zusätzliche Änderung ist das hier, ne?
Code Auswählen
3357c3357
< #Log3 $name, 1, "$name - " . $param->{"data"};
---
> Log3 $name, 1, "$name - Refresh token request url: " . $param->{"url"} . " data: " . $param->{"data"};
Ich habe das in die vorherige Version mit Log 1 eingepflegt, um weiterhin alles diesbezüglich zu loggen.
Ich fand an der bisherigen Ausgabe schon komisch, das "getRefreshCallback went ok" ok ist, dann aber Müll im response ist. Sollte das nicht einen Error werfen? Und die Warnung ist auch nicht hilfreich? Kann mein unterschiedliches Verhalten an meiner docker Umgebung liegen? perl version?
Code Auswählen
# perl -v
This is perl 5, version 36, subversion 3 (v5.36.3) built for aarch64-linux-gnu
Sind da ggf. irgendwelche perl safe-settings gesetzt? #7
Einplatinencomputer / RPi 3 - wie CULs anbinden [ge...
Letzter Beitrag von Zrrronggg! - 04 Januar 2026, 21:06:44Ich wollte hier Fragen, wie man CULs an einem RPi 3A+ mit Debian Trixie 64 bit (also die Standardinstallation zur Zeit) an's Laufen bekommt. Habs aber doch noch rausbekommen, daher hier mal kurz, falls jemand sucht.
Eingesteckt ist ein nano CUL
definiert in FHEM mit z.b.:
(ich habe noch 2 FHT Fensterkontakte, wer keinerlei FHT mehr hat "0000" am Ende)
Das führt aber nicht zum Erfolg, FHEM zeigt das CUL als "Disconnected" und Log zeigt
CUL1: Can't open /dev/ttyUSB0: Permission denied
Also ein Rechteproblem. FHEM läuft mit dem user fhem und der darf offenbar nicht auf tty zugreifen.
Mit
prüfen, wer Rechte an tty hat. Ergebnis
crw-rw----+ 1 root plugdev 188, 0 4. Jan 19:54 /dev/ttyUSB0
Die Gruppe "plugdev" kommt etwas unerwartet, war das nicht früher "serial" oder "tty"? Ist das eine Eigeneheit von Trixie? Egal:
Reboot.
Geht, CUL ist jetzt Initialized.
Eingesteckt ist ein nano CUL
definiert in FHEM mit z.b.:
Code Auswählen
define CUL1 CUL /dev/ttyUSB0@38400 1234 (ich habe noch 2 FHT Fensterkontakte, wer keinerlei FHT mehr hat "0000" am Ende)
Das führt aber nicht zum Erfolg, FHEM zeigt das CUL als "Disconnected" und Log zeigt
CUL1: Can't open /dev/ttyUSB0: Permission denied
Also ein Rechteproblem. FHEM läuft mit dem user fhem und der darf offenbar nicht auf tty zugreifen.
Mit
Code Auswählen
sudo ls -l /dev/ttyUSB0prüfen, wer Rechte an tty hat. Ergebnis
crw-rw----+ 1 root plugdev 188, 0 4. Jan 19:54 /dev/ttyUSB0
Die Gruppe "plugdev" kommt etwas unerwartet, war das nicht früher "serial" oder "tty"? Ist das eine Eigeneheit von Trixie? Egal:
Code Auswählen
sudo usermod -a -G plugdev fhemReboot.
Geht, CUL ist jetzt Initialized.
#8
Anfängerfragen / fhem auf Raspi 4 100% cpu load
Letzter Beitrag von Hackstall - 04 Januar 2026, 20:27:15Hi mein fhem ist sehr langsam geworden.
Immer wieder alle 20 braucht mein fhem ca 100% für 10sec.
Ich habe schon viel gelesen aber alles hat nicht geholfen.
Ich betreiber fhem in einem DockerContainer und auch den MQTT Server in einem anderen Container.
Beides läuft auf einem RASPI4.
Irgendwie mache ich mir Sorgen für Erweiterungen.
Ich habe diese Verhalten seit ungefähr 6 Monaten und war anfänglich der Meinung dass es nach einem
Update kam.
Gibt es etwas dass ich überprüfen kann?
Wie geht man hier am besten vor?
Einen Umzug auf einen NUC würde dann doch etwas Arbeit bedürfen wobei ich natürlich zunächst herausfinden möchte woran es liegt?
Danke für Eure Hilfe
P.S.: Auch der Start dauert sehr lange. Am Memory liegt es nicht. Genug vorhanden und kein Swapping
P.P.S: Ich habe dann doch einige Fhem2Fhem Devices auf einem anderen Rechner der viele Devices aus meinem langsamen Raspi spiegelt. Ist das ev. ein Problem?
Immer wieder alle 20 braucht mein fhem ca 100% für 10sec.
Ich habe schon viel gelesen aber alles hat nicht geholfen.
Ich betreiber fhem in einem DockerContainer und auch den MQTT Server in einem anderen Container.
Beides läuft auf einem RASPI4.
Irgendwie mache ich mir Sorgen für Erweiterungen.
Ich habe diese Verhalten seit ungefähr 6 Monaten und war anfänglich der Meinung dass es nach einem
Update kam.
Gibt es etwas dass ich überprüfen kann?
Wie geht man hier am besten vor?
Einen Umzug auf einen NUC würde dann doch etwas Arbeit bedürfen wobei ich natürlich zunächst herausfinden möchte woran es liegt?
Danke für Eure Hilfe
P.S.: Auch der Start dauert sehr lange. Am Memory liegt es nicht. Genug vorhanden und kein Swapping
P.P.S: Ich habe dann doch einige Fhem2Fhem Devices auf einem anderen Rechner der viele Devices aus meinem langsamen Raspi spiegelt. Ist das ev. ein Problem?
#9
1Wire / 4,7k Widerstand zu groß für 12...
Letzter Beitrag von marexel - 04 Januar 2026, 20:21:24Nabend,
da ich schon wieder Stress mit dem ZeroPi habe, hab ich jetzt meinen alten RPi2b angeworfen. Läuft soweit alles, nur bekomme ich im Gegensatz zum ZeroPi nicht alle (aktuell 10 (längste Strecke ca. 10m), später 12) DS18b20 ans laufen. Sobald mehr als 8 Sensoren angeschlossen sind, bricht alles zusammen.
Finde ich komisch und frage mich, woran es liegen könnte. (gleiches Netzteil, dtoverlay=w1-gpio-pullup)
Bei meiner Recherche bin ich auf den Widerstand gestoßen der teilweise auf 800Ohm reduziert wurde. In einem anderen Thread waren es 2,35kOhm.
Jetzt frage ich mich: kann ich damit etwas verkehrt machen oder zeigen im schlimmsten Fall die Sensoren einfach keine Werte mehr wie beim 4,7k?
Danke für eure Hilfe, Grüße,
marexel
da ich schon wieder Stress mit dem ZeroPi habe, hab ich jetzt meinen alten RPi2b angeworfen. Läuft soweit alles, nur bekomme ich im Gegensatz zum ZeroPi nicht alle (aktuell 10 (längste Strecke ca. 10m), später 12) DS18b20 ans laufen. Sobald mehr als 8 Sensoren angeschlossen sind, bricht alles zusammen.
Finde ich komisch und frage mich, woran es liegen könnte. (gleiches Netzteil, dtoverlay=w1-gpio-pullup)
Bei meiner Recherche bin ich auf den Widerstand gestoßen der teilweise auf 800Ohm reduziert wurde. In einem anderen Thread waren es 2,35kOhm.
Jetzt frage ich mich: kann ich damit etwas verkehrt machen oder zeigen im schlimmsten Fall die Sensoren einfach keine Werte mehr wie beim 4,7k?
Danke für eure Hilfe, Grüße,
marexel
#10
1Wire / Aw: Mehrere Pi GPIO 1-Wire Sch...
Letzter Beitrag von marexel - 04 Januar 2026, 20:11:36Nabend,
meist du das hier? https://wiki.fhem.de/wiki/Raspberry_Pi_und_1-Wire#Betrieb_eines_weiteren_1-Wire_Bus
meist du das hier? https://wiki.fhem.de/wiki/Raspberry_Pi_und_1-Wire#Betrieb_eines_weiteren_1-Wire_Bus