Differenz-Temperatur-Sensor HM-WDS30-OT2-SM

[martinp876]

Hi,

was die beiden Channels machen, warum man sie peeren kann kann ich nicht sagen. Normal ist es zu etwas gut, wen HM sie vorsieht...
vielleicht kommen wir noch drauf.
kommt eine Antwort auf statusRequest oder ein NACK?

[cwagner]

Sorry, dieses Mal kam viel dazwischen - das mit dem Statusrequest werde ich noch überprüfen.

Die Verwirrung über abweichende Datenformate der Telegramme erledigt sich vielleicht mit diesen Zeilen aus einem ElvJOURNAL Artikel bei der Vorstellung des Gerätes:

Wird der Sensor direkt an eine Wetterstatfon angelernt,sendet er zyklisch ein Wettertelegramm an diese Station.
In dem Wettertelegramm ist lediglich Platz für eine Temperatur, weshalb hier die Differenztemperatur über-
tragen wird. Mit der Konfigurationsoberfläche der CCU oder eines Konfigurationsadapters kann aber auch eingestellt werden, dass stattdessen die
Temperatur des Sensors 1 oder 2 übertragen werden soll.
Durch das Anmelden des Sensors an eine Zentrale wird automatisch das zykLische Aussenden eines Messwerttelegramms
aktiviert. In diesem Telegrammtyp ist Platz für mehrere Temperaturwerte, er wird jedoch von
den bisherigen Wetterdatenempfängern wie der Wetterstation WDC7000 nicht unterstützt. Müssen beide Telegrammtypen gesendet werden, so
wechseln sich die beiden Typen bei jedem Sendeintervall ab. Um den Funk-Verkehr zu reduzieren und die Batterielebensdauer zu vergroßern, ist es
auch noch möglich, das Sendeintervall per Konfiguration zu verlängern.
..

Herzliche Grüße

Christian

[martinp876]

Hi Christian,
erst einmal bekommst du Register
burstRx         schaltet burst mode ein. Würde ich nicht empfehlen - device reagiert schneller, BAtterie eher leer
cyclicInfoMsgDis=ich denke, hier kann man die Frequenz des sendens einstellen. Musst du probieren
localResDis     =hmm ... abschaffung den lokalen Reset...
regL0_1b        = keine Ahnung, was das Register macht. Ist an dir zu testen oder nicht.

Setze expert mode auf 2 um alles zu sehen

Dann ist es auch mit den peers klar. Scheinbar kann der Sensor 2 Peers bedienen.
Wenn du einen peer eingetragen hast sollte man auch dessen einstellungen sehen koennen. Immerhin muss man festlegen koennen, was gesendet werden soll (nach Beschreibung).


Also erst einmal peeren (mit dummy reicht)
set <wds_Th1> peerChan 0 33333301 single set remote

dann schauen, was man lesen kann ( nach jedem einmal anlernen oder warten sonst wird der rest vorausführung gelöscht)
set <wds> raw ++A001F1123420BEDC00040000000001
set <wds> raw ++A001F1123420BEDC00043333330103
set <wds> raw ++A001F1123420BEDC00043333330104
set <wds> raw ++A001F1123420BEDC00043333330105


wahrscheinlich gibt es nur auf eine Nachricht eine Antwort.

Gruss Martin

[cwagner]

Moin, Martin,

im Einsatz: Deine 10_CUL_HM 3473

hier nun die gewünschten Ergebnisse: Ein statusrequest führt immer, auch nach frischen Neustart oder Anlernen des Device, zu einem "NACK"

Ansonsten: Im Status erscheint jetzt sauber jeweils CMDs_pending, CMDs_processing und bei Erfolg CMDs_Done


Ein getConfig führt über 3 Cmds_pending manchmal zu Response Timeout: PeerList; meistens aber zu CMDs_Done und RegL_00 ist gefüllt wie unten dokumentiert.

set CUL_HM_HM_WDS30_OT2_SM_20BEDC_Th_01 peerChan 0 33333301 single set remote
führt zu MISSING ACK


