HM-CC-TC und HM-CC-VD und HM-SEC-RHS

Begonnen von betateilchen, 08 Juli 2013, 20:00:41

Vorheriges Thema - Nächstes Thema

betateilchen

Vorab: ich habe die Suche benutzt und mir alle einschlägigen Threads zu diesem Thema durchgelesen.

Ausgangssituation:

1 * HM-CC-TC mit hmID 1D919A ist gepaired mit FHEM
1 * HM-CC-VD mit hmID 1DA1A9 ist gepaired mit FHEM
1 * HM-SEC-RHS mit hmID 1F10D8 ist gepaired mit FHEM

HM-CC-TC_Climate ist gepeered mit HM-CC-VD


Attributes:
   group      Heizung
   model      HM-CC-TC
   peerIDs    00000000,1DA1A901,
   room       10_Wohnzimmer

Attributes:
   actCycle   028:00
   actStatus  alive
   expert     2_full
   firmware   2.0
   group      Heizung
   model      HM-CC-VD
   peerIDs    00000000,1D919A02,
   room       10_Wohnzimmer
   serialNr   JEQ0556343
   subType    thermostat


HM-CC-TC_WindowRec ist gepeered mit HM-SEC-RHS


Attributes:
   group      Heizung
   model      HM-CC-TC
   peerIDs    00000000,1F10D801,
   room       10_Wohnzimmer

Attributes:
   IODev      HMUSB
   actCycle   028:00
   actStatus  alive
   eventMap   open:offen closed:zu tilted:gekippt
   expert     2_full
   firmware   2.0
   group      31 Melder Tueren
   model      HM-SEC-RHS
   peerIDs    00000000,1D919A03,
   room       50_Alarmanlage,10_Wohnzimmer
   serialNr   KEQ0019445
   subType    threeStateSensor


Es gibt keine direkten Peerings zwischen den Komponenten.
Nach meinem Verständnis sind die Verknüpfungen alle in Ordnung. Trotzdem bekomme ich im WindowRec keine Daten, sondern im STATE nur "???"


Internals:
   CFGFN      
   DEF        1D919A03
   NAME       wz_FHT_WindowRec
   NR         363
   STATE      ???
   TYPE       CUL_HM
   chanNo     03
   device     wz_FHT
   CHANGED:
     R-Melder_Balkon_chn-01-tempWinOpen: 12 C
   Readings:
     2013-07-08 19:42:03   R-Melder_Balkon_chn-01-tempWinOpen 12 C
     2013-07-08 19:44:52   RegL_05:        
     2013-07-08 19:42:03   RegL_05:Melder_Balkon_chn:01   05:18 00:00
     2013-07-08 19:42:03   peerList        Melder_Balkon_chn:01,
   Helper:
     peerIDsRaw ,1F10D801,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   group      Heizung
   model      HM-CC-TC
   peerIDs    00000000,1F10D801,
   room       10_Wohnzimme


Wenn ich komplett ohne FHEM arbeite und sowohl den Stellantrieb als auch den Fenstersensor direkt mit dem Thermostaten peere, funktioniert alles wie gewünscht und ich sehe auch den "Fenster offen" Status im Display. Aktuell interessiert sich der Thermostat überhaupt nicht für den Fenstersensor.

Bitte um Hilfe. Dieses Problem ist im Moment das letzte große ungelöste Geheimnis in meiner Installation.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

92 Aufrufe und keiner hat eine Idee? *Frust*
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

snoop

Hallo betateilchen,

nur eine Idee.

Wie bist du vorgegangen?

TC / VD / RHS gepairt und dann die Channels gepeert?

Versuche doch mal folgendes, um herauszufinden wo der Fehler liegt:
1) Alles reseten
2) Alles anlernen
3) Alle Komponenten pairen - mit getCionfig Readings einlesen und prüfen ob die Komponenten sauber gepairt sind. Bekommst du dann von den Komponenten ein Status?
4) Fals ja, dann die Komponenten peeren.

Probier das mal.
Gruß
Arthur


betateilchen

Zitat von: snoop schrieb am Mi, 10 Juli 2013 16:05Probier das mal.

