Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[betateilchen]

https://github.com/kc-GitHub/Wettersensor

[Dirk]

Hi @all,

Die beiden Sensoren laufen nun schon über einen Tag ohne Ausfall.
Daher gehe ich davon aus, das das Hängenbleiben-Problem nun gelöst ist.

Anbei sind die neuen Hex-Files mit der Version 0.6
Es gibt hier 2x2 unterschiedliche Versionen.

WetterSensor_06.hex ist  die Firmware so wie bisher mit der Device-ID vom HM_WDS10_TH_O
WetterSensor_06_test.hex das selbe mit Sendeinterval von 5 Sek. falls noch jemand Testen möchte

WetterSensor_06_type-F101.hex ist eine Version mit einem neuen Device-Type
WetterSensor_06_type-F101_test.hex das Selbe mit Senmdeinterval von 5 Sek.

Durch den eigenen Device-Type muss CUL_HM nicht mehr gepatcht werden (Fast)
Es muss noch ein kleiner Patch gemacht werden.
Diese Version wird so von der CCU noch nicht erkannt.
Für die CCU will ich auch noch eine Unterstützung zur Verfügung stellen.

Gleich zu Beginn vom 10_CUL_HM.pm etwa an Zeile 10 muss nach der Zeile

Code Auswählen Erweitern

use HMConfig;
Diese Zeile eingefügt werden:

Code Auswählen Erweitern

use HMConfig_additionalDevices;

Ausserdem muss die Datei HMConfig_additionalDevices.pm ins FHEM-Verzeichniss kopiert werden.

Dadurch kann CUL_HM den neuen Device-Type interpretieren. Folgende Readings gibt es hier:

• Temperatur
• Luftfeuchte
• Luftdruck
• Luftdruck-NN
• Helligkeit
• Batteriespannung

Abhängig von den bestückten Sensoren sollten nur die relevanten Readings sichtbar sein.
Temperatur wird aber immer Übertragen. Bei fehlendem Sensor kommt dann 0.

Luftdruck-NN ist nur Verfügbar, wenn das Globale Attribute "altitude" gesetzt ist und wenn der Luftdrucksensor bestückt ist.

@Martin,
Ich habe noch keine sinnvolle Lösung gefunden die Datei anders einzubinden. Über 99_... klappt es so nicht. Die Modellist und die Subtypelist muss erweitert werden.
Hast du eine Idee wie wir das ohne Patch hinbekommen?


@thorsten,
Testest du bitte mal die 0.6er Version.
Ich habe aktuell keine Idee warum die 0.2er Version bei dir läuft und die anderen nicht.
So groß waren die Änderungen nicht.
Blöderweise habe ich den Codeerst ab V0.4 oder 0.5 auf Github

Gruß
Dirk

Update:
Anhang gelöscht. Der Link zur letzten Firmware ist jetzt immer hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/Firmware/Flash-Tool-Windows.zip

[betateilchen]

Gleich zu Beginn vom 10_CUL_HM.pm etwa an Zeile 10 muss nach der Zeile
Diese Zeile eingefügt werden:

Code Auswählen Erweitern

use HMConfig_additionalDevices;

Ausserdem muss die Datei HMConfig_additionalDevices.pm ins FHEM-Verzeichniss kopiert werden.
....
@Martin,
Ich habe noch keine sinnvolle Lösung gefunden die Datei anders einzubinden. Über 99_... klappt es so nicht. Die Modellist und die Subtypelist muss erweitert werden.
Hast du eine Idee wie wir das ohne Patch hinbekommen?

Das mit dem Einbinden ist eigentlich kein Problem. Aber man sollte das unbedingt in ein eval {} packen, sonst zerschießt dieser Patch die komplette fhem-Konfiguration bei Anwendern, die die zusätzliche Datei gar nicht benötigen und/oder diese Datei nicht auf Ihrem Sytem haben. Beispiele für diese Vorgehensweise gibt es z.B. in fhem.pl (fallweises Einbinden der configDB.pm, falls das jemand nutzen möchte) und in 32_mailcheck.pm (feststellen, welche Zusatzfunktionen zur Verfügung gestellt werden können).

Die Frage ist ausserdem, ob man das Einbinden der Zusatzdatei wirklich in 10_CUL_HM.pm machen will oder ob man das nicht in die HMConfig.pm verlegt.

[Dirk]

Genau diese Punkte möchte ich noch klären.
Das sollte kein genereller Patch sein.

Am liebsten hätte ich diese File dynamisch eingebunden. Das muss aber CUM_HM machen.
Da Modellist und Subtypelist erweitert werden müssen.

[Thorsten Pferdekaemper]

Hi,
@Betateilchen: Danke.

