Nach Einbinden eines HM-TC-IT-WM-W-EU geht "Heizung zu" bei "winOpen" nicht mehr

[hauwech]

Hallo zusammen,

ich hatte bisher nur einen Fensterkontakt (HM-SEC-SC-2) und einen Heizkörperthermostat (HM-CC-RT-DN) im Einsatz. Wichtig ist mir neben der Heizungsregelung die "Fenster-Auf -> Heizung zu" Funktion.
Gestern habe ich einen Wandthermostat (HM-TC-IT-WM-W-EU) eingebunden, weil der Heizkörperthermostat schlecht zugänglich ist (WAF!).
Ich habe den Wandthermostat mit meinem HM-LAN-CFG gepairt:

Code Auswählen Erweitern

set HMLAN1 hmPairForSec 30 -> am TC-IT "boost" gedrückt -> hat geklappt.
Dann die channels gepeert:

Code Auswählen Erweitern

set <HM-TC-IT-WM-W-EU-Gerät>_Weather peerChan 0 <HM-CC-RT-DN-Gerät>_Weather single set

Code Auswählen Erweitern

set <HM-TC-IT-WM-W-EU-Gerät>_Climate peerChan 0 <HM-CC-RT-DN-Gerät>_Climate single set
Dann habe ich den Fensterkontakt mit dem HM-TC-IT-WM-W-EU_WindowRec gepeert.

Ab da geht am Fensterkontakt bei open oder close die LED auf gelb -> rot. Die Stati werden gemeldet, aber "Heizung zu" geht nicht mehr.
Ich habe für den Fensterkontakt zwei notify, die einen Log-Eintrag schreiben. Seltsamerweise werden für "open" vier Events gemeldet, für "close" nur drei:

Code Auswählen Erweitern

014.03.29 08:37:16 3: AnbauBadFenster: Badfenster geoeffnet - contact: open (to AnbauBadHZ)                         <- RT-DN
2014.03.29 08:37:17 3: AnbauBadFenster: Badfenster geoeffnet - contact: open (to AnbauBadHeizung_WT)                   <- TC-IT
2014.03.29 08:37:17 3: AnbauBadFenster: Badfenster geoeffnet - contact: open (to HMLAN1)
2014.03.29 08:37:17 3: AnbauBadFenster: Badfenster geoeffnet - contact: open (to AnbauBadHZ)
2014.03.29 08:37:27 3: AnbauBadFenster: Badfenster wieder geschlossen - contact: closed (to AnbauBadHeizung_WT)
2014.03.29 08:37:27 3: AnbauBadFenster: Badfenster wieder geschlossen - contact: closed (to HMLAN1)
2014.03.29 08:37:28 3: AnbauBadFenster: Badfenster wieder geschlossen - contact: closed (to AnbauBadHZ)

Als ich gesehen habe, daß der HM-TC-IT-WM-W-EU_Climate channel kein "R-winOpnTemp" hat, habe ich nochmal

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single
gemacht.
Bei den peerings scheint was durcheinander geraten zu sein. Ein "set HM peerXref" liefert:

Code Auswählen Erweitern

peerXref done:
x-ref list
    AnbauBadFenster => AnbauBadHZ_WindowRec, AnbauBadHeizung_WT_WindowRec
    AnbauBadHZ_Climate => AnbauBadHeizung_WT_Climate
    AnbauBadHZ_Weather => AnbauBadHeizung_WT_Weather
    AnbauBadHZ_WindowRec => AnbauBadFenster_chn:01
    AnbauBadHeizung_WT_Climate => AnbauBadHZ_Climate
    AnbauBadHeizung_WT_Weather => AnbauBadHZ_Weather
    AnbauBadHeizung_WT_WindowRec => AnbauBadFenster_chn:01

Möglicherweise habe ich in der command-history Kommandos versehentlich mehrmals abgesetzt.

Wie kann ich das wieder geradebiegen?
Und wie kriege ich den HM-CC-RT-DN wieder dazu, daß das Ventil bei "Fenster auf" wieder geschlossen wird?

