HM-CC-RT-DN

[juelich]

Das ist schon der ClimRT_tr-Register. Wirst du vermutlich nur umbenannt haben.

Aber du hast schon recht, sieht alles recht ordentlich aus. Was ich natürlich nicht weiß, ist das zusätzliche Detail, das du gerade verraten hast. Das alle RTs miteinander gepeert sind. Vielleicht liegt da das Problem.
Hast du die Geräte direkt untereinander gepeert oder es über FHEM realisiert?

Ich habe die Geräte alle (jedes mit jedem) untereiander gepeert, mit FHEM fiunktionierte das nicht so ganz (siehe irgendwo in diesem Megathread). Denke auch, das da irgendwo das Problem liegt (beispielsweise: 1 RT erkennt "Fenster auf", schaltet auf 5°C, meldet dies den Peers und diese senden eventuell die 5°C als desired Temp an alle Peers zurück. So wäre so ungefähr mein Erklärungsversuch.
Kann man die RTs eigentlich nachträglich auslesen, d.h. bekommt man raus, wann diese Temperatur gesetzt wurde und ob dabei WinOpen erkannt wurde? Das Ganze lief ja nicht FHEM, deshalb ist das Log da ja auch leer...


Viele Grüße

Markus

[Rohan]

Hallo Markus,

lies mal 1 Post über deinem. Martin(p876) hat da Änderungen vorgenommen, die bei normalem Update ab Morgen genutzt werden können und dein Problem evtl. lösen helfen

Gruß
Thomas

Edit: Nickname korrigiert und ein "n" gekauft

[martinp876]

Die aktuellen temp eines RT kann nicht gelesen werden, wird aber regelmässig vom RT freiwillig gemeldet. Der unterschied ist, dass es in FHEM zeitverzögert eingetraben wird.
der RT (wie der TC) melden NICHT wenn sie im Fenster-offen-mode sind. Wird ein externen SC genutzt und sind die peer-listen komplett wird FHEM einen entsprechenden Eintrag in die Readings machen, dass ein Trigger dieses Sensors gekommen ist. Mehr ist nicht möglich (meines Wissens)

Gruss Martin

[snoop]

Hallo Martin,

Anmerkungen / offene (Verständnis-)Fragen zum Thema "winOpnTemp":

- Fehler beim schreiben: "cannot calculate value. Please issue set <rt_WindowRec> getConfig first - invalid". Ein "getConfig" - auf beiden Seiten (RHS bereits gpeert - vor dem Update) als auch RT brachte kein Erfolg. Was mache ich falsch?
- wie kommst du auf "tempWinOpen" wenn das Resgister "winOpnTemp" heißt? ;o) (Sowohl init als auch bei peer) - ok meine Idee, 1st (Verständliche-Schreibweise) 2nd (Technische-Schreibweise) - will sagen -> irritierend ;o).
- Verständnisfrage:
   - Sensor 1 (Terrasse) geppert mit RT1
   - Sensor 2 (kleines Fenster) geppert mit RT1
"winOpnTemp" kann nicht separat definiert werden richtig?
Hier das Motto: Fenster auf dann alles auf peer "winOpnTemp" SC/RHCs egal welches(wieviele) peer(s) - RICHTIG? Falls Antwort = "ja" dann verstehe ich dises "peer"-winOpnTemp Konstrukt nicht.
- winOpnTemp-int wenn dies die interne "Fenster 'auf'" Erkennung ist was hat das mit dem WindowRec zu tun - will sagen -> weg lassen und in "clima" lassen - so gibt es eine klare Zuordnung. Oder? Was war deine Idee?
Viele Grüße
Arthur

EDIT: command 'set <rt_WindowRec> regSet winOpnTemp 10'

[Kruemel]

Zeig doch mal bitte, welche Versionen du von den zuständigen Versionen auf deinem System hast.

Code Auswählen Erweitern

version HMLAN
version CUL_HM

Hallo, hier meine Versionen
# $Id: 00_HMLAN.pm 4232 2013-11-16 14:00:26Z martinp876 $
# $Id: 10_CUL_HM.pm 4232 2013-11-16 14:00:26Z martinp876 $
Gruß
Wolfgang

[Mr. P]

ich habe einen HM-CC-RT-DN bei fhem angelernt.

Und du bist dir sicher, dass FHEM deinen RT nicht nur erkannt und die Channels per Autocreate erstellt hat, sondern du ihn auch wirklich gepairt hast?

Also am Display des RT erscheint das Antennensymbol und auch in FHEM steht er als mit FHEM gepairt?

Postest du bitte mal den Output von:

Code Auswählen Erweitern

