- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
FHEM Code changes / Revision 31624: controls_fhem....
Letzter Beitrag von System - 07 September 2026, 07:51:04Revision 31624: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31624: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31624: controls_fhem.txt: fhemupdate checkin
#2
Homematic / Aw: QCCU — Homematic-IP-Zentra...
Letzter Beitrag von Beta-User - 07 September 2026, 07:14:18Zitat von: tostmann am 06 September 2026, 22:51:48Nimm 2026.9.7 vor dem FHEM-Update mit, dann hast du beide Wechsel in einem Rutsch.So, die Quiche ist aktuell, die firmware auch, update mit "ohne" Button war kein Problem, Danke!
Das HMUARTLGW stecke ich heute nachmittag mal eine Zeitlang aus, dann sollte der CUL tatsächlich auch was zu tun bekommen.
Der Maple hat es die Nacht über übrigens nicht geschafft, die (zur Änderung angeforderte) peer-Liste im Bewegungsmelder zu aktualisieren. Hab's jetzt neu gestartet, aber vermutlich muss ich das Ding doch von der Wand holen, um den Knopf zu drücken...
#3
Homematic / Aw: QCCU — Homematic-IP-Zentra...
Letzter Beitrag von tostmann - 06 September 2026, 22:51:48Danke euch beiden. Bestätigt: uptime, also das t-Kommando.
Die cmds-Zeile zeigt es: der CUL-Zugang von QCCU meldete "A V X T", beantwortete aber nur V, ? und T01 (und nahm As entgegen). t stand nicht in der Liste, X und C<hh> wurden verworfen. uptime, fhtbuf, credit10ms und raw liefen damit in den 3-s-Timeout von CUL_ReadAnswer, und der generische Zweig von CUL_Get ruft dann DevIo_Disconnected: Verbindung weg, Neuanmeldung (V, ?, X21, Ar, T01). Daher der Neuaufbau im Log. Nur ccconf gibt bloß den Timeout zurück.
Behoben in 2026.9.7. cmds lautet jetzt "A C T V X t", so antwortet eine laufende Zentrale:
get ccconf ergibt daraus freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB. Dafür war eine Umschrift nötig: der Stick antwortet C0D=21, CUL_Get prüft ^C.* = .* und nimmt den Dezimalwert aus dem fünften Feld. t kennt der Stick nicht; die Zentrale antwortet mit ihrer eigenen Laufzeit in 8-ms-Ticks.
Ansgar, zu #28: ja, CUL_Get prüft nur %gets, nicht CMDS — das t geht auch an einen Stick, der es nie angeboten hat. Trotzdem mein Fehler: wer sich als CUL ausgibt, muss t können und melden. Zu get raw: Unbekanntes quittiert der Zugang jetzt mit "? " wie der Stick selbst, kostet also nicht mehr die Verbindung. Ausgeführt wird davon nichts: W0F/W10/W11, B01 und C<hh> oberhalb 0x2E bleiben draußen und stehen als verworfen im Protokoll der Zentrale. Grund ist die zweite Familie am selben Stick: ein verstellter Träger oder ein Sprung in den Bootlader legt die HmIP-Seite mit still, und 0x3F ist der RX-FIFO.
IO-Wechsel: deine Erklärung in #28 trifft es besser als meine Vermutung; der Nebensatz (beim Antworten kein Wechsel, weil HM-LAN/HMUARTLGW/TSCUL selbst quittieren, der CUL aber von CUL_HM aus) ist die Trennlinie für alles Weitere. Beta-User: den CUL-Anteil siehst du, wenn du einem der anderen IOs eine Weile den Stecker ziehst. Nach dem FHEM-Update wären list <cul> und get <hminfo> protoEvents short interessant, vor allem ob der HM-SEN-MDIR-O über ihn läuft. Nimm 2026.9.7 vor dem FHEM-Update mit, dann hast du beide Wechsel in einem Rutsch.
Sidey, zur Richtung: nicht ,,noch ein FHEM-Modul", sondern wer quittiert.
HM-LAN, HMUARTLGW und TSCUL quittieren selbst, der CUL lässt quittieren. Der Stick kann es seit 19.08. auch: Aa setzt die eigene Adresse, Aq1 schaltet die Selbstquittung ein (100 ms nach Empfang), und die später vom Wirt gebaute Quittung schluckt er — sonst lag sie doppelt auf dem Funk, byte-gleich im Abstand von 23 ms. Einschalten darf man das nur, wenn der Wirt schweigt, und mit dem gewöhnlichen CUL-Modul tut er das nicht: CUL_HM prüft IODev->{helper}{VTS_ACK}, gesetzt wird das allein von 00_TSCUL.pm, nicht von dem, was in FHEM mitkommt.
Dazu kommt, was der Stick nicht wissen kann: ob noch etwas ansteht. Ein Wakeup-Gerät braucht das Wach-Bit in der Quittung, sonst schläft es ein und der wartende Befehl verpasst sein Fenster — genau das würde eine blinde Selbstquittung verursachen. Das Gegenstück gibt es (Aw<Adresse>, Aw000000 wenn nichts ansteht), sagen muss es der Wirt, so wie CUL_HM es mit $wulzy führt. Dasselbe für aesCommReq (Challenge statt Quittung) und Sensoren mit ACK-Status (motionDetector, HM-SEC-SC). CUL_HM baut das je Gerät längst zusammen — hmInitMsg mit Adresse, Flags, Schlüsselindex, AES-Maske — gibt es aber nur an HMLAN, HMUARTLGW und IOs mit VTS_AES weiter.
Was fehlt, ist die Zahl, die das rechtfertigt. Am 19.08. gemessen quittiert CUL_HM sieben Frames hintereinander nach 100–101 ms ohne eine einzige Wiederholung des Geräts; die 100 ms sind in 00_CUL.pm Absicht ($waitTgt). Der Gewinn liegt also nicht im Normalbetrieb, sondern wo der Wirt die Frist nicht hält: über Netz, unter Last, oder wenn er gar nicht quittiert. Beta-User, deshalb sind deine protoEvents mehr wert als jede Messung hier: ohne Resends ist die Quittung bei dir nicht das Problem, und ich baue an der falschen Stelle.
Ansgar, dazu brauche ich dich: welchen Zustand führt TS-CUL je Gerät, und was liefert der Wirt zur Laufzeit nach? Was der Stick hat (eine Adresse, ein Wach-Bit für eine Gegenstelle, Duplikat-Schlucken), ist die Fassung für ein Gerät; für mehrere braucht es je Gerät einen Eintrag, und die Duplikatprüfung vergleicht heute nur Zähler und Ziel — eine abweichende Quittung des Wirts würde sie ebenfalls schlucken.
Sidey, HMUARTLGW-Emulation: als Erkundung lohnt sie nicht, was FHEM einem IO mitgibt, steht in 00_HMUARTLGW.pm und 10_CUL_HM.pm. Sinn hat sie, wenn QCCU diese Schnittstelle am Ende anbietet — dann als Alternative zum CUL-Weg, nicht als Vorprodukt: das Modul erwartet vom IO das komplette Sendeverhalten samt Wiederholungen, Credits und AES. Beides zu pflegen ist unrealistisch.
Wenn du dafür bist, ist der Anmeldeautomat das Stück ohne Funk: 16 Zustände (STATE_QUERY_APP bis STATE_SET_TEMP_KEY) bis RUNNING, bei der LAN-Variante ein zweiter Port mit KeepAlive alle 10 s und optional Rijndael mit MD5(lgwPw) als Schlüssel. Zwei Stolpersteine: das Modul schickt einen laufenden Coprozessor beim Start per CHANGE_APP erst in den Bootlader zurück, die Gegenstelle muss damit anfangen; und die Antwort auf ADD_PEER trägt AssignedPeerCnt, taugt also nicht als feste Tabelle. Erfolgskriterium: cond = ok, KeepAlive läuft, je Gerät ein ADD_PEER im Log, bei aesCommReq zusätzlich PEER_ADD_AES. Dafür lieber ein eigenes Thema.
Die cmds-Zeile zeigt es: der CUL-Zugang von QCCU meldete "A V X T", beantwortete aber nur V, ? und T01 (und nahm As entgegen). t stand nicht in der Liste, X und C<hh> wurden verworfen. uptime, fhtbuf, credit10ms und raw liefen damit in den 3-s-Timeout von CUL_ReadAnswer, und der generische Zweig von CUL_Get ruft dann DevIo_Disconnected: Verbindung weg, Neuanmeldung (V, ?, X21, Ar, T01). Daher der Neuaufbau im Log. Nur ccconf gibt bloß den Timeout zurück.
Behoben in 2026.9.7. cmds lautet jetzt "A C T V X t", so antwortet eine laufende Zentrale:
Code Auswählen
V V 2.0.92 q-culfw
? ? (? is unknown) Use one of A C T V X t
t 00001B6A -> uptime 0 00:00:56
T03 00 -> fhtbuf (kein FHT hier)
X 21 900 -> credit10ms des Sticks
C0D C0D = 21 / 33
C0E C0E = 65 / 101
C0F C0F = 6A / 106
C10 C10 = C8 / 200
C1B C1B = 43 / 67
C1D C1D = 91 / 145
C3F ? -> quittiert, nicht ausgeführt
W0F21 ?
B01 ?
get ccconf ergibt daraus freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB. Dafür war eine Umschrift nötig: der Stick antwortet C0D=21, CUL_Get prüft ^C.* = .* und nimmt den Dezimalwert aus dem fünften Feld. t kennt der Stick nicht; die Zentrale antwortet mit ihrer eigenen Laufzeit in 8-ms-Ticks.
Ansgar, zu #28: ja, CUL_Get prüft nur %gets, nicht CMDS — das t geht auch an einen Stick, der es nie angeboten hat. Trotzdem mein Fehler: wer sich als CUL ausgibt, muss t können und melden. Zu get raw: Unbekanntes quittiert der Zugang jetzt mit "? " wie der Stick selbst, kostet also nicht mehr die Verbindung. Ausgeführt wird davon nichts: W0F/W10/W11, B01 und C<hh> oberhalb 0x2E bleiben draußen und stehen als verworfen im Protokoll der Zentrale. Grund ist die zweite Familie am selben Stick: ein verstellter Träger oder ein Sprung in den Bootlader legt die HmIP-Seite mit still, und 0x3F ist der RX-FIFO.
IO-Wechsel: deine Erklärung in #28 trifft es besser als meine Vermutung; der Nebensatz (beim Antworten kein Wechsel, weil HM-LAN/HMUARTLGW/TSCUL selbst quittieren, der CUL aber von CUL_HM aus) ist die Trennlinie für alles Weitere. Beta-User: den CUL-Anteil siehst du, wenn du einem der anderen IOs eine Weile den Stecker ziehst. Nach dem FHEM-Update wären list <cul> und get <hminfo> protoEvents short interessant, vor allem ob der HM-SEN-MDIR-O über ihn läuft. Nimm 2026.9.7 vor dem FHEM-Update mit, dann hast du beide Wechsel in einem Rutsch.
Sidey, zur Richtung: nicht ,,noch ein FHEM-Modul", sondern wer quittiert.
HM-LAN, HMUARTLGW und TSCUL quittieren selbst, der CUL lässt quittieren. Der Stick kann es seit 19.08. auch: Aa setzt die eigene Adresse, Aq1 schaltet die Selbstquittung ein (100 ms nach Empfang), und die später vom Wirt gebaute Quittung schluckt er — sonst lag sie doppelt auf dem Funk, byte-gleich im Abstand von 23 ms. Einschalten darf man das nur, wenn der Wirt schweigt, und mit dem gewöhnlichen CUL-Modul tut er das nicht: CUL_HM prüft IODev->{helper}{VTS_ACK}, gesetzt wird das allein von 00_TSCUL.pm, nicht von dem, was in FHEM mitkommt.
Dazu kommt, was der Stick nicht wissen kann: ob noch etwas ansteht. Ein Wakeup-Gerät braucht das Wach-Bit in der Quittung, sonst schläft es ein und der wartende Befehl verpasst sein Fenster — genau das würde eine blinde Selbstquittung verursachen. Das Gegenstück gibt es (Aw<Adresse>, Aw000000 wenn nichts ansteht), sagen muss es der Wirt, so wie CUL_HM es mit $wulzy führt. Dasselbe für aesCommReq (Challenge statt Quittung) und Sensoren mit ACK-Status (motionDetector, HM-SEC-SC). CUL_HM baut das je Gerät längst zusammen — hmInitMsg mit Adresse, Flags, Schlüsselindex, AES-Maske — gibt es aber nur an HMLAN, HMUARTLGW und IOs mit VTS_AES weiter.
Was fehlt, ist die Zahl, die das rechtfertigt. Am 19.08. gemessen quittiert CUL_HM sieben Frames hintereinander nach 100–101 ms ohne eine einzige Wiederholung des Geräts; die 100 ms sind in 00_CUL.pm Absicht ($waitTgt). Der Gewinn liegt also nicht im Normalbetrieb, sondern wo der Wirt die Frist nicht hält: über Netz, unter Last, oder wenn er gar nicht quittiert. Beta-User, deshalb sind deine protoEvents mehr wert als jede Messung hier: ohne Resends ist die Quittung bei dir nicht das Problem, und ich baue an der falschen Stelle.
Ansgar, dazu brauche ich dich: welchen Zustand führt TS-CUL je Gerät, und was liefert der Wirt zur Laufzeit nach? Was der Stick hat (eine Adresse, ein Wach-Bit für eine Gegenstelle, Duplikat-Schlucken), ist die Fassung für ein Gerät; für mehrere braucht es je Gerät einen Eintrag, und die Duplikatprüfung vergleicht heute nur Zähler und Ziel — eine abweichende Quittung des Wirts würde sie ebenfalls schlucken.
Sidey, HMUARTLGW-Emulation: als Erkundung lohnt sie nicht, was FHEM einem IO mitgibt, steht in 00_HMUARTLGW.pm und 10_CUL_HM.pm. Sinn hat sie, wenn QCCU diese Schnittstelle am Ende anbietet — dann als Alternative zum CUL-Weg, nicht als Vorprodukt: das Modul erwartet vom IO das komplette Sendeverhalten samt Wiederholungen, Credits und AES. Beides zu pflegen ist unrealistisch.
Wenn du dafür bist, ist der Anmeldeautomat das Stück ohne Funk: 16 Zustände (STATE_QUERY_APP bis STATE_SET_TEMP_KEY) bis RUNNING, bei der LAN-Variante ein zweiter Port mit KeepAlive alle 10 s und optional Rijndael mit MD5(lgwPw) als Schlüssel. Zwei Stolpersteine: das Modul schickt einen laufenden Coprozessor beim Start per CHANGE_APP erst in den Bootlader zurück, die Gegenstelle muss damit anfangen; und die Antwort auf ADD_PEER trägt AssignedPeerCnt, taugt also nicht als feste Tabelle. Erfolgskriterium: cond = ok, KeepAlive läuft, je Gerät ein ADD_PEER im Log, bei aesCommReq zusätzlich PEER_ADD_AES. Dafür lieber ein eigenes Thema.
#4
Homematic / Aw: QCCU — Homematic-IP-Zentra...
Letzter Beitrag von noansi - 06 September 2026, 20:17:32ZitatCUL_CUL cmds => A V X TOk, 't' wird nicht gemeldet, also auch nicht zu erwarten, dass uptime funktioniert.
Eher eine Schwäche des CUL Moduls, es dennoch zu probieren, statt eine Fehlermeldung auszuwerfen oder uptime gar nicht erst anzubieten.
ZitatWas mich etwas überrascht hat: Da taucht der CUL überhaupt nur bei den Devices auf, die seit der (Wieder-) Inbetriebnahme des CUL irgendwelche Probleme hatten (Strom weg oder die Batterien getauscht...).Der RSSI muss besser sein und eine Kommunikation muss von FHEM inititiert werden, damit ein IO Wechsel stattfinden kann.
Beim Antworten (ACK) darf ein IO-Wechsel nicht stattfinen, weil HM-LAN/HMUARTLGW/TSCUL schon geantwortet hätten oder noch antworten würden, CUL aber noch vom CUL_HM aus muss. Ebenso im Lauf von Multi-Message Kommunikation ist ein IO-Wechsel nicht günstig, wegen Zeitaufwand.
Totes oder überlastetes bisheriges IO ist ein sonstiger Wechselgrund.
Ein "unmotivierter" IO-Wechsel zwischendurch oder beim Empfang mit besserem RSSI ist nicht vorgesehen.
FHEM-Neustart behält den letzten Zustand, gibt ja dann auch noch keine RSSI-Info.
Also mal manuell motivieren, z.B. einem IO eine Weile den Stecker ziehen.
Gruß, Ansgar.
#5
FHEMapp / Aw: iframe-URL aus Reading
Letzter Beitrag von binford6000 - 06 September 2026, 19:46:35Danke Ulli für die Rückmeldung.
Das Image-Panel kommt für meinen Anwendungsfall leider nicht in Frage.
Für Webcams oder Gleiches ist es aber definitiv die bessere Wahl 👍🏻
Ich nutze es zB. für die Map von meinem Staubsauger 😉
Gruß,
Sebastian
Das Image-Panel kommt für meinen Anwendungsfall leider nicht in Frage.
Für Webcams oder Gleiches ist es aber definitiv die bessere Wahl 👍🏻
Ich nutze es zB. für die Map von meinem Staubsauger 😉
Gruß,
Sebastian
#6
Homematic / Aw: QCCU — Homematic-IP-Zentra...
Letzter Beitrag von Sidey - 06 September 2026, 19:19:31Hi,
Gibt es schon was neues bezüglich des HMUART Adapters oder könnte ich da irgendwas helfen?
Wenn ja, dann bräuchte ich den Punkt, an dem ich was tun könnte. Aktuell verstehe ich noch zu wenig von der Gesamtarchitektur
Grüße Sidey
Gibt es schon was neues bezüglich des HMUART Adapters oder könnte ich da irgendwas helfen?
Wenn ja, dann bräuchte ich den Punkt, an dem ich was tun könnte. Aktuell verstehe ich noch zu wenig von der Gesamtarchitektur
Grüße Sidey
#7
Homematic / Aw: QCCU — Homematic-IP-Zentra...
Letzter Beitrag von Beta-User - 06 September 2026, 19:06:14Ups, klar, "uptime" war gemeint.
get cmds liefert
Was mich etwas überrascht hat: Da taucht der CUL überhaupt nur bei den Devices auf, die seit der (Wieder-) Inbetriebnahme des CUL irgendwelche Probleme hatten (Strom weg oder die Batterien getauscht...).
protoEvents meldet dementsprechend auch (fast) keine Probleme, im Moment hängen noch ein paar Konfigurations-cmds an einen (bekanntermaßen zickigen) HM-SEN-MDIR-O.
Beantwortet das (halbwegs) die Frage?
get cmds liefert
Code Auswählen
CUL_CUL cmds => A V X TZitat von: noansi am 06 September 2026, 18:06:56Wie viele HM-devices sind ihm denn zugeordnet und wie sehen die protoEvents dazu aus?Meine Installation läuft vollständig mit automatischer IODev-Verwaltung, es sind derzeit keine ausdrücklichen Zuordnungen (mehr) vorhanden. Da die anderen beiden IOs vorher schon unter der VCCU liefen und der CUL erst im laufenden Betrieb dazukam, scheint es bislang weiter so zu sein, dass die Kommunikation mehr oder weniger ausschließlich über das Pi-Modul (HMUARTLGW) bzw. den MapleCUL läuft, vorrangig (und wenig überraschend) meint mein HMinfo-Device (bzw. franks HMInfo-Tools), dass das sich im jeweiligen Stockwerk befindliche IO im ranking die Nase vorn hat.
Was mich etwas überrascht hat: Da taucht der CUL überhaupt nur bei den Devices auf, die seit der (Wieder-) Inbetriebnahme des CUL irgendwelche Probleme hatten (Strom weg oder die Batterien getauscht...).
protoEvents meldet dementsprechend auch (fast) keine Probleme, im Moment hängen noch ein paar Konfigurations-cmds an einen (bekanntermaßen zickigen) HM-SEN-MDIR-O.
Beantwortet das (halbwegs) die Frage?
#8
FHEMWEB / Aw: Neuer Style: f18
Letzter Beitrag von cwagner - 06 September 2026, 19:04:43Ich benutzte seit langem und mit großer Begeisterung F18. Nun habe ich erstmals einen weblink (iframe) eingebaut und wollte diesen in meinem Dashboard an die gewünschte Stelle mit der Funktion 'Dragging active' an die gewünschte Stelle ziehen. Ups: alle Elemente haben den Kreuzcursor zum Skalieren der Fläche und den zweiten zum Verschieben. Nur Weblink nicht. Ich habe sicherheitshalber alle Beispiele aus der cmdRef nachgebaut, überall fehlen die Kreuzcursors. Beifund: Das gilt auch für die Pin-Nadel (mit Ausnahme der Befehlsoption cmdList).
Was mache ich falsch, wo kann ich mir ein Ei auf die Schiene genagelt haben?
Christian
Was mache ich falsch, wo kann ich mir ein Ei auf die Schiene genagelt haben?
Christian
#9
Sonstige Systeme / Aw: shelly duo bulb gen3 über ...
Letzter Beitrag von the ratman - 06 September 2026, 18:35:48das wäre blöd für mich. was ich weiß, geht ja beim modul kein blu - oder hat sich da was die letzten wochen getan?
derweil hab ich nämlich viele sensoren an einer 4fachsteckdose (damals zum shelly kennenlernen besorgt). die würden danach schreien an die unterputzschalter zu dürfen.
derweil hab ich nämlich viele sensoren an einer 4fachsteckdose (damals zum shelly kennenlernen besorgt). die würden danach schreien an die unterputzschalter zu dürfen.
#10
Sonstige Systeme / Aw: shelly duo bulb gen3 über ...
Letzter Beitrag von enno - 06 September 2026, 18:15:01habe ich hier zwei im Betrieb. Aber weil ich auch faul 
bin, nutze ich das Shelly Modul und nicht MQTT.
Gruss
Enno
bin, nutze ich das Shelly Modul und nicht MQTT. Code Auswählen
define Shelly_LED Shelly 192.168.178.150 Funktioniert tadellos.Gruss
Enno