Plot- Darstellungen zusammenfassen / Mittelwert über alle?

Begonnen von M_I_B, 19 Dezember 2015, 17:02:03

Vorheriges Thema - Nächstes Thema

jensb

Hallo M_I_B,

hier geht es nicht ums "unterstellen". Manche Antwort kommt vielleicht etwas anders an, als sie gemeint ist.

ZitatIm Übrigen sind alle 4 Sensoren nagelneu...
Das ein Sensor neu ist, sagt nichts über seine Eigenschaften. Habe selbst ein ganzes Rudel verschiedener Sensoren, die einen schnell, die anderen träge, die eine besser kalibriert, die anderen weniger. Wenn ich aber Sprünge im Verlauf habe, dann hat sie der Sensor meist gesehen, auch wenn man als Mensch davon nichts mitbekommt (kurz anfassen bzw. in Richtung des Sensors ausatmen kann bei einem Temperatursensor schon etwas bewirken). Sind die Sprünge auch so nicht zu erklären, dann sollte man sich die Sensoren trotzdem nochmal als Ursache ansehen. Habe leider nirgendwo in deinem Post gefunden, was du für Sensoren verwendest.

ZitatBTW: In dem Zusammenhang wäre es auch nett, wenn man für einzelne Sensoren Offsets für T und H angeben könnte, damit man verschiedene Sensoren aneinander anpassen und Fehlmesungen ausbügeln kann.
Natürlich kann man solche Funktionen auch in ein Modul integrieren. Aber als Anwender kann man sich da auch selbst helfen und da sind wir schon wieder beim notify. Versuchs doch einfach mal:


define myNotify notify mySensorDevice:mySensorReading.* {
  my $newSensorVal = ReadingsVal("mySensorDevice", "mySensorReading", 0) + 100;
  fhem("setreading mySensorDevice mySensorReadingPlus $newSensorVal");
}


Grüße,

Jens

FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

M_I_B

... so, jetzt komme ich auch mal zum Antworten ...

An erster Stelle: Euch und den Euren ein gesundes, erfolgreiches und problemloses neues Jahr! Ich hoffe, Ihr seid alle gut rein gekommen...

Zitathier geht es nicht ums "unterstellen". Manche Antwort kommt vielleicht etwas anders an, als sie gemeint ist.hier geht es nicht ums "unterstellen". Manche Antwort kommt vielleicht etwas anders an, als sie gemeint ist.
Das ist schon richtig. Dieses Problem besteht immer, wenn man sich nicht Angesicht zu Angesicht gegenüber steht. Deshalb hat ein schlauer Mensch mal die Smilies erfunden, die nicht aus Spaß auch als Emoticons bezeichnet werden und die bewusste und unbewusste Minik des Gegenüber ersetzen sollen. Ich bin auch kein Freund von teils massiv eingesetzten Smilies, aber in vielen Fällen helfen die ungemein, solchen Aussagen jene Bedeutung zu geben, die auch gemeint ist.

ZitatDas ein Sensor neu ist, sagt nichts über seine Eigenschaften.
Das ist schon klar. Ich habe lange genug im Bereich ISO 9001 f.f. gearbeitet und Messmittel für die Luft- und Raumfahrt kalibriert und justiert. Nichts desto weniger heißt das noch lange nicht ...
ZitatWenn ich aber Sprünge im Verlauf habe, dann hat sie der Sensor meist gesehen,
... Die 4 identischen Sensoren lagen zu der Zeit gemeinsam in einem geschlossenen Schuhkarton und sollten tendenziell die gleichen Werte anzeigen (excl. Fehler). Wenn also einer einen solchen Sprung gesehen hätte, müssten die anderen Sensoren solch einen Sprung auch gesehen haben. Ausserdem ist der Sprung von Raumtemperatur auf z.B. -30°C in einem beheizten Raum eher unwahrscheinlich. Ich denke, da wirst Du mir uneingeschränkt zustimmen können.

ZitatNatürlich kann man solche Funktionen auch in ein Modul integrieren. Aber als Anwender kann man sich da auch selbst helfen und da sind wir schon wieder beim notify.
Klar, so geit dat natürlich auch. Dennoch ist auch das nur eine Krücke, die wiederum zusätzlichen Code und Rechenzeit generiert, auch wenn im Einzelnen betrachtet zu vernachlässigen ist.