Gruß Roland

Meist kommen die Reaktionen hier sehr schnell. Falls ich nicht gleich reagiere: Ich bin nachher unterwegs und kann erst heute abend wieder antworten.

[martinp876]

wenn der RT von TC gesteuert werden soll, sollte auch der Fensterkontakt an diesen gehen.
Das peering AnbauBadFenster => AnbauBadHZ_WindowRec kannst du ggf abstellen.

Interessant wäre
- ein log der rohmessags vom Fenster-öffnen
Trotz allem sollte der FK nicht rot werden - die Frage ist, welches Device nicht antwortet.

Gruss Martin

[hauwech]

Soooo,

ich habe jetzt mal

Code Auswählen Erweitern

attr global verbose 1
attr global mseclog 1
attr <hmlan> logIDs all,sys

gesetzt, fhem neu gestartet, das Fenster auf und zu gemacht und den letzten Teil vom log kopiert.

Code Auswählen Erweitern

2014.03.29 20:25:50.716 1: Including ./log/fhem.save
2014.03.29 20:25:50.737 1: usb create starting
2014.03.29 20:25:50.880 1: usb create end
2014.03.29 20:25:50.885 0: Server started with 54 defined entities (version $Id: fhem.pl 5238 2014-03-16 16:23:31Z rudolfkoenig $, os linux, user fhem, pid 61410)
2014.03.29 20:25:50.886 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:010ADEED IDcnt:0001
2014.03.29 20:25:50.886 0: HMLAN_Parse: HMLAN1 R:R0F4E1D88 stat:0002 t:00000000 d:FF r:7FFF     m:99 8112 999999 000001
2014.03.29 20:25:50.886 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.29 20:26:12.455 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B3C85 d:FF r:FFAB     m:1A A441 24D474 22BBAA 0109C8
2014.03.29 20:26:13.067 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B3EEA d:FF r:FFAD     m:1B B041 24D474 2702B3 0109C8
2014.03.29 20:26:13.489 0: HMLAN_Send:  HMLAN1 I:K
2014.03.29 20:26:13.492 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:010B409E IDcnt:0001
2014.03.29 20:26:13.794 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B41C1 d:FF r:FFAD     m:1C A241 24D474 272DDE 0109C8
2014.03.29 20:26:13.795 0: HMLAN_Send:  HMLAN1 I:+24D474,00,00,
2014.03.29 20:26:13.898 0: HMLAN_Send:  HMLAN1 S:+24D474,00,01,1E
2014.03.29 20:26:13.898 0: HMLAN_Send:  HMLAN1 S:S0F4E8068 stat:  00 t:00000000 d:01 r:0F4E8068 m:1C 8002 272DDE 24D474 0101C800
2014.03.29 20:26:13.930 0: HMLAN_Parse: HMLAN1 R:R0F4E8068 stat:0002 t:00000000 d:FF r:7FFF     m:1C 8002 272DDE 24D474 0101C800
2014.03.29 20:26:14.045 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B42BE d:FF r:FFB0     m:1A A041 24D474 22BBAA 0109C8
2014.03.29 20:26:14.662 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B4524 d:FF r:FFB1     m:1B B041 24D474 2702B3 0109C8
2014.03.29 20:26:14.785 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010B45A2 d:FF r:FFBD     m:1B 8002 2702B3 24D474 00
2014.03.29 20:26:15.638 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B48F7 d:FF r:FFB2     m:1A A041 24D474 22BBAA 0109C8
2014.03.29 20:26:16.252 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B4B5D d:FF r:FFB1     m:1B B041 24D474 2702B3 0109C8
2014.03.29 20:26:16.379 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010B4BDC d:FF r:FFBE     m:1B 8002 2702B3 24D474 00
2014.03.29 20:26:17.739 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B512C d:FF r:FFB1     m:1A A041 24D474 22BBAA 0109C8
2014.03.29 20:26:18.352 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B5391 d:FF r:FFB1     m:1B B041 24D474 2702B3 0109C8
2014.03.29 20:26:18.479 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010B5410 d:FF r:FFC0     m:1B 8002 2702B3 24D474 00
2014.03.29 20:26:20.852 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B5D55 d:FF r:FFB2     m:1A A041 24D474 22BBAA 0109C8
2014.03.29 20:26:21.465 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B5FBB d:FF r:FFB1     m:1B B041 24D474 2702B3 0109C8
2014.03.29 20:26:21.592 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010B603A d:FF r:FFBE     m:1B 8002 2702B3 24D474 00
2014.03.29 20:26:25.991 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B7169 d:FF r:FFB1     m:1A A041 24D474 22BBAA 0109C8
2014.03.29 20:26:26.603 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B73CE d:FF r:FFB0     m:1B B041 24D474 2702B3 0109C8
2014.03.29 20:26:26.730 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010B744D d:FF r:FFC1     m:1B 8002 2702B3 24D474 00
2014.03.29 20:26:28.453 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B7B08 d:FF r:FFA3     m:1D A441 24D474 22BBAA 010A00
2014.03.29 20:26:29.193 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010B7DEC d:FF r:FFBD     m:1E 8002 2702B3 24D474 00
2014.03.29 20:26:29.323 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B7E6E d:FF r:FF99     m:1F A241 24D474 272DDE 010A00
2014.03.29 20:26:29.430 0: HMLAN_Send:  HMLAN1 S:S0F4EBD11 stat:  00 t:00000000 d:01 r:0F4EBD11 m:1F 8002 272DDE 24D474 0101C800
2014.03.29 20:26:29.598 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B7F6B d:FF r:FFA0     m:1D A041 24D474 22BBAA 010A00
2014.03.29 20:26:29.602 0: HMLAN_Parse: HMLAN1 R:R0F4EBD11 stat:0002 t:00000000 d:FF r:7FFF     m:1F 8002 272DDE 24D474 0101C800
2014.03.29 20:26:30.082 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B8165 d:FF r:FFA3     m:1D A041 24D474 22BBAA 010A00
2014.03.29 20:26:31.095 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B855B d:FF r:FFA8     m:1D A041 24D474 22BBAA 010A00
2014.03.29 20:26:33.122 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B8D46 d:FF r:FFA6     m:1D A041 24D474 22BBAA 010A00
2014.03.29 20:26:37.175 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:010B9D1C d:FF r:FFA4     m:1D A041 24D474 22BBAA 010A00
2014.03.29 20:26:37.962 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010BA02F d:FF r:FFBD     m:54 865A 2702B3 000000 A8BC42
2014.03.29 20:26:38.492 0: HMLAN_Send:  HMLAN1 I:K
2014.03.29 20:26:38.495 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:010BA24E IDcnt:0002
2014.03.29 20:26:47.964 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010BC742 d:FF r:FFBE     m:71 8410 2702B3 000000 0BA8BC1113
2014.03.29 20:26:57.962 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:010BEE52 d:FF r:FFBD     m:54 8470 2702B3 000000 00BC42
2014.03.29 20:27:03.503 0: HMLAN_Send:  HMLAN1 I:K
2014.03.29 20:27:03.506 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:010C0405 IDcnt:0002

