Ein Fensterkontakt und 4 Heizungsthermostaten und FHEM

Begonnen von shorty1111, 11 Juli 2016, 11:27:35

Vorheriges Thema - Nächstes Thema

shorty1111

Vielleicht bin ich hier ja falsch aber ich versuch es einfach mal:

Ich habe in einem Zimmer 4 Heizungsregler

Typ: HM-CC-RT-DN und

einen optischen Fensterkontakt Typ: HM-Sec-Sco

Folgendes Problem:
alle RTs untereinander direkt gepeert. Dann an jedem RT den SEC direkt mit RT1 bis RT3 gepeert. Soweit ok. Dann Versuch den 4.RT mit SEC zu peeren. Der SEC geht nach Verbindungsaufbau (Druck auf lern-Knopf) in rotes Blinken über.

Auch schon versucht dieses über FHEM als Pairing Master per VCCU ( in allen RTs die VCCU als Master gesetzt und auch im SEC die VCCU als Master gesetzt) so durchzuführen, genau das gleiche Verhalten vom SEC.

Es scheint so als ob der Fensterkontakt (SEC) maximal 3 RTs abspeichern kann.

Inzwischen habe ich es zumindest geschafft das der SEC alle RTs steuert und die RTs sowie der SEC in FHEM mitgeschrieben werden indem ich nach dem roten Blinken einfach nur die Batterie aus dem SEC genommen habe und dann wieder eingesetzt habe. Funktion jetzt da, nur in FHEM ist die Konstellation natürlich dadurch noch nicht "sauber". Vielleicht hat ja jemand einen Tipp wie mein Vorhaben durchzuführen ist und auch FHEM damit glücklich ist ohne das mir beim HM- Config Check das fehlende Peering von den RTs zum Fensterkontakt in den Registern des SEC vorgeworfen wird.

... oder kann der SEC vielleicht nur 3 RTs steuern weil sonst in dem Ding der Speicher überläuft?

habe das alles mit einem Selbsbau CUL und auch mit dem HM-USB-Stick versucht. AES ist ausgeschaltet im SEC, aber auch mit AES an gleiches Verhalten.

Ich habe das dann auch noch mal nur mit der Windows Software für den USB Stick versucht, auch da gleiches Verhalten. Drei Partner gehen, beim vierten geht die rote Lampe an.

martinp876

Hm gibt an wie viele peers ein kanal kann - meist jedenfalls. Moeglich, dass es 3 sind.
Hast du die config des sc ausgelesen? Nicht dass noch ein alter peer eingetragen ist.

Den Status sendet ein device meist( nicht alle) an die Gruppe. Dann werden noch alle einzeln befragt. Das bedeutet, dass alle aktoren die den sc als peer eingetragen haben sofort reagieren.
In deinem Fall ist es wohl so, dass alle 4 rts den sc als peer haben und somit reagieren. Der sc hat aber nur 3 und fordert von diesen ein ack, nicht aber vom 4ten.
Sollte es zum uebertragungsproblem kommen wird der sc die msg für die ersten 3 wiederholen, nicht aber fuer den 4.

Diese config kannst du im peerchan kommando erzewingen mit actor als parameter.

shorty1111

So wird es sein, ich habe mich schon fast mit dem Ergebnis abgefunden, ist zwar nicht "hübsch" aber die Funktion und das Protokoll in FHEM ist ja da.

frank

ich glaube, es gab hier auch schon mal so einen thread. eventuell aber mit den magnetischen kontakten.
mach doch mal bei elv/eq3 eine anfrage.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html