Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[vbs]

Ok, habe das mit dem Wissen nochmal getestet. Vorab: getConfig läuft ohne Fehler durch, wenn ich den Taster später nochmals drücke.

Bei mir ist das so:

• in FHEM getConfig machen (führt zu 2 CMDs_pending)
• Taster am Sensor betätigen
• LED blinkt kurz wild und das "2 CMDs_pending" verschwindet. Jedoch bleibt "protState CMDs_processing..." stehen
• Wenn ich jetzt nichts weiter mache, dann steigt protResnd nach und nach um 3 an und resultiert dann in protResndFail

Wenn ich nach Punkt 3 jedoch nochmal den Taster drücke, dann hört das protResnd auf und es erscheint auch kein protResndFail und protState wechselt auf "CMDs_done". Also ich muss im Endeffekt zweimal den Taster drücken bei getConfig.

[frank]

Also ich muss im Endeffekt zweimal den Taster drücken bei getConfig.

bei mir auch. das muss aber neu sein.

[Dirk]

bei mir auch. das muss aber neu sein.

Ja, das hab ich letztens auch festgestellt. Der Sensor wartet wohl nicht so lange bis alle Configtelegramme abgearbeitet wurden und geht schon mal schlafen.

[frank]

Ja, das hab ich letztens auch festgestellt. Der Sensor wartet wohl nicht so lange bis alle Configtelegramme abgearbeitet wurden und geht schon mal schlafen.

aber ist er dann nicht falsch in cul_hm konfiguriert? wenn er als config-device läuft, müssten die cmds doch pending bleiben, bis man wieder den configtaster drückt. wenn man jetzt aber nur einmal drückt, versucht fhem rücksichtslos das command zu senden. erfolg ist cmds_error.

[Dirk]

Ich weis nicht genau wie das in cul_hm geregelt ist. In der ccu bleibt die Info "Konfigdaten stehen zur Übertragungan" so lange stehen bis alles übertragen wurde.

[frank]

nach meinem verständnis mit dem rxt-type.

Code Auswählen Erweitern

#rxt - receivetype of the device------
# l: receive on lazy config - no idea how this works so far.....
# c: receive on config
# w: receive in wakeup
# b: receive on burst
# f: receive on burst if enabled


Code Auswählen Erweitern

$HMConfig::culHmModel{'F101'} = {name => 'HB-UW-Sen-THPL-I', st => 'THPLSensor', cyc => '00:10', rxt => 'c:f', lst  => 'p',   chn  => '',};
$HMConfig::culHmModel{'F102'} = {name => 'HB-UW-Sen-THPL-O', st => 'THPLSensor', cyc => '00:10', rxt => 'c:f', lst  => 'p',   chn  => '',};


vielleicht hat die burst option "f" ein eigenleben? oder man müsste hier etwas ändern?

Code Auswählen Erweitern