Kann ich noch was hilfreiches liefern? Und wenn ja: Wie?

Der Wandthermostat zeigt übrigens im Display ein "Offenes Fenster" Symbol an, wenn der FK auf "open" steht.
In der "Anleitung" steht zur "Fenster offen" Funktion praktisch gar nix außer einem Satz unter Kapitel 19 "Anlernbare Komponenten", daß die "Fenster-Auf-Funktion" des Heizkörperthermostaten automatisch deaktiviert wird. Das habe ich eh' schon deaktiviert, das soll ja der FK machen.

Gruß Roland

[hauwech]

Hallo Martin,

ich habe

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single unset actor
gemacht. Am FK habe ich auf Anlernen gedrückt. Die Ausgabe von

Code Auswählen Erweitern

set HM peerXref ändert sich aber nicht:

Code Auswählen Erweitern

peerXref done:
x-ref list
    AnbauBadFenster => AnbauBadHZ_WindowRec, AnbauBadHeizung_WT_WindowRec
    AnbauBadHZ_Climate => AnbauBadHeizung_WT_Climate
    AnbauBadHZ_Weather => AnbauBadHeizung_WT_Weather
    AnbauBadHZ_WindowRec => AnbauBadFenster_chn:01
    AnbauBadHeizung_WT_Climate => AnbauBadHZ_Climate
    AnbauBadHeizung_WT_Weather => AnbauBadHZ_Weather
    AnbauBadHeizung_WT_WindowRec => AnbauBadFenster_chn:01