Deine Set-Befehle führten bei Register 1 zu NACK
Bei Register 3 zu NACK
Bei Register 4 zu einem timeout RegRead
Bei Register 5 zu NACK

spasseshalber habe ich auch an 2 und 6 Deine Sequenz geschickt: Response_Timeout RegisterRead bzw. NACK

Das Ergebnis in den Readings ist danach:
RegL_00: 01:00 02:01 0A:F1 0B:12 0C:34 11:00 18:00 1B:03 00:00               2013-07-23 05:50:54
RegL_01:
RegL_02:
RegL_03:33333301
RegL_04:33333301
RegL_05:
RegL_06:

Demnach funktionierte das Füllen der Register 3 und 4 mit dem Wert 33333301

Wie gehe ich mit den von Dir erwähnten Register burstRx, cyclicInfoMSgDis etc um? Im Web-Interface sehe ich die nicht.

Angehängt habe ich Ausschnitte aus dem Log für die Zeiten, wo ich gestern Abend und heute Morgen die Experimente gemacht habe.

Herzliche Grüße

Christian

[martinp876]

Hallo Christian,

es geht voran.

Das Peering hat prinzipiell funktioniert. Nur das nachträgliche Setzen eines Parameters geht schief.
Daher brauchen wir die noch die Register. Beim lesen wurde hier leider Channel 0 verwendet, mein Fehler.
Also testen wir alle Möglichkeiten (voraussichtlich klappt nur eines...)

set <wds> raw ++A001F1123420BEDC00140000000001
set <wds> raw ++A001F1123420BEDC00143333330103
set <wds> raw ++A001F1123420BEDC00143333330104
set <wds> raw ++A001F1123420BEDC00143333330105

Du solltest, wenn gepeert ist, schon ein Reading "temperatur" erhalten - Korrekt?

Ach so, schau, dass auch das File HMconfig upgedated ist. Dann werden die Register angezeigt, die wir schon kennen

Gruss Martin

[cwagner]

Moin, Martin,

im Einsatz: Deine 10_CUL_HM 3483
Deine HMInfo vom 23.7.

hier nun die gewünschten Ergebnisse: Ein statusrequest führt immer, auch nach frischen Neustart oder Anlernen des Device über CMDsProcessing zu einem "NACK"

set CUL_HM_HM_WDS30_OT2_SM_20BEDC_Th_01 peerChan 0 33333301 single set remote
führt zu MISSING ACK (lstMsg: No:B8 - t:02 s:20BEDC d:F11234 02), aber DANACH erscheint dann in den Readings "temperature". Dieser zeigt allerdings eine für mich zunächst nicht nachvollziehbaren Minus-Wert. Es ist NICHT eine der beiden Differenzen, es hat auch keinen Bezug auf die tatsächlichen beiden Fühlertemperaturen.
Val_temp_T1/2 geben die korrekten Fühlertemperaturen wieder, wie ich mit Eiswasser nochmals sicher überprüft habe.
Nach diesem peerChan haben wir im Status dann auch
T: -38,4 H:100 D:-38,4 (das D kommt von dem Modul Taupunkt, was alle Temperatur-Readings automatisch um den Taupunkt ergänzt. Die -38,4 ist die erwähnte falsche Temp) Der verwandte Sensor WDS30-T-O zeigt an dieser Stelle H:0, als 0% Luftfeuchtigkeit, weil er ja eigentlichen keinen Feuchtesensor hat.

R-burstRx ist wie Du vermutet hast off
R-cyclicInfoMsgDis ist 0, könnte das auch die in dem ELV-Artikel/Bauanleitung erwähnte Tatsache sein, dass nach Anlernen an eine Zentrale das automatische Umschalten zwischen den beiden Telegrammtypen, ausgeschaltet ist?
R-LocalResDis ist off
R-pairCentral gibt das aus, was auch PairedTo ausgibt (0XF11234)
R-regL0_1b gibt 3 aus   ??Sendezyklus für die Telegramme ist derzeit 3 Minuten????

Die Ergebnisse Deiner SET-Befehle:

set CUL_HM_HM_WDS30_OT2_SM_20BEDC raw ++A001F1123420BEDC00140000000001
führt zur lastmsg No:3A - t:70 s:20BEDC d:000000 7E8164

set CUL_HM_HM_WDS30_OT2_SM_20BEDC raw ++A001F1123420BEDC00143333330103
führt zu STatus NACK und lastmsg No:B0 - t:02 s:20BEDC d:F11234 00


set CUL_HM_HM_WDS30_OT2_SM_20BEDC raw ++A001F1123420BEDC00143333330104
führt zu Status MISSING ACK und lastmsg No:C1 - t:02 s:20BEDC d:F11234 00

set CUL_HM_HM_WDS30_OT2_SM_20BEDC raw ++A001F1123420BEDC00143333330105
führt zu Status Missing ACK und lastmsg No:44 - t:53 s:20BEDC d:000000 0041010142027E43FE8344017D

Übrigens: Die abgesetzten SET-Befehle scheinen wir immer so lange pending, bis das nächste Temperatur-Telegramm kommt.
Und: Hilft Dir eigentlich diese langatmige Beschreibung in Prosa, oder liest Du das und viel mehr sowieso in den Log-Ausschnitten?

Für Ausprobieren der R-Register müsste ich wahrscheinlich lernen, wie man den Raw-Befehl formuliert?

Herzliche Grüße

Christian

[martinp876]

Hallo Christian

ok, statusRequest geht nicht. Mal sehen, dass ich es aus der command Liste nehmen kann.

peerChan geht noch schief, also nicht richtig, braucht etwas tuning. Kommt, wenn ich die List4 kenne.
Reading temperatur ist laut anleitung einstellbar. Mal sehen - erst einmal nach den Einstellunge suchen. Hierzu sollte auch List4 helfen.

T: -38,4 H:100 D:-38,4
ist vom thermalDevice, muss für OT2 adaptiert werden.
OT2 liefert 3 Byte, diese werden aktuell einfach falsch interpretiert. Generell sollte das Format aber dem anderer Sensoren entsprechen, da alle ja an die gleiche Zentrale gepeert wreden könten

R-cyclicInfoMsgDis: koennte sein. Die InfoMsg geht an die Zentrale. Um es auszuschalten kannst du folgenden Werte testen:1,100,200. XML ist nicht klar, was 'true' ist
R-pairCentral/ PairedTo ist immer so. "PairedTo" sollte ich einmal entfernen, ist 'historich'.
R-regL0_1b gibt 3 aus ??Sendezyklus für die Telegramme ist derzeit 3 Minuten????
  kann ich mir nicht vorstellen. Minuten ist keine übliche Angabe bei HM. Kannst aber gerne probieren. Wenn/falls wir wissen, was es ist wird es einen odentlichen Namen geben
 
 
Übrigens: Die abgesetzten SET-Befehle scheinen wir immer so lange pending, bis das nächste Temperatur-Telegramm kommt.
ist klar. Dein Device kann config und wakeup. Auf eines der beiden muss ich warten. ok, man kann im Register Burst einschalten, dann sollte es auch burst (also immer ) empfangen können. Aber ich habe bislang nicht eingebaut, dass sich der Mode aendern kann. Nutzt also bislang nichts.

Für Ausprobieren der R-Register müsste ich wahrscheinlich lernen, wie man den Raw-Befehl formuliert?
Es sollten eigentlich alle Register durch regSet zu setzen können.

und wieder habe ich geschlampt. Die Kommandos, die ich brauche sind:
set <wds> raw ++A001F1123420BEDC01040000000001
set <wds> raw ++A001F1123420BEDC01043333330103
set <wds> raw ++A001F1123420BEDC01043333330104
set <wds> raw ++A001F1123420BEDC01043333330105

33333301 sollten immer noch in der peerIDs sichtbar sein.

Sorry, Gruß Martin

[cwagner]

