HM-CC-RT-DN WindowRec mit mehreren Sensoren peeren klappt nicht

[Ralli]

Hallo,

ich habe einen neuen HM-CC-RT-DN mit FW 1.4 und einen HM-SCI-3-FM. An dem TTS hängen drei Magnetkontakte zur Verschlusserkennung von Fenstern.

Nun habe ich - wohlgemerkt erfolgreich - den WindowRec-Channel des RT mit allen drei Kanälen des TTS gepeered und auch die winOpnTemp pro Sensor gesetzt. Der RT erkennt alles wunderbar, das Peering und das Register-Setzen hat also scheinbar erfolgreich funktioniert.

Allerdings bekomme ich auch nach bereits mehrfachen Unpeeren und Neu-peeren den WindowRec-Kanal nicht mit allen Registerwerten ausgelesen. Es gibt nur die Register für einen einzigen Sensor/Kanal, nicht für alle drei.

Nun weiß ich nicht mehr weiter. Wo hängt (mein) der Fehler?

Code Auswählen Erweitern


Internals:
   DEF       
   NAME       HWR_HK_WindowRec
   NR         544
   STATE      last:HWR_Fenster_Nord :closed
   TYPE       CUL_HM
   chanNo     03
   device     HWR_HK_Device
   peerList   HWR_Fenster_Nord,
   Readings:
     2015-05-14 10:43:33   R-HWR_Fenster_Nord-shCtValLo 50
     2015-05-14 10:43:34   R-HWR_Fenster_Nord-winOpnTemp 8 C
     2015-05-14 10:43:33   R-sign          off
     2015-05-14 11:50:09   RegL_01:          08:00 00:00
     2015-05-14 11:50:16   RegL_03:HWR_Fenster_Nord   04:32 00:00
     2015-05-14 11:50:17   RegL_07:HWR_Fenster_Nord   05:10 00:00
     2015-05-14 11:50:09   peerList        HWR_Fenster_Nord,
     2015-05-14 11:50:09   state           unknown
     2015-05-14 11:10:00   trigLast        HWR_Fenster_Nord :closed
     2015-05-14 11:10:00   trig_HWR_Fenster_Nord closed
     2015-05-14 11:08:50   trig_HWR_Fenster_West_L closed
     2015-05-14 11:08:26   trig_HWR_Fenster_West_R closed
   Helper:
     peerIDsRaw ,12345603,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   model      HM-CC-RT-DN
   peerIDs    00000000,12345603,
   stateFormat last:trigLast


Edit; Version:

# $Id: 10_CUL_HM.pm 8559 2015-05-10 14:30:05Z martinp876 $

Gepeered habe ich nach dem Schema

set TTS_Kanal1 peerChan 0 HK_WindowRec single
set TTS_Kanal2 peerChan 0 HK_WindowRec single
set TTS_Kanal3 peerChan 0 HK_WindowRec single

[martinp876]

habe es nachgestellt.
der winrec Kanal akzeptiert  nur einen Channel je device als peer. Du versuchst 3 Kanäle eines Device zu peeren.

[frank]

die sind schon ganz schön trickreich beim geld verdienen. 

[Ralli]

Hallo Martin,

vielen Dank für Deinen Test. Aber ich muss Dir widersprechen.

Der RT hat tatsächlich alle drei Kanäle des TTS in seinem WinRec akzeptiert. Denn sonst würde ja der RT ja nicht die "Fenster-Auf-Anzeige" aktivieren und die Temperatur gemäß eingestelltem Wert regeln. Das tut er aber, wenn ich eines nach dem anderen Fenster (und damit einen nach dem anderen Kanal des TTS) exklusiv öffne.

Also: es funktioniert tatsächlich alles wie es soll - nur fhem kann nicht alle gepeerten Kanäle aus dem WinRec des RT auslesen.

[martinp876]

gut möglich.
fhem fragt immer identisch "welche peers sind eingetragen". Das Device meldet alle (oder eben nicht).
Du kannst jetzt noch prüfen, ob, wenn Chan 01 gepeert ist, Chan 03 aber nicht : jetzt schaltet Chan 03 -> reagiert der rt?
Das ist für mich die letzte offene Frage. Wenn ja ist das Verhalten vorhersehbar - wenn nicht ist alles in dieser Konfig Zufall.

Fakt: der winrec denkt (zu viel) mit. er geht davon aus, dass die gepeerten Devices nur einen Channel haben und somit nur einer dargestellt werden muss. Ich würde es als Bug, zumindest als "sinnlos-inteligent" bezeichnen.

FHEM fragt immer erst die peers ab, dann die Register zu den peers. Da offensichtlich nur ein Channel je device als peer gemeldet wird kommen auch nur dessen Register.

Nun kannst du weiter testen: wenn du 3 channels gepeert hast und einen löschst - gehen dann die beiden anderen noch? In der peerlist erscheint dann keiner.
wenn du die Einstellungen eines Channels änderst - werden dann alle anderen dieses Devices auch geändert?

Ich verbuche das ganze unter "vom RT WinRec wird nur ein Channel je peer unterstützt". Alles andere ist unsicher.
FHEM wird (auch weiterhin) nicht prüfen, ob du mehrere Channels eines Devices peeren willst - ein getConfig wird es klarstellen.

[Ralli]

Du kannst jetzt noch prüfen, ob, wenn Chan 01 gepeert ist, Chan 03 aber nicht : jetzt schaltet Chan 03 -> reagiert der rt?

Nein.

Ich habe einen zweiten HM-SCI-3-FM, bei dem ich tatsächlich nur einen Kanal (3) an einen anderen RT gepeered habe. An den anderen beiden Kanälen des SCI sind andere Kontakte dran; wenn diese geöffnet werden, wirkt sich das auf den RT nicht aus.

[martinp876]

Gut. Dann kann man peeren aber sonst nicht kontrolieren

[martinp876]

Du kannst auch die peerids im attribut eintragen und dann mit set getreglist die listen 3 und 7 fuer diesen peer leses. Viellei ht klappts

[Ralli]

Danke, Martin.

Dumme Frage: ich kann "set getreglist" nicht in der commandref und nur ein einziges mal im Forum finden. Wie wende ich den Befehl an?

[martinp876]

Sorry, nehme ich zurueck. Das ko,mando habe ih eingezogen, da es im getconfig aufging.

[martinp876]

so - habe es probiert. die Register kann man nicht lesen. Offensichtlich eine unsauberheit. HM rechnet ausschließlich mit SC - und die haben nur einen Kanal. Schade eigentlich.

Somit kann ich nichts machen.
Lässt sich so ein peering mit der win-SW überhaupt einstellen - und konfigurieren?

[Ralli]

Vielen Dank für Deine Mühe, Martin.

Ich habe es nur mit fhem versucht, in der Win-Soft habe ich sie bislang nicht angelernt.

[stromer-12]

Ich habe hier jetzt das gleiche Problem mit virtuellen Fensterkontakten (2 angelegt).
Wird ein Fensterkontakt betätigt reagieren auch die Thermostate des anderen.
Aber im Webinterface werden nur die zugehörigen Thermostate mit den übermittelten Zustand angezeigt.
Die Thermostate des anderen virtuellen Fensterkontaktes reagieren ebenfalls,
im Webinterface werden sie aber richtig mit den Zustand des gepeerten virtuellen Kontaktes angezeigt.

Ich muss mir also mehrere virtuelle Fensterkontakte mit unterschiedlichen HM IDs anlegen, mit einer VCCU komme ich nicht ans Ziel.