HM-TC-IT-WM-EU, Fenstersensor und HM-CC-RT-DN machen komische Sachen

Begonnen von schitzosteve, 29 Oktober 2018, 14:45:26

Vorheriges Thema - Nächstes Thema

schitzosteve

Hallo zusammen,

ich habe hier ein sehr schräges Phänomen mit dem WM-EU und einem Fenster Sensor, und bräuchte dringend Unterstützung bei der Fehlersuche. Ist etwas kompliziert, hoffe es kommt verständlich rüber.

Kurz:
HM-TC-IT-WM-EU: kueche_WandThermostat
HM-CC-RT-DN: kueche_Thermostat, wz_Thermostat, sz_Thermostat, ...
virtueller Fenster Sensor über vccu: kuecheFensterSensor, wz_FensterSensor, sz_FensterSensor ...

kuecheWandThermostat und kuecheThermostat Kanäle _Clima und _Weather gepaired, wie im Wiki angegeben.


Erster Versuch:

kueche_FensterSensor mit kueche_Wandthermostat_WindowRec gepaired (d.h. der Fenstersensor ist nur mit dem Wandthermostat verbunden)

=>Wenn ich in der Küche das Fenster öffne, werden _alle_ RT-DN runtergeregelt, obwohl kein Pairing zwischen kuecheFensterSensor und den anderen RT-DN existiert. Das ist für mich absolut unerklärlich.

Zweiter Versuch:

kueche_FensterSensor mit kueche_WindowRec gepaired (d.h. der Fenstersensor ist nur mit dem Heizkörperthermostat verbunden)

=>Wenn ich in der Küche das Fenster öffne, wird nur der Thermostat in der Küche runtergeregelt. Nach kurzer Zeit überschreibt aber der Wandthermostat wieder die Zieltemperatur (er weiss ja nicht, dass das Fenster auf ist).

Dritter Versuch:

kueche_FensterSensor mit Wand- und Heizkörperthermostat verbunden.

=>Gleiches Ergebnis wie beim ersten Versuch.

Da ich leider kein Profi im Debugger bin, wäre es nett, wenn Ihr mir helfen könntet, den Fehler zu finden.

slor

was genau soll denn passieren?

Ich habe meine Ventile (RT-DN) mit dem WandThermostat (WM-EU) gepeert.
Der Fensterkontakt (oder Kontakte) sind mit dem Wandthermostat gepeert.

Geht ein Fenster auf, regelt der Thermostat die Ventile runter.

Man muss die Kontakte nicht mit den Thermostaten peeren.

Bitte den Unterschied zwishen Pairing -> mit Zentrale und peering -> zwischen Geräten beachten :-)

schitzosteve

#2
Hallo slor,

Ok, ich meinte natürlich gepeert, nicht gepaired.

Was passieren soll:
Wenn ich in der Küche das Fenster aufmache, dann soll der Thermostat in der Küche runtergeregelt werden. Und nicht gleichzeitig alle anderen Thermostate in der Wohnung. Leider passiert das aber, wenn ich den Fenster Sensor mit dem WM-EU peere. Das macht so ja keinen Sinn.

Was mir noch aufgefallen ist: Im Bad habe ich keinen Fenster Sensor - der Thermostat wird auch nicht runtergeregelt.


frank

zeig mal die ausgabe von "get hminfo peerXref" für deinen 1. fall. zusätzlich "get hminfo configCheck".
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

schitzosteve

get hminfo peerXref
peerXref done:
x-ref list
    ez_WindowRec => v_ez_FensterSensor
    flur_Deckenlampe => self01
    kueche_Climate => kueche_Wandthermostat_Climate
    kueche_Wandthermostat_Climate => kueche_Climate
    kueche_Wandthermostat_Weather => kueche_Weather
    kueche_Wandthermostat_WindowRec => v_kueche_FensterSensor
    kueche_Weather => kueche_Wandthermostat_Weather
    kz_WindowRec => v_kz_FensterSensor
    sz_WindowRec => v_sz_FensterSensor
    v_ez_FensterSensor => ez_WindowRec
    v_kueche_FensterSensor => kueche_Wandthermostat_WindowRec
    v_kz_FensterSensor => kz_WindowRec
    v_sz_FensterSensor => sz_WindowRec
    v_wz_FensterSensor => wz_WindowRec
    vccu_wz_vT_1 => wz_Weather
    wz_Weather => vccu_wz_vT_1
    wz_WindowRec => v_wz_FensterSensor


