Jeelik Modul zur Einbindung von La Crosse!

Begonnen von Billy, 16 September 2013, 15:12:15

Vorheriges Thema - Nächstes Thema

hulzer

Hallo,

in der aktuellen Version r4354 hat sich ein Fehler beim Setzen des State eingeschlichen. Es wird $humidity anstatt $dewpoint gesetzt.

Gruß

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Alex8508

In der aktuellsten Version von eben wird die Luftfeuchtigkeit falsch gerundet. Ich habe hier statt 50% Luftfeuchtigkeit nur 5%. Statt 99% (Sensor ohne Humidity) werden 10% angezeigt.

justme1968

hallo zusammen,

ich habe gestern schon wieder eine version eingecheckt die in der falschen reihenfolge mittelt und rundet. es ist seit eben korrigiert und ab morgen sollte es dann wirklich gehen. zumdest der angedachte stand.

ich bin aber mit dem mitteln an sich noch nicht wirklich zufrieden. das funktioniert bei dem grundrauschen den der sensor hat noch nicht wirklich gut.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

justme1968

wenn mir einer von euch die raw messages von ein paar sensoren loggt kann ich das nächste mal besser testen und es geht nicht ganz so viel schief.

sorry noch mal.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gero

Ich hatte leider die letzten Tage wenig Zeit.
In der aktuellen Version ist zumindest noch ein Fehler beim Runden der Humidity:
     
   $humidity = int($humidity + 0.5) / 10;

Das Teilen durch 10 muß hier weg.
Außerdem habe ich noch ein paar kleine Anmerkungen:

  • Der gleitende Mittelwert sollte immer auf den "genauen" Werten berechnet werden. Ansonsten bleiben wir bei einer höheren resolution auf einer Temperatur hängen und benötigen eine hohe Temperaturdifferenz, um den Wert wirklich zu ändern.
  • Ungültige Humidity-Werte sollten nicht in die Berechnung  einfließen
  • Beim Start sollte der erste Wert ohne Mittelung übernommen werden
  • Meinen Beobachtungen nach können wir nach den Fixes im Sketch auf den filterThreshold verzichten. Er stört aber nicht.
  • Eigentlich müßten Humidity und DewPoint eine eigene resolution bekommen. Für mich ist das aber unnötig

Mein Vorschlag wäre folgender:

  if( $type == 0x00 ) {
    $channel = "" if( $channel == 1 );

    if( AttrVal( $rname, "doAverage", 0 ) ) {
      if(defined($rhash->{"previousT$channel"})){
          $humidity = ($rhash->{"previousH$channel"}*3+$humidity)/4  if( $humidity && $humidity <= 99 );
          $temperature = ($rhash->{"previousT$channel"}*3+$temperature)/4;
      }
    }

    if( defined($rhash->{"previousT$channel"})
        && abs($rhash->{"previousH$channel"} - $humidity) <= AttrVal( $rname, "filterThreshold", 10 )
        && abs($rhash->{"previousT$channel"} - $temperature) <= AttrVal( $rname, "filterThreshold", 10 ) ) {

      readingsBeginUpdate($rhash);

      my $dewpoint;
      if( AttrVal( $rname, "doDewpoint", 0 ) && $humidity && $humidity <= 99 ) {
        $dewpoint = LaCrosse_CalcDewpoint($temperature,$humidity);
        $dewpoint = int($dewpoint*10 + 0.5) / 10;
        readingsBulkUpdate($rhash, "dewpoint$channel", $dewpoint);
      }   

      my $outTemp;
      my $outHum;
      my $resolution = AttrVal( $rname, "resolution", 1 );
      $outTemp = int($temperature*10 / $resolution + 0.5) * $resolution / 10;
      $outHum = int($humidity / $resolution + 0.5) * $resolution;

      readingsBulkUpdate($rhash, "temperature$channel", $outTemp);
      readingsBulkUpdate($rhash, "humidity$channel", $outHum) if( $humidity && $humidity <= 99 );

      if( !$channel ) {
        my $state = "T: $outTemp";
        $state .= " H: $outHum" if( $humidity && $humidity <= 99 );
        $state .= " D: $dewpoint" if( $dewpoint );
        readingsBulkUpdate($rhash, "state", $state) if( Value($rname) ne $state );
      }

      readingsBulkUpdate($rhash, "battery$channel", $battery_low?"low":"ok");

      readingsEndUpdate($rhash,1);
    } else {
      readingsSingleUpdate($rhash, "battery$channel", $battery_low?"low":"ok" , 1);
    }

    $rhash->{"previousH$channel"} = $humidity;
    $rhash->{"previousT$channel"} = $temperature;
  }


