Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[Prof. Dr. Peter Henning]

Das Datenblatt habe ich vorher schon angesehen - der Sensor nimmt einfach ein thermisches Spektrum an.

Vielleicht reden wir aneinander vorbei, mein Punkt ist nämlich nur: Wenn Du einen Filter unbekannter spektraler Charakteristik davorsetzt, kann das beliebig daneben gehen.

LG

pah

[Dirk]

Wenn Du einen Filter unbekannter spektraler Charakteristik davorsetzt, kann das beliebig daneben gehen.

Das ist klar.
Daher ist die Idee: eine Weile einen "nackten" Sensor neben einen mit "Filter" zu legen und beide Kurven dann zur Korrektur heran zu ziehen. Es sei denn die Werte des Sensors mit "Filter" verhalten sich annähernd liniar. Was vermutlich nicht der Fall sein wird. Mal sehen Die Tage werde ich mal einen Versuch starten

Gruß
Dirk

[PeMue]

Hallo Dirk,

welches Referenzgerät nimmst Du für die Helligkeit?

Gruß PeMue

[Dirk]

welches Referenzgerät nimmst Du für die Helligkeit?

Bitte nicht übertreiben

Ich glaube nicht das dieses Teil die Bezeichnung "Referenzgerät" verdient hat.
http://www.pollin.de/shop/dt/NDA3OTYxOTk-/Messtechnik_Uhren/Messtechnik/Multimeter/Digital_Luxmeter_MASTECH_MS6610.html

Aber ich kann somit bestimmen dass ich keinen absoluten "Mist messe".

Gruß
Dirk

[betateilchen]

HMConfig hat eigentlich keinen Code - somit werde ich das Lesen weiterer files in CUL_HM implementieren. Macht mehr Sinn, meine ich.

Seit dem heutigen Update von 10_CUL_HM.pm und HMConfig.pm funktioniert der Sensor nicht mehr. Und er scheint als "virtual Actor" geführt zu werden, weil ich plötzlich ein "set <name> virtual <n>" angeboten bekomme.

[betateilchen]

Nachtrag:

HMConfig hat eigentlich keinen Code - somit werde ich das Lesen weiterer files in CUL_HM implementieren. Macht mehr Sinn, meine ich.

Offenbar nicht...

Wenn ich das Nachladen der HMConfig_Zusatzmodule in der aktuellen 10_CUL_HM.pm komplett auskommentiere und wieder in die HMConfig.pm verlege, funktioniert alles einwandfrei.

[martinp876]

könnt ihr einmal das HMConfig_ posten? Hätte gleich danach fragen sollen...

[Dirk]

Hi Martin,

die letzte Version ist hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/FHEM/HMConfig_SenTHPL.pm

Gruß
Dirk

[betateilchen]

(http://up.picr.de/18010586lh.png)

Sieht gut aus (ok, Firmwareupdate fehlt noch)

Die Idee mit dem HB-Präfix finde ich übrigens sehr gut, auch deshalb, weil die Markenbezeichnung "HomeMatic" geschützt ist.

Ach, und HB ist wohl KEINE geschützte Markenbezeichnung   

[Dirk]

Firmware und Flash-Tool sind hier:
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/Firmware/Flash-Tool-Windows.zip?raw=true
Es gibt jetzt 2 Versionen der Firmware. einmal für den Innensensor (HB-UW-Sen-THPL-I) und einmal für den Außensensor (HB-UW-Sen-THPL-0).
Hier ist aber nur die Device-ID unterschiedlich welche bei der CCU für das andere Bildchen sorgt.
Bitte mit der neuen Version das neue Flas-Tool beutzen, da ich die Default-ID und Seriennummer generischer gestaltet habe.

Das Addon für die CCU ist hier:
https://github.com/kc-GitHub/Wettersensor/blob/master/Tools/CCU/HB-UW-Sen-THPL_CCU-addon.tgz?raw=true
Bitte vorher eine Backup machen, da ich das noch nicht zu Hause an der "echten" CCU testen konnte.
Das sollte auf CCU1 und CCU2 und unabhängig von der Firmwareversion funktonieren.

Ich habe das Helligkeits-Reading von Lux nach Luminosity geändert, da der wert in Lux nur stimmt, wenn das Licht ungefiltert auf den Sensor fällt. Ansonsten muss man das entsprechend umrechnen.

Gruß
Dirk

[betateilchen]

Die 0.8 für den Aussensensor sendet bei mir keine Daten.

Ich habe den Sensor komplett aus meinem fhem gelöscht und dann ein neues Pairing durchgeführt.

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        6FB75D
   IODev      wz_HMUSB
   LASTInputDev wz_HMUSB
   MSGCNT     13
   NAME       CUL_HM_HB_UW_Sen_THPL_O_6FB75D
   NR         272
   STATE      ???
   TYPE       CUL_HM
   az_HMUSB_MSGCNT 5
   az_HMUSB_RAWMSG E6FB75D,0000,07D92A77,FF,FFB8,05A0106FB75D1270000100000000
   az_HMUSB_RSSI -72
   az_HMUSB_TIME 2014-04-19 12:46:07
   lastMsg    No:05 - t:10 s:6FB75D d:127000 0100000000
   protLastRcv 2014-04-19 12:46:07
   protSnd    9 last_at:2014-04-19 12:46:07
   protState  CMDs_done
   rssi_at_az_HMUSB avg:-69.8 min:-72 max:-66 lst:-72 cnt:5
   rssi_at_wz_HMUSB avg:-43.5 min:-44 max:-40 lst:-44 cnt:8
   wz_HMUSB_MSGCNT 8
   wz_HMUSB_RAWMSG R7997E0E2,0001,0233F226,FF,FFD4,05A0106FB75D1270000100000000
   wz_HMUSB_RSSI -44
   wz_HMUSB_TIME 2014-04-19 12:46:07
   Readings:
     2014-04-19 12:46:09   Activity        alive
     2014-04-19 12:46:06   CommandAccepted yes
     2014-04-19 12:46:05   D-firmware      0.8
     2014-04-19 12:46:05   D-serialNr      UWS0000001
     2014-04-19 12:46:07   PairedTo        0x127000
     2014-04-19 12:46:07   R-burstRx       off
     2014-04-19 12:46:07   R-pairCentral   0x127000
     2014-04-19 12:46:07   RegL_00:          01:00 02:01 0A:12 0B:70 0C:00 00:00


[betateilchen]

ah... Verwirrendes Problem erkannt.

Der Sensor führt den ersten Sendezyklus nicht mehr direkt nach dem EInschalten (Batterieeinlegen) durch, sondern erst nach Ablauf mindestens eines Sendezyklus (ca 2,5 Minuten) durch:

(http://up.picr.de/18010792vk.png)

Jetzt sind jedenfalls Sensordaten vorhanden. Das Verhalten war aber bis zur 0.7 anders?

[martinp876]

das Problem in CUL_HM sollte gelöst sein - backslash vergessen....

[hexenmeister]

Bin jetzt wieder zuhause. Habe neue Firmware-Version eingespielt, FHEM upgedatet (CUL_HM aus SVN genommen). Alles tut wie es soll

[betateilchen]

Jetzt muss Dirk nur noch das THPL einchecken