Hallo Arthur,

wenn ich das so mache, wie von Dir vorgeschlagen, funktioniert zwar prinzipiell alles (wie ich eingangs ja schon geschrieben hatte), aber

1.) habe ich dann in WindowRec immer noch kein gültiges STATE
2.) WILL ich so nicht vorgehen, da ich die Geräte untereinander gar nicht erst anlernen will, sondern ausschließlich durch FHEM peeren will.

Meine Vorgehensweise ist - wie auch hier und im Wiki vorgeschlagen - folgende:

1. alles resetten
2. alle drei Komponenten mit FHEM pairen (funktioniert wunderbar)
3. alle peerings einrichten (funktioniert auch alles wunderbar - siehe oben in den Listings)

Damit funktioniert ja grundsätzlich auch schon die Steuerung zwischen Thermostat und Stellantrieb, nur die Fensterkontaktauswertung eben nicht. Mir scheint, dass da irgendwo ein setstate() o.ä. verlorengeht und der Status vom Fensterkontakt einfach gar nicht an WindowRec übertragen wird.

Viele Grüße
Udo
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

snoop

Hallo Udo,

Zitat2.) WILL ich so nicht vorgehen, da ich die Geräte untereinander gar nicht erst anlernen will, sondern ausschließlich durch FHEM peeren will.
Offensichtlich falsch verstanden bzw. falsch beschrieben.
Mit Anlernen meine ich in FHEM bekanntgeben *stichwort: autocreate* - Achtung ist nicht gleich pairing und auch nicht gleich peering.

Ich meine bevor du peerst solltest du die Geräte pairen. Meine Idee/Frage ist, melden die Komponenten nach pairing und vor peering ihren Status, um herauszufinden, ob es ein peering Problem ist.

Alternativ kannst du auch die geräte ausserhalb von FHEM peeren und dann den TC mit fhem anlernen und pairen.


Viele Grüße
Arthur



betateilchen

Hallo Arthur,

Zitat von: snoop schrieb am Mi, 10 Juli 2013 18:33Alternativ kannst du auch die geräte ausserhalb von FHEM peeren und dann den TC mit fhem anlernen und pairen.

Genau DAS will ich ja nicht.

Alles andere habe ich genau so gemacht, wie von Dir vorgeschlagen. Und zwar schon mehrfach.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

snoop

Hallo Udo,

ZitatGenau DAS will ich ja nicht.

Frage: Wieso nicht? Technisch passiert nichts anderes - und wenn ein FHEM Fehler vorliegt hasst du es mit der Vorgehensweise umgangen....

ZitatAlles andere habe ich genau so gemacht, wie von Dir vorgeschlagen. Und zwar schon mehrfach.

Heißt: Nach dem pairing und vor dem peering sendet der SEC sein Status - richtig?

Alternativ schau dir das hier an, sollte mMn vom Vorgehen kein unterschied zwischen den beiden Sensoren geben, ist nur etwas genauer beschrieben.

Viele Grüße
Arthur

betateilchen

Hallo Arthur!

Zitat von: snoop schrieb am Mi, 10 Juli 2013 20:23Frage: Wieso nicht?

Weil ich den Ehrgeiz habe, das auch ohne diese Krücke zum Laufen zu bringen.

Zitat von: snoop schrieb am Mi, 10 Juli 2013 20:23Heißt: Nach dem pairing und vor dem peering sendet der SEC sein Status - richtig?

Ja. Und das tut er laut EventMonitor sogar an beide "Empfänger" - sowohl an FHEM (als Pairingpartner) als auch an den Thermostaten (als Peeringpartner) Aber einer der beiden Partner bestätigt das einfach nicht. Im Moment versuche grade, anhand der ProtocolEvents rauszufinden, bei welchem Partner es klemmt.

Zitat von: snoop schrieb am Mi, 10 Juli 2013 20:23Alternativ schau dir das an,

danke, das kannte ich schon. Das Funktionsprinzip der Einrichtung ist mir ja völlig klar. Nur - es funktioniert eben nicht, wie es soll.


VIele Grüße
Udo
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