Ich hoffe, ich finde die nächsten Tage Zeit noch etwas mehr zu testen.


Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

justme1968

das mit der feuchtigkeit hatte ich gestern schon repariert das sollte behoben sein.

- wenn man den mittelwert auf den original werten rechnet schlägt der nachteil das er bei 'hohen' frequnzen nicht mehr sauber funktioniert aber leider durch. also z.b. ein messert der immer genau +-0.1 grad schwankt wird durchgereicht oder sogar invertiert.
die die hinter dem einstellen der auflösung ist je genau das sich erst grössere schwankungen auswirken sollen. eigentlich ist aber glaube ich ein anderer filter wie gaus oder einfacher binominal viel geeigneter

- mein verständnis war das ungültige humidity werte nur von sensoren kommen die keine humidity senden d.h. der wert immer 99 ist. daran ändert auch die mitteilung nichts. die auflösung schon. du hast recht.

- du hast recht. das übernehmen des ersten wertes ist zur zeit falsch. ursprünglich wurde er garnicht angezeigt sondern nur als previous gespeichert. und erst ab dem zweiten wert wird auch angezeigt. das hat noch mit den ausreissern am anfang auf grund der falschen crc prüfung zu tun. dadurch das die mitteilung ganz an den anfang gewandert ist passt das natürlich so nicht mehr.

- das mit der eigenen resolution für humidity ist richtig ich wollte aber erst mal sehen ob es überhaupt so funktioniert. beim dewpoint bin ich mir aber nicht sicher. der wird ja auf die temperatur die schon in der auflösung beschnitten ist gerechnet. noch mal bescheiden ist glaube ich nicht richtig.

- wenn alle bestätigen das die neue cri prüfung so effektiv ist das es keine ausreisser mehr gibt würde ich den threshold eigentlich gerne rausschmeissen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gero

Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
das mit der feuchtigkeit hatte ich gestern schon repariert das sollte behoben sein.
Ich habe erst vor 3 Stunden ein Update gemacht und da war der Fehler noch drin.

Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
- wenn man den mittelwert auf den original werten rechnet schlägt der nachteil das er bei 'hohen' frequnzen nicht mehr sauber funktioniert aber leider durch. also z.b. ein messert der immer genau +-0.1 grad schwankt wird durchgereicht oder sogar invertiert.
die die hinter dem einstellen der auflösung ist je genau das sich erst grössere schwankungen auswirken sollen. eigentlich ist aber glaube ich ein anderer filter wie gaus oder einfacher binominal viel geeigneter
Okay. Ich habe die Forderujg nach der resolution anders verstanden. Ich dachte, es wäre die Auflösung der readings gemeint:
z.B.: resolution = 5, previousT = 20.0, temperature = 21.5
Das führt bei deinem Code dazu, dass
temperature = (20.0*3 + 21.5)/4 = 20.375 -> 20.4
(oder habe ich mich vertan)

Wenn ich den gleitenden Mittelwert immer auf den Originalwerten berechne, wird doch gerade ein Schwanken von +-0.1 Grad herausgefiltert(?) Ich sehe hier kein Problem.

Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
- mein verständnis war das ungültige humidity werte nur von sensoren kommen die keine humidity senden d.h. der wert immer 99 ist. daran ändert auch die mitteilung nichts. die auflösung schon. du hast recht.
Ich habe mich falsch ausgedrückt. Es ging mir um das Einschwingen am Anfang durch die Mittelwertbildung und den nicht gesetzten Startwert. D.h. dein Code liefert bei eingeschalteter Rundung am Anfang Humidity-Werte auch für Sensoren, die konstant 99 liefern.

Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
- das mit der eigenen resolution für humidity ist richtig ich wollte aber erst mal sehen ob es überhaupt so funktioniert. beim dewpoint bin ich mir aber nicht sicher. der wird ja auf die temperatur die schon in der auflösung beschnitten ist gerechnet. noch mal bescheiden ist glaube ich nicht richtig.
Wenn du den dewpoint auf den beschnittenen Werten berechnest, hast du recht. Aber korrekter ist meiner Meinung nach auch hier die Berechnung auf den nicht beschnittenen Werten.

Ich möchte dir aber nicht in deinen Code reinreden und danke dir natürlich für deine Arbeit.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