.
.
.
... ein paar Minuten später ...
.
.
.
Ich habe eben nochmal ein

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single unset (ohne "actor") hinterhergeschickt.
Ich habe den FK wieder angebracht -> er geht wieder auf grün!

Und das Wichtigste: Er setzt die desired-temp am Heizkörperthermostat bei "WinOpn" auf 12°. Die Antwort auf peerXref bleibt aber. Ich hätte erwartet, daß sich da was ändert.

Gruß Roland

[martinp876]

Hallo Roland,

so aus der Ferne hätte ich noch eine ganze Reihe Fragen

1) peerXref
zeigt an, wer mit wem gepeert ist. Wie bei allen Auswertungen der Device-Konfig basiert es auf den in FHEM vorliegenden Daten - es kann in einigen Fällen garnicht aus dem Device problemlos gelesen werden.
1a) möglich ist, dass die daten nicht/noch nicht  frisch gelesen wurden. Möglich, dass noch eine Abfrage in der queue hängt oder die Automatic abgeschaltet wurde. Ein getConfig sollte es klären
1b) mit checkPeer kann man prüfen, ob die peers symetrisch eingetragen sind. Bei den RT/TC sollten die Daten - zumindest nach einiger Zeit - aktuell vorliegen (automatisch). Natürlich nur, wenn du es nicht abschaltest. Sollte also der Peereintrag im RT gelöscht sein, die Daten aus dem FK aber noch falsch sein müsste hier ein Fehler gemeldet werden.
1c) Die Daten könnten nicht geschrieben worden sein.

Wenn man sich unklar ist über den Zustand kann man mit HMInfo einmal "aufräumen".  Da man alles verbiegen kann setzt es natürlich voraus, dass man dies nicht hat.
I) ALLE Devices habe das Attribut autoReadReg auf "5" - channels brauchen es nicht
=> get hm param -d autoReadReg
II) Lösche alle messageevents - dann hat man eine bessere Übersicht
=> set hm clear msgEvents
III) starte einmal ein neues Lesen für alle
=> set hm autoReadReg
IV) warte bis es abgeschlossen ist, kontrolliere auf Fehler und arbeite ggf  nach. Zumindest die Komponenten, die du untersuchen willst
=> get hm protoEvents short
V) prüfe, ob die Daten konsistent sind (peerCheck ist Teil davon)
=> set hm configCheck

Nun zu den Logs:
Der FK 24D474 ist gepeert (in den Logs) mit 3 IDs
22BBAA
2702B3
272DDE

22BBAA antwortet NIE! Wenn das ein RT ist, ist dies klar - da wird kein Burst gesendet
2702B3  antwortet, aber der FK versteht es nicht
272DDE ist der einzige, der Fehlerfrei funktioniert

wer ist hier wer?
Gruss Martin

[hauwech]

Hallo Martin,

ich fange mal hinten an:

272DDE: HM-LAN-CFG alias HMLAN1
2702B3: HM-TC-IT-WM-W-EU alias AnbauBadHeizung_WT
22BBAA: HM-CC-RT-DN alias AnbauBadHZ
24D474: HM-SEC-SC-2 alias AnbauBadFenster

Ich habe Deine command list abgearbeitet. Nachfolgend das Kommando und die erbeutete Ausgabe:

Code Auswählen Erweitern

---------------------------------------------
get hm param -d autoReadReg

