[Erl] Stringvariable bearbeiten

[Henke]

Deine 2 Thesen sind:
1: Es werden als Messwert/Eingangswerte relativ ungenaue Werte verwendet.
2: Bei ungenauen Werte ist es egal ob fehlerbehaftete oder ungenaue Berechnungen gemacht werden, solange das Ergebnis nicht auffällig ist bzw. auch innerhalb der Messtoleranz des Eingangswertes sind.

Habe ich das so richtig verstanden? Und bitte, fasse dich kurz und bündig. Ja/Nein reicht. Sexuelle Gewohnheiten deinerseits oder Auto Vergleiche kannst du dir sparen.

Erfreut nehme ich zur Kenntnis, das du wohl erkannt hast, das ein Script das reduziert auf Berechnungen mit nur 6 Komma Stellen recht schnell Schrott liefert. Nimm als Hinweis, das Berechnungen auch mit 16 Stellen, die mehrmals log und exp verwenden, nicht gerade förderlich sind was das Ergebnis betrifft. Bei javascript fällt das jedoch weniger auf, da dort mit 64bit als Standard gerechnet wird, aber mir fällt dann natürlich auf warum ein CCU Script durchaus signifikant andere Werte ergibt.

[Xel66]

Deine 2 Thesen sind:

Keine Thesen, sondern Fakten.
1: Ja, ungenau, aber für die gewählte Aufgabe (Regelung einer Wohnraumtemperatur) in ihrer Toleranz ausreichend
2: Auch ja, denn das Endergebnis kann nicht genauer als die Datenquelle sein, auch wenn es dieses durch noch so viele Nachkommastellen suggeriert oder damit berechnet wurde.

Ergänzung: in der vor-elektronischen-Thermostat-Ära hat die Einstellmöglichkeit zwischen fünf Strichen zur Wohnraumtemperierung gereicht. Heutzutage werden die Werte mit Kommastelle angezeigt, die aber auf Basis der prinzip- und hardwarebedingten Toleranzen nichts wert sind.

Sexuelle Gewohnheiten deinerseits oder Auto Vergleiche kannst du dir sparen.

Über meine Gewohnheiten berichte ich gewöhnlich nicht, sondern bewerte eine solche Pedanz auf (mit vorhandener Hardware nicht leistbare) Genauigkeit als Fetisch oder Befriedigung irgendwelcher Vorlieben. Und das ist nicht mein Fetisch, denn ich klebe nicht an Nachkommastellen und sehe solche Messwerte realistisch. Obiges Beispiel mit den fünf Teilungseinheiten eines klassischen Heizkörperthermostat habe ich hier im Forum schon mehrmals zum Besten gegeben.

Erfreut nehme ich zur Kenntnis, das du wohl erkannt hast, das ein Script das reduziert auf Berechnungen mit nur 6 Komma Stellen recht schnell Schrott liefert.

Im Rahmen der Messgenauigkeit der zugrundeliegenden Datenquellen ist das tolerierbar. Für "genaue" Berechnungen ist ReGa-Script schon allein wegen fehlender mathematischer Funktionen auch nur sehr begrenzt geeignet. Auch das hatte ich mehrmals geschrieben. Aber Du verweigerst Dich ja der Lektüre.

Nimm als Hinweis, das Berechnungen auch mit 16 Stellen, die mehrmals log und exp verwenden, nicht gerade förderlich sind was das Ergebnis betrifft.

Genau das habe ich versucht, Dir zu erklären. Witzig, dass gerade Du mir diesbezügliche Begriffsstutzigkeit vorwerfen willst. Du hast doch Gegenteiliges behauptet.

Bei javascript fällt das jedoch weniger auf, da dort mit 64bit als Standard gerechnet wird, aber mir fällt dann natürlich auf warum ein CCU Script durchaus signifikant andere Werte ergibt.

Auch das habe ich bereits mehrmals geschrieben. Aber schön, dass Du auch endlich zur Erkenntnis kommst, dass ReGa-Script für solche Aufgaben eher ungeeignet ist.

Gruß Xel66

[Henke]