gero

Zitat von: hthiery am 11 Dezember 2013, 09:22:20
Falls Du den Code hier meinst, dann kann ich dir zustimmen! Den habe ich auch nicht verstanden und wollte ihn nicht ohne weiteres umstellen. Ich werd mich mal daran machen das zu verstehen und aufzuräumen, sobald ich den neuen Sensor hab.

  // bogus check humidity + eval 2 channel TX25IT
  // TBD .. Dont understand the magic here!?
  if ( (msg->humidity >= 0 && msg->humidity <= 99)
       || msg->humidity == 106
       || (msg->humidity >= 128 && msg->humidity <= 227)
       || msg->humidity == 234)
  {
    pBuf += 1 | msg->batt_inserted;
    pBuf += ' ';
  } else if (msg->humidity == 125 || msg->humidity == 253 ) {
    pBuf += 2 | msg->batt_inserted;
    pBuf += ' ';
  } else {
    return "";
  }


Nach meinen Recherchen:
humidity
0..99 -> Hygrosensor vorhanden
106  -> kein Hygrosensor vorhanden
125 -> TX25IT channel 2 (da bin ich mir nicht ganz sicher)

Bit 7 -> battery low indicator

Dadurch kommen die Werte im obigen Code zustande.

Im vorangeganenen Post habe ich mich natürlich vertan:
Sensoren ohne Hygrosensor liefern keine 99, sondern eine 106!

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

gero

Zitat von: justme1968 am 12 Dezember 2013, 10:43:39
wenn mir einer von euch die raw messages von ein paar sensoren loggt kann ich das nächste mal besser testen und es geht nicht ganz so viel schief.

Falls du es noch brauchen solltest, als Anhang ein Mitschnitt der Rohdaten von meiner Sensoren. Ich hoffe, du kannst in dieser Form etwas damit anfangen.

Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

justme1968

super. danke.

ich werde deinen vorschlag mit der aktuellen version zusammen bringen und dann zum testen hier rein stellen. mit der reparierten crc prüfung kann man glaube ich ein paar altlasten raus schmeissen.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Tobias

Hi,
kann man den JeeLink Sketch auch mit panstamps verwenden?
Ich habe hier noch Panstamps herumliegen, würde aber auch ungern noch ein weiteres System integrieren. Mit Panstamps kenne ich mich schon etwas aus.
Maintainer: Text2Speech, TrashCal, MediaList

Meine Projekte: https://github.com/tobiasfaust
* PumpControl v2: allround Bewässerungssteuerung mit ESP und FHEM
* Ein Modbus RS485 zu MQTT Gateway für SolarWechselrichter

justme1968

das funkmodul ist ein anderes. ohne größere änderungen geht es also nicht und auch dann nicht automatisch für alle sketches.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Alex8508

Hallo zusammen,

ich habe jetzt die neueste Version des Moduls laufen. Dabei kommt es noch zu zwei Problemen:

1) Zwischendurch habe ich in den Logs immer wieder Ausreißer, welche um bis zu 10°C vom tatsächlichen Wert abweichen. Wenn ich den filterThreshold erhöhe (zwischen aus und Wert 10), wird das ganze schlimmer, je höher der Wert eingestellt ist.
=> Kann man hier eine Plausibilitäts-Prüfung in den Code einbauen? Wenn beispielsweise die Werte zeitlich sehr nahe beeinander sind, dann ist maximal eine Temperaturabweichung von x °C zum letzten Wert zugelassen - ansonsten wird der neue Wert verworfen. Da es im Log meist nur ein falscher Wert ist, könnte man diese so herausfiltern.

2) Die Funktion resolution funktioniert bei mir nicht. Ich habe hier als Wert 2 gewählt, aber dennoch wird jede Aktualisierung (auch um nur 0,1°C) angezeigt und geloggt.

justme1968

die ausreisser sollten weg sein wenn du den neuesten sketch verwendest. in vorherigen versionen war die crc prüfung falsch.

je grösser der filterThreshold wert ist um so grössere temperatur sprünge sind erlaubt. bei 10 sind bis zu 10 grad erlaubt.

genau für diese plausibilitätsprüfung ist der filterThreshold wert.

resolution beschneidet den original wert den der sensor sendet. wenn du auch noch ein doAverage gesetzt hast kann hierbei natürlich wieder ein wert entstehen der um weniger abweicht.

ich werde das mitteln und runden aber noch mal komplett überarbeiten.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968