Probleme mit HMLAN/FHEM/Fenstersensoren?

[Pfriemler]

Grund: ein gepeerter WinRec sollte als state open oder closed haben. das soll nicht überschrieben werden.

Nur für mich interessehalber, weil mich das sicher auch mal betrifft: das Reading state = unpeered stammt also aus einer Zeit vor einem Peering. Da macht unknown als default natürlich mehr Sinn - ob gepeert ist oder nicht, ist ja in der peerList ohnehin ersichtlich.
Andererseits sollte state also den Status des Fensterkontakts spiegeln - sprich: bei einer Zustandsänderung des Fenstersensors würde das aktualisiert - im Internal STATUS steht ja closed. Hat das der Thermostat geliefert oder hat das FHEM gelesen? Ist der Thermostat so modifiziert worden, dass er vom Fensterkontakt geweckt werden kann, weiß der Fensterkontakt, dass er den Thermostaten wecken muss? Da war doch irgendsowas ... http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat, Stichwort Burst ...

[martinp876]

Möglich, dass etwas nicht funktioniert - dennoch ist das in diesem einfachen Fall gar nicht so einfach.
Grundsätzlich ist es ein Versuch immer etwas im Status stehen zu  haben, auch bei Kanälen, die keinen operationalen Status liefern können.
Zum einen haben wir den SC und dann den WINREC. Die sind erst einmal unabhängig.
Mehr noch - der allgemeine Fall ist, dass es peerings mit Sensoren gibt, die keinen Status liefern (nicht beim Winrec, aber ClimaTeam z.B.). Da gibt es als Status nur peered/unpeered.

Zurück zum WinRec:
Wenn das Peering eingetragen wird - in FHEM! - wird der Status geprüft. Das passiert auch bei neustarts, es passiert, wenn das Attribut in der peerlist gesetzt wird. Beim Neustart wird es dann durch das lesen der alten Readings wieder überschrieben - vom letzten (zeitpunkt etwas undefiniert..) bekannten Zustand. Das ist FHEM-Kernal.

Wenn ein WinRec nun nicht gepeert ist ist der Zustand unpeered - es gibt keinen SC.
Wenn gepeert ist ist der Zustand NICHT der des SC - sondern der des WINREC. Nur wenn ein trigger eines gepeerten SC an den Winrec gesehen wird ändert sich der Zustand des WinRec.
Das Kopieren des Zustands eines SC  in den des WinRec ist sinnlos. Es könnte sei, dass - warum auch immer - kein trigger kommt (SC ist nicht gepeert, WinRec schon...). Ausserdem kann ein WinRec mit mehreren SC gepeert sein. Kopieren ist da sowieso kein Thema.

Es könnte also ein Thema sein, dass das handling mehrere SC an einem WinRec nicht korrekt dargestellt wird -kann ich noch einmal nachsehen.

Ist der Thermostat so modifiziert worden, dass er vom Fensterkontakt geweckt werden kann

conditional Burst muss an sein. Sollte HMInfo prüfen - wenn nicht werden ich es nachtragen.

weiß der Fensterkontakt, dass er den Thermostaten wecken muss?

der muss gepeert sein - im peering (den Registern des SC für denWinRec) muss eingetragen sein, dass der winrec burst braucht.
Wird alles beim Peering autmatisch gesetzt. (peerChan)