Keine Thesen, sondern Fakten.
1: Ja, ungenau, aber für die gewählte Aufgabe (Regelung einer Wohnraumtemperatur) in ihrer Toleranz ausreichend
2: Auch ja, denn das Endergebnis kann nicht genauer als die Datenquelle sein, auch wenn es dieses durch noch so viele Nachkommastellen suggeriert oder damit berechnet wurde.

Sehr schön. Grell was du als Fakten ansiehst.

Zu 1.
Wie die Qualität des Eingangswertes ist, ist nicht bestimmt. Von deiner Installation aus ausschließlich HM Komponenten auf andere zu schließen ist falsch. Bei einer Berechnung die Aufgabe festzulegen ist auch falsch.
Als Beispiel verarbeite ich die Wetterdaten der DWD Mosmix Stationen. Die werden durch 2 Sensoren ermittelt und der Wert durch mehrere Messungen abgeglichen. Die haben eine ganz andere Genauigkeit und es steht dabei dann noch nicht fest ob die Daten für eine Statistik oder Steuerung gebraucht werden. Wenn ich also nicht genau weiß wie die Eingangsdaten sind und wofür sie verwendet werden, sollte die Berechnung so gut wie möglich sein.
Zu 2.
Es geht darum, das Ergebnis nicht ungenauer zu machen. Nicht um eine Interpretation deinerseits. Eine Formel/Script zu verwenden das aufwendiger und ungenauer ist mach keinerlei Sinn. Da These 1 widerlegt ist, fällt auch These 2.

[Xel66]

Sehr schön. Grell was du als Fakten ansiehst.

Nun ja, wenn die dokumentierten technischen Daten des Herstellers keine Fakten sind, was denn dann?

Von deiner Installation aus ausschließlich HM Komponenten auf andere zu schließen ist falsch. Bei einer Berechnung die Aufgabe festzulegen ist auch falsch.

Du kannst vielleicht mit Buchstaben und Zahlen umgehen, aber das sinnerfassende Lesen scheint nicht die Kernkompetenz zu sein. Wenn ich mal Deinen Blick auf die URL dieser Seite lenken dürfte oder etwas runter auf das, was das Topic dieses Forums ist, dann dürfte Dir klar sein, aus welchen Gründen und worauf ich mich beziehe. Und diese von Dir angeführten DWD Mosmix Stationen stehen also bei Dir in unmittelbarer Nähe ums Haus? Cool. Wenn nicht, nun ja... Schaue ich mir auf einschlägigen Wetterseiten die Daten von Stationen im Umkreis von ein paar Kilometern an, dann weichen die durchaus von einander ab. Allerdings ist dieses meist Hobbyeqipment, aber da die Werte mal positive und negative Abweichungen untereinander haben, ist das keine grundsätzliche Missweisung der Sensorik, sondern die lokalen Bedingungen sind tatsächlich unterschiedlich. Allerdings sehe ich diese nur als Momentaufnahme und nicht als Verläufe. Ob Messungenauigkeiten jetzt von unterschiedlicher Bauteilqualität und Bauelementedrift kommt, oder die Daten von mehreren Kilometern Entfernung herangezogen werden, ist vermutlich mit ähnlichem "Fehler" behaftet.

Mein Brötchengeber in Luftlinie von fünf Kilometern unterhält auch aus bestimmten Gründen, die ich hier nicht näher darlegen werde, umfangreiche hochqualitative Wettersensorik (welche genau entzieht sich allerdings meiner aktuellen Kenntnis, könnte ich aber rausbekommen, die sogar kalibriert und regelmäßig geprüft ist). Wenn ich mir die Werte dieser Sensorik (auf die ich auch aus beruflichen Gründen Zugriff habe), weichen diese auch teils um mehrere Kelvin bzw. Feuchteprozente von meinen Werten zu Hause ab. Selbst die verschiedenen übers Gelände verteilten Sensoren zeigen aus topografischen Gründen zwar ähnliche Verläufe aber nicht identische Werte. Eine Berechnung von Werten in mehreren Kilometern Entfernung ist also auch bezüglich der Genauigkeit für eine lokale Verwendung bei Dir sehr begrenzt geeignet. Und Berechnungen mit vielen Nachkommastellen machen es auch nicht besser.