list CUL_HM_HM_CC_RT_DN_223378

Thx a lot!

[Kruemel]

Und du bist dir sicher, dass FHEM deinen RT nicht nur erkannt und die Channels per Autocreate erstellt hat, sondern du ihn auch wirklich gepairt hast?

Also am Display des RT erscheint das Antennensymbol und auch in FHEM steht er als mit FHEM gepairt?

Postest du bitte mal den Output von:

Code Auswählen Erweitern

list CUL_HM_HM_CC_RT_DN_223378

Thx a lot!

Hallo Mr.P.,

erstmal Danke für die schnellen Antworten.
Hier das Listing.

Zeigt diese Zeile das Pairing an?
2013-11-19 23:45:57   R-pairCentral   0x123ABC
     
Das MissingACK irritiert mich etwas, es war nicht immer da.

Es gibt doch auch eine Firmware im Thermostaten? Wie zeigt man sich diese Version an? Wie macht man hier ein Update?

Ich habe im Thread gelesen das Martin eine neue Version rausgegeben hat. Habe überlegt diese upzudaten, mich aber entschieden zu warten, bis du dich wieder gemeldet hast.

Vielen Dank.
Gruß
Wolfgang

Internals:
   DEF        223378
   EVENTS     2099
   HMLAN1_MSGCNT 2118
   HMLAN1_RAWMSG E223378,0000,6E1490DD,FF,FFA7,2086102233780000000A9CE410002B
   HMLAN1_RSSI -89
   HMLAN1_TIME 2013-11-22 07:51:40
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     2118
   NAME       CUL_HM_HM_CC_RT_DN_223378
   NR         407
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_CC_RT_DN_223378_Weather
   channel_02 CUL_HM_HM_CC_RT_DN_223378_Climate
   channel_03 CUL_HM_HM_CC_RT_DN_223378_WindowRec
   channel_04 CUL_HM_HM_CC_RT_DN_223378_ClimRT_tr
   channel_05 CUL_HM_HM_CC_RT_DN_223378_ClimRT_r
   channel_06 CUL_HM_HM_CC_RT_DN_223378_rCtrl
   lastMsg    No:20 - t:10 s:223378 d:000000 0A9CE410002B
   protCmdDel 14
   protLastRcv 2013-11-22 07:51:40
   protNack   1 last_at:2013-11-19 22:04:15
   protResnd  27 last_at:2013-11-19 23:46:13
   protResndFail 10 last_at:2013-11-19 23:46:17
   protSnd    223 last_at:2013-11-19 23:46:05
   protState  CMDs_done_events:9
   rssi_at_HMLAN1 avg:-77.94 min:-102 max:-72 lst:-89 cnt:2118
   Readings:
     2013-11-19 23:45:56   CommandAccepted yes
     2013-11-19 23:45:57   PairedTo        0x123ABC
     2013-11-19 23:45:57   R-backOnTime    10 s
     2013-11-19 23:45:57   R-btnLock       unlock
     2013-11-19 23:45:57   R-burstRx       off
     2013-11-19 23:45:57   R-cyclicInfoMsg on
     2013-11-19 23:45:57   R-cyclicInfoMsgDis 0
     2013-11-19 23:45:57   R-globalBtnLock off
     2013-11-19 23:45:57   R-intKeyVisib   invisib
     2013-11-19 23:45:57   R-localResDis   off
     2013-11-19 23:45:57   R-lowBatLimitRT 2.1 V
     2013-11-19 23:45:57   R-modusBtnLock  off
     2013-11-19 23:45:57   R-pairCentral   0x123ABC
     2013-11-19 23:45:57   RegL_00:          01:00 02:01 09:01 0A:12 0B:3A 0C:BC 0E:0A 0F:00  11:00 12:15 16:00 18:00 19:00 1A:00 00:00
     2013-11-22 07:51:40   noReceiver      src:223378 8610 0A9CE410002B
     2013-11-19 23:46:17   state           MISSING ACK
   Helper:
     burstEvtCnt 9
     mId        0095
     rxType     12
     Respwait:
     Role:
       dev        1
     Rssi:
       At_hmlan1:
         avg        -77.948536355052
         cnt        2118
         lst        -89
         max        -72
         min        -102
     Shadowreg:
Attributes:
   expert     2_full
   firmware   1.0
   model      HM-CC-RT-DN
   peerIDs   
   room       CUL_HM
   serialNr   KEQ0517369
   subType    thermostat

[Rohan]

Hallo Wolfgang,

