Probleme mit HM-SEC-SC & HM-CC-TC

[USTA70]

Hallo, ich benutzte einen Fensterkontakt HM-SEC-SC in Verbindung mit einem Thermostat HM-CC-TC. Hier beobachte ich häufig das Problem, dass der Status "Open/Closed" nicht im TC aktualisiert wird und somit die Heizung z.B. abgesenkt bleibt, obwohl das Fenster bereits geschlossen wurde.

Weiss jemand woran das liegen könnte? Kann man hier ggf. einen watchdog definieren? Falls ja, wie müsste der aussehen?

1000 Dank im Voraus - Grüsse Uli

[martinp876]

Hallo Uli,

keine Ahnung, woran es liegen kann. Es tritt nur beim schliessen auf - nie beim Offnen?
FHEM kann den schalter nicht "umlegen" - du könntest aber eine neue temperatur setzen oder den mode neu setzen. das sollte funktionieren, kannst du sicher selbst testen.
Wenn du nun ein notify einbaust wenn der Fensterkontakt "gemeldet" wird - ein "at" bauen, das nach x min den mode umschaltet.

Gruss Martin

[USTA70]

Hallo Martin,

nein, ich habe das Problem sowohl beim Öffnen als auch beim Schliessen. Der Fensterkontakt selbst arbeitet korrekt. Das schliesse ich jedenfalls daraus, dass in den Readings der Eintrag "state" immer korrekt gesetzt. Wenn ich jedoch im logfile des SC nachschaue stelle ich fest, dass der Eintrag "...contact: open (to Bad_Thermostat)" des Tripels auch oft nicht enthalten ist, sehr wohl aber die beiden anderen Einträge:

2013-10-27_11:32:02 Badfenster_rechts open
2013-10-27_11:32:02 Badfenster_rechts contact: open (to HMLAN1)