Es geht darum, das Ergebnis nicht ungenauer zu machen. Nicht um eine Interpretation deinerseits. Eine Formel/Script zu verwenden das aufwendiger und ungenauer ist mach keinerlei Sinn. Da These 1 widerlegt ist, fällt auch These 2.

Auch hier wieder das Problem mit dem sinnerfassenden Lesen. Es geht mir nicht darum zu unterstellen, dass ein Ergebnis ungenauer gemacht werden soll, sondern dass bei einem ungenauen Eingangssignal das Rechenergebnis eben nicht genauer als die Datenbasis sein kann. Das ist der Punkt. Da ist der Interpretatsionsspielraum verdammt schmal. Du hast somit weder Tatsache 1 noch Tatsache 2 (und nicht These! - das hier ist keine Dissertation) widerlegt. q.e.d.

Beispiel (ohne Auto): Wenn Dein Eingangsignal Deiner Berechnung um 5% dess Messbereichs) neben dem realen Wert liegt, dann kann das Ergebnis einer rechnerischen Verarbeitung dieses Wertes nicht genauer als diese 5% Fehler sein (es sei denn man würde zusätzlich bei der Berechnung individuelle Korrekturfaktoren zur Kompensation der Missweisung verwenden). Und je umfangreicher die nachträgliche Verarbeitung (z.B. durch Heranziehen eines weiteren fehlerbehafteten Wertes) kann der Fehler größer werden (aber theoretisch sogar kleiner, wenn der Fehler des zweiten Wertes z.B. kleiner 0 ist). Ich habe absichtlich dimensionslose Werte verwendet, da die Wichtung bei Berechungen auch noch zusätzliche Fehler bringt. Und um bei Deinem Beispiel mit der absoluten Feuchte zu bleiben. Für diese benötigt man nun mal mindestens zwei Ausgangswerte. Die Temperatur und die relative Luftfeuchte, und beide Werte sind bei Homematic(IP)-Sensorik (um diese geht es hier im Forum und auch bei den meisten Anwendern zu Hause) nun mal stark fehlerbehaftet, so dass eine Verarbeitung mit einer größeren Anzahl von Nachkommastellen das Rechenergebnis eben nicht genauer macht bzw. eine Genauigkeit suggeriert, die die Ausgangwerte gar nicht leisten können. Es ergibt daher gar keinen Sinn, mit möglichst vielen Nachkommastellen zu arbeiten, auch wenn Du Dich noch so anstrengst.

Gruß Xel66

[Henke]

Bla bla bla, nur überflogen.
Wo steht eine Behauptung, das das Rechenergebnis genauer ist?
Das Topic ist schon seit Seite 2 durch, irrelevant.
Behauptung HM Geräte und deren Fehlertoleranz ist maßgebend ist falsch.
Damit bin ich bei dem Geschwafel raus.

[Xel66]

Bla bla bla, nur überflogen.

Das ist Dein Hauptproblem. Fakten interessieren Dich nicht.

Wo steht eine Behauptung, das das Rechenergebnis genauer ist?

Da: Zitat:

Bei jeder Umrechnung von Relativer zu Absoluten Feuchte wäre eine Reduzierung auf nur 6 Stellen bei den Berechnungen schon übel. Genauso bei Sonnen oder Mondständen, akkumulierte Energiewerte, und und und.

Und jetzt brauchst Du nur noch behaupten, das nicht geschrieben zu haben. Dann wird es absolut lächerlich.

Das Topic ist schon seit Seite 2 durch, irrelevant.

Auch falsch, es war schon nach meinem Beitrag (dem zweiten in diesem Thread!) gelöst - zumindest nach Aussage des TE.

Behauptung HM Geräte und deren Fehlertoleranz ist maßgebend ist falsch.

Du behauptest also allen Ernstes, dass der Hersteller in seinen Dokumenten falsche Angaben macht. Merkwürdige Sichtweise. Und btw. schwafelt hier nur einer - der der sogar dokumentierte Tatsachen bezweifelt und Leuten weismachen will, dass man unbedingt mit einer hohen Anzahl von Nachkommastellen rechnen muss, weil sonst das Ergebnis "ungenau" wäre. Auch diese Behauptung ist nachweislich falsch. Der daraus resuliterende Rechenfehler ist vermutlich weitaus kleiner als der ursprüngliche Fehler in der Messwerterfassung.

