Selbstbau HM_WDS10_TH_O mit Luftdruckmessung

[santalaus]

Hallo betateilchen,

ich wollte Dir gerade schreiben, das ich mir das auch überlegt hatte. Dann aber feststellte, das der neue DevTyp mit dem use eintrag IMHO einfacher zu patchen ist.
Aber Du hast das ja schon vorgenommen

Ich kann das nciht nachvollziehen, da ich einen Vollständig bestückten Sensor habe.

Diese ist wg dem Lux Messer und meinen Bastelleien allerdings noch offen. Hoffentlich kommen die PIRs bald.

Nico

[betateilchen]

Diese ist wg dem Lux Messer und meinen Bastelleien allerdings noch offen. Hoffentlich kommen die PIRs bald.

Meiner hängt schon seit ein paar Tagen im Flur

(http://up.picr.de/17945138sq.jpg)

[betateilchen]

*lach* jetzt weiss ich auch, woher die zweitweisen Unterschiede zwischen Dirks pressure-nn und meinem pressure-nn kommen: Ich nutze die komplexere barometrische Formel, nicht die simple

Hier ein paar Vorschläge zu der zusätzlichen HMConfig-Datei

1. bitte einen kürzeren Namen wählen, bei mir heißt die jetzt HMConfig_add.pm

2. Soweit ich das sehe, ist Lux immer 1000, wenn kein Lichtsensor existiert? Dann sollte sich so das überflüssige Reading unterdrücken lassen:

Code Auswählen Erweitern


if ($lux < 100001 && $lux != 1000) {


3. Aus Performancegründen würde ich die Abhandlung des Luftdrucks so umsetzen:

Code Auswählen Erweitern


# air pressure
if ($pressure) {
$stateMsg .= ' P: '    . $pressure;
push (@events, [$shash, 1, 'pressure:'    . $pressure]);

# my $altitude = AttrVal('global', 'altitude', 0);
my $altitude = $attr{global}{altitude};
if ($altitude) {
my $pressureNN = $altitude ? sprintf('%.0f', ($pressure + ($altitude / 8.5))) : 0;
# if ($pressureNN) {
$stateMsg .= ' P-NN: ' . $pressureNN;
push (@events, [$shash, 1, 'pressure-nn:' . $pressureNN]);
}
}


[Dirk]

äh... WetterSensor_06.hex sendet bei mir aber auch alle 5 Sekunden...

Hm, ich check das nacher mal, kann gut sein dass ich das Hex-File verwechselt habe.

Deshalb kommt der Einsatz des neuen Devicetyp für mich erst dann in Frage, wenn die Erweiterung fest implementiert ist.

Leider ist Martin noch nicht auf meine Fragen hierzu eingegangen.

Ich habe aber folgenden Vorschag:
CUL_HM sollte unmittelbar nach HMConfig automatisch alle Files laden die mit "HMConfig_" beginnen.
Dann kann jeder der ein eigenes Device baut seine eigenen Types definieren.

Ich würde CUL_HM mal entsprechend umbauen und Martin den Patch schicken.
Oder hat jemand einen anderen Vorschlag?

Die 0.6 mit eigenem Typ zeigt bei mir Werte für Lux und Batteriespannung an. Ich habe aber gar keinen Lichtsensor und ob die Spannungsmessung wirklich korrekt ist, weiss ich auch nicht.

Da gibt es wohl noch einen kleinen Bug.
Eigentlich sollte bei fehlenden Lichtsensor 100.001 Lux gemeldet werden. Der eigene DeviceType sollte dann kein Reading melden.

Ich nutze die komplexere barometrische Formel, nicht die simple

Das ist die gleiche Formel wie in I2C_BMP180. Da hast du dich nicht beschwehrt

1. bitte einen kürzeren Namen wählen, bei mir heißt die jetzt HMConfig_add.pm

Wenn wir es Umsetzen wie unten vorgeschlagen könnte man auch "HMConfig_<type>" nehmen.

2. Soweit ich das sehe, ist Lux immer 1000, wenn kein Lichtsensor existiert? Dann sollte sich so das überflüssige Reading unterdrücken lassen:

Sollte es, ist noch ein Bug.

3. Aus Performancegründen würde ich die Abhandlung des Luftdrucks so umsetzen:

Ich kann gerne auch deine komplexere Formel einbauen.
Welche ist das?

Gruß
Dirk

[betateilchen]

CUL_HM sollte unmittelbar nach HMConfig automatisch alle Files laden die mit "HMConfig_" beginnen.
Ich würde CUL_HM mal entsprechend umbauen und Martin den Patch schicken.

Da bin ich aber gespannt. Und ich bin nach wie vor der Meinung, dass HMConfig das Nachladen machen sollte und nicht CUL_HM.

Das ist die gleiche Formel wie in I2C_BMP180. Da hast du dich nicht beschwehrt

Da habe ich auch nie in den Quelltext geschaut, um rauszufinden, wie Du das machst. Ausserdem war das keine Beschwerde.

Ich kann gerne auch deine komplexere Formel einbauen.

Lohnt sich aus Performance- und Ressourcengründen nicht.
Die Differenz tritt eh nur selten auf und die Abweichung ist maximal +/- 1 hPa.

[Dirk]

Und ich bin nach wie vor der Meinung, dass HMConfig das Nachladen machen sollte und nicht CUL_HM.

Von mir aus auch in der HMConfig am Ende.
Wichtig ist, das die Daten da sind bevor CUL_HM die Modellist und die TypeList baut.

Lohnt sich aus Performance- und Ressourcengründen nicht.

Auf welche Platform beziehst du dich da? Ist deine Formel so komplex? Währ ne FB damit schon überfordert?

[betateilchen]

Ich halte die Genauigkeit Deiner einfachen Formel für völlig ausreichend.

Code Auswählen Erweitern


sub relDruck($){
# Messwerte
my ($Pa) = @_;
my $Temp = ReadingsVal('BMP180','temperature',20);
my $Alti = AttrVal('global','altitude',0);

# Konstanten
my $g0 = 9.80665;
my $R  = 287.05;
my $T  = 273.15;
my $Ch = 0.12;
my $a  = 0.065;
my $E  = 0;

if($Temp < 9.1){
$E = 5.6402*(-0.0916 + exp(0.06 * $Temp));
} else {
$E = 18.2194*(1.0463 - exp(-0.0666 * $Temp));
}

my $xp = $Alti * $g0 / ($R*($T+$Temp + $Ch*$E + $a*$Alti/2));
my $Pr = $Pa*exp($xp);
return int($Pr);
}


[betateilchen]

Wenn wir es Umsetzen wie unten vorgeschlagen könnte man auch "HMConfig_<type>" nehmen.
...
Von mir aus auch in der HMConfig am Ende.
Wichtig ist, das die Daten da sind bevor CUL_HM die Modellist und die TypeList baut.

Beispielsweise so? (am Ende der HMConfig.pm einzufügen)

Code Auswählen Erweitern


my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
  next if($m !~ m/^HMConfig_(.*)\.pm$/);
  no strict "refs";
  my $ret = eval { do "./FHEM/$m"; };
  use strict "refs";
}
closedir(DH);


Code Auswählen Erweitern


HMConfig Loading: HMConfig_001.pm
HMConfig Loading: HMConfig_002.pm
HMConfig Loading: HMConfig_THPL.pm


[Dirk]

Hallo,

ich habe mal etwas mit dem HM-LAN experimentiert.
Sobald der Sensor mehr als 17 Bytes Payload in einem Frame sendet, rebootet der HM-LAN reproduzierbar.
darunter ist alles ok.

Ab Version 0.3 oder 0.4 (weiß nicht mehr genau) hatte ich noch ein paar Bytes zusätzliche Debugging-Infos mit  gesendet.
Das waren 20 Bytes.
In der Version > 0.5 werden nur 11 Bytes versendet. Diese Versionen sind also ok und auch mit HM-LAN verwendbar.

äh... WetterSensor_06.hex sendet bei mir aber auch alle 5 Sekunden...

WetterSensor_06.hex und WetterSensor_06_test.hex waren identisch.

Beispielsweise so? (am Ende der HMConfig.pm einzufügen)

Code Auswählen Erweitern


my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
  next if($m !~ m/^HMConfig_(.*)\.pm$/);
  no strict "refs";
  my $ret = eval { do "./FHEM/$m"; };
  use strict "refs";
}
closedir(DH);