get hminfo configCheckResult
configCheck done:-ret--ret- missing register list-ret-    klingel: RegL_00.,RegL_01.-ret-    kz_Taster1: RegL_01.-ret-    kz_Taster2: RegL_01.-ret-    kz_Taster3: RegL_01.-ret-    kz_Taster4: RegL_01.-ret-    kz_Taster: RegL_00.-ret-    wz_Taster2: RegL_01.-ret--ret- peer list incomplete. Use getConfig to read it.-ret-    incomplete: klingel:-ret-    incomplete: kz_Taster1:-ret-    incomplete: kz_Taster2:-ret-    incomplete: kz_Taster3:-ret-    incomplete: kz_Taster4:-ret--ret- PairedTo missing/unknown-ret-    klingel

Die Fehler mit den Tastern und dem Klingelsensor sind wohl hier nicht relevant, und das Peering scheint zu stimmen, oder?

martinp876

Die virtuellen sensoren sind Kanäle des gleichen device? Vccu?
Trenne das einmal. Evtl lauschen die anderen rts und filtern den kanal nicht

turo

Zitat von: martinp876 am 29 Oktober 2018, 21:00:29
Die virtuellen sensoren sind Kanäle des gleichen device? Vccu?
Trenne das einmal. Evtl lauschen die anderen rts und filtern den kanal nicht
Die Beobachtung habe ich auch gemacht: Bei mir haben 2 HM-TC-IT-WM-EU auch jeweils kreuzweise auf das andere virtuelle Fenster reagiert, solange das nur unterschiedliche Kanäle des gleichen Device waren. Seit ich da unterschiedliche Devices verwende, funktioniert alles wie geplant.

Turo
3xRaspberry PI, Homematic, SELVE Rollos, 1-wire, Logitech Harmony, Alexa, Fussbodenheizung (ESP8266), Netatmo

Hollo

Zitat von: martinp876 am 29 Oktober 2018, 21:00:29
Die virtuellen sensoren sind Kanäle des gleichen device? Vccu?
Trenne das einmal. Evtl lauschen die anderen rts und filtern den kanal nicht
Genau.
Ob Fenster- oder Temperatursensoren...  wenn es das selbe virtuelle Device ist, geht es meist schief weil der Thermostat nur auf den 1. kanal des Devices guckt.

Siehe hier... https://forum.fhem.de/index.php/topic,19686.msg773977.html#msg773977
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

schitzosteve

Hallo zusammen,

Danke für eure Ratschläge. Ja, die Fenstersensoren sind als Channels einer VCCU implementiert.

Ich habe mal einiges ausprobiert, komme aber nicht zum Ziel:
Ich würde ja gerne getrennte Devices für die unterschiedlichen virtuellen Fenstersensoren anlegen, aber wie geht das? Wenn ich eine weitere VCCU mit der gleichen HMID anlegen will, geht das nicht ("HMid DEF already used by vccu"). Wenn ich eine andere HMID verwende, schlägt das Peeren fehl.

Die Wiki-Artikel https://wiki.fhem.de/wiki/HomeMatic#Besondere_Entities und https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU helfen hier nur bedingt, denn es ist nirgendwo beschrieben, wie man mehrere Devices mit der selben HMID anlegt.

Könnt ihr vielleicht mal kurz skizzieren, wie das geht?

Vielen Dank!

turo

Hallo,

also mit der selben HMID wird das nix - das muss jeweils eine neue sein. Denk Dir eine neue 6-stellige HMID aus und mach es genau so, wie in dem von Dir verlinkten Wiki-Artikel unter "Virtuelle Entities" beschrieben ist! Das erzeugt dann (mindestens) noch einen Kanal (mit 8-stelliger HMID), den Du dann peeren kannst. Oder was genau geht da beim peeren schief?

Gruss,
Turo
3xRaspberry PI, Homematic, SELVE Rollos, 1-wire, Logitech Harmony, Alexa, Fussbodenheizung (ESP8266), Netatmo

schitzosteve

Neues Device:
Internals:
   CFGFN     
   DEF        AFFE00
   IODev     
   NAME       vhm_kueche_Fenster
   NOTIFYDEV  global
   NR         501
   STATE      ???
   TYPE       CUL_HM
   channel_01 vhm_kueche_Fenster_Sensor
   READINGS:
   helper:
     HM_CMDNR   217
     mId       
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +AFFE00,00,00,00
       prefIO     
       rxt        0
       vccu       
       p:
         AFFE00
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   expert     2_raw
   model      virtual_1
   subType    virtual
   webCmd     virtual


Neuer Channel:
Internals:
   CFGFN     
   DEF        AFFE0001
   NAME       vhm_kueche_Fenster_Sensor
   NOTIFYDEV  global
   NR         504
   STATE      set_postEvent open
   TYPE       CUL_HM
   chanNo     01
   device     vhm_kueche_Fenster
   peerList   kueche_Wandthermostat_WindowRec,
   READINGS:
     2018-11-06 14:13:50   peerList        kueche_Wandthermostat_WindowRec,
     2018-11-06 13:49:04   state           set_postEvent open
   helper:
     count      5
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     role:
       chn        1
       vrt        1