Gruß Xel66

[Henke]

Alter Schwede, lesen und verstehen! Versuch es mal mit langsam lesen!

"Bei jeder Umrechnung von Relativer zu Absoluten Feuchte wäre eine Reduzierung auf nur 6 Stellen bei den Berechnungen schon übel."
Heißt, das Ergebnis wird ungenauer. Wie kann man daraus deine Behauptung ableiten, das ich damit sage es wird genauer?
Mach aus den 6 Stellen mal 0 Stellen, vielleicht kannst du dann den Sinn erfassen.
Wichtig ist dabei auch das Wort "wäre". Es ging darum, das die Berechnungen mit mehr als 6 Stellen laufen und es sofort auffallen würde, wenn es nicht so ist. Nicht meine Berechnungen, sondern alle in allen Scripten.

Ich behaupte auch nicht, das die Dokumentation der Messgenauigkeit falsch ist. Deine Behauptung es werden diese und nur diese Geräte als Lieferant der Eingangswerte genutzt ist Blödsinn.

Ahh, Texte hervorgehoben. Gut!

Eine Berechnung von Werten in mehreren Kilometern Entfernung ist also auch bezüglich der Genauigkeit für eine lokale Verwendung bei Dir sehr begrenzt geeignet.

Woher willst du wissen, wie weit der Messpunkt weg ist? Wieder eine an den Haaren herbeigezogene falsche Annahme.
Genauso wie das Ziel. Lokale Verwendung bei mir. Die Berechnungen werden nicht nur von mir, sondern durch Veröffentlichung auch von anderen verwendet.
Um es nochmals zu wiederholen:
Die Qualität des Eingangswertes ist unbestimmt.
Die Verwendung des Wertes ist unbestimmt.

[MichaelN]

Habt ihr zuviel Tagesfreizeit?

[[sprotte80]]

Hi

Für "genaue" Berechnungen ist ReGa-Script schon allein wegen fehlender mathematischer Funktionen auch nur sehr begrenzt geeignet.

nur aus interesse:
Was für Funktionen fehlen?

Thomas

[Xel66]

Alter Schwede, lesen und verstehen! Versuch es mal mit langsam lesen!

Das ist genau das Definzit, welches Du auch noch dokumentiert an den Tag legst. Du solltest ggf. überhaupt mal anfangen zu lesen und nicht nur zu überfliegen.

Heißt, das Ergebnis wird ungenauer. Wie kann man daraus deine Behauptung ableiten, das ich damit sage es wird genauer?

Das habe ich nie behauptet. Mein Statement dazu ist, egal ob man es mit sechs oder sechzehn Nachkommastellen berechnet ist bei der Fehlerbreite des Ausgangssignals schlichtweg Wurst, egal, überflüssig, Bullshit. Mal ein kleines Beispiel:

Gegeben seiem hypothetische Realitäswerte von 20° und 50% r.F.. Diese Werte habe ich mal mit den Fehlerangaben des Herstellers ±5 % und ±0,8 K variiert (und somit noch nicht mal die Extremwerte von ±2 K des Differnztemperatursensors angenommen) und in dem von Dir hier verlinkten Luftfeuchtigkeitsrechner eingegeben.

eine r.F. von 45% bei 19,2°C ergeben 7,42 g/m³ (Fehler: -5% r.F. und -0,8K)
eine r.F. von 45% bei 20,0°C ergeben 7,78 g/m³ (Fehler: -5% r.F.)
eine r.F. von 50% bei 20,0°C ergeben 8,64 g/m³ (hypotetischer Referenzwert)
eine r.F. von 55% bei 20,0°C ergeben 9,5 g/m³ (Fehler: +5% r.F.)
eine r.F. von 55% bei 20,8°C ergeben 9,96 g/m³ (Fehler: +5% und +0,8K)