param done:
param list
    entity              : autoReadReg          |
    AnbauBadFenster      : 4_reqStatus   
    AnbauBadHZ          : 4_reqStatus   
    AnbauBadHeizung_WT  : 4_reqStatus
----------------------------------------------
set hm clear msgEvents

unknown parameter - use Protocol, readings, msgStat, register or rssi
----------------------------------------------
get hm clear msgEvents

Unknown argument clear, choose one of clear configCheck help models msgStat param peerCheck peerXref protoEvents regCheck register rssi templateChk templateList
----------------------------------------------
set hm autoReadReg

autoReadReg done:
triggered:
    AnbauBadFenster
    AnbauBadHZ
    AnbauBadHeizung_WT
----------------------------------------------
get hm protoEvents short

protoEvents done:
    name                :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    AnbauBadFenster     :  -             | -        | -        | -        # -        | -        | -        | -       
    AnbauBadHZ          : done           | -        |1:        | -        # -        | -        | -        | -       
    AnbauBadHeizung_WT  : done           | -        |58:       | -        # -        | -        | -        | -       
================================================================================================================
    sum                 0                |0         |59        |0         #0         |0         |0         |0         

    CUL_HM queue length:0

    requests pending
    ----------------
    autoReadReg          :
        recent           :AnbauBadHeizung_WT
    status request       :
    autoReadReg wakeup   :AnbauBadFenster, AnbauBadHZ
    status request wakeup:
    autoReadTest         :AnbauBadHeizung_WT

    IODevs:HMLAN1:opened pending=0 condition:ok
            msgLoadEst: 1hour:3% 10min steps: 3/0/0/0/0/0
----------------------------------------------
set hm configCheck

configCheck done:

peerNeedsBurst cannot be determined
    AnbauBadFenster
----------------------------------------------

Sorry, wenn ich noch nicht alles raffe - ich habe den Kram jetzt seit vier Wochen in Betrieb und stehe bei vielen Zusammhängen noch vor'm Berg.... daher: Danke für die Geduld

Gruß Roland

[martinp876]

1) der FK hat zum RT kein burst gesendet. Das Register peerNeedsBurst war 'off'

Code Auswählen Erweitern

set AnbauBadFenster regSet peerNeedsBurst on peerNeedsBurst
wenn der RT noch gepeert ist.
im RT sollte burst eingeschaltet sein (ist es wahrscheinlich)

2) autoReadReg steht auf 4 (default) Ich setze es gerne auf 5 - da versucht FHEM noch etwas mehr, einen Konsistenten Datensatz zu halten... ist aber kein Problem hier

3) mein fehler: set hm clear  Protocol

4) autoReadReg wakeup   :AnbauBadFenster, AnbauBadHZ
die beiden verbleibenden sind noch nicht gelesen - das wird passieren, wenn sie aufwachen. Dauert etwa 3 min.

5) keine Probleme bein übertragen aufgetreten.
So lange bei get hm protoEvents short keine Zähler hinter dem "#" stehen ist alles ok. Noch prüfen, was in den queues wartet und was noch pending ist. Steht alles in diesem Screen

6) peerNeedsBurst cannot be determined
    AnbauBadFenster
klar. AnbauBadFenster ist noch nicht gelesen, steht noch in der Queue, siehe oben. Es wäre geprüft worden, ob peerNeedsBurst gesetzt ist (siehe ganz oben) - aber da die Register nicht gelesen sind kann es nicht bestätigt werden.

Eine Frage ist, warum der SC mit der zentrale gepeert ist (gepairt ist klar). Das 2. Problem, warum der SC die Antwort des TC nicht versteht.
Evtl loggst du noch einmal, wenn das peering SC/RT gelöscht ist (ich nehme an, das ist geschehen?)

Gruss Martin

[hauwech]

Hallo Martin,

zu 1: den peer FK<->RT habe ich gelöscht

Code Auswählen Erweitern

set AnbauBadFenster peerChan 0 AnbauBadHZ_WindowRec single unset
Wahrscheinlich kommt deshalb bei

Code Auswählen Erweitern