Guten Morgen,
hier muss ich Dich enttäuschen. Mit dem update von gestern Mittag führten alle drei set-Befehle aus meiner Sicht zu Fehlermeldungen:
Response Timeout: registerRead für den 1.-3., für den 4. kam nach vergleichsweise sehr kurzem Processing "Nack". Beim zweiten Druchgang erntete ich auch beim 2. Set-Befehl ein NACK.
Jedes mal neu angelernt. Beide Kanäle sind geppert.

Set regraw führt zu einer Änderung der Anzeige der R-Register - allerdings kann ich erst am Wochenende das mal gründlicher beobachten.

Herzliche Grüße

[martinp876]

Hallo Christian,

in den Logs kann ich den test mit 01 und 04 finden, aber nicht mit 03 und 05.

03 ist unwahrscheinilch, aber in 05 setze ich noch Hoffnungen. In einer der Listen sollte(muss) eine konfiguration möglich sein.

Gruss Martin

[cwagner]

Hallo Martin,

das tut mir leid, vielleicht war ich hitzebedingt zu unkonzentriert. Deshalb habe ich es gestern Abend noch je zweimal mit 3 und 5 versucht. Anliegend das entsprechende log aus der Zeitspanne.
Bei 3 und 5 war das processing des CMDs dieses Mal einige Sekunden,doch dann gab es eben Timeout und in den Readings konnte ich keine Veränderung sehen. Aber vielleicht sagt Dir das Log mehr.

Weiterhin gutes Gelingen!


Christian

[martinp876]

Hallo Christian,

wir haben nicht viel Glück ;-)

es war das falsche Kommando,das aus dem älteren Versuch
Kannst du noch einmal

set <wds> raw ++A001F1123420BEDC01043333330103
set <wds> raw ++A001F1123420BEDC01043333330105

probieren? Das waren die 03 und 05 die ich gemeint hatte

Gruss Martin

[cwagner]

Guten Abend,
ups, da habe ich wohl meine Versionen nicht ordentlich beisammen gehabt. So habe ich Deinen Test gerade wiederholt:

19:55
3: RESPONSE TIMEOUT:RegisterRead 2013-07-26 19:57:29
5: RESPONSE TIMEOUT:RegisterRead 2013-07-26 20:04:48  
lastMsg No:5E - t:02 s:20BEDC d:F11234 00
20:06

Herzliche Grüße

Christian

[martinp876]

Hallo Christian,

der WDS hat auf keine der Anfragen geantwortet. Das erscheint nicht realistisch, ist aber Fakt.
Es muss noch irgendwo eine Einstellmöglichkeit geben.

Noch eine Frage: Der 33333301 ist schon noch gepeert? Nur dann wird der WDS auch Antworten. Kannst du dies noch einmal prüfen?
Wenn er nicht gepeert ist kannst du ihn noch einmal peeren und noch einmal probieren. Ansonsten bin ich am Ende, vielleicht kommt einmal ein neues xml mit Infos...

Gruss Martin

[cwagner]

Moin, Martin,
ich denke schon, sicherheitshalber hier die Listings:

CUL_0_MSGCNT 314
   CUL_0_RAWMSG A1621865320BEDC000000004100FA42022843FED244012EEF
   CUL_0_RSSI -82.5
   CUL_0_TIME 2013-07-27 08:15:02
   DEF        20BEDC
   EVENTS     312
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     314
   NAME       CUL_HM_HM_WDS30_OT2_SM_20BEDC
   NR         470
   STATE      CMDs_done_events:2
   TYPE       CUL_HM
   channel_01 CUL_HM_HM_WDS30_OT2_SM_20BEDC_Th_01
   channel_02 CUL_HM_HM_WDS30_OT2_SM_20BEDC_Th_02
   lastMsg    No:21 - t:53 s:20BEDC d:000000 004100FA42022843FED244012E
   protCmdDel 0
   protLastRcv 2013-07-27 08:15:02
   protResndFail 2 last_at:2013-07-26 20:04:48
   protSnd    8 last_at:2013-07-26 20:14:48
   protState  CMDs_done_events:2
   rssi_at_CUL_0 avg:-82.19 min:-99.5 max:-73 lst:-82.5 cnt:314
   Readings:
     2013-07-26 20:34:23   Activity        alive
     2013-07-26 20:14:47   CommandAccepted yes
     2013-07-26 20:14:48   PairedTo        0xF11234
     2013-07-26 20:14:48   R-burstRx       off
     2013-07-26 20:14:48   R-cyclicInfoMsgDis 0
     2013-07-26 20:14:48   R-intKeyVisib   invisib
     2013-07-26 20:14:48   R-localResDis   off
     2013-07-26 20:14:48   R-pairCentral   0xF11234
     2013-07-26 20:14:48   R-regL0_1b      3
     2013-07-26 20:14:48   RegL_00:          01:00 02:01 0A:F1 0B:12 0C:34 11:00 18:00 1B:03  00:00
     2013-07-27 08:15:02   Val_temp_T1     25.0
     2013-07-27 08:15:02   Val_temp_T1-T2  -30.2
     2013-07-27 08:15:02   Val_temp_T2     55.2
     2013-07-27 08:15:02   Val_temp_T2-T1  30.2
     2013-07-26 20:14:48   state           CMDs_done_events:2
   Helper:
     burstEvtCnt 2
     mId        00A8
     rxType     12
     Respwait:
     Role:
       dev        1
     Rssi:
       At_cul_0:
         avg        -82.1926751592356
         cnt        314
         lst        -82.5
         max        -73
         min        -99.5
     Shadowreg:
Attributes:
   actCycle   000:05
   actStatus  alive
   expert     2_full
   firmware   1.1
   model      HM-WDS30-OT2-SM
   peerIDs    00000000,
   room       InArbeit
   serialNr   KEQ0178415
   subType    THSensor
   userReadings temperature
   webCmd     getConfig

 DEF        20BEDC01
   NAME       CUL_HM_HM_WDS30_OT2_SM_20BEDC_Th_01
   NR         473
   STATE      ???
   TYPE       CUL_HM
   chanNo     01
   device     CUL_HM_HM_WDS30_OT2_SM_20BEDC
   Readings:
     2013-07-26 20:14:48   peerList        12345602,33333301,
   Helper:
     peerIDsRaw ,12345602,33333301,00000000
     Role:
       chn        1
Attributes:
   expert    
   model      HM-WDS30-OT2-SM
   peerIDs    00000000,12345602,33333301,
   room       CUL_HM

 DEF        20BEDC02
   NAME       CUL_HM_HM_WDS30_OT2_SM_20BEDC_Th_02
   NR         475
   STATE      ???
   TYPE       CUL_HM
   chanNo     02
   device     CUL_HM_HM_WDS30_OT2_SM_20BEDC
   Readings:
   Helper:
     peerIDsRaw ,00000000
     Role:
       chn        1
Attributes:
   expert    
   model      HM-WDS30-OT2-SM
   peerIDs    00000000,
   room       CUL_HM

Ist es ein Problem, dass Channel 2 nicht gepeert ist?

Ich mache gerne weitere Schritte, wenn Du noch eine Chance siehst.

Ein kleinen Tipp bräuchte ich auch noch: Wie setze ich das fhem.log wieder in die menschenlesbare Form zurück? Ich hatte ja drei Parameter auf Deinen wusnch gesetzt, von denen ich die Parameter von nur einem verstanden hatte (verbose)

Herzliche Grüße

Christian

[martinp876]

Hallo Christian,

also erst einmal stop: ich habe ein neues XML gefunden, mit Infos zu OT2 (und mehr)

Ich arbeite das einmal ein. Der OT2 hat hier 5!!! channels, 4 gleiche und einen separaten (channel 5).
Die Auswahl ob t1,t2,t1-t2,... ist in '1B' zu finden, werden ich also entsprechend einbauen.

Rücksetzen:
lösche attr global mseclog
lösche attr hmlan loglevel
setze attr global verbose 3

wenn die neue SW da ist könntest du noch einmal mit dem Device spielen. Unter anderen testen, welche Channels sich peeren lassen und was passiert, wenn sie gepeert sind.
Einbauen will ich es heute noch - mit dem nächsten Update ist in jedem Fall eine Aenderung drin

Gruss Martin