Hallo liebe Leute,
ich frage mal hier, weil ich kein passerendes Board gefunden habe; notfalls verschieben bitte.
Ich habe inzwischen insg. 5 Aussenfühler, jeweils mit Temp & Hum, welche ich mir in FHEM darstellen lasse (siehe Bild).
Aber rein optisch gefällt mir da so nicht wirklich. Natürlich könnte man alle Graphen in ein Fenster schreiben, aber das wird extrem unübersichtlich. Daher suche ich nach einer Möglichkeit, die Darstellung durch editieren der plot-Datei o.ä. soweit zu verändern, das (auf das Bild bezogen) alle weißen Flächen mit einer ganz schlanken Trennlinie untereinander stehen, so das die Überschriften und die Zeitbeschriftung lediglich ganz unten (und ggf. ganz oben noch einmal) steht, wie in der Montage angedeutet.
Ein weiterer Wunsch wäre, in einem weiteren Plot jeweils die Mittelwerte aller 5 Sensoren darzustellen. Da hab ich aber im Moment nicht den blassesten Schimmer, wie man da rangehen sollte...
Als erstes wuerde ich alle Linien in einem Plot darastellen, das geht relativ einfach mit dem PlotEditor (DetailAnsicht eines Plots).
Die Linien verschieben kann man mit einer Funktion (Bei FileLog $fld[4]+100, usw.)
Blassen Strich kann man vmtl. mit logProxy bauen.
Skalenwerte kann man korrigieren, indem man die Werte manuell definiert.
Meine Meinung: viel Arbeit...
ZitatEin weiterer Wunsch wäre, in einem weiteren Plot jeweils die Mittelwerte aller 5 Sensoren darzustellen.
Mittelwerte gibt es viele. Aber sowohl für Block-Mittelwert als auch gleitenden Mittelwert über einen festen Zeitraum kannst du den event-aggregator verwenden. Dopple über einen Notfiy die Readings und aktiviere für die gedoppelten Readings den event-aggregator mit der Funktion "mean" (siehe Commandref). In den gedoppelten Readings stehen dann immer die jeweiligen Mittelwerte der ursprünglichen Readings, und die kannst du dann z.B. mit in den Plot aufnehmen.
Gruß,
Jens
... erstmal Dank Euch für die Antwort!
ZitatMeine Meinung: viel Arbeit...
Ich befürchtete es schon ??? ::)
Ich habe mir gerade mal einen Plot im Editor angesehen und die Funktion *100 eingebaut, wobei ich mal ins Blaue vermute, das $fld[] das Array ist, in dem die letzte Datenzeile aus dem entsprechenden FileLogf stehen. Immerhin sind die beiden Linien jetzt nicht mehr zu sehen und vermutlich nach oben hinaus geschossen; scheint zu funktionieren ;)
Allerdings fehlt mir jetzt erstmal das Wissen, wie man mit welchen Attributen was verändert, wie z.B. die Anzeigehöhe des ganzen Plotfensters u.s.w.. Da werde ich mich notgedrungen noch mal ganz tief einlesen müssen, sonst wird das m.E. nix... Denn z.B. ...
ZitatMittelwerte gibt es viele. Aber sowohl für Block-Mittelwert als auch gleitenden Mittelwert über einen festen Zeitraum kannst du den event-aggregator verwenden.
...sagt mir so erst einmal gar nix. Mir ist zwar aus den Bezeichnungen heraus schon in etwa klar, für was das gut ist, aber bis ich das umsetzen kann, wird wohl noch eine Weile ins Land gehen, womit wir mal wieder beim EIngangs erwähnten ...
ZitatMeine Meinung: viel Arbeit...
... wären *seufz*
Zitatvermutlich nach oben hinaus geschossen
Unwahrscheinlich, die Bereieche werden automatisch ermittelt, es sei denn, man hat sie manuell festgesetzt.
Ich vermute eher, dass mit $fld[4] nicht die richtige Spalte getroffen wurde, man muss eins von der gewaehlten Spalte abziehen. Dokumentiert ist das hier: http://fhem.de/commandref.html#FileLogget
Zum Pruefen kann man "Show preprocessed input" in der Detailansicht verwenden.
... ok, hätte ich auch selber drauf kommen können, das Arrays gewöhnlich mit "0" beginnen ...
Dennoch scheine ich irgend etwas grundsätzliches falsch zu machen. Wie im Bild schaut das nun aus. Man sieht am ENde so ein paar senkrechte Linien über dem Sheet; oder meinst Du mit "...es sei denn, man hat sie manuell festgesetzt..." die Werte, die ich bei "Range as..." eingetragen habe?
Zitatoder meinst Du mit "...es sei denn, man hat sie manuell festgesetzt..." die Werte, die ich bei "Range as..." eingetragen habe
Yepp.
... ahhhh ... Eine Insel mit zwei Bergen ;D So langsam sickert das ins Hirn; Dankeschön!
Ich habe das mal raus genommen und mal geschaut, was dann so passiert. Dabei stoße ich auf eine "Merkwürdigkeit", die ich mir nicht so wirklich erklären kann... ich meine die hässlichen Ausreißer. Ich habe mal drei Bilder angehängt, einmal wie ich's hatte, einmal ohne fixe Skalierung und einmal mit +100
Bild 1 und 2 sind stimmig, da durch die dynamische Skalierung alles was geht gestreckt wird. Die Spikes in Bild 2 sind deine Messwerte.
Bei Bild 3 stimmt die Temperatur zu Bild 1 und 2, aber der "%"-Verlauf nicht. Falsche Spalte? Andere Daten?
Zitataber der "%"-Verlauf nicht. Falsche Spalte? Andere Daten?
Nö, nimmernich. Die sind identisch zu 1 & 2 und daran wurde nichts verändert. Daher verstehe ich es ja auch nicht *GroßesWeihnachtsGrübeln*
Noch 'nen Versuch:
schreib bei % mal bitte "$fld[5]&&($fld[5]+100.0)". Die Formel mag Logeinträge ohne Werte nicht, deshalb "$fld[5]&&" davorstellen. Außerdem funktionieren die Formeln meist nicht, wenn da Leerzeichen drin sind. Andere Merkwürdigkeiten fallen mir momentan nicht ein.
Ich probiere das morgen ... ach ne... heute (is ja schon Sonntag) mal aus, auch wenn ich die Nummer formeltechnisch nicht verstehe...
Aber ist das nicht eher Sympthom- Bekämpfung? Ist ja nicht das eigentliche Kernproblem. Ich habe mal einen Blick in die Logfiles geworfen. Typisches Beispiel:
2015-12-19_17:53:15 AS.TH.5 T: 19.6 H: 66
2015-12-19_17:56:03 AS.TH.5 T: 19.7 H: 73
2015-12-19_17:56:59 AS.TH.5 T: 20.1
2015-12-19_17:57:55 AS.TH.5 T: 20.4
2015-12-19_17:58:51 AS.TH.5 T: 20.6
2015-12-19_17:59:47 AS.TH.5 T: 20.7 H: 67
2015-12-19_18:00:43 AS.TH.5 T: 20.6 H: 66
Gut zu erkennen ist die Lücke, aber ebenso der Ausreisser vor der Lücke; 73% zu dem Zeitpunkt ist Quatsch. Das kann ich deshalb so genau sagen, weil alle 4 Sensoren derzeit noch gemeinsam in einem Schuhkarton hier im Büro liegen, um Unterschiede bei der Messung zu erfassen.
Besser wäre es m.E., wenn man das Übel bei der Wurzel packt und die Daten vor dem Schreiben ins Logfile zum einen auf Plausibilität überprüft und bei Ausreissern wie diesen mit den Werten davor interpoliert so wie Lücken entsprechend füllt.
In PHP würde ich das hinbekommen, aber wie das hier aus FHEM resp Perl heraus ausschaut, ist aus meiner Sicht weit hinter dem Horizont, da ich natürlich nicht nachvollziehen kann, wie das intern der Reihe nach abgefrühstückt wird. Oder gibt es so was schon und ich weiß davon nur nix?
BTW: 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.
Da du wirklich Logs ohne Werte hast, sollte das vorgestellte $fld[5]&& schon mal helfen.
Natürlich ist das Symtombekämpfung, aber dann zeigt der Plot schon mal das an, was aufgezeichnet wurde und danach geht es an die Ursachen.
Wenn du den Sensorwerten nicht trauen kannst, spricht das eher für neue Sensoren, denn FHEM denkt sich keine Werte aus. Wenn du die Werte aber prüfen und ggf. ändern willst, dann sind wir wieder beim notify-Modul. Damit kannst du bei jeder Wertemeldung des Sensors einen Perl-Ablauf ausführen und dabei auch neue Werte schreiben oder halt nicht, wahlweise in das Sensordevice zurück unter neuem Namen oder z.B. auch gern genutz in ein Dummy-Device. Anschließend stellst du dein Logging und den Plot von den Sensorwerten auf die selbst erzeugten Readings um.
ZitatBTW: In dem Zusammenhang wäre es auch nett, wenn man für einzelne Sensoren Offsets für T und H angeben könnte
Je 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.
ZitatWenn du den Sensorwerten nicht trauen kannst, spricht das eher für neue Sensoren, denn FHEM denkt sich keine Werte aus
Das sich FHEM Werte ausdenkt habe ich ja auch an keiner Stelle behauptet; warum unterstellst Du mir denn sowas?!? Im Übrigen sind alle 4 Sensoren nagelneu...
Das mit den Lücken im Log scheint ja nicht nur ein Problem bei mir zu sein; zumindest meine ich das so zwischen Deinen Worten herauslesen zu können. Und was die unterschiedlichen Messwerte anbelangt, wirst Du das bei allen Sensoren beobachten können, ausgenommen mal sehr hochpreisige Teile, die einzeln im Werk explizit auf Referenznormale abgeglichen werden.
Zitat... Dummy-Device. Anschließend stellst du dein Logging und den Plot von den Sensorwerten auf die selbst erzeugten Readings um. ...
Ich meinte das mit dem Abfangen und der PLausibilität zwar anders, aber ... macht nix. Ja, irgendwie so werde ich das wohl notgedrungen lösen müssen. Ich schreibe es mir erst mal auf die ToDo für das kommende Jahr.
ZitatUebrigens sehe ich FHEM nicht als Wunsch-Veranstaltung
Wer sagt denn das? Und Dir sollte eigentlich klar sein, das ich noch sehr weit entfernt davon bin, selbst einen Patch zu schreiben. Ich wollte lediglich mit jemandem diese Idee in meinem Kopf besprechen, auch mit der Hoffnung, das sich daraus vielleicht eine Lösung für alle entwickelt. Ich bin noch nicht so lange dabei resp. so lange in diesem Forum, um wissen zu können, das ein Kommunizieren solcher Ideen den Profis vorbehalten ist...
Also Sorry, das ich laut gedacht habe; kommt nicht wieder vor.
Also vielen Dank für die Hilfe und ein schönes Fest Euch allen...
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
... 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.
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?
... 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.
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
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
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
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.
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
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
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:5Wie 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 fstepsDas 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?
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.
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 ^^
...
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.
.. 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...