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.
92 Aufrufe und keiner hat eine Idee? *Frust*
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
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
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
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.
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 (//www.fhemwiki.de/wiki/HM-SEC-SC_T%C3%BCr-Fensterkontakt) an, sollte mMn vom Vorgehen kein unterschied zwischen den beiden Sensoren geben, ist nur etwas genauer beschrieben.
Viele Grüße
Arthur
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
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
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.
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?
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
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.
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
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.
dein wz_Fht ist der TC -> ist laut Log nicht mit fhem gepaired
Mann oh Mann... ganz so doof, wie Du hier seit Stunden versuchst, mich hinzustellen, bin ich dann doch nicht!
wz_FHT ist das Device und das ist sehr wohl gepaired. Und wenn Du oben die Logs genau anschauen würdest, könntest Du sogar erkennen, dass wz_FHT sogar ein ACK an FHEM verschickt! Das wäre ziemlich unmöglich, wenn es keine Verbindung gäbe.
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)
Internals:
DEF 1D919A
EVENTS 186
HMUSB_MSGCNT 190
HMUSB_RAWMSG E1D919A,0000,0B3FE4A0,FF,FFB4,D786701D919A00000000E833
HMUSB_RSSI -76
HMUSB_TIME 2013-07-10 23:34:33
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 190
NAME wz_FHT
NR 353
NTFY_TRIGGERTIME 2013-07-10 23:34:33
STATE T: 23.2 H: 51
TYPE CUL_HM
channel_01 wz_FHT_Weather
channel_02 wz_FHT_Climate
channel_03 wz_FHT_WindowRec
lastMsg No:D7 - t:70 s:1D919A d:000000 00E833
protCmdDel 5
protLastRcv 2013-07-10 23:34:32
protResnd 99 last_at:2013-07-10 22:17:51
protResndFail 47 last_at:2013-07-10 22:17:44
protSnd 87 last_at:2013-07-10 22:17:44
protState CMDs_done_events:2
rssi_at_HMUSB avg:-69.93 min:-83 max:-64 lst:-76 cnt:190
Readings:
2013-07-10 21:59:49 Activity: alive
2013-07-10 22:17:52 CommandAccepted yes
2013-07-10 21:57:45 PairedTo 0x127000 <<<<<--- guckst Du hier!
2013-07-10 21:57:45 R-backlOnMode undef lit
2013-07-10 21:57:45 R-backlOnTime 15 s
2013-07-10 21:57:45 R-btnLock unlock
2013-07-10 21:57:45 R-intKeyVisib invisib
2013-07-10 21:57:45 R-pairCentral 0x127000
2013-07-10 21:57:45 RegL_00: 01:00 02:01 05:8F 0A:12 0B:70 0C:00 0F:00 00:00
2013-07-10 23:32:09 actuator 0 %
2013-07-10 21:10:13 battery ok
2013-07-10 22:02:43 controlMode central
2013-07-10 22:02:43 day-temp 21 C
2013-07-10 22:02:43 decalcDay Sat
2013-07-10 21:38:39 desired-temp 21.0
2013-07-10 22:02:43 displayMode temp-hum
2013-07-10 22:02:43 displayTemp actual
2013-07-10 22:02:43 displayTempUnit celsius
2013-07-10 23:34:33 humidity 51
2013-07-10 23:34:33 measured-temp 23.2
2013-07-10 22:02:43 night-temp 17 C
2013-07-10 22:02:43 party-temp 20 C
2013-07-10 23:34:33 state T: 23.2 H: 51
Helper:
burstEvtCnt 2
mId 0039
rxType 12
Respwait:
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -69.9315789473684
cnt 190
lst -76
max -64
min -83
Shadowreg:
Attributes:
actCycle 000:10
actStatus alive
expert 2_full
firmware 2.1
group Heizung
model HM-CC-TC
peerIDs
room 10_Wohnzimmer
serialNr JEQ0551882
subType thermostat
Hallo Udo,
ich habe, bisher versucht konstruktiv zu unterstuetzen und bisher themen/bereiche angesprochen bei denen oft fehler gemacht werden bzw. oft probleme auftreten.
Wenn du eine andere wahrnehmung hast - dann war das in keinster weise meine absicht.
Wuensche dir noch viel erfolg...
Viele gruesse
Arthur
Hi @ Betateilchen
Ich habs jetzt auch 3 mal durchgelesen bis ich dein "Problem" verstanden hab :)
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)
Peering lt Event richtig, vom Melder Balkon
Wenn ich es richtig verstehe, siehst du den state auch im Device Melder_Balkon (open-closed)
Melder_Balkon contact: closed (to HMUSB)
und da geht die Meldung auch hin.
soweit ist ja auch alles richtig.
Du hättest jetzt noch gerne, das der state auch im wz_FHT_WIndowRec erscheint!
also sprich, das Martin die Meldung
Melder_Balkon contact: open (to wz_FHT)
auswertet.
so wie beim VD, einmal im Device VD und zusätzlich im TC und TC_Climate oder?
Hary
Hallo Arthur,
ich habe nichts gegen Deine Unterstützung und Deine Hilfsabsicht. Aber Du hast mir gefühlte 728 Mal die gleiche Vorgehensweise vorgeschlagen und ich habe Dir mindestens genauso oft geantwortet, dass ich diese Vorgehensweise kenne und eingehalten habe. Du unterstellst mir unterschwellig, jeglichen Hilfsversuch von Dir auszuschlagen und als "nicht sinnvoll" zu betrachten. Stimmt aber nicht - denn wie gesagt, die vorgeschlagene Vorgehensweise habe ich durchaus schon eingehalten, bevor ich diesen Thread eröffnet habe. Es hilft mir nicht weiter, wenn Du mir noch 100 Mal den gleichen Vorschlag machst, und ich Dir noch 100 Mal antworten muss, dass ich das schon gemacht habe - das frustriert doch nur uns BEIDE.
Und Deine Schlussfolgerung hier:
Zitatist laut Log nicht mit fhem gepaired sieht man an Broadcast Messages
ist so pauschal einfach nicht richtig, weil das Senden von Messages an Broadcast nichts damit zu tun haben muss, ob ein Gerät gepaired ist oder nicht. Es gibt eine ganze Reihe von Homematic Geräten, die sich so verhalten.
Beispiel: Viele (nein, nicht alle!) Homematic-Fernbedienungen, die zwar mit FHEM korrekt gepaired sind, senden Button-Events so lange an Broadcast, solange der Button nicht mit einem Channel (egal ob physischer oder virtueller Aktor) gepeert ist.
Anderes Beispiel: Der Umweltsensor HM-WDS10-TH-O sendet seine Messwerte zu Temperatur und Luftfeuchtigkeit ebenfalls an Broadcast, obwohl er mit FHEM gepaired ist.
Um das nochmal ausdrücklich festzuhalten: Ich nehme wirklich gerne Hilfe an und freue mich auch über jeden Hilfeversuch - aber x-Mal das gleiche vorzuschlagen, das bereits getestet wurde, ist nicht wirklich eine zielführende Hilfe.
Viele Grüße
Udo
Hallo Hary,
danke für Deine Antwort.
Zitat von: fhem-hm-knecht schrieb am Do, 11 Juli 2013 09:31Du hättest jetzt noch gerne, das der state auch im wz_FHT_WIndowRec erscheint!
Ich bin bisher nach meinem Verständnis (nach dem Lesen vieler Doku, Wiki und hier im Forum) davon ausgegangen, dass der WindowRec exakt dafür vorhanden ist, solche Meldungen zu empfangen.
Zitat von: fhem-hm-knecht schrieb am Do, 11 Juli 2013 09:31also sprich, das Martin die Meldung
Melder_Balkon contact: open (to wz_FHT)
auswertet. so wie beim VD, einmal im Device VD und zusätzlich im TC und TC_Climate oder?
Naja, ich möchte einfach erreichen, dass der TC mitbekommt, dass die Balkontür offen ist, dass das dann auch im Display angezeigt wird und der Thermostat die Temperatur entsprechend runterfährt.
Die Meldung von der Balkontür wird ja korrekt an die Steuereinheit verschickt, d.h. das Peering funktioniert grundsätzlich. Das anforderte ACK kommt aber nicht, was dazu führt, dass der Melder an der Tür immer eine rote statt einer grünen Rückmeldung liefert.
Viele Grüße
Udo
ich habe gerade gesehen, dass du im TC
2013-07-10 22:02:43 controlMode central
gesetzt hast.
Naja, ich möchte einfach erreichen, dass der TC mitbekommt, dass die Balkontür offen ist, dass das dann auch im Display angezeigt wird und der Thermostat die Temperatur entsprechend runterfährt.
Das ist die Frage, ob das im Centralmodus überhaupt geht!
soweit ich das weiß, übergibst du Fhem komplett die Steuerung, das ist eh ein komischer Modus, mit dem ich nichts anfangen kann :)
was ich noch weiß, es gab für das TC verschiedene SW stände , wo der TC sich komisch verhalten hat mit dem Fenterstatus. mußt mal
googeln. sollt aber ab 2.0 gehen
ich betreibe meine TC nur Manu-Auto. nicht Central. und ohne Fensterkontakt
Das Verhalten ist auch im Berieb mit FHEM in Auto und Manu nicht anders. Und im Betrieb ganz ohne FHEM funktioniert alles perfekt.
Hi,
ich denke, das Problem ist die "burst" Einstellung.
Habe noch nichts selbst getestet - aber kannst du einmal nachsehen, ob der RHS in peerNeedsBurst fuer den WinRec ein 'on' stehen hat?
Der TC kann, sobald ein WinRec eingetragen ist, auch burst mode, damit ein 'plötzliches' Fensteröffnen auch bearbeitet wird.
Sollte eigentlich automatisch kommen. ggf. einmal die Register des RHS auslesen und (expert = 2 ) posten.
Gruss Martin
habe einen Bug beim aufsetzen der Peerings. Im Falle des winRec sollte beim RHS burst automatisch gesetzt werden - leider ein Kodierfehler. Kommt im nächsten Update.
So lange - wenn man das manuell setze sollte es klappen - oder?
Gruss Martin
Hallo Martin,
wenn ich das richtig sehe 2013-07-10 22:12:06 R-wz_FHT_WindowRec-peerNeedsBurst off
steht da nicht on :)
Gib mir mal bitte noch einen Tipp, wie ich das manuell auf on stellen kann. Ich habe so ziemlich alle regSet Kombinationen dazu durch, die mir einfallen, aber ausser Syntaxfehlern keine Antwort erhalten.
set Melder_Balkon regSet wz_FHT_WindowRec???
Viele Grüße
Udo
Internals:
DEF 202CF9
EVENTS 5
HMUSB_MSGCNT 10
HMUSB_RAWMSG E202CF9,0000,13DF6F50,FF,FFAC,40A041202CF91D919A012700
HMUSB_RSSI -84
HMUSB_TIME 2013-07-12 15:45:48
IODev HMUSB
LASTInputDev HMUSB
MSGCNT 10
NAME Melder_Balkon
NR 340
NTFY_TRIGGERTIME 2013-07-12 15:46:17
STATE zu
TYPE CUL_HM
lastMsg No:40 - t:41 s:202CF9 d:1D919A 012700
protCmdPend 1 CMDs_pending
protLastRcv 2013-07-12 15:45:48
protState CMDs_pending
rssi_at_HMUSB avg:-81.2 min:-84 max:-77 lst:-84 cnt:10
Readings:
2013-07-12 15:46:17 Activity: alive
2013-07-10 22:12:04 CommandAccepted yes
2013-07-10 22:12:04 PairedTo 0x127000
2013-07-10 22:12:04 R-cyclicInfoMsg off
2013-07-10 22:12:04 R-eventDlyTime 0 s
2013-07-10 22:12:04 R-intKeyVisib invisib
2013-07-10 22:12:04 R-ledOnTime 0.5 s
2013-07-10 22:12:04 R-msgRhsPosA closed
2013-07-10 22:12:04 R-msgRhsPosB open
2013-07-10 22:12:04 R-msgRhsPosC tilted
2013-07-10 22:12:04 R-pairCentral 0x127000
2013-07-10 22:12:04 R-transmDevTryMax 6
2013-07-10 22:12:04 R-transmitTryMax 6
2013-07-10 22:12:06 R-wz_FHT_WindowRec-expectAES off
2013-07-10 22:12:06 R-wz_FHT_WindowRec-peerNeedsBurst off
2013-07-10 22:12:04 RegL_00: 02:01 09:00 0A:12 0B:70 0C:00 10:01 14:06 00:00
2013-07-10 22:12:04 RegL_01: 08:00 20:6C 21:00 22:64 30:06 00:00
2013-07-10 22:12:06 RegL_04:wz_FHT_WindowRec 01:00 00:00
2013-07-10 22:12:32 alive yes
2013-07-10 22:12:32 battery ok
2013-07-12 15:45:41 contact closed (to wz_FHT)
2013-07-10 22:12:32 cover closed
2013-07-12 14:56:15 peerList wz_FHT_WindowRec,
2013-07-12 15:45:41 state closed
cmdStack:
++A001127000202CF900040000000000
Helper:
mId 0030
rxType 12
Respwait:
Role:
chn 1
dev 1
Rssi:
At_hmusb:
avg -81.2
cnt 10
lst -84
max -77
min -84
Attributes:
actCycle 028:00
actStatus alive
eventMap open:offen closed:zu tilted:gekippt
expert 2_full
firmware 2.0
group 30 Melder Tueren
model HM-SEC-RHS
peerIDs 00000000,1D919A03,
serialNr KEQ0069535
subType threeStateSensor
Habs rausgefunden.
set Melder_Balkon regSet peerNeedsBurst on wz_FHT_WindowRec
Jetzt muss ich das dem Sensor nur noch beibringen.
edit1:
Jetzt ist im WindowRec der gepeerte RHS komplett verschwunden - sehr merkwürdig.
---------------------------------------------------------------------------------------
edit2:
2013-07-12 19:42:26 HMLAN HMUSB RCV L:0C N:13 F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 010A00 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:10 NEXT:0) (,BURST,BIDI,RPTEN)
Der Sensor schickt jetzt wohl die korrekte Nachricht, aber der WindowRec reagiert nun deshalb nicht, weil der Melder als Peer in der WindowRec-Konfiguration verschwunden ist und ich es bisher nicht geschafft habe, den dort wieder reinzukriegen.
Ich bekomme den WindowRec - trotz komplettem Zurücksetzen der Komponenten - nicht mehr mit dem Fenstermelder gepeert, es ist zum Ko....
Warum gibts eigentlich beim WindowRec kein peerChan, sondern nur peerBulk zum peeren?
MIt dem Burst-Mode und nach (gefühlten) 728 weiteren Konfigurations- und Peeringversuchen scheint das jetzt wirklich zu funktionieren.
Mal sehen, wie lange...
Der STATE im Channel WindowRec wird allerdings immer noch nicht aktualisiert - da stehen nach wie vor 3 Fragezeichen. Scheint aber der Funktion keinen Abbruch zu tun.
Übrigens: wenn man weiß, wonach man suchen muß, kann man die Lösung mit dem Burst-Modus in dieser Konstellation schon mehrfach hier im Forum finden, zum Beispiel hier (//forum.fhem.de/index.php?t=msg&goto=70577&rid=1592&srch=peerneedsburst#msg_70577). Sehr beruhigend, dass ich nicht der erste und einzige bin, der in diese Falle getappt ist *g*
Hi,
zur Erklärung:
der TC schaltet auch seinen 'burst-detektor' ein wenn ein window-receiver gepeert ist. Somit kann er immer empfangen, braucht aber mehr strom für den Receiver.
Dem Sender muss gesagt werden, welcher peer burst benötigt, default ist kein burst.
FHEM schaltet beim peeren mit TC-WinRec den Burst am Sender automatisch ein - leider habe ich beim Lesen des subType einen Fehler gemacht, daher hat es nicht geklappt.
Setzen von registern ist immer
set <entity> regSet <regname> <value> [<peer>]
peer ist optional, abhängig vom Register und muss daher am Ende stehen. Wir arbeiten hier ohne Trennzeichen, daher können optionale Parameter nur am Ende stehen.
Zum state des WindowRec channel - da ist wohl nichts drin. kannst du ein paar roh-logs schicken, wenn das Fenster auf und zu geht? Mal sehen, ob der TC ein statusbit setzt.
Gruss Martin
Hallo Martin,
hier habe ich mal den Fenstergriff von "open" nach "closed", danach wieder auf "open" -> "tilted" und wieder zurück bewegt.
2013.07.13 12:47:44 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862C1A9 d:FF r:FFAD m:34 A441 202CF9 127000 011E00
2013.07.13 12:47:44 1: RCV L:0C N:34 F:A4 CMD:41 SRC:Melder_Balkon DST:127000 011E00 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:30 NEXT:0) (,CFG,BIDI,RPTEN)
2013.07.13 12:47:45 1: HMLAN_Send: HMUSB S:SD7A4BDC3 stat: 00 t:00000000 d:01 r:D7A4BDC3 m:34 8002 127000 202CF9 0101C800
2013.07.13 12:47:45 1: SND L:0D N:34 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.13 12:47:45 1: HMLAN_Parse: HMUSB R:RD7A4BDC3 stat:0002 t:00000000 d:FF r:7FFF m:34 8002 127000 202CF9 0101C800
2013.07.13 12:47:45 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862C404 d:FF r:FFAC m:35 B041 202CF9 1D919A 011E00
2013.07.13 12:47:45 1: RCV L:0C N:35 F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 011E00 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:30 NEXT:0) (,BURST,BIDI,RPTEN)
2013.07.13 12:47:48 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:1862CD93 d:FF r:FFB4 m:37 A410 1D919A 127000 06020000000000
2013.07.13 12:47:48 1: RCV L:10 N:37 F:A4 CMD:10 SRC:wz_FHT DST:127000 06020000000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:47:48 1: SND L:0A N:37 F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
2013.07.13 12:47:48 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862CFBE d:FF r:FFAF m:37 B041 202CF9 1D919A 011FC8
2013.07.13 12:47:48 1: RCV L:0C N:37 F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 011FC8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:31 NEXT:200) (,BURST,BIDI,RPTEN)
2013.07.13 12:47:49 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:1862D03D d:FF r:FFB4 m:37 8002 1D919A 202CF9 00
2013.07.13 12:47:49 1: RCV L:0A N:37 F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
2013.07.13 12:47:50 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862D694 d:FF r:FFB0 m:36 A041 202CF9 127000 011FC8
2013.07.13 12:47:50 1: RCV L:0C N:36 F:A0 CMD:41 SRC:Melder_Balkon DST:127000 011FC8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:31 NEXT:200) (,BIDI,RPTEN)
2013.07.13 12:47:50 1: HMLAN_Send: HMUSB S:SD7A4D33B stat: 00 t:00000000 d:01 r:D7A4D33B m:36 8002 127000 202CF9 0101C800
2013.07.13 12:47:50 1: SND L:0D N:36 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.13 12:47:50 1: HMLAN_Parse: HMUSB R:RD7A4D33B stat:0002 t:00000000 d:FF r:7FFF m:36 8002 127000 202CF9 0101C800
2013.07.13 12:47:50 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:1862D852 d:FF r:FFB3 m:38 A410 1D919A 127000 06021800000000
2013.07.13 12:47:50 1: RCV L:10 N:38 F:A4 CMD:10 SRC:wz_FHT DST:127000 06021800000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x18 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:47:50 1: SND L:0A N:38 F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
Use of uninitialized value in split at FHEM/SetExtensions.pm line 146.
2013.07.13 12:47:52 1: HMLAN_Send: HMUSB I:K
2013.07.13 12:47:52 1: HMLAN_Parse: HMUSB V:03C3 sNo:JEQ0534751 d:1DAFAC O:127000 t:1862E0CD IDcnt:0003
2013.07.13 12:47:54 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862E7C1 d:FF r:FFAD m:38 A441 202CF9 127000 012064
2013.07.13 12:47:54 1: RCV L:0C N:38 F:A4 CMD:41 SRC:Melder_Balkon DST:127000 012064 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:32 NEXT:100) (,CFG,BIDI,RPTEN)
2013.07.13 12:47:54 1: HMLAN_Send: HMUSB S:SD7A4E3E5 stat: 00 t:00000000 d:01 r:D7A4E3E5 m:38 8002 127000 202CF9 0101C800
2013.07.13 12:47:54 1: SND L:0D N:38 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.13 12:47:55 1: HMLAN_Parse: HMUSB R:RD7A4E3E5 stat:0002 t:00000000 d:FF r:7FFF m:38 8002 127000 202CF9 0101C800
2013.07.13 12:47:55 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862EA1E d:FF r:FFAC m:39 B041 202CF9 1D919A 012064
2013.07.13 12:47:55 1: RCV L:0C N:39 F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 012064 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:32 NEXT:100) (,BURST,BIDI,RPTEN)
2013.07.13 12:47:55 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:1862EA9C d:FF r:FFB4 m:39 8002 1D919A 202CF9 00
2013.07.13 12:47:55 1: RCV L:0A N:39 F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
2013.07.13 12:47:57 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:1862F2B0 d:FF r:FFB3 m:3A A410 1D919A 127000 06021800000000
2013.07.13 12:47:57 1: RCV L:10 N:3A F:A4 CMD:10 SRC:wz_FHT DST:127000 06021800000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x18 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:47:57 1: SND L:0A N:3A F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
2013.07.13 12:47:59 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862F955 d:FF r:FFAE m:3A A441 202CF9 127000 0121C8
2013.07.13 12:47:59 1: RCV L:0C N:3A F:A4 CMD:41 SRC:Melder_Balkon DST:127000 0121C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:33 NEXT:200) (,CFG,BIDI,RPTEN)
2013.07.13 12:47:59 1: HMLAN_Send: HMUSB S:SD7A4F586 stat: 00 t:00000000 d:01 r:D7A4F586 m:3A 8002 127000 202CF9 0101C800
2013.07.13 12:47:59 1: SND L:0D N:3A 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.13 12:47:59 1: HMLAN_Parse: HMUSB R:RD7A4F586 stat:0002 t:00000000 d:FF r:7FFF m:3A 8002 127000 202CF9 0101C800
2013.07.13 12:47:59 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1862FBB0 d:FF r:FFAE m:3B B041 202CF9 1D919A 0121C8
2013.07.13 12:47:59 1: RCV L:0C N:3B F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 0121C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:33 NEXT:200) (,BURST,BIDI,RPTEN)
2013.07.13 12:48:01 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:1862FC2F d:FF r:FFB3 m:3B 8002 1D919A 202CF9 00
2013.07.13 12:48:01 1: RCV L:0A N:3B F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
2013.07.13 12:48:01 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:18630412 d:FF r:FFAE m:3C A441 202CF9 127000 012200
2013.07.13 12:48:02 1: RCV L:0C N:3C F:A4 CMD:41 SRC:Melder_Balkon DST:127000 012200 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:34 NEXT:0) (,CFG,BIDI,RPTEN)
2013.07.13 12:48:02 1: HMLAN_Send: HMUSB S:SD7A50045 stat: 00 t:00000000 d:01 r:D7A50045 m:3C 8002 127000 202CF9 0101C800
2013.07.13 12:48:02 1: SND L:0D N:3C 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.13 12:48:02 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:186304EE d:FF r:FFB4 m:3C A410 1D919A 127000 06021800000000
2013.07.13 12:48:02 1: RCV L:10 N:3C F:A4 CMD:10 SRC:wz_FHT DST:127000 06021800000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x18 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:48:02 1: SND L:0A N:3C F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
2013.07.13 12:48:02 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:186304EE d:FF r:FFB4 m:3C A410 1D919A 127000 06021800000000
2013.07.13 12:48:02 1: HMLAN_Parse: HMUSB R:RD7A50045 stat:0002 t:00000000 d:FF r:7FFF m:3C 8002 127000 202CF9 0101C800
2013.07.13 12:48:02 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1863066F d:FF r:FFAE m:3D B041 202CF9 1D919A 012200
2013.07.13 12:48:02 1: RCV L:0C N:3D F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 012200 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:34 NEXT:0) (,BURST,BIDI,RPTEN)
2013.07.13 12:48:03 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:18630A9F d:FF r:FFAE m:3D B041 202CF9 1D919A 012200
2013.07.13 12:48:03 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:18630B1E d:FF r:FFB4 m:3D 8002 1D919A 202CF9 00
2013.07.13 12:48:03 1: RCV L:0A N:3D F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
2013.07.13 12:48:05 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:186311C1 d:FF r:FFAC m:3E A441 202CF9 127000 0123C8
2013.07.13 12:48:05 1: RCV L:0C N:3E F:A4 CMD:41 SRC:Melder_Balkon DST:127000 0123C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:35 NEXT:200) (,CFG,BIDI,RPTEN)
2013.07.13 12:48:05 1: HMLAN_Send: HMUSB S:SD7A50DE6 stat: 00 t:00000000 d:01 r:D7A50DE6 m:3E 8002 127000 202CF9 0101C800
2013.07.13 12:48:05 1: SND L:0D N:3E 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.13 12:48:06 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:186312EA d:FF r:FFB1 m:3E A410 1D919A 127000 06020000000000
2013.07.13 12:48:06 1: RCV L:10 N:3E F:A4 CMD:10 SRC:wz_FHT DST:127000 06020000000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:48:06 1: SND L:0A N:3E F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
2013.07.13 12:48:06 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:186312EA d:FF r:FFB1 m:3E A410 1D919A 127000 06020000000000
2013.07.13 12:48:06 1: HMLAN_Parse: HMUSB R:RD7A50DE6 stat:0002 t:00000000 d:FF r:7FFF m:3E 8002 127000 202CF9 0101C800
2013.07.13 12:48:06 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:186313EA d:FF r:FFB2 m:3F A410 1D919A 127000 06020000000000
2013.07.13 12:48:06 1: RCV L:10 N:3F F:A4 CMD:10 SRC:wz_FHT DST:127000 06020000000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x00 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:48:06 1: SND L:0A N:3F F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
2013.07.13 12:48:07 1: HMLAN_Parse: HMUSB R:E202CF9 stat:0000 t:1863141D d:FF r:FFAB m:3F B041 202CF9 1D919A 0123C8
2013.07.13 12:48:07 1: RCV L:0C N:3F F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 0123C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:35 NEXT:200) (,BURST,BIDI,RPTEN)
2013.07.13 12:48:07 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:186318CB d:FF r:FFB5 m:3F 8002 1D919A 202CF9 00
2013.07.13 12:48:07 1: RCV L:0A N:3F F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
Use of uninitialized value in split at FHEM/SetExtensions.pm line 146.
2013.07.13 12:48:09 1: HMLAN_Parse: HMUSB R:E1D919A stat:0000 t:18632096 d:FF r:FFB1 m:40 A410 1D919A 127000 06021800000000
2013.07.13 12:48:09 1: RCV L:10 N:40 F:A4 CMD:10 SRC:wz_FHT DST:127000 06021800000000 (INFO_ACTUATOR_STATUS RSSI:0 CHANNEL:0x02 STATUS:0x18 UNKNOWN:0x00) (,CFG,BIDI,RPTEN)
2013.07.13 12:48:09 1: SND L:0A N:40 F:80 CMD:02 SRC:127000 DST:wz_FHT 00 (ACK) (,RPTEN)
Viele Grüße
Udo
Hallo Udo,
der TC meldet zwar die Temperatur-aenderung aber nicht warum.
Es waere also eine Auswertung der trigger-endpunkte notwendig um den Status zu schreiben. Das ist in CUL_HM nicht generell drin - und bedarf auch etwas performance. Daher scheue ich etwas davor. Werde einmal nachdenken....
Wirklich auswerten kann ich es aber nur, wenn immer die peerings korrekt aus den devices gelesen werden. Der Senso sagt nicht, an welchen Channel ersendet, nur welches Device. Nächstes Problem ist, dass ein TC an mehrere RS gepeert sein kann. Gibt in der Summe einen beachtlichen Aufwand.
Mal grübeln....
Gruss
Martin
Hallo Martin!
Mach Dir keinen allzu großen Streß wegen dieses Schönheitsfehlers. Die Technik an sich funktioniert ja. Es wäre halt schöner gewesen, anstatt den ??? etwas anderes zu sehen. Ich habe mal mit stateFormat getestet, da kann ich einfach den Status des Sensors in den WIndoRec darstellen, aber es wird nicht aktualisiert.
Schönen Sonntag,
Udo
Hi Udo
ich habe einmal trigger-Events eingebaut - Version 3441.
Du kannst die Anleitung lesen und Kommentieren.
Ansatz ist, die Peerliste des Senders herzunehmen und daraus ein Event in den Aktoren zu starten.
Da ein Aktor mehrere Trigger-Quellen haben kann gibt es:
trig_<src>:<value>
trigLast:<chan>
Du solltest beim winRec also auch den Wert des Triggers des RHS sehen.
Wenn du das nach state mappen willst, kannst du trigLast nehmen.
sollte man
trigLast:<chan> <value>
schreiben?
Das klappt alles nicht, wenn die perrlliste in FEHM eingelesen wurde
Gruß
Martin
Hallo Martin,
ich habe Deinen Beitrag jetzt mindestens 10 Mal gelesen - aber nichts verstanden. Was soll ich wo eingeben/sehen?
Ok - es war ein anstrengender Tag heute - ich bin müde. Vielleicht wird mir morgen klar, was Du möchtest.
Hi,
ich dachte, du wolltest im TC WinRec sehen, dass ein RHS ausgelöst hat. Am besten im Status.
So weit ist die Lösung nicht, sollte aber mechanismen liefern, dass es der User schafft.
Der Ansatz ist Generell, also nicht nur für TC-RHS. Kommt ein trigger wird in dem gepeerten Aktoren ein Reading gesetzt.
Da ich aus performancegründen nicht alles durchsuchen will nehme ich die peerlist (genauer attr peerIDs) des Senders um die Aktoren zu finden.
Wenn dein RHS mit TC_Win gepeert ist UND die Daten in FHEM vorliegen (aus getConfig, dann save....) funktioniert es so
RHSx send trigger mit Wert 0|100|200 (=0/50%/100%)=zu/halb/offen
In TC-Win
- trig_RHSx:100
- trigLast:RHSx
Im TC-Win kannst du mit stateFormat dann trigLast anzeigen
Trifft dies in etwa, was du sehen willst?
Gruß Martin
Hallo Martin,
also gepeert ist der RHS mit dem WinRec. Verstehe ich das richtig: Ich müsste dann im Event Monitor zwei neue Einträge mit den Triggern sehen, die ich dann auch als Reading im WinRec wiederfinde.
Muss ich heute abend nochmal drauf achten, gestern abend hatte ich jedenfalls nix derartiges festgestellt.
Danke erstmal!
Udo
korrekt.
Falls mehrere Sensoren an den TC_WIN gepeert sind gibt es einen Eintrag pro Quelle und einen, der die letzte Quelle ausgibt.
Ausserdem wird der 'Wert' mit ausgegeben. Beim RHS ist es einer von 0/100/200, beim mdir ein dimmwert. Bei tastern ein '-', die liefern keinen Wert dazu.
Wenn du wissen willst, ob der TC_WIN aktiv ist, musst du alle 'trig_name' durchsehen. Ich habe keine Ahnung, was passiert, wenn ein TC_WIN mehrere peers hat, diesen auch noch verschiedene temperaturen zugewiesen sind. Raum zum Testen. Bei nur einem RHS ist dies einfach.
Bei bedarf kann ich bei Last auch noch den Wert angeben. Evtl Sinnvoll.
Gruss Martin
Ich habe keine neuen Readings im WindowRec. Ist mir langsam aber auch egal.
2013-07-19 17:30:59 HMLAN HMUSB RCV L:0C N:86 F:A4 CMD:41 SRC:Melder_Balkon DST:127000 0145C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:69 NEXT:200) (,CFG,BIDI,RPTEN)
2013-07-19 17:31:00 HMLAN HMUSB SND L:0D N:86 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-19 17:31:00 CUL_HM Melder_Balkon offen
2013-07-19 17:31:00 CUL_HM Melder_Balkon contact: offen (to HMUSB)
2013-07-19 17:31:01 HMLAN HMUSB RCV L:0C N:87 F:B0 CMD:41 SRC:Melder_Balkon DST:wz_FHT 0145C8 (Sensor_event BUTTON:1 LONG:0 LOWBAT:0 VALUE:69 NEXT:200) (,BURST,BIDI,RPTEN)
2013-07-19 17:31:01 CUL_HM Melder_Balkon offen
2013-07-19 17:31:01 CUL_HM Melder_Balkon contact: offen (to wz_FHT)
2013-07-19 17:31:01 HMLAN HMUSB RCV L:0A N:87 F:80 CMD:02 SRC:wz_FHT DST:Melder_Balkon 00 (ACK) (,RPTEN)
2013-07-19 17:31:02 CUL_HM wz_FHT CommandAccepted: yes
Hi,
Das Reading kommt, wenn im Melder_Balkon der wz_FHT als peer eingetragen ist, also
attr Melder_Balkon peerIDs 1D919A03
Da sie gepeert sind sollte das Attribut so stehen
Gruss Martin
Das ist doch aber schon lange so?
(http://up.picr.de/15233076af.png)
Das einzige Reading im WIndowRec ist die peerList
(http://up.picr.de/15233081kg.png)
Hi Udo,
bist du auf der neusten SW?
Wenn ich simuliere klappt es.
1) der Aktor-Channel muss im Attr peerIDs eingetragen sein (ist der Fall bei dir)
bei mir:
attr FB2_Btn_01 peerIDs 00000000,172A8503
2) nach dem Trigger (bei mir ein remote-sender) werden folgende Trigger geschrieben:
2013-07-20 14:21:04.794 CUL_HM th_WindowRec trig_FB2_Btn_01: -
2013-07-20 14:21:04.794 CUL_HM th_WindowRec trigLast: FB2_Btn_01
der Level ist bei mir '-' da es ein remote ist - der liefert keinen. Dein RHS sollte hier eine Zahl einstellen.
Somit ergibt sich
Internals:
DEF 172A8503
NAME th_WindowRec
NR 97
STATE trig:FB2_Btn_01
TYPE CUL_HM
chanNo 03
device th
Readings:
2013-07-20 14:21:04 trigLast FB2_Btn_01
2013-07-20 14:21:04 trig_FB2_Btn_01 -
Wie gesagt, dass ist nicht auf den TC beschränkt, das ist generell - alle Sensor/aktor peerings
Kann es sein, dass du nicht die Aktuelle SW hast?
Gruss Martin
Martin,
der WIndowRec hat hier NOCH NIE irgendeinen Event ausgelöst. Hast Du das wirklich mit einem TC getestet oder ist auch der WindowRec bei Dir nur ein Dummy?
Ja, ich bin auf dem aktuellen Softwarestand.
# CUL HomeMatic handler
# $Id: 10_CUL_HM.pm 3452 2013-07-19 09:52:46Z martinp876 $
Viele Grüße
Udo
Hi Udo,
klar hat das der TC_WindowRec noch nie gemacht. Und macht der jetzt auch nicht. Trigger ist der RHS.
Es funktioniert so:
Sendet ein Device einen Trigger (RHS,Remote,mdir,...) wir in dessen peerListe nachgesehen, wer diese empfangen soll. Jeder potentielle Empfänger bekommt ein Reading, dass ein Trigger an ihn versant wurde.
Steht also beim RHS der TC_WindowRec in der Liste wird dort der Trigger eingetragen.
Es ist also unabhängig vom TC_WindowRec. Der ist komplett passiv.
getestet habe ich mit einer "remote", nicht mit einem RHS. Da wäre schon ein unterschied, da hier eine message mit "parameter" kommt, bei einer remote nicht.
=> Du solltest bei ALLEN aktoren-channels ein entsprechendes "trig..." erhalten, wenn eine remote auslöst.
=> falls es bei allen remote geht, bei RHS aber nicht werde ich es noch einmal untersuchen
=> welche Version von CUL_HM hast du?
Du kannst einmal mit HMinfo nachsehen, ob es irgendwo steht:
set hm param -c trigLast
prüfe bitte noch einmal. Interessant wäre, ob der level korrekt mit kommt.
Zum Verfahren: Ich bin noch an überlegen, es etwas restriktiver zu machen - nur wenn das Device auch in der destination auftaucht... mal sehen.
Gruss Martin
Zitat=> Du solltest bei ALLEN aktoren-channels ein entsprechendes "trig..." erhalten, wenn eine remote auslöst.
Dann müsste ja auch im Stellantrieb ein trig... auftauchen, da der vom Climate gesteuert wird? Da ist auch nix zu sehen.
Zitat=> welche Version von CUL_HM hast du?
hatte ich doch oben schon geschrieben, die Version von gestern.
Zitatset hm param -c trigLast
param done:
param list
ok - klar.
das Problem war, dass dein RHS channel UND device in einer entity ist. Hatte ich nicht bedacht, sollte in 3462 gelöst sein.
der trigger wird/kann nicht in climate gemeldet werden, da der RHS mit winrec gepeert wird. Ansonsten könnte ich keine generelle Lösung anbieten.
Gruss Martin
Hallo Martin,
ich meinte auch nicht, dass der Climate von RHS getriggert wird, aber Du schriebst, dass das jede Sensor-Aktor Verbindung betrifft und eine solche gibt es ja auch zwischen Climate und dem Stellantrieb. Hat an sich nix mit RHS zu tun.
Viele Grüße
Udo
Zitat von: martinp876 schrieb am So, 21 Juli 2013 08:35das Problem war [...] sollte in 3462 gelöst sein.
na dann guck... fast super :)
(http://up.picr.de/15242606ym.png)
Lass bitte das Prozentzeichen weg. Erstens ist es völlig unsinnig bei diesen Werten, zweitens sieht 200% einfach doof aus und drittens bevorzuge ich Messwerte immer ohne Einheiten.
Der Wert bei trig_Melder_Balkon wird übrigens bei mir nicht automatisch aktualisiert, sondern erst nach einem "set <> statusRequest".
--------------------
edit:
wz_FHT_WindowRec { my $pos = ReadingsVal("wz_FHT_WindowRec","trigLast",""); (my $p1, my $p2) = split(":", $pos); ($p1, $p2) = split(/\ /,$p2); if($p1 == 0){fhem("attr wz_FHT_WindowRec stateFormat closed")} if($p1 == 100){fhem("attr wz_FHT_WindowRec stateFormat tilted")} if($p1 == 200){fhem("attr wz_FHT_WindowRec stateFormat open")} }ziemlich gruslig, aber es funktioniert :)
(http://up.picr.de/15243575fj.png)
Jetzt steht da wenigstens mal was Sinnvolles.
Danke!
ZitatLass bitte das Prozentzeichen weg.
na wo du recht hast...
nachdem es von unterschiedlichen Sensoren kommt kann ich die Einheit nicht fehlerfrei bestimmen. Beim RHS ist es übrigens % mal 2. Somit gibt es 0 %, 50%, 100%.
Aber beim MDIR kann ich nicht sagen, was es sein soll.
Da dein schöner Code für einige etwas komplex ist sehe ich schon, es sollte von der FHEM SW erledigt werden. Ich denke noch einmal...
ZitatDer Wert bei trig_Melder_Balkon wird übrigens bei mir nicht automatisch aktualisiert, sondern erst nach einem "set <> statusRequest".
das ist jetzt sehr seltsam. statusRequest ist ein CUL_HM kommando. Das Reading 'trig' wird nicht angefasst. Ein einfacher refresh im browser reicht nicht? bei mir schon.
Gruss Martin
Zitat von: martinp876 schrieb am So, 21 Juli 2013 13:53Das Reading 'trig' wird nicht angefasst. Ein einfacher refresh im browser reicht nicht?
Reicht meistens. Aber interessanterweise wird trigLast sofort und ohne refresh aktualisiert, trig_Melder_Balkon aber nicht. Könnte auch einfach ein Browserthema sein.
probier einmal 3465 - sollte die 'literals' selbst einsetzen. Konnte ich nicht komplett testen - überlasse ich dir :-)