@thorsten,
Testest du bitte mal die 0.6er Version.
Ich habe aktuell keine Idee warum die 0.2er Version bei dir läuft und die anderen nicht.
So groß waren die Änderungen nicht.
Blöderweise habe ich den Codeerst ab V0.4 oder 0.5 auf Github

Die 0.6er werde ich ausprobieren.
Den 0.2er Code habe ich, den hast Du mir mal per Mail geschickt.
Vielleicht hilft auch folgende Beobachtung weiter: Das ganze läuft bei mir auf einer Fritz!Box 7390. Wenn der Sensor sendet, dann hat nicht nur FHEM Probleme damit, sondern mein ganzes Netzwerk scheint kurz zusammenzubrechen. (Ich habe gestern parallel einen Film über T-Entertain aufgenommen und der hatte alle ungefähr 2,5 Minuten einen Aussetzer von ein paar Sekunden.)
Außerdem haben die  beiden grünen LEDs vom HM-LAN manchmal wie verrückt geblinkt. 
Mein "echter" HM-Sensor hat diese Probleme übrigens nicht.
Gruß,
    Thorsten

[betateilchen]

Das sollte kein genereller Patch sein.

Die grundsätzliche Einbindung (das "use") sollte per eval fest erfolgen.

Das dynamische Laden des Erweiterungsmoduls könnte man dann über verschiedene Wege steuern. (sowas gibt es auch für die configDB Erweiterung, die nur geladen wird, wenn sie wirklich gebraucht/benutzt wird)

[hexenmeister]

Mein "echter" HM-Sensor hat diese Probleme übrigens nicht.

Sehr interessant. Ich habe auch ähnliche Probleme. Ich weiss jetzt nicht seit welcher Version, aber ich habe Störungen gemerkt. Zuletzt waren diese so heftig, dass ich den Sensor erstmal deaktiviert habe. Bin je Paar Tage weg, kann nicht ständig fhem beruhigen:)
Mein hmlan blinkt heftig, die rote led leuchtet lange, dann scheint es Sich zurebooten. Manchmal blieb sogar so hängen. Und ständige disconnects, die sind nach dem Stillegen verschwunden.
Irgedndwas scheint mir dem Protokoll nicht zu stimmen.

Insgesamt spinnt mein hmlan letzte Zeit. Mal änderte sich die MAC-adresse, so dass der router neue ip vergeben hat, dann ging dhcp gar nicht mehr. Habe ip fest vergeben... Und die serialnummer änderte sich plötzlich auf ree999999 o.ä. Das ist aber eher die Auswirkung nach dem firmware Update. Ansonsten tut aber...  Bin etwas verwirrt 

Lg
Alexander

[Thorsten Pferdekaemper]

Mal änderte sich die MAC-adresse, so dass der router neue ip vergeben hat, dann ging dhcp gar nicht mehr. Habe ip fest vergeben... Und die serialnummer änderte sich plötzlich auf ree999999 o.ä. Das ist aber eher die Auswirkung nach dem firmware Update. Ansonsten tut aber...  Bin etwas verwirrt 

Die Probleme habe ich nicht. Ich hatte vorher schonmal von Problemen beim Firmware-Update des HMLAN gelesen und habe es dann bleiben lassen, da ja alles funktioniert hat. Mein HMLAN hat Firmware 0.961.
Gruß,
   Thorsten

[Dirk]

Ich mache heute abend noch mal einen Test mit dem HM-LAN.
Zumindest mit dem CUL und auch an meiner CCU1 (als HM_WDS10_TH_O) gibt es aktuell keine Probleme.

In den letzten Versionen waren noch zusätzliche Bytes am Frame mit dran die ich zum debugen genutzt hatte.
Die sind in der 0.6er wieder raus. Vielleicht störte sich der HM-LAN daran?

@Betateilchen
Was sagt dein USB-Config-Adapter dazu?

Die grundsätzliche Einbindung (das "use") sollte per eval fest erfolgen.

Das ist schon klar. Ich würde das aber gerne so gestalten dass man ggf. auch mehrere Erweiterungsdateien einhängen kann ohne CUL_HM oder HMConfig zu patchen.
Daher hat Martin vielleicht eine Idee wie wir das generischer machen

Das Laden muss aber nach HMConfig erfolgen und bevor CUL_HM initialisiert wird.

Gruß
Dirk

[betateilchen]

@Betateilchen
Was sagt dein USB-Config-Adapter dazu?

Mit Version 0.5 bisher keinerlei Auffälligkeiten.

Ich hatte weiter oben schonmal darum gebeten, einmal ein "list <device>" zu posten - leider wurde das wohl übersehen. Vielleicht könnte man darin schon Auffälligkeiten erkennen.

[Thorsten Pferdekaemper]

Ich hatte weiter oben schonmal darum gebeten, einmal ein "list <device>" zu posten - leider wurde das wohl übersehen.