...klar, man könnte auch mit einem notify eine andere Temperatur setzten (wie von Dir vorgeschlagen), aber mich wurmt trotz allem dem, dass ich die Standard-Funktion des TC nicht nutzen kann (. Vielleicht hast Du ja noch eine Idee, woran es liegen könnte?

Grüsse Uli

[martinp876]

Hallo Uli,

dann hätte ich doch gerne die rohmessages gesehen.
wenn der SC mit dem TC gepeert ist sollte der SC eben auch an den TC den trigger schicken.
HMLAN bekommt "nur" eine statusmessage, nicht den eigentlichen Trigger.

kannst du die messages aufzeichnen mit
attr HMLAN1 loglevel 1

Gruss Martin

[USTA70]

Hallo Martin,

ich hoffe, dass mir das Loggen geglückt ist (siehe Anhang). Der erste Block gehört zum Öffnen. In diesem Fall wurde "Fenster geöffnet" vom TC nicht erkannt. Der zweit Block beschreibt das Schliessen der Tür.
1F36A4 ist SC
1BFA8D ist TC

(1D48D0 ist LED16)
(1B603C ist Jalousie Actor)

Kannst Du damit etwas anfangen?

Gruss Uli

[martinp876]

Hallo Uli,

dein SC ist nicht mit deinem TC gepeert. Er schickt diesem nie trigger-evets.
kannst du dies einmal prüfen? Ein getConfig.
wahrscheinlich ist der TC auch nicht mit dem SC gepeert - also auch prüfen

Gruss Martin

[USTA70]

...ja, mit dem peer-en stehe ich immer ein wenig auf dem Kriegsfuss und bin unsicher wer mit wem? Im Anhang habe ich einen Screenshot vom TC, TC_WindowRec und dem SC angehängt. Wie von Dir vermutet ist hier nicht alle gepeert. Kannst Du mir helfen, mit welchen Kommandos ich wenn mit wem peeren muss.

Im Voraus eine riesiges Dankschön!

Gruss Uli

[martinp876]

Code Auswählen Erweitern

set <sc> peerChan 0 <tc_WindowRec> single

für alle, die du gepeert haben willst.

beim SC musst du anschliessend anlernen drücken - sonst kann man dem nichts senden.

danach prüfen ob alles gut gegangen ist. Ich würde immer ein getConfig machen (oder automatisch mit autoReadReg)

Auch gut (meiner Ansicht nach) - kontrolle mit HMinfo

Code Auswählen Erweitern

define hm HMinfo
set hm protoEvents short

Gruss Martin

[volschin]

Hallo Martin,
was mir in dem Zusammenhang bei protoEvents aufgefallen ist, dass dort auch die Geräte angezeigt werden, die ein ignore-Flag gesetzt haben, da es die meines Nachbarn sind. ansonsten sind die überall raus aus der Oberfläche.
Ist das so gewollt?

Gruß
Veit

[martinp876]

Hallo Veit,

habe ich nicht explizit darüber nachgedacht - aktuell sind alle device drin, die in CUL_HM definiert sind - und die ignore sind es auch.
es immer herausfallen zu lassen halte ich nicht für optimal...
sinnvoll wäre es über filter zu steuern. default wäre, dass ignore unterdrückt wird, man es aber einschalten kann.

filtern lässt sich übrigens schon jetzt - fast alles in HMInfo. Auf channel, device, virtual und auf namen. (ignore noch nicht...)

Gruss Martin

[USTA70]

Hallo Martin,

ich habe nun alle TC mit den SC ge-peer-t und beide haben jetzt wechselseitig die entsprechende peerID. Hurra!

Da das eingangs beschriebene Problem (wie gesagt) nicht permanent auftritt, werde ich das weitere Verhalten nun beobachten - bisher sieht es stabil aus.

Eine Frage habe ich jedoch noch: Bisher hatte ich das TC und das SC via HM-Konfiguration-Software miteinander verknüpft. Ist das jetzt noch erforderlich, oder ist sogar störend für FHEM?

Dank+Gruss
       Uli

[martinp876]

Hallo Uli,

FHEM macht das gleiche - ok ich muss einschränken dass ich definitiv nicht alles ausprobiere wie es die HM SW macht und dann nachbaue.
Das peering macht FHEM identisch.
Es gibt manchmal zusatz-aktionen wir burst-einstellungen - ob hier wirklich alles nachgebaut wird....

Generell gibt es mitlerweile aber schon einige User die peeren komplett ohne HM-SW machen. Ich habe es noch nie mit der PC-SW gemacht...

FHEM macht verknüpfen, entknüpfen, auslesen, überwachen, auswerten(HMInfo) - ich glauben mehr als du im HM-konfigurator findest

Gruss Martin

[Rohan]

Hallo Uli,

... Eine Frage habe ich jedoch noch: Bisher hatte ich das TC und das SC via HM-Konfiguration-Software miteinander verknüpft. Ist das jetzt noch erforderlich, ...

Nein, wenn in den Readings die entsprechenden Pairings und Peerings stehen (ohne "set_...")

... oder ist sogar störend für FHEM?

Eher weniger, dürfte für dich aber nun geringeren Aufwand bedeuten, oder?

Gruß
Thomas

[USTA70]

Vielen Dank für Eure Antworten!

Heute habe ich das Verhalten des nun gepeerten SC's und TC's geprüft. Es wird zwar nun verlässlich der state-Wert des SC im TC_WindowRec angezeigt, jedoch zeigt sich nach wie vor das Problem, dass lt. dem TC Display der Status im TC nicht immer korrespondiert.

@Martin, könntest Du bitte noch einmal einen Blick in die Log-Daten werfen? Falls ja, welcher verbose-Level wäre für einen Check am geeignetsten?

Dank + Gruss
   Uli

[martinp876]

Hallo Uli,

was stimmt nicht zwischen TC Display und Status?

bitte immer rohmessages
attr global verbose 1
attr global mseclog 1
attr <hmlan> loglevel 1

Gruss Martin