ZitatJe nach Modul geht das direkt, oder indirekt ueber userReadings. Uebrigens sehe ich FHEM nicht als Wunsch-Veranstaltung: wenn etwas fehlt, oder besser gemacht werden koennte, Patch schreiben, und dem Modulautor zur Verfuegung stellen.
Das FHEM eine "Wunschveranstaltung" ist, hat ja auch niemand gesagt. Und wenn Du meine Beiträge gelesen hast, dürfte Dir klar sein, das ich noch lange nicht so weit bin, dafür einen eigenen Patch zu schreiben. Du darfst mir glauben, das ich schon längst solch eine Option in die entsprechenden Module gepatch hätte, wäre ich dazu in der Lage. Da ich von Elektronik weitaus mehr verstehe, bin ich nun den direkten Weg gegangen, habe den Sensoren für T und H jeweils einen Spindeltrimmer verpasst und die Sensoren direkt justiert. Das ist aus technischer Sicht die sauberste Lösung, aber definitiv nur von einigen Usern in Eigenregie zu bewerkstelligen, da man davon ausgehen kann, das nicht jeder über das KnowHow und einen SMD- Arbeitsplatz verfügt.
Daher halte ich für solche Art von Sensoren resp. alle analogen Sensoren die Eingabe eines Offsets für ziemlich genial, um bei Einsatz mehrerer Sensoren, welche die gleiche physikalische Größe messen, direkt an der Eingangsquelle eine Kalibrierung vornehmen zu können. Das betrifft ja nicht nur Temperatur und Luftfeuchte, sondern u.a. auch Umgebungshelligkeit, Durchfluss, elektrische Spannungen und Ströme, u.d.G.m.

rudolfkoenig

ZitatIch habe lange genug im Bereich ISO 9001 f.f. gearbeitet und Messmittel für die Luft- und Raumfahrt kalibriert und justiert.

Apropos Luft :) , gibt es eigentlich einfache Verfahren, wie man Temperatur-, Feuchte-, Windstaerke-, etc-Sensoren grob kalibriert? Muss nicht supergenau sein, aber ich kann doch nicht ein S300TH in ein Wasserbad mit Eiskristallen reinstecken, und sie zu kochen ist auch nicht so praktisch. Die Verfahren fuer Feuchtebestimmung sind genauso problematisch, insb. wenn die billigeren Sensoren gar nicht fuer 0% oder 100% ausgelegt sind. Kann man irgendwo kalibrierte Instrumente fuer paar Tage mieten?

M_I_B

#18
... das ist in der Tat nicht so einfach. Bei Temperatur ist es noch easy, da es für etwas über 100 Tacken kalibrierte Systeme zu kaufen gibt (z.B. von Testo). Bei Luftfeuchte wird es schon schwieriger. Da braucht es eine Klimakammer, die i.d.R. fest verbaut ist und somit nicht beweglich / vermietbar.
Für Windstärke kann man sich behelfen, wenn man sich mit KG-Rohr (250er oder größer) einen Windkanal baut. Mit einem kalibriertem Windmessgerät oder SelfMade via Stauklappe mit definiertem Gewicht (und viel Umrechnerei) bekommt man das ausreichend genau hin. Testo hat da aber auch was zum Thema Windgeschwindigkeit zu bieten, wenn mich nicht alles täuscht.
Leider arbeite ich nicht mehr in der Firma in Hannover, sonst könnte ich dort direkt helfen und mal neben den anderen Systemen ein paar mit kalibrieren lassen... Irgendwo in Hannover gab es auch eine Firma, die hochgenaue Refferenzen vermietet hat, aber da ich nur der "Anforderer" war, kann ich nicht sagen, wie die Fa. heißt...

EDIT sagt: Für genaue Temperatur- Messungen kommen eigentlich Geräte mit Typ-T/Klasse 1 oder etwas ungenauer Typ-K/Klasse 1 in Frage. Für den Hausgebrauch tun es ganz sicher Typ-K Sensoren, die an jeder Ecke zu kaufen sind. ENtscheidend ist dann die Genauigkeit der Auswerter- Elektronik in Bezug auf Drift- und Kompensation.
Gute Seite dazu: https://de.wikipedia.org/wiki/Thermoelement
Dem kann ich nichts hinzu fügen.

jensb

Hallo Micha,

auch dir ein frohes neues Jahr  ;)!

Wenn du dich mit Kalibrieren auskennt, dann ist für mir schon klar, warum du einen Abgleich möglichst im Sensor-Kontext durchführen willst.

Und da stellt sich für mich die Frage, was hast du eigentlich konkret für Sensoren und wie sind die in FHEM eingebunden, also von welchem FHEM-Modul reden wir? Hab es vielleicht übersehen, aber scheinbar hast du das bisher nicht geschrieben. Vielleicht hilft das herauszufinden, wo die Ausreißer herkommen.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