Kleine Ergänzung, damit man auch sieht wenn man Fehler im Code hat:

Code Auswählen Erweitern


my $mp = "./FHEM";
opendir(DH, $mp) || return;
foreach my $m (sort readdir(DH)) {
  next if($m !~ m/^HMConfig_(.*)\.pm$/);

  no strict "refs";
  my $file = "./FHEM/$m";
  my $ret = do $file;
  if(!$ret) {
    main::Log3 undef, 1, "Error loading file: $file:\n $@";
  }
  use strict "refs";

}
closedir(DH);


@Martin kannst du das so in HMConfig einbauen?
Oder soll ich das machen.
Ich würde dann HMConfig_THPL.pm einchecken.

2. Soweit ich das sehe, ist Lux immer 1000, wenn kein Lichtsensor existiert? Dann sollte sich so das überflüssige Reading unterdrücken lassen:

Da ist mir wohl der Wert um 2 Kommastellen verrutscht.

Es gibt nun Version 0.7.
Dies überträgt dann auch den richtigen Wert wenn kein Helligkeitssensor da ist, und wenn der Sensor gesättigt ist.

Die aktuellste Version der Firmware ist jetzt immer hier:
https://github.com/kc-GitHub/Wettersensor/raw/master/Tools/Firmware/Flash-Tool-Windows.zip