sieht nach einem korrekt durchgeführten Pairing aus. Aber deine RSSI-Werte von bis zu -102 erscheinen mir doch sehr niedrig. Vlt. führt das zu den Kommunikationsstörungen? Und deine Firmwareversion im RT ist 1.0 (steht auch da ). Update kann nur von eQ-3/ELV durchgeführt werden (so es eine neue gibt?). Dafür musst du den RT dann einschicken.

Gruß
Thomas

[Mr. P]

sieht nach einem korrekt durchgeführten Pairing aus. Aber deine RSSI-Werte von bis zu -102 erscheinen mir doch sehr niedrig. Vlt. führt das zu den Kommunikationsstörungen? Und deine Firmwareversion im RT ist 1.0 (steht auch da ). Update kann nur von eQ-3/ELV durchgeführt werden (so es eine neue gibt?). Dafür musst du den RT dann einschicken.

Hej ihr beiden,

also bezüglich Firmwareversion und RSSI-Werte kann ich Rohan nur recht geben. Firmwareversion steht in den Attributen und RSSI ist wirklich schwach. Versuche doch einmal zum Testen den Thermostat und den Sender ein wenig näher aneinander zu bringen, dass du Werte von max. -80 (besser -70) zusammen bekommst.
Nur was die Sache mit dem Firmwareupdate anbelangt, glaube ich, dass Rohan daneben liegt. Wenn ich das jetzt nicht falsch im Hinterkopf habe, Ist der RT doch die erste Komponente, die der User selbst updaten können sollte (bitte korrigiert, aber steinigt mich nicht, wenn ich mich irre). Aber so oder so, von einer neueren Version als der 1.0 ist mir bislang nichts bekannt.
Interessieren würden mich auch die Rohdaten, die du bei der Kommunikation bekommst. Da wären Verbindungsabbrüche auch recht gut erkennbar. Wäre toll, wenn du uns diese noch zur Verfügung stellen könntest.
Kleine Anmerkung noch am Rande: In den neuesten Versionen funktioniert das Logging jetzt etwas anders - bitte beachten, solltest du bereits eine solche Version haben.

Edit: Hier noch der Link zu den neuen Logparametern:
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848

[Rohan]

Hi,

... Nur was die Sache mit dem Firmwareupdate anbelangt, glaube ich, dass Rohan daneben liegt. Wenn ich das jetzt nicht falsch im Hinterkopf habe, Ist der RT doch die erste Komponente, die der User selbst updaten können sollte (bitte korrigiert, aber steinigt mich nicht, wenn ich mich irre). ...

Gerade mal Manual gelesen Dort steht in der Beschreibung der Status-/Fehlermeldungen:

Code Auswählen Erweitern


CRC - CRC-Fehler nachFirmwareupdate - Firmwareupdate erneut durchführen
FUP - Firmwareupdate wird durchgeführt - /


Sieht also so aus, wie du es geschrieben hast 

Gruß
Thomas

[martinp876]

Hallo Arthur

- Fehler beim schreiben: "cannot calculate value. Please issue set <rt_WindowRec> getConfig first - invalid".

Ein
set rt_WindowRec getConfig
oder
set rt getConfig

sollte das Problem lösen.
Natürlich musst du das Kommando absetzen UND ausführen. Also mittels burst (so enabled) oder warte, bis der RT aufgewacht ist, und es abgeholt hat.
Du solltest dann sehen, dass
- im rt keine Kommandos "pending" sind
- im rt_WindowRec die peers zu sehen sind.

ein getConfig auf den RHS ist nicht notwendig.

- wie kommst du auf "tempWinOpen" wenn das Resgister "winOpnTemp" heißt? ;o) (Sowohl init als auch bei peer) - ok meine Idee, 1st (Verständliche-Schreibweise) 2nd (Technische-Schreibweise) - will sagen -> irritierend ;o).

tempWinOpen ist es beim TC, winOpnTemp beim RT. Habe ich es irgendwo vertauscht? Wo?

- Verständnisfrage:
   - Sensor 1 (Terrasse) geppert mit RT1
   - Sensor 2 (kleines Fenster) geppert mit RT1
"winOpnTemp" kann nicht separat definiert werden richtig?

ja, kannst du.

Fenster auf dann alles auf peer "winOpnTemp" SC/RHCs egal welches(wieviele) peer(s) - RICHTIG?

falsch

- winOpnTemp-int wenn dies die interne "Fenster 'auf'" Erkennung ist was hat das mit dem WindowRec zu tun - will sagen -> weg lassen und in "clima" lassen - so gibt es eine klare Zuordnung.