$HMConfig::culHmRegModel{'HB-UW-Sen-THPL-I'} = {
'burstRx'         => 1,


[Dirk]

nach meinem verständnis mit dem rxt-type.

Code Auswählen Erweitern

#rxt - receivetype of the device------
# l: receive on lazy config - no idea how this works so far.....
# c: receive on config
# w: receive in wakeup
# b: receive on burst
# f: receive on burst if enabled


Ich habe hier in meiner pm-datei "l" schon mal eingebaut. das hat aber noch nicht so richtig funktioniert. Daher ist das so noch nicht im repo.
Ich habe aber mal einchecken. Ist im master.

[hglaser]

Hallo allerseits

Ich habe heute auf die neue Version upgedated und es ging auf Anhieb
Es tut mir jetzt schon fast leid, so eine triviale Frage hier dazwischen zu drücken aber ich glaub es ist ein Bug, oder besser ein buggelchen.

Code Auswählen Erweitern

   Readings:
     2015-03-05 22:07:33   Activity        alive
     2015-03-05 22:07:33   CommandAccepted yes
     2015-03-05 22:07:33   D-firmware      0.14
     2015-03-05 22:07:33   D-serialNr      UWS5439349
     2015-03-05 22:07:34   PairedTo        0x23A776
     2015-03-05 22:07:34   R-altitude      645 m
     2015-03-05 22:05:58   R-burstRx       off
     2015-03-05 22:05:58   R-ledMode       on
     2015-03-05 22:05:58   R-lowBatLimitTHPL 1.6 V
     2015-03-05 22:05:58   R-pairCentral   0x23A776
     2015-03-05 22:05:58   R-transmDevTryMax 3
     2015-03-05 22:07:34   RegL_00:          01:00 05:64 0A:23 0B:A7 0C:76 12:10 14:03 24:02  25:85 00:00
     2015-03-05 22:12:09   batVoltage      3.10
     2015-03-05 22:12:09   battery         ok
     2015-03-05 22:12:09   dewpoint        8.0
     2015-03-05 22:12:09   humidity        36
     2015-03-05 22:12:09   luminosity      4.33
     2015-03-05 22:12:09   pressure        1030.6
     2015-03-05 22:07:08   pressure-nn     1030.7
     2015-03-05 22:05:57   recentStateType info
     2015-03-05 22:12:09   state           T: 24.0 H: 36 L: 4.33 P: 1030.6
     2015-03-05 22:12:09   temperature     24.0
pressure ist 1030,6 und über NNull nur um 0,1 mehr? Ich habe die Höhe von 645 Metern angegeben. Laut Wetterbericht ist der wert über NN 1035 hPa. Dieser Wert wüde also passen. Aber der berechnete Wert müsste so um 1120 hPa liegen.

lg Harald

[Dirk]

@ Mr. P

Hast du schon eine Idee, wie die Syncproblematik bei gepeerten Thermostaten in den Griff zu bekommen ist? Zur Zeit sind sie die meiste Zeit out-of-sync (und finden sich dann immer wieder für kurze Zeit über den Tag verteilt).

Ich habe da noch eine Idee:
hast du zufällig einen Sensor mit Helligkeitssensor mit dem Thermostat gepeert?
Kannst du da ggf. zu den Syncproblemen eine Verbindung zur Helligkeit erkennen?
Denn, wenn es hell ist, dann braucht der Helligkeitssensor ca. 500ms um den Messwert zu sampeln. wenn es dunkel ist braucht der nur um die 230ms.

Gruß
Dirk

[Dirk]

pressure ist 1030,6 und über NNull nur um 0,1 mehr? Ich habe die Höhe von 645 Metern angegeben. Laut Wetterbericht ist der wert über NN 1035 hPa. Dieser Wert wüde also passen. Aber der berechnete Wert müsste so um 1120 hPa liegen.

Ich glaube hier liegt eine Kollission mit der Höhe in FHEM vor.
Schau mal ob du in FHEM das globale Attribute altitude gesetzt hast.
Die Höhe im Sensor hatte ich bisher hauptsächlich für CCU-User gedacht, da dort nicht so einfach der reduzierte Luftruck berechnet werden kann.
Bei FHEM braucht du das Register "R-altitude" also nicht setzen. Die Berechnung macht FHEM dann.
Ich werde in das Modul aber noch einbauen, dass die Höhe von FHEM nicht benutzt wird, wenn R-altitude im Sensor gesetzt ist.

Gruß
Dirk

[Mr. P]

@ Mr. PIch habe da noch eine Idee:
hast du zufällig einen Sensor mit Helligkeitssensor mit dem Thermostat gepeert?
Kannst du da ggf. zu den Syncproblemen eine Verbindung zur Helligkeit erkennen?
Denn, wenn es hell ist, dann braucht der Helligkeitssensor ca. 500ms um den Messwert zu sampeln. wenn es dunkel ist braucht der nur um die 230ms.

Hej Dirk,
zufällig sind alle meine gepeerten Sensoren mit einem Helligkeitssensor ausgestattet (alles 03er-Modelle).
Ich werde einmal schnell einen Tagesplot generieren, wo man Temperatur- & Helligkeit vom Sensor plus die Temperatur vom gepeerten RT vergleichen kann.

Edit:
Und da ist auch schon das passende Plot-File von gestern. Allzu viel Zusammenspiel zwischen Helligkeit und vorkommenden Temperaturschwankungen kann ich allerdings leider nicht erkennen.

[hglaser]

Hallo Dirk

Ich glaube hier liegt eine Kollission mit der Höhe in FHEM vor.
Schau mal ob du in FHEM das globale Attribute altitude gesetzt hast.

Ja genau so ist es. Ich hab natürlich die altitude in FHEM gesetzt. Register gelöscht und schon gehts.

lg Harald

[HoTi]

Hallo zusammen,

ich habe da mal eine Frage dazu, bitte nicht schlagen aber 105 seiten Lesen fehlt mir dann doch die Zeit.

Ist der Innen sensor mit dem    HM-CC-RT-DN koppelbar. Also als Temperatursensor?

[Adam]

Hallo zusammen,

ich habe da auch noch mal ne Frage zum flashen, ich habe einen Sensor mit OTA-Bootloader,
habe aber kein HM-USB Adapter.

Ich habe einen HM-LAN Adapter und auch einen CUL, den ich nutzen könnte.
Kann man mittels CUL flashen ?? Und wenn ja, welches Programm muss ich dazu nutzen?

Danke
Adam

[Mr. P]

Ja, mit dem CUL kannst du flashen.
Und egal ob mit dem hm-cfg-usb oder dem cul: in beiden Fällen ist flash-ota die Antwort.