Der Maximalwert läge bei Referenztemperatur und 100% r.F. bei 17,28 g/m³! Bei der Varianz des Ergebnisses (2,54 g/m³) willst Du der Welt weismachen, dass es einen Unterschied macht, ob man mit sechs oder mehr Nachkommastellen rechnet, wenn schon eine Varianz der Ausgangswerte um die vom Hersteller dokumentierte Fehlerbandbreite ein stark schwankendes Ergebnis vor dem Komma liefert? Und bei diesen Berechnungen handelt es sich immer um die gleiche Formel. Jetzt variiere diese Werte mal mit Deinen sechs oder x Nachkommastellen in Deiner Berechnung. Deine Werte liegen auch irgendwo dazwischen, sind aber weder falsch noch richtig und schon gar nicht genau.

Für den Normalanwender ergibt sich daraus sowieso keinerlei Relevanz. Für den sind die Absolutwerte maximal im Rahmen einer Luftfeuchte"waage" relevant, mit der er Lüfungsentscheidungen treffen kann (ziehe ich mir jetzt beim Einschalten der Lüftung zusätzliche Feuchtigkeit ins Haus oder nicht). Solange beide Rechenmethoden identisch sind, ist das Ergebnis bis auf die jeweilige Fehlerrate der Messwerterfassung irrelevant. Hier baut man einfach für diese Steuerung eine entsprechende Hysterese ein und gut.

Ich behaupte auch nicht, das die Dokumentation der Messgenauigkeit falsch ist. Deine Behauptung es werden diese und nur diese Geräte als Lieferant der Eingangswerte genutzt ist Blödsinn.

Hä? Kannst Du dieses Kauderwelsch mal in einen verständlichen Satz umwandeln? Der Hersteller gibt die Messtoleranz auf Basis der verwendeten Sensorik und ggf. notwendiger Eingangsbeschaltung an. Dort ist nun mal eine gewisse Fehlerbandbreite in den verwendeten Bauelementen vorhanden. Und in der Billighardware von Hausautomationssystemen steckt nun mal keine Hochpräzisionssensorik. Die muss nur die Genauigkeitsanforderungen erfüllen, die für die durchzuführenden Aufgabe zielführend sind. Und ob am Ende in einem Wohnraum 20,0°C oder 20,8°C "gemessen" werden. Ist es dem Anwender zu kühl, erhöht er die Solltemperatur. So wie er früher das Dehnkörperthermostat ein wenig weiter aufgedreht hat. Nur dass damals Nachkommastellen scheißegal waren.

Woher willst du wissen, wie weit der Messpunkt weg ist? Wieder eine an den Haaren herbeigezogene falsche Annahme.

Weiß ich nicht, darum hatte ich dieses als Frage formuliert (würdest Du lesen und verstehen und nicht nur überfliegen oder nicht lesen, wäre Dir das sicher aufgefallen) und fände es cool, wenn es so wäre. Aber ich halte es nun mal für statistisch relativ unwahrscheinlich, dass im nahen Umkreis Deines Wohnhauses mehrere (Deine Forumlierung! Du schreibst von Stationen) hochqualitative Wetterstationen ihren Dienst tun.

Die Qualität des Eingangswertes ist unbestimmt.
Die Verwendung des Wertes ist unbestimmt.

Ein paar Zeilen drüber hast Du noch anderes behauptet und zugegeben, dass die die Dokumentation der Messgenauigkeit nicht falsch ist. Ja was denn nun?

Gruß Xel66

PS: @MichaelN: Einerseits ja , andererseits läuft bei mir im Kopf ein Programm:

Code: Alles auswählen

WENN Bullshitdetektor bull erkannt bei Aktualisierung
DANN Faktencheck EIN verzögert um "wenn ich Bock habe" Sekunden

Glücklicherweise lese ich nicht überall mit und manchmal kann ich sogar dem Reflex widerstehen. Aber wenn ich die Gefahr sehe, dass irgendwelche Mitleser auf solchen Quatsch aufspringen könnten, kann ich nicht anders. Und meine Postings sind "sinnvolles" Training für meinen Zehnfingerschreibskill.
Und selbst in der aktuellen Politik sieht man wie auch hier, dass ein Mal gefasste Standpunkte selbst mit unabhängigen Fakten schlecht zu entkräften sind.