das Register winOpnTemp-int ist in "Clima". Daher auch kein "R-" prefix.
Der Gedanke ist, dass im WindowRec die daten des Fenster-offen sichtbar sind. Das betrifft alle 5 "interneFenster register".
Zumindest sollte man sehen, und es einem Auffallen, dass ein interner Fenster-erkenner AUCH aktiv ist, oder eben nicht. Die Daten gehören dann dazu.
Die Idee ist, Daten eines Themas in einem Kontext darzustellen.

EDIT: command 'set <rt_WindowRec> regSet winOpnTemp 10'

wo ist den dein peer? regSet für peer-related-register ist

set <rt_WindowRec> regSet winOpnTemp 10 <peer>

die SW kann den peer "" auch nach getConfig nicht finden

Interessant wird es übrigens, wenn du 4 Fenster hast, alle mit verschiedenen Temperaturen, und diese dann abwechselnd auf und zu machst. Ob der RT das sauber abarbeitet?

Achtung: ich habe gerade einen Bug bei burstXmit (hoffentlich) behoben V4258

Gruss Martin

[Rohan]

... tempWinOpen ist es beim TC, winOpnTemp beim RT. Habe ich es irgendwo vertauscht? Wo? ...

Stand auch im Wiki so (falscher Registername und fehlender Peer) verkehrt drin. Ist korrigiert.

Gruß
Thomas

[snoop]

Hallo Martin,

Ein
set rt_WindowRec getConfig
oder
set rt getConfig

sollte das Problem lösen.
Natürlich musst du das Kommando absetzen UND ausführen. Also mittels burst (so enabled) oder warte, bis der RT aufgewacht ist, und es abgeholt hat.
Du solltest dann sehen, dass
- im rt keine Kommandos "pending" sind
- im rt_WindowRec die peers zu sehen sind.

ein getConfig auf den RHS ist nicht notwendig.

- getConfig auf Device inkl.  pendings abgearbeitet -> sollte damit sauber sein. Die peers sehe ich auch -> ich habe offensichtlich (noch nciht getestet) einen Fehler beim regSet gemacht - ich versuche später mal wie von dir vorgeschlagen mit

Code Auswählen Erweitern

set <rt_WindowRec> regSet winOpnTemp 10 <peer>

das Register winOpnTemp-int ist in "Clima". Daher auch kein "R-" prefix.
Der Gedanke ist, dass im WindowRec die daten des Fenster-offen sichtbar sind. Das betrifft alle 5 "interneFenster register".
Zumindest sollte man sehen, und es einem Auffallen, dass ein interner Fenster-erkenner AUCH aktiv ist, oder eben nicht. Die Daten gehören dann dazu.
Die Idee ist, Daten eines Themas in einem Kontext darzustellen.

Hmmm ja ok verstanden.

wo ist den dein peer? regSet für peer-related-register ist

set <rt_WindowRec> regSet winOpnTemp 10 <peer>

die SW kann den peer "" auch nach getConfig nicht finden

Ja das wird wohl der (mein) Fehler sein -> Test folgt.

Interessant wird es übrigens, wenn du 4 Fenster hast, alle mit verschiedenen Temperaturen, und diese dann abwechselnd auf und zu machst. Ob der RT das sauber abarbeitet?

Ja, darauf will ich hinaus - Tests (zwar nur mit zwei Fenstersensoren) folgen.

Achtung: ich habe gerade einen Bug bei burstXmit (hoffentlich) behoben V4258

Danke für den Hinweis.

Danke und Viele Grüße
Arthur

[snoop]

Hallo Thomas,
danke für die Anpassung.
In der ersten Fassung hatte ich das hier eingetragen:

Code Auswählen Erweitern

set <tc_WindowRec> regSet tempWinOpen 23 <SensorFensterLinks>
und war offensichtlich auch korrekt ;o)

Anmerkung/Vorschlag für den Wiki Eintrag:

Code Auswählen Erweitern

set <tc_WindowRec> regSet tempWinOpen 10 <SensorFenster>
?
Viele Grüße
Arthur

[Rohan]

Hallo Arthur,

... Anmerkung/Vorschlag für den Wiki Eintrag:

Code Auswählen Erweitern

set <tc_WindowRec> regSet tempWinOpen 10 <SensorFenster>
? ...

Jetzt bin ich etwas verwirrt.

Laut Martin (martinp876) soll es heißen beim HM-CC-RT-DN:

Code Auswählen Erweitern

set <rt_WindowRec> regSet winOpnTemp 10 <peer>

Wir sollten beim HM-CC-RT-DN nicht von "tc_WindowRec" schreiben und beim HM-CC-RT-DN heißt das Register wohl "winOpnTemp", wohingegen es beim HM-CC-TC "tempWinOpen" lautet.

Oder liege ich da jetzt komplett daneben?

Gruß
Thomas