Gruß
Dirk

[hexenmeister]

Sieht nach einem typischen Pufferüberlauf aus. Wir sollen es an Elv/Eq3 melden. Evtl. gibt es dann eine korrigierte Version.

Grüße,
Alexander

[betateilchen]

Kleine Ergänzung, damit man auch sieht wenn man Fehler im Code hat:
...
@Martin kannst du das so in HMConfig einbauen?
Oder soll ich das machen.

(http://us.cdn2.123rf.com/168nwm/ppart/ppart1012/ppart101200017/8476748-stop-schild-isolated-on-white.jpg)

Das eval {} hatte ich nicht zum Spaß eingebaut, das solltest Du unbedingt drinlassen.

Wenn Du schon irgendwas zum Loggen haben willst (ich hatte das während meiner Tests einfach mit print() gemacht), dann bitte nur so:

Code Auswählen Erweitern



  my $ret = eval { 
    my $ret=do "$file";
    if(!$ret) {
      main::Log 1, ""Error loading file: $file:\n $@";";
      return $@;
    }
  }



[betateilchen]

Sieht nach einem typischen Pufferüberlauf aus. Wir sollen es an Elv/Eq3 melden. Evtl. gibt es dann eine korrigierte Version.

*g* die Antwort kann ich mir gut vorstellen: "Wir haben keine Homematic Komponenten, die mehr als 17 Byte payload senden"

(natürlich nur eine Vermutung)

[Dirk]

Das eval {} hatte ich nicht zum Spaß eingebaut, das solltest Du unbedingt drinlassen.

Ist aber an dieser Stelle völlig unnötig, da das File ja da ist.

[betateilchen]

Es geht nicht darum, zu prüfen, ob das File da ist oder nicht.

Wenn in dem File etwas drinsteht (z.B. Perl Syntaxfehler), das fhem zum Absturz bringt (und das passiert schneller als Du denkst) kriegst Du davon im aufrufenden Modul nichts mehr mit und hast auch nix zum Loggen.

Wenn es nur darum ginge, die Existenz eines Files zu prüfen, bräuchte man eval nicht, sondern könnte das viel einfacher testen: if(! -r "$file");

[Dirk]

Wenn in dem File etwas drinsteht (z.B. Perl Syntaxfehler), das fhem zum Absturz bringt (und das passiert schneller als Du denkst) kriegst Du davon im aufrufenden Modul nichts mehr mit und hast auch nix zum Loggen.

Do macht das selbe wie Eval. Nur eben für externe Dateien. Daher ist das unnötig das doppelt zu machen.