set AnbauBadFenster regSet peerNeedsBurst on peerNeedsBurst als Antwort "Peer not valid".
Im RT ist burst eingeschaltet, der FK soll ja sofort das Ventil zudrehen, wenn jemand das Fenster öffnet.

Wo sieht man, daß der SC mit dem HMLAN gepeert ist? In der peerList für den Fensterkontakt steht:

Code Auswählen Erweitern

peerList        AnbauBadHZ_WindowRec,AnbauBadHZ_WT_WindowRec,. Das ist der RT-DN und der HM-TC-IT-WM-W-EU. (den habe ich indessen umbenannt [...Heizung -> ...HZ], weil ich mich vertan hatte).

Ich habe nochmal Fenster auf-Fenster zu geloggt:

Code Auswählen Erweitern

2014.03.30 21:28:56.774 0: Server started with 56 defined entities (version $Id: fhem.pl 5340 2014-03-27 16:19:53Z rudolfkoenig $, os linux, user fhem, pid 64067)
2014.03.30 21:28:56.775 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:06344C2F IDcnt:0003
2014.03.30 21:28:56.775 0: HMLAN_Parse: HMLAN1 R:R14774FA3 stat:0002 t:00000000 d:FF r:7FFF     m:99 8112 999999 000001
2014.03.30 21:28:56.776 1: HMLAN_Parse: HMLAN1 new condition ok
2014.03.30 21:29:19.381 0: HMLAN_Send:  HMLAN1 I:K
2014.03.30 21:29:19.385 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:0634ADEB IDcnt:0003
2014.03.30 21:29:44.408 0: HMLAN_Send:  HMLAN1 I:K
2014.03.30 21:29:44.412 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:06350FB2 IDcnt:0003
2014.03.30 21:30:09.427 0: HMLAN_Send:  HMLAN1 I:K
2014.03.30 21:30:09.431 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:06357171 IDcnt:0003
2014.03.30 21:30:22.793 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:0635A59C d:FF r:FFB4     m:43 B441 24D474 2702B3 011BC8
2014.03.30 21:30:22.922 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:0635A61B d:FF r:FFBC     m:43 8002 2702B3 24D474 00
2014.03.30 21:30:23.049 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:0635A69C d:FF r:FFB5     m:44 A241 24D474 272DDE 011BC8
2014.03.30 21:30:23.053 0: HMLAN_Send:  HMLAN1 I:+24D474,00,00,
2014.03.30 21:30:23.146 0: HMLAN_Send:  HMLAN1 S:+24D474,00,01,1E
2014.03.30 21:30:23.147 0: HMLAN_Send:  HMLAN1 S:S1478AA12 stat:  00 t:00000000 d:01 r:1478AA12 m:44 8002 272DDE 24D474 0101C800
2014.03.30 21:30:23.437 0: HMLAN_Parse: HMLAN1 R:R1478AA12 stat:0002 t:00000000 d:FF r:7FFF     m:44 8002 272DDE 24D474 0101C800
2014.03.30 21:30:24.457 0: HMLAN_Parse: HMLAN1 R:E22BBAA   stat:0000 t:0635AC15 d:FF r:FFBF     m:34 8610 22BBAA 000000 0AA8C00F6424
2014.03.30 21:30:30.103 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:0635C22B d:FF r:FFBB     m:B4 8410 2702B3 000000 0B60C13113
2014.03.30 21:30:31.293 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:0635C6D2 d:FF r:FFAF     m:45 B441 24D474 2702B3 011C00
2014.03.30 21:30:31.420 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:0635C751 d:FF r:FFB8     m:45 8002 2702B3 24D474 00
2014.03.30 21:30:31.552 0: HMLAN_Parse: HMLAN1 R:E24D474   stat:0000 t:0635C7D4 d:FF r:FFAF     m:46 A241 24D474 272DDE 011C00
2014.03.30 21:30:31.650 0: HMLAN_Send:  HMLAN1 S:S1478CB46 stat:  00 t:00000000 d:01 r:1478CB46 m:46 8002 272DDE 24D474 0101C800
2014.03.30 21:30:31.940 0: HMLAN_Parse: HMLAN1 R:R1478CB46 stat:0002 t:00000000 d:FF r:7FFF     m:46 8002 272DDE 24D474 0101C800
2014.03.30 21:30:34.434 0: HMLAN_Send:  HMLAN1 I:K
2014.03.30 21:30:34.438 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:0635D325 IDcnt:0003
2014.03.30 21:30:39.106 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:0635E555 d:FF r:FFBA     m:B5 8410 2702B3 000000 0BA8C11113
2014.03.30 21:30:54.350 0: HMLAN_Parse: HMLAN1 R:E2702B3   stat:0000 t:063620E7 d:FF r:FFB7     m:8E 865A 2702B3 000000 A8C13D
2014.03.30 21:30:59.441 0: HMLAN_Send:  HMLAN1 I:K
2014.03.30 21:30:59.445 0: HMLAN_Parse: HMLAN1 V:03C4 sNo:LEQ0050127 d:272DDE O:272DDE t:063634D9 IDcnt:0003