snoop

Hallo Udo!

ZitatWeil ich den Ehrgeiz habe, das auch ohne diese Krücke zum Laufen zu bringen.
Das hat nichts mit Krücke zu tun sondern Analyse wo es klemmt. Sprich: Liegt es an dem Sensor, Aktor oder Fhem (peering)
*nebenbei hast du das scheinbar garnicht versucht - erscheint dir ja nicht sinnvoll*.

Offensichtlich hast "du" ja "alles"! richtig gemacht - damit ist die Situation klarer - jetzt kann nur noch Martin helfen - dafür braucht er mit sicherheit auch mal ein paar RAW Messages.

Viele Grüße
Arthur

betateilchen

Zitat von: snoop schrieb am Mi, 10 Juli 2013 21:03*nebenbei hast du das scheinbar garnicht versucht - erscheint dir ja nicht sinnvoll*.

Stimmt doch gar nicht. Wenn Du meinen Eingangsbeitrag hier nochmal aufmerksam liest, wird Dir auffallen, dass Dein Vorschlag meine ganz ursprüngliche Ausgangssituation war. Und ich habe auch schon zweimal beschrieben, dass die Steuerung durchaus funktioniert, wenn man die Komponenten - wie von Dir vorgeschlagen - direkt peert. Aber selbst dann wird mir nach dem pairen mit FHEM kein Status bei WindowRec angezeigt.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen


2013-07-10_22:13:10 Melder_Balkon contact: closed (to HMUSB)
2013-07-10_22:13:11 Melder_Balkon closed
2013-07-10_22:13:11 Melder_Balkon contact: closed (to wz_FHT)
2013-07-10_22:14:43 Melder_Balkon open
2013-07-10_22:14:43 Melder_Balkon contact: open (to HMUSB)
2013-07-10_22:14:47 Melder_Balkon open
2013-07-10_22:14:47 Melder_Balkon contact: open (to wz_FHT)


Müsste der event nicht an wz_FHT_WIndowRec gehen anstatt an wz_FHT? *grübel*

Zitatjetzt kann nur noch Martin helfen

Das denke ich auch. Irgendwann wird er diesen Thread sicher entdecken.



2013-07-10 22:17:51 HMLAN HMUSB RCV L:0C N:B9 F:86 CMD:70 SRC:wz_FHT DST:broadcast 00E731 (WeatherEvent TEMP:23.1 HUM:49) (,WAKEMEUP,CFG,RPTEN)
2013-07-10 22:17:51 HMLAN HMUSB SND L:09 N:6F F:A1 CMD:12 SRC:127000 DST:wz_FHT (HAVE_DATA) (,WAKEUP,BIDI,RPTEN)
2013-07-10 22:17:52 HMLAN HMUSB RCV L:0A N:6F F:80 CMD:02 SRC:wz_FHT DST:127000 00 (ACK) (,RPTEN)
2013-07-10 22:17:52 CUL_HM wz_FHT CommandAccepted: yes
2013-07-10 22:17:57 HMLAN HMUSB RCV L:0C N:1F F:A4 CMD:41 SRC:Melder_Balkon DST:127000 011700 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:23 NEXT:0) (,CFG,BIDI,RPTEN)
2013-07-10 22:17:57 HMLAN HMUSB SND L:0D N:1F F:80 CMD:02 SRC:127000 DST:Melder_Balkon 0101C800 (ACK_STATUS CHANNEL:0x01 STATUS:0xC8 UP:0 DOWN:0 LOWBAT:0) (,RPTEN)
2013-07-10 22:17:57 CUL_HM Melder_Balkon closed
2013-07-10 22:17:57 CUL_HM Melder_Balkon contact: closed (to HMUSB)
2013-07-10 22:17:58 HMLAN HMUSB RCV L:0C N:20 F:A0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 011700 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:23 NEXT:0) (,BIDI,RPTEN)
2013-07-10 22:17:58 CUL_HM Melder_Balkon closed
2013-07-10 22:17:58 CUL_HM Melder_Balkon contact: closed (to wz_FHT)