Hi,
das habe ich schon zweimal gemacht, z.B. hier:
http://forum.fhem.de/index.php/topic,20620.msg157916.html#msg157916
Gruß,
    Thorsten

[Dirk]

Ich hatte weiter oben schonmal darum gebeten, einmal ein "list <device>" zu posten - leider wurde das wohl übersehen. Vielleicht könnte man darin schon Auffälligkeiten erkennen.

Hier von mir:

Code Auswählen Erweitern


Internals:
   CUL_MSGCNT 6
   CUL_RAWMSG A1424A2706FB74DF1123400EE3003E5000186600A00::-18:CUL
   CUL_RSSI   -18
   CUL_TIME   2014-04-12 13:44:59
   DEF        6FB74D
   IODev      CUL
   LASTInputDev CUL
   MSGCNT     6
   NAME       CUL_HM_UWS_THPL_6FB74D
   NR         75
   STATE      T: 23.8 H: 48 Lux: 999 P: 997 P-NN: 1017 batVoltage: 2.56
   TYPE       CUL_HM
   lastMsg    No:24 - t:70 s:6FB74D d:F11234 00EE3003E5000186600A00
   protLastRcv 2014-04-12 13:44:59
   rssi_at_CUL avg:-18 min:-18 max:-18 lst:-18 cnt:6
   Readings:
     2014-04-12 13:44:35   .D-devInfo      030100
     2014-04-12 13:44:35   .D-stc          70
     2014-04-12 13:44:59   .protLastRcv    2014-04-12 13:44:59
     2014-04-12 13:44:35   Activity        alive
     2014-04-12 13:44:35   D-firmware      0.6
     2014-04-12 13:44:35   D-serialNr      XLU0001002
     2014-04-12 02:09:53   R-pairCentral   set_0x1ACAE5
     2014-04-12 13:33:10   RegL_00:        0
     2014-04-12 13:44:59   batVoltage      2.56
     2014-04-12 13:44:59   battery         ok
     2014-04-12 13:44:59   humidity        48
     2014-04-12 13:44:59   lux             999
     2014-04-12 13:44:59   pressure        997
     2014-04-12 13:44:59   pressure-nn     1017
     2014-04-12 13:44:59   state           T: 23.8 H: 48 Lux: 999 P: 997 P-NN: 1017 batVoltage: 2.56
     2014-04-12 13:44:59   temperature     23.8
   Helper:
     mId        F101
     rxType     132
     Io:
       newChn     +6FB74D,00,01,1E
       nextSend   1397303099.43017
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf   
       qReqStat   
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul:
         avg        -18
         cnt        6
         lst        -18
         max        -18
         min        -18
Attributes:
   IODev      CUL
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   0.6
   model      UWS-THPL
   peerIDs   
   room       CUL_HM
   serialNr   XLU0001002
   subType    THPLSensor


Ich kann das das Problem mit dem HM-LAN auch in der 0.6er Firmware bestätigen.
Der HM-LAN bootet neu wenn er Packete vom Sensor empfängt.

Aus meiner Sicht ist das auch eine böse Sicherheitslücke im HM-LAN.
Denn so kann ich mit einem kleinen Sender in der Nähe eine ganze Hausautomatisierung ggf. incl. Alarmanlage ganz, aber mindestens teilweise außer Gefecht setzen.

@Thorsten,
Kannst du mir die 0.2er nochmal zukommen lassen.
Ich glaube die hab ich gar nicht mehr

Gruß
Dirk

[Thorsten Pferdekaemper]

Ich kann das das Problem mit dem HM-LAN auch in der 0.6er Firmware bestätigen.

Ok, dann fühle ich mich zumindest nicht mehr alleine.

Der HM-LAN bootet neu wenn er Packete vom Sensor empfängt.

Erklärt das auch, warum mein komplettes Netzwerk in dem Moment spinnt?

Kannst du mir die 0.2er nochmal zukommen lassen.

...ist hier drangehängt.
EDIT: Anhang entfernt, um Verwirrungen zu vermeiden.
Gruß,
    Thorsten

[betateilchen]

Tipp von mir:

Das Attribut autoReadReg maximal auf 3 setzen, noch besser auf 0 (zumindest bei diesem Selbstbausensor!).

Dann warte ich mal mit dem Update auf 0.6, zumal die 0.5 bei mir völlig problemlos läuft.

[Dirk]

Das Attribut autoReadReg maximal auf 3 setzen, noch besser auf 0 (zumindest bei diesem Selbstbausensor!).

Kannst du da noch etwas zum Hintergrund sagen? Also wieso?

Die Register sind von der Ursprungsversion. Da babe ich nix geändert.
Daher vermute ich mal, das wird an dem HM-LAN-Problem nix ändern.
Kannst du mal ein List <device> vom Originalsensor Posten. Oder gab es das hier schon mal?

Gruß
Dirk