Danke und Gruß
Roland

[martinp876]

Hallo Roland,

das Kommando wäre
set AnbauBadFenster regSet peerNeedsBurst on <peer>

das peerNeedsBurst  war ein Fehler von mir. ggf wäre ein
set AnbauBadFenster regSet peerNeedsBurst on AnbauBadHZ_WT_WindowRec
korrekt.

Im RT ist burst eingeschaltet, der FK soll ja sofort das Ventil zudrehen, wenn jemand das Fenster öffnet.

das ist so korrekt - hört sich zwischen den Zeilen aber nach einem falschen Verständniss an.
ein FK sendet, wenn das Fenster bewegt wird.
Der RT schläft zu diesem Zeitpunkt
Wenn der FK einen burst sendet und der RT entsprechend eingestellt ist wird der RT aufgeweckt und reagiert
Im anderen Fall wird der FK 3-mal senden, der RT wacht nicht auf - und fertig. Der RT wird irgendwann aufwachen, aber der fk sendet dann nicht mehr
Der RT wird so NIE erfahren dass das Fenster offen ist.
=> es handelt sich also nicht um eine Verzögerung

Das darfst du nicht mit der FHEM -SW verwechseln. Die probiert mehr, evtl erst burst und wartet andernfalls auf ein Aufwachen. Je nach Einstellungen und Device. der FK wartet nicht auf aufwachen, für den ist es nach dem Versuch erledigt.

Wo sieht man, daß der SC mit dem HMLAN gepeert ist? In der peerList für den Fensterkontakt steht:

hm - konnte ich mich auch irren. Bisher kenne ich, dass ein Sensor einen Status an die Zentrale sendet - könnte sein, dass ein FK einen trigger an die Zentrale adressiert. Dann wäre der Auslöser des Triggers nicht das peeren sondern das pairen - bei diesem Device.

Die Trigger sehen jetzt prima aus. War interessant, dass ein nicht reagierender RT auch das ACK eines weiteren peers gestört hat.

Gruss Martin

[hauwech]

Hallo Martin,

das

Code Auswählen Erweitern

set AnbauBadFenster regSet peerNeedsBurst on AnbauBadHZ_WT_WindowRec bringt auch einen "Peer not valid". Aber ich will da jetzt nicht so drauf rumreiten. Ich kann nicht so recht einschätzen, wie wichtig das ist. Da aber grundsätzlich "Heizung zu" bei "Fenster auf" wieder funktioniert, denke ich, das gehört in die Kategorie "Feintuning".
Sehr aufschlussreich für mich ist Deine Detailschilderung zur Kommunikation zwischen den Devices. Wenn ich das jetzt richtig verstehe, kommt man an "burst on" gar nicht vorbei, wenn man WinOpn vernünftig nutzen möchte. Auch wenn dadurch das Funkkontingent belastet wird und bei einem Event alle Devices aus dem Schlaf gerissen werden. Bei meinem Pipikram ist das nicht das große Problem - außer Batterielebensdauer -, aber so nach und nach wird's mehr....