Da fehlt für mich irgendwie das ACK vom Thermostaten (wz_FHT). Und wieso fordert der Sensor (Melder_Balkon) eigentlich ein ACK vom wz_FHT an und nicht vom wz_FHT_WindowRec?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

snoop

Hallo Udo,
Ich fuerchte wir reden/ schreiben aneinander vorbei.
Meine Frage lautete:
Wenn der Sensor RHS nur mit Fhem gepairt ist - schickt dieser dann den Status korrekt - zu sehen am RHS Sensor nicht im winrec. Winrec kann in dem Moment keinen status anzeigen da er kein peering Partner hat- logisch. TC seitig wuerde ich andere channels, also <> winrec auf funktion pruefen... zb temp...

Wenn du RHS und winrec Channel außerhalb von fhem peerst und dann den tc mit fhem pairst - sieht man dann ein status in fhem Channel winrec. Falls immer noch Status mit ??? zu sehen ist, dann kann man ein Fehler in Peering Prozess ausschließen - dann sieht es nach ein Fehler in der Darstellung, fhem (cul_hm) peer entity Fehler oder Channel <-> Sensor Kommunikation aus und dazu kann Martin was sagen.
*alles nur Vermutung*

Viele Gruesse
Arthur

snoop

Hallo Udo,
ZitatMüsste der event nicht an wz_FHT_WIndowRec gehen anstatt an wz_FHT? *grübel*
Ja, richtig - winrec = Channel => Peer mit Sensor.
Laut Log scheint der Sensor RHS mit dem tc und nicht mit dem channel geleert zu sein, wie und ob das geht kann ich mir nicht erklären bzw. sagen.

Mein Vorschlag immer noch.... Erst Komponenten pairen dann nach und nach peeren und Funktion prüfen.....
Grundsatz immer wieder von Martin gepredigt:
Anlernen (manuell wenn man weiß was man tut sonst autocreate)
Alle komponenten pairen mit getConfig readings Auslesen und pairedto prüfen..... Mus hm id der zentrale stehen
peeren
Mit getConfig readings Auslesen und peers prüfen, auf beiden seiten sowohl auf dem Channel des Aktors als auch auf dem Sensor/Remote.

Wie bereits erwähnt umgehst du das ganze indem du die hm Std. Mechanismen nutzt und die Komponenten peerst und anschließend den tc mit fhem pairst (dabei bleiben bzw. sollten die peers auch automatisch angelegt werden).

Viele Gruesse
Arthur

P.S: dein wz_Fht ist der TC -> ist laut Log nicht mit fhem gepaired sieht man an Broadcast Messages - RHS sieht gepaired aus => Führe bitte alle pairing peering Schritte sauber aus, um Vorgehensfehler auszuschließen.

betateilchen

Hallo Arthur,

ZitatIch fuerchte wir reden/ schreiben aneinander vorbei.

Und ich fürchte, Du liest einfach meine Antworten nicht (oder Du verstehst sie einfach nicht)

Nochmal: JA - der Sensor reagiert und kommuniziert grundsätzlich völlig korrekt mit FHEM.

ZitatMein Vorschlag immer noch.... Erst Komponenten pairen dann nach und nach peeren und Funktion prüfen.....
Grundsatz immer wieder von Martin gepredigt:

Nochmal: Lies bitte meine Antworten! Dann wirst Du erkennen, dass ich das alles ganz genau so gemacht habe, wie von Dir immer wieder vorgeschlagen! Das hatte ich schon in meinem allerersten Beitrag, mit dem ich diesen Thread eröffnet habe, beschrieben und mit Listings dokumentiert.

Ich habe mit Martin zusammen schon andere Probleme gelöst und habe dadurch schon vieles gelernt und (technisch) verstanden- und ich kenne seine völlig richtigen und sinnvollen Grundsatzpredigen.

Viele Grüße
Udo
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

snoop

P.S: dein wz_Fht ist der TC -> ist laut Log nicht mit fhem gepaired sieht man an Broadcast Messages - RHS sieht gepaired aus => Führe bitte alle pairing peering Schritte sauber aus, um Vorgehensfehler auszuschließen.