M_I_B

#20
Moin Jens,

also die Sensoren sind vom Aldi/Lidl (hat Frauchen besorgt). Die hatten vor ein paar Wochen mal so eine schicke, bunte Wetterstation. Da war ein Sensor dabei. Als ich den hier in Betrieb genommen hatte, stellte sich heraus, das der sich in FHEM greifen lässt. Also habe ich nochmals drei Stück nachbestellt (ePray). Die Dinger schimpfen sich GT-WT-02 (Bild in der Anlache).
In einem anderen Fred (http://forum.fhem.de/index.php?topic=45609) gibt es mit der kleineren Version des Sensors selbige Probleme; dort wird auch versucht, die Fehler im Nachhinein zu plätten ...
EDIT: Dort wird auch die Vermutung laut, das es ggf. ein Problem in der a-culfw geben könnte, die ich auch auf einem SCC nutze. Die Vermutung ist nicht so abwägig, da wohl mit der okkinolen BusWare-FW diese Sprünge nicht aufgetreten sind

jensb

Hallo Micha,

gehe davon aus, dass du einen CUL für den Funkempfang verwendest. Da ich meine T/H-Sensoren (überwiegend Oregon Scientific) mit einem DVB-T-Stick empfange, kann ich leider nichts genaues zu den Sensoren und der Empfangsverarbeitung sagen (meine haben dieses Problem zum Glück nicht).

Eine theoretischer Ansatz wäre das Loggen der Rohdaten der Telegramme und eine exemplarische manuelle Auswertung, falls das nicht schon jemand gemacht hat. Damit könnte man herausfinden, ob der Sensor selbst oder der Telegrammdekoder die Ursache ist. Es kann aber z.B. auch sein, dass Funkübertragungsstörungen einzelne Bits kippen und mangels einer Telegrammprüfsumme der empfangene Unsinn ausgegeben wird. Hier möchte ich mich dann aber ausklinken.

Falls du noch Fragen zur Plot-Darstellung bzw. Mittelwerten hast, lass es mich wissen.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

Puschel74

Sensoren in diesem Preissegment (Aldi/Lidl etc.) würde ich nicht mit industriellen Sensoren vergleichen.
Noch nichtmal bei Sensoren von HM lege ich die Messlatte höher.
P.S.: Bevor Missverständnisse aufkommen - beruflich kalibriere ich unter anderem Sensoren für die Pharmaindustrie.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

M_I_B

Zitatwürde ich nicht mit industriellen Sensoren vergleichen.
Hast Du vollkommen Recht und das bestreitet niemand. Dennoch sind solche Sensoren, ggf. nach Kalibrierung, mehr als ausreichend für die von der vermeintlichen Masse der User gewünschten Funktionen. Wir wollen hier ja keinen Prozessreaktor steuern, sondern lediglich die Umgebungswerte in ausreichender Genauigkeit erfassen. Da kommt es nicht auf eine Fehler von z.B. +/-1°C an. Und wenn man das Prinzip der parallelen Erfassung mit nachgeschalteter statistischer Mittelwertbildung über mehrere identische Sensoren verwendet, ist man annährend so genau wie ein deutlich teurer, kalibrierter Sensor.
Aber das ist hier ja auch nicht der Knackpunkt; der liegt immer noch bei den Ausreißern, deren Ursache noch ungeklärt ist und bei meiner Idee resp. Wunsch, den Sensoren Offset's mitgeben zu können. Sowas wäre z.B. schick:

define AS.TH.2 CUL_TCM97001 CUL_TCM97001_5
attr AS.TH.2 event-on-change-reading .*
attr AS.TH.2 model GT-WT-02
... blablub ...
attr AS.TH.2 offset-temp -0.75 <--- Übermittelte Temperatur minus 0,75
attr AS.TH.2 offset-humi +12.5 <--- Übermittelte Feuchte plus 12,5

Ich habe im Moment keine Infos darüber, wie z.B. Helligkeitssensoren ihre Daten abliefern, aber auch da wäre es sinnig. Letztlich muss man das ganze noch nicht einmal validieren, wenn man zu Grunde legt, das die ankommenden Daten immer Zahlen sind und der Anwender selber entscheiden muss, welcher Zahlenwert einen sinnvollen Offsetwert für seinen Sensor ergibt

jensb

Hallo Micha,

schick wäre das schon - habe das für meinen Wetterdatenempfänger (RTL-SDR) auch so ähnlich umgesetzt.

Aber wenn wir FHEM als Ganzes betrachten, sind da eine sehr große Anzahl von Modulen, die hier nachgerüstet werden müssten. Je nach Sensor ist nicht nur ein Offset erforderlich, sondern auch noch ein Korrekturfaktor, ggf. sogar eine nichtlineare Korrektur oder eine abschnittsweise Korrektur über ein Tabellensystem. Da ich mich manchmal um den Helligkeitssensor TSL2561 kümmere, kann ich dir sagen, dass dieses Modul  2 wählbare Rechenwerke an Board hat, die außerdem abhängig von den Rohdatenwerten unterschiedliche Berechnungsformeln verwenden. Mit einem Offsets oder einer lineare Korrektur kann man da nicht sinnvoll korrigieren. An diesem Beispiel wird vielleicht klar, dass man diesen Wunsch nicht ohne weiteres für die gesamte Infrastruktur umsetzten kann.

Vermutlich würde es dir auch reichen, wenn man zunächst das CUL_TCM97001 Modul anpassen würde. Wie Rudi es bereits gesagt hat, steht es dir frei, dir das Modul vorzunehmen, die Erweiterung einbauen und es dem Maintainer zur Prüfung vorlegen.

Falls du übrigens mindestens 3 Sensoren am gleichen Ort hast, kannst du doch bei Einzelfehlern über ein notify eine eindeutige 2 aus 3-Auswahl treffen, den Mittelwert der beiden Gutwerte bilden und dies als Messergebnis abliefern.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

M_I_B

#25
Zitathabe das für meinen Wetterdatenempfänger (RTL-SDR) auch so ähnlich umgesetzt.
Dat is ma schrill ;) Ich hatte zwar auch mal eine Zeit lang einen SDR am Start, aber eher als Spectrumanalyser für die KW-Bänder, um mit meinen "Schätzen" (FRG-7700, 9R-4J, ...) schnell da hin kurbeln zu können, wo was los ist (hängen an einem AAA-1C/OctoLoop). Auf die Idee, damit Wetterdaten zu empfangen und in FHEM darzustellen, wäre ich tatsächlich nicht gekommen, da es mehr als ausreichend Quellen im Netz gibt, die man anzapfen kann. Aber dennoch eine seeeehr interessante Variante, die mein Fricklerherz begeistert ;D