Gruß Roland

[martinp876]

Hallo Roland,

bringt auch einen "Peer not valid". Aber ich will da jetzt nicht so drauf rumreiten.

schon klar.
Grundsätzlich: das "AnbauBadHZ_WT_WindowRec" am Ende ist der Peer. Viele Devices und channel habe gewisse Register mehrfach - einmal für jeden Peer. Wenn du expert auf 1 setzt kannst du alle Register sehen. Da du mittlerweile den Peer aber "gelöscht" hast (mit unset) ist der Peer nicht mehr vorhanden - für diesen Channel des FK.
Das ist wichtig zu verstehen (auch wenn dieser Fall geklärt ist) - Das Prinzip ist überall in HM anzutreffen.

kommt man an "burst on" gar nicht vorbei, wenn man WinOpn vernünftig nutzen möchte

korrekt

Auch wenn dadurch das Funkkontingent belastet wird

nur dass des Senders. Der, welcher einen Burst auslöst wird belastet - in diesem Fall also nicht das HMLAN. Es ist eher unwahrscheinlich, dass der FK so oft aktiviert wird, dass er in Overload geht. Man kann es natürlich provozieren... aber real ist das, meine ich, nicht.

bei einem Event alle Devices aus dem Schlaf gerissen werden

alle, die auf Burst reagieren werden aufgeschreckt - korrekt.

[hauwech]

Hallo Martin,

vielen Dank für Deine Hilfe, ich hab' ne Menge gelernt.
Eine Verständnisfrage habe ich doch noch ...
Ich hatte im "Heimautomatisierung mit fhem - Für Einsteiger" (Seite 10) gelesen, daß die Anzahl der Funktelegramme durch rechtliche Bestimmungen auf 160 pro Stunde begrenzt ist. Ich habe das so verstanden, daß sich das auf die komplette Installation bezieht, egal, welche Komponente sendet. Folglich (... das hatte ich mit "Funkkontingent belasten" gemeint) ist in einer größeren Installation damit zu rechnen, daß man an diese Grenze kommt und daß "burst on" das Erreichen der Grenze beschleunigt. Ich habe allerdings noch keine Vorstellung, wieviele Devices man dazu braucht. Es gibt geschwätzige Devices wie die RT-DN und Schweiger wie die Fensterkontakte. Bei meiner derzeitigen Ausbaustufe mache ich mir noch keine Sorgen.
Aber wenn ich den Event Monitor ein paar Minuten geöffnet habe, sehe ich alle paar Minuten Statusmeldungen der Thermostate. Nach meiner laienhaften Vorstellung ist eine Statusmeldung jeweils ein Funktelegramm, weil es "über den Äther gegangen" ist. Dann würden aber drei Thermostate nur mit den Statusmeldungen bereits die Grenze sprengen. Meine Vorstellung kann also nicht stimmen. Oder ist ein "Funktelegramm" nur das, was die Zentrale sendet? Oder bezieht sich die Begrenzung etwa nur auf FS20 bzw. das 433 MHz Band im Allgemeinen?

Gruß Roland

.... sorry - das ist schon etwas off topic ...

[hauwech]

Ergänzung:

Ich habe mittlerweile herausgefunden, daß man die aktuelle Funklast unter "msgLoadEst" im HM-CFG-LAN nachschauen kann.

Gruß Roland

[martinp876]

Ich habe mittlerweile herausgefunden, daß man die aktuelle Funklast unter "msgLoadEst" im HM-CFG-LAN nachschauen kann.

gut

rechtliche Bestimmungen auf 160 pro Stunde begrenzt ist

sollten wohl 1600 sein - ist aber nur ungefähr, da die Messagelänge eingeht. Genau genommen ist die Sendezeit begrenzt.

daß sich das auf die komplette Installation bezieht, egal, welche Komponente sendet

falsch, gilt je device.

Gruss Martin

[hauwech]

... danke für die hilfreichen Infos!

Gruß Roland