Attributes:
   expert     1_allReg
   model      virtual_1
   peerIDs    3879CD03,
   webCmd     postEvent open:postEvent closed


Nach Ausführen von
set vhm_kueche_Fenster_Sensor peerChan 0 kueche_Wandthermostat_WindowRec single set

steht folgendes im Event-Log:
2018-11-06 14:18:27 CUL_HM kueche_Wandthermostat CMDs_pending
2018-11-06 14:18:36 CUL_HM kueche_Wandthermostat ResndFail
2018-11-06 14:18:36 CUL_HM kueche_Wandthermostat CMDs_done_Errors:1
2018-11-06 14:18:36 CUL_HM kueche_Wandthermostat MISSING ACK


Und das Peering taucht niemals in kueche_Wandthermostat_WindowRec auf.

turo

Klingt eigentlich richtig. Ich habe noch IOgrp gesetzt beim Device. Manchmal braucht das Peeren nach meiner Erfahrung auch mehrere Versuche (und immer schön mit Ruhe und jedes Mal die Anlerntaste drücken...).

Ich poste mal schnell meine funktionierende Konfiguration: Vielleicht findest Du noch einen wichtigen Unterschied.

Device:
Internals:
   DEF        A6A00E
   IODev      hmusb
   LASTInputDev hmusb
   MSGCNT     29
   NAME       Virtual_Contacts1
   NOTIFYDEV  global
   NR         455
   NTFY_ORDER 50-Virtual_Contacts1
   STATE      Info_Cleared
   TYPE       CUL_HM
   channel_01 virtual_Fenster_Leo
   hmusb_MSGCNT 29
   hmusb_RAWMSG EA6A00E,0000,4ACDE9C7,FF,FFBE,C7A441A6A00E354975011E00
   hmusb_RSSI -66
   hmusb_TIME 2018-11-06 08:23:41
   lastMsg    No:C7 - t:41 s:A6A00E d:354975 011E00
   protLastRcv 2018-11-06 08:23:41
   protRcv    29 last_at:2018-11-06 08:23:41
   rssi_at_hmusb cnt:29 min:-79 max:-59 avg:-68.03 lst:-66
   READINGS:
   helper:
     HM_CMDNR   199
     mId       
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1541489021.48404
       prefIO     
       vccu       VCCU
     mRssi:
       mNo        C7
       io:
         hmusb:
           -62
           -62
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_hmusb:
         avg        -68.0344827586207
         cnt        29
         lst        -66
         max        -59
         min        -79
     shadowReg:
Attributes:
   IODev      hmusb
   IOgrp      VCCU
   expert     2_full
   model      virtual_1
   room       Homematic
   subType    virtual
   webCmd     virtual


Kanal:

Internals:
   DEF        A6A00E01
   NAME       virtual_Fenster_Leo
   NOTIFYDEV  global
   NR         456
   NTFY_ORDER 50-virtual_Fenster_Leo
   STATE      set_postEvent closed
   TYPE       CUL_HM
   chanNo     01
   device     Virtual_Contacts1
   peerList   Heizung_Leo_WindowRec,
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1541489019.46386
           VALUE      set_postEvent closed
       trigger_cnt:
         logdb:
           TIME       1541489021.44212
           VALUE      30
   READINGS:
     2018-10-22 20:18:10   peerList        Heizung_Leo_WindowRec,
     2018-11-06 08:23:39   state           set_postEvent closed
     2018-11-06 08:23:41   trigger_cnt     30
   helper:
     count      30
     expert:
       def        1
       det        1
       raw        0
       tpl        0
     role:
       chn        1
       vrt        1
     shadowReg:
Attributes:
   devStateIcon set_postEvent.closed:shutter_closed set_postEvent.open:shutter_open
   expert     1
   group      Virtual
   model      virtual_1
   peerIDs    36497503,
   room       Heizung,Homematic
   webCmd     postEvent closed:postEvent open


Gruss,
Turo
3xRaspberry PI, Homematic, SELVE Rollos, 1-wire, Logitech Harmony, Alexa, Fussbodenheizung (ESP8266), Netatmo

schitzosteve

Hallo,

manchmal kann die Welt so einfach sein - ein
attr vhm_kueche_Fenster IODev CUL_0

und anschließendes erneutes Peeren hat zum Erfolg geführt! :)

Und jetzt spielen die Thermostate auch nicht mehr verrückt.

Vielen Dank an alle die geholfen haben!