ZitatCUL_TCM97001 Modul anpassen würde. Wie Rudi es bereits gesagt hat, steht es dir frei, dir das Modul vorzunehmen, die Erweiterung einbauen und es dem Maintainer zur Prüfung vorlegen.
Klar würde mir pers. das erstmal reichen. Aber wie gesagt habe ich überhaupt keinen Plan, wie man so was einbaut resp. wer der Maintainer dafür ist. Daher bin ich ja auch den anderen Weg gegangen und habe die Sensoren direkt kalibriert durch Einbau von Trimmern. Aus meiner Sicht und Kenntnisstand war das um einiges einfacher, also mich da noch in die Modul-Sachen reinzufrickeln.
Natürlich würde ich so was auch gerne in Software umsetzen, aber ich muss hier aufpassen, das ich mich nicht verzettel. Haus & Hof, Familie & Co., Oldtimer & Dampfradios, ... müssen auch bedient werden, und leider ist aus einem Tag ums Verrecken nicht mehr als 24h heraus zu quetschen...

Zitatkannst du doch bei Einzelfehlern über ein notify eine eindeutige 2 aus 3-Auswahl treffen
Tja... da kommt das schlimme Wort "kannst" drin vor. Ich kann es leider nicht. Ich habe so ein paar Dinge in FHEM noch nicht wirklich begriffen. Das geht schon mit einem Problem los im Zusammenhang mit schnöden IT-Steckdosen; alles funktioniert, nur eine einzige Steckdose reagiert beim Abschalten mit "off, on, off", was auch durch Austausch der Steckdose bleibt. Und da alle Steckdosen per Copy&Past in FHEM angelegt wurden, ist der Fehler bis jetzt nicht auszumachen... Also habe ich es erstmal so gelassen und mich um die Restauration eines schönen Blaupunkt Röhrenradios gekümmert, um den Kopf frei zu bekommen... Irgendwann komme ich wohl mal per Zufall auf den Fehler...


BTW: Da ich hier nebenbei drei FHEM- Projekte am Laufen habe, ist mir das Folgende erst heute aufgefallen...

