LevelSender - Tankfüllstand mit JeeLink empfangen

[Wzut]

also einfach einen Gartenschlauch in den Öltank gesteckt und am Ende den SRF02 montiert.

und der hängt "freiwillig" senkrecht im Öl ohne das das untere Ende aufschwimmt ?
Oder hast da noch etwas montiert als Ballast wie z.B. schwere Messingkupplung ?

[chunter1]

Dich treffe ich auch überall neuerdings 

Stimmt, wir haben offensichtlich die gleichen Interessen... lass uns ein Startup gründen!

@chunter1: sag mal, könnten wir das auch mit dem Radar messen? 
OK, wohl eher nicht, weil das Öl sich zu langsam bewegt ... 

Naja, nimm einen FMCW/FSK Radar-Sensor dann braucht sich nichts zu bewegen.
Für eine vergleichbare Auflösung und Strahlbreite brauchts allerdings einen deutlich teureren Sensor als unseren IPM.
Positionsradar steht übrigens auch auf meiner Liste (für die mir nur die Zeit fehlt).

und der hängt "freiwillig" senkrecht im Öl ohne das das untere Ende aufschwimmt ?
Oder hast da noch etwas montiert als Ballast wie z.B. schwere Messingkupplung ?

Ich habs damals so gemacht, dass ich um das Rohrende ein relativ schweres Stück Metallrohr geschoben habe und mit einer Schlauchkupplung + Schlauchschelle am unteren Ende fixiert hab.
Den letzten "cm" misst er halt dann nicht mehr.
Beim Grundwassersensor hab ich noch einen "Partikelfilter" aus Flies reingestopft damit sich möglichst keine Partikel an der Rohrwand ablagern.

[E-J-D]

Hach, was haben wir hier für ein tolles Projekt  !!

Mein Sensor verrichtet auch treu seinen Dienst. Ich habe aber nach wie vor das Problem, dass immer mal wieder falsche Werte gemessen werden und der Tankinhalt um bis zu 1.000 Liter nach oben springt. Seltsamerweise immer nur hoch und nie runter. Am Ende schiebe ich das einfach auf unseren kellergeschweißten Tank der 60er Jahre. Trotz Sensor im 75er Roher ist das Phänomen nicht ganz weg. Irgendwie ist es ja auch kein Hammerproblem, aber eine echte Unschönheit.

Daher habe ich mir überlegt das Probem per Code zu lösen. Sinngemäß beschrieben ... "Wenn der minütliche Meßwerte größer ist als zuvor, dann verwerfe diesen. Ist der Meßwert kleiner, dann trage ihn ein."

Ich bin an dem Thema der hüpfenden Werte immer noch dran. Der aktuelle Stand ist, dass das ursprünglich im Heizöltank verbaute und durch den provisorischen Holzdeckel guckende Rohr leider nicht luftdicht hinzubekommen war. Die Geruchsbelästigung durch das Heizöl hat einen Rückbau erfordert. Nun ist also der Stahldeckel mit zwei kleinen Löchern für den US Sensor wieder drauf. Der Sensor ist mit Heißkleber abgedichtet und darüber eine Blechdose luftdicht verbaut. Somit ist das Problem der Geruchsbelästigung weg und das Problem der schwankenden Messungen wieder da. Nur ca. jede dritte Messung ist richtig, die anderen immer VIEL zu hoch. Ich gehe einfach davon aus, dass es mit der geriffelten Bauform des Tanks zusammenhängt.

Da die falschen Messwerte immer zu hoch sind, muss es doch möglich sein, den richtigen Messwert per Logik auszuwerten, oder? Ich nehme nun also wieder einen Anlauf, um dies in den Griff zu bekommen. Mein Versuch war mit einem userReadings "Heizoel" mir den realistischen Füllstand rauszufiltern. Und zwar will ich das userReading nur aktualisiert haben, wenn der Wert des readings "liters" niedriger ist als der Wert, der schon im userReadings "Heizoel" steht.

attr Keller.Oeltank userReadings Heizoel {if(ReadingsVal("Keller.Oeltank","liters","") < ("Keller.Oeltank","Heizoel","")) {return ("Keller.Oeltank","liters","")}  else {return ("Keller.Oeltank","Heizoel","")}} ... ist mein Versuch dazu. Geht aber leider nicht.

