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
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
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 :o(. Vielleicht hast Du ja noch eine Idee, woran es liegen könnte?
Grüsse Uli
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
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
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
...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
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
define hm HMinfo
set hm protoEvents short
Gruss Martin
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
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
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
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
Hallo Uli,
Zitat von: Uli70 am 28 Oktober 2013, 20:12:06... 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_...")
Zitat von: Uli70 am 28 Oktober 2013, 20:12:06... oder ist sogar störend für FHEM?
Eher weniger, dürfte für dich aber nun geringeren Aufwand bedeuten, oder?
Gruß
Thomas
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
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
Hallo Martin,
im Anhang nun noch einmal ein Auszug aus der log Datei.
Block 1 beschreibt das Öffnen der Tür. Im Display des TC ist das "Fenster offen" Symbol zu sehen.
Block 2 beschreibt das Schliessen der Balkontür. Der State vom TC_WindowRec geht auf "closed", im TC-Display bleibt jedoch das Symbol stehen und die Ventile bleiben zu (siehe Screenshot + Foto).
Ich hoffe, dass Du was entdeckst :o)
Grüsse Uli
Hallo Uli,
einfacher tue ich mir, wenn du die logs in ASCII anhängst.
dein Fensterkontakt (1F36A4) sendet an
1C67FA (Zentrale?)
1BFA8D (TC)
Die Zentrale sendet dann einen LED kommando (2mal???)
schon im ersten Block wird vom 1F36A4 ein close gesendet, an die Zentrale.
Der SC sendet dann an den TC, aber dieser antwortet nicht.
damit stellt sich dar:
das Öffnen wird sauber verarbeitet
beim schliesen antwortet der TC nicht, der SC wiederholt nicht.
FHEM wertet das senden des SC aus - wartet aber nicht auf ein ACK des TC
warum der TC nicht antwortet ist unklar - vielleicht kommt der trigger zu schnell (nur 6 sec)
warum der SC nicht wiederholt ist unklar
fhem könnte das Prinzip der Statusmeldungen bei diesen Triggern verfeinern... so dass ACKs berücksichtigt werden.
Das wäre dann im Prinzip so etwas wie
=> trigger gesehen: "set_closed"
=> ack gesehen "closed"
mal sehen.
Gruss Martin
Hallo Martin,
...das wäre grossartig, wenn man hier was machen könnte. Da wir insbesondere die Balkontür täglich mehrfach für unseren Kater auf- und zumachen müssen, ist es schon ziemlich mühselig immer zwischen Tür und TC zu Pendeln um zu kontrollieren (naja, das nur am Rande).
Ich habe gestern auch noch einmal Türkontakte in anderen Räumen getestet, um auszuschliessen, dass es vielleicht nur ein Raum-spezifisches Problem ist. Aber auch hier hängt es von Zeit zu Zeit beim Öffnen wie auch beim Schliessen.
Grüsse Uli
P.S.: ...versprochen, demnächst nur noch ascii. Hatte aber versucht alles übers ipad zu sammeln, da mein HMlan nach einer Zeit immer auf disconnected geht, wenn ich den PC nutze. Kann das an der installierten HM Software liegen, die irgendwie im Hintergrund mitgestartet wird!???
Hallo Uli,
bin etwas am Basteln mit der Überwachung. Es ist nicht ganz einfach (der Code schon - aber die Kriterien...). Soll ja schliesslich stabil funktionieren.
Beim PC habe ich keinen Tip.
Auf welcher Platform läuft FHEM? Auf dem IPAD? disconnected der HMLAN wenn du am PC ein Frontend betreibst - oder das ganze FHEM?
Die HM-Config-SW ist ausgeschaltet, nehme ich an.
Gruss Martin
Hallo Martin,
nein, FHEM läuft auf der Fritzbox, Frontend auf dem Ipad.
Wann genau HMlan auf disconnected springt bei PC-Betrieb habe ich noch nicht rausgefunden. In der Regel, aber erst wenn ich eine Zeit lang mit dem Frontend am PC gearbeitet habe. Die HM Config Software ist dabei nicht im Betrieb. - Das ist zwar ärgerlich, aber damit kann ich mich arrangieren :o) - Damit "musst" Dich nicht auch noch plagen!
Das die Wahl der Kriterien nicht einfach sind, kann ich nur erahnen. Man muss ja auch berücksichtigen, dass das Öffnen und Schliessen sehr kurz hintereinander erfolgen kann (Beispiel Katze).
Grüsse
Uli
Hallo Martin, ...konntest Du für mein Problem etwas in Erfahrung bringen? Grüsse Uli
Hallo Uli,
sorry, hatte ich verdrängt.
der SC muss den TC aufwecken. Also musst du das Register
und der TC muss burst-empfang einschalten
set <sc> regSet peerNeedsBurst on <tc-window>
set <tc> regSet burstRx on
Dann sollte es klappen.
Gruss Martin
Hallo Martin,
...so war es bereits in der Reg definiert. Nichtsdestotrotz, ich habe ich die Kommandos noch nochmals ausgeführt. Nach einer mehrtägigen Testphase zeigt sich das Problem jedoch unverändert.
Vielleicht hast Du noch eine Idee?
Um auf deine anfänglichen Idee zurückzukommen, die Temperatur-Absenkung über ein notify zu steuern habe ich folgende Fragen:
1. Mit welchen Kommando löse (un-peer-e) ich das TC und den SC wieder voneinander?
2. Wie sorge ich dafür, dass nach dem Setzen eines entsprechenden desiredTemp diese durch das Zeitprogramm im automode nicht wieder überschrieben wird? Gibt es da was "kurzes Elegantes" oder muss ich hier mit Dummys und if ... Then Abfragen arbeiten? Ich habe es mit umschalten auf Mode manual versucht, aber dabei geht mir das Kommando oft verloren.
Grüsse
Uli
Hi Uli,
zum Untersuchen brauche ich das aktuelle list des TC, tc_Window und des SC. Dann noch einmal ein log, wenn das Fenster öffnet.
unpeeren mit
set sc peerChan 0 tcwin single unset
das Überschreiben lässt sich nicht verhindern -so ist der TC gestrickt.
Du kannst aber auf cent-mode stellen, dann desired-temp. Hernach zurück nach auto.
Gruss Martin