#FileLog_AC_ZS_WZ 3:AC_ZS_WZ.*::$fld[2]=~"on"?95:5
Wie ist das =~"on"?95:5 gemeint? Ich war der Auffassung, das bei "on"= "95" gesetzt wird, im anderen Fall "5" ?!? Wenn ich mir die Sache im Ergebnis aber ansehe, ist es genau umgekehrt ^^ Wo mache ich da meinen Denkfehler? Ok, ich könnte es jetzt einfach umdrehen, aber verstanden habe ich es dadurch auch noch nicht.

In dem Zusammenhang habe ich in den Plot-Dateien folgendes notiert:
"<IN>" using 1:2 axes x1y2 title '  PWR  ' ls l5 lw 1 with fsteps
Das funktioniert so weit, aber wenn ich mir z.B. die Plots in der Anlage ansehe, dann wird z.B. im "Kinderzimmer" der Plot für den Zustand des Aktors erst gegen 12:15 begonnen, jener des "Schlafzimmers" ist durchgezogen über die aktuelle Zeit hinaus bis zum Ende des Tages (beide sind natürlich invers zu lesen wegen der 95:5 Frage). Wie bekommt man das denn hin, das die Darstellung in beiden Fällen korrekt ist?

Puschel74

Ich frage mich grad was das alles noch mit der Eingangsfrage zu tun hat  ???

Zum Offset:
Das sollte sich per userreading bereits Modulunabhängig erledigen lassen.
Hat Rudi ja auch schon geschrieben:
ZitatJe nach Modul geht das direkt, oder indirekt ueber userReadings.

Zum Wunsch nach dem Offset:
Wozu sollen in allen beteiligten Modulen Attribute eingeführt werden die 99,99% der User nicht brauchen da sie kein Referenzequipment haben?
Dem Aufwand durch die Entwickler steht wohl, in meinen Augen, kein Nutzen gegenüber.
Und nein, ich pack mittlerweile keine Temperaturensoren in einen "Jofra-Ofen" oder Feuchtesensoren in eine Klimakammer und fahr sie durch obwohl ich das Eqiupment hätte da mir die gelieferten Daten "für zuhause" genau genug sind.
Ja ich hab in der Firma auch eine FHEM-Installation und könnte mir die Offsetwerte "nebenbei" erstellen aber da der Unterschied bisher immer < 0.5 °C resp. < 2% rH war habe ich mittlerweile drauf verzichtet - ich benutze aber auch keine Aldi/Lidl-Sensoren.

Zum "aussreißenden Sensor":
Der sollte beim Hersteller reklamiert werden.

Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

M_I_B

ZitatIch frage mich grad was das alles noch mit der Eingangsfrage zu tun hat
...

ZitatWozu sollen in allen beteiligten Modulen Attribute eingeführt werden die 99,99% der User nicht brauchen da sie kein Referenzequipment haben?
Was hat das damit zu tun? Je mehr Sensoren ich habe, um so wahrscheinlicher ist es, einen genauen Wert zu bekommen, wenn ich vorher den Mittelwert aller Sensoren händisch ermittle und dann jedem Sensor den Offset zum Mittelwert mitgebe... Ich sag nur: Gausche Verteilung und statistische Wahrscheinlichkeit...

Zitatich benutze aber auch keine Aldi/Lidl-Sensoren.
Das zum Thema "die 99,99% der User nicht brauchen". Oder meinst Du, das die besagten 99,99% fette Taler für kalibrierte Sensoren ausgeben (wollen)? Das fand ich jetzt ziemlich daneben... Meine pers. Meinung...

ZitatDer sollte beim Hersteller reklamiert werden.
... na, dann schicke ich doch gleich mal alle Sensoren zurück, da diese Aussetzer unabhängig vom Sensortyp auftreten ...

Summa summarum viel geschrieben, aber nix weitergeholfen ^^

Puschel74

#28
...
Lesen - denken - verstehen.
Ich zerpflück deinen Beitrag nicht weil mir das zu mühsam ist.

Wer lesen kann und das gelesene versteht ist klar im Vorteil.
Und wer das verstandenen dann noch umsetzen kann hat schon gewonnen.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

M_I_B

.. Sorry, wenn ich das so sagen muss... Aber Du nerfst nur. Es wäre schön, wenn Du Dich aus den von mir initiierte Threads heraus halten würdest.
Es gibt genug anständige User, die an statt Anfängern das Leben schwer zu machen hilfreiche Beiträge generierten, ohne mit hoch im Himmel schwebenden Nasenspitze auf die doofen Anfänger herunter zu blicken...