Ich freue mich, wenn mir jemand unter die Arme greifen kann. Einen Screenshot der aktuellen Werte und readings des Devices habe ich mit angehängt.

[fiedel]

Hi,
hier hab ich schon mal eine Lösung für ein gleichgelagertes Problem mit einem anderen Füllstandssensor gepostet.
Funktioniert zuverlässig bis heute...

[E-J-D]

Hi,
hier hab ich schon mal eine Lösung für ein gleichgelagertes Problem mit einem anderen Füllstandssensor gepostet.
Funktioniert zuverlässig bis heute...

Danke für die prompte Antwort. Ich habe mir die Lösnug angesehen. Für die Probleme mit den "Werten größer max. Kapazität" sieht das echt smart aus. Aber mein Problem bekomme ich nicht darauf adaptiert. Ich habe eben versucht dies mit folgendem Code umzusetzen, aber das funzt nicht... buhuuu ... ich habe zu wenig Ahnung von Perl . Das userReading "content" bleibt leer.

Code Auswählen Erweitern


[b]sub LevelSender_filter($) {

  my ($LevelSender_name) = @_;
  my $lev = ReadingsNum("$LevelSender_name","level",0);
  my $con = ReadingsNum("$LevelSender_name","content",0);

if ($lev <= $con) {
return sprintf "%.1f",$lev*0.001
}
}[/b]
Ist die Zeile "return sprintf "%.1f",$lev*0.001" in meinem Zusammenhang überhaupt noch richtig?!?! Und kann man eine Berechnung auf sich selbst (content) laufen lassen?

Auch verwirrt mich der folgende Logeintrag...
2018.03.06 08:20:03 1: PERL WARNING: Argument "" isn't numeric in numeric ge (< at ./FHEM/99_myUtils.pm line 74.
2018.03.06 08:20:03 3: eval: {LevelSender_filter($name)}

[fiedel]

Die Voraussetzungen sind halt nicht genau gleich, daher musst du etwas tüfteln:
Den Max- Wert gibt dein Gerät vermutl. nicht her, deshalb solltest du einen Festwert nehmen,
den du empirisch ermittelst. Die return- Formatierung lässt du erst mal ganz weg und je
nach dem was raus kommt wird sie später angepasst, oder kann weg bleiben:

Code Auswählen Erweitern

sub LevelSender_filter($) {

  my ($LevelSender_name) = @_;
  my $lev = ReadingsNum("$LevelSender_name","level",0);
  my $con = 1000;

   if ($lev <= $con) {
      return $lev
      }
}

... und bitte Code- Tags verwenden - das ist der Button mit der Raute bzw. "Hashtag" über dem Emotschi: 

[E-J-D]

Hallo fiedel,

danke für Deine Inspirationen. Ich habe jetzt diesen Code in der 99_myUtil...

Code Auswählen Erweitern

sub LevelSender_filter($) {

  my ($LevelSender_name) = @_;
  my $lev = ReadingsNum("$LevelSender_name","liters",0);
  my $con = ReadingsNum("Keller.Oeltank.rp","state",0);

   if ($lev <= $con) {
      return $lev
      }
}
(Cool, dieser Code Tag )

Zusätzlich habe ich dann noch das Device Keller.Oeltank.rp als readingsProxy angelegt und dort

Code Auswählen Erweitern


event-min-interval content:120
event-on-change-reading content:120
stateFormat content L
userReadings content {ReadingsNum("Keller.Oeltank","content",0)}

definiert. Damit bekam ich ein state in dem readingsProxy, das mir anscheinend den gewünschten Wert gab . Später war dann aber content wieder leer und kurz darauf auch state. Beißt die Katze sich hier irgendwie noch in den Schwanz??!

[fiedel]

Da jault ja der Hund vor Mitleid, so wie sich die Katze in den Schwanz beißt... 
Ich würde das erst mal alles strukturieren und auf ein Blatt malen, was da worauf zugreift und ob das "Sinn macht".
Außerdem würde ich die "event-min /-on" Sachen erst mal weg lassen und auch keine Namen mit Punkt- Trennung vergeben.
Erst mal alles so simpel wie möglich halten und wenn es dann läuft das Feintuning dazubasteln.

[E-J-D]

Neuer Anlauf mit einfacheren Waffen. Ich habe ein Dummy Keller.Oeltank.dummy mit dem Reading "Inhalt" angelegt. Dazu ein DOIF mit dem Namen "Keller.Oeltank.doif" und folgendem Inhalt:

Code Auswählen Erweitern

([Keller.Oeltank:liters] <= [Keller.Oeltank.dummy:Inhalt]) (setreading Keller.Oeltank.dummy Inhalt {(ReadingsVal("Keller.Oeltank","liters",""))})

Was soll ich sagen? Scheint zu funktinieren 

[Lucky2k12]

Ich habe seit einiger Zeit mit den HC-SR04 Chinasensoren das Problem, dass bei Temperaturen unter etwa 3 Grad C statt 100cm nur noch ca 40 cm gemessen wird.

Daher habe ich versucht, auf die viel gelobten SRF02 Sensoren umzubauen.
Diese sind wohl kaum noch erhältlich, aber mutmaßlich baugleiche GY-US42  wie z.b. Hier https://www.ebay.de/itm/I2C-Pixhawk-APM-Flight-Control-Ultrasonic-Module-replace-SRF02-MB1242-40-/232914590940?_trksid=p2385738.m4383.l4275.c10 

Leider gibt der Sensor auf der seriellen Konsole immer 0.0cm aus: 

Code Auswählen Erweitern


Values: 0.0 cm   19.50 C   5.44 V
Sent with 17241
Sent with 8842
407 ms powered

Values: 0.0 cm   19.00 C   5.43 V
Sent with 17241
Sent with 8842
406 ms powered

Wie kann ich das Problem einkreisen?

[HCS]

Wie kann ich das Problem einkreisen?

Auf SRF02 umkonfiguriert und neu compiliert?

Code Auswählen Erweitern

// --- Configuration ---------------------------------------------------------
#define SENSOR_TYPE           2     // 0 = no sensor   2=SRF02

Verdrahtung korrekt geändert gem. Schaltplan "SRF02 Version" ?

[Lucky2k12]

Danke HCS für die schnelle Antwort!

Ja, beides, Sketch Sensortyp ist geändert und die Verdrahtung natürlich auch.
Ist zwar etwas rustikal aber ich habe die Sensorverkabelung durchgeklingelt und das sollte soweit passen.

Sollte der Messwert nicht -1 sein, wenn der Sensor nicht erreichbar ist?

[Lucky2k12]

Hier noch ein paar Details zum Sensor, den ich zu verwenden versuche (ja meiner ist von ali, nicht aus der Bucht, also erstmal Vorsicht an evtl. Interessenten):
https://de.aliexpress.com/item/1-st-cke-GY-US42-i2c-Pixhawk-APM-Flight-Control-Ultraschall-Abstand-Messung-Modul/32914012790.html?spm=a2g0x.search0604.3.1.14f75f1bm6PLxG&ws_ab_test=searchweb0_0%2Csearchweb201602_3_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10902_10843_10059_10884_10887_321_322_10103%2Csearchweb201603_51%2CppcSwitch_0&algo_pvid=265697dc-12ee-4016-a909-9ebe83681a68&algo_expid=265697dc-12ee-4016-a909-9ebe83681a68-0

Habt ihr "originale"  SRF02 im Einsatz? Falls ja werde ich wohl die Investition abschreiben und die ca 23Eur abdrücken.
 

[Wzut]

Wenn nicht such doch mal nach dem US 100  (recht günstig und auf 0,5cm genau)
ich hatte den eigentlich für HM gekauft weil er ab 3,3 V läuft, habe ihn aber inzwischen als Ersatz für meinen defekten URM37 im HCS LevelSender verbaut.

[Lucky2k12]

Danke für den Tipp mit dem us100.
Ist der 5v tolerant oder muss dann ein anderer polulu rein?

Gesendet von meinem SM-P600 mit Tapatalk