[Erl] Stringvariable bearbeiten

[Henke]

Wieder nur über überflogen und ich verzweifle. Letzter Versuch.

Die Qualität des Eingangswertes ist für mich als Entwickler unbestimmt und damit nicht relevant. Ich muss davon ausgehen, das die Qualität optimal ist und entsprechend programmieren.
Es geht dabei nicht um bestimmte Geräte und auch nicht um bestimmte Verwendungen der Ergebnisse.

[MichaelN]

Mein Gott, ihr habt beide recht.

Natürlich sollte ein Algorithmus so genau wie möglich arbeiten.

Andererseits ist die Genauigkeit immer begrenzt und muss daher mit dem Anwendungszweck abgeglichen werden.

In der Messtechnik ist es vollkommen üblich die systematischen und zufälligen Abweichungen zu betrachten und gemeinsam mit dem Messergebnis anzugeben. Solange sich diese in einem sinnvollen Verhältnis zur definierten Toleranz befindet, wird niemand Zeit und Geld in eine weitere Optimierung stecken.

[Xel66]

Ich muss davon ausgehen, das die Qualität optimal ist und entsprechend programmieren.

Davon kann man nur ausgehen, wenn man die in den Herstellerdokumenten dargelegten Messfehler ignoriert. Irgendwie ist das absolut an der Realität vorbei und eine merkwürdige Weltsicht. So kann nur jemand argumentieren, der noch nie mit Messtechnik zu tun hatte. Mit dem vorhandenen Equipment ist nun mal das von Dir vorausgesetzte Exaktheit nicht zu leisten und das hat der Hersteller auch so dokumentiert. Und Deine Kommastellen kannst Du somit in der Pfeife rauchen. Sie sind nichts wert, da der mögliche Berechnungsfehler durch Verringerung eben um Größenordnungen unterhalb des vom Bauteiledrift verursachten Messfehlers liegt. Die Welt ist nun mal nicht digital. Insofern hast Du recht eindeutig dokumentiert, dass ich das "Nuhr" eben ungebraucht zurückgeben kann.

Um mal wieder einen Autovergleich zu bemühen. Glaubst Du wirklich der in Deinem Fahrzeug angezeigten Geschwindigkeit? Allein schon durch Reifenabrieb über die Nutzungsdauer eines Reifens erlebt diese einen prinzipbedingten Drift. Von unterschiedlichen Reifendrücken wage ich noch nicht mal zu schreiben, denn der Zusammenhang ist auch eher analog. Und wenn Du diese Geschwindigkeit mit noch so viel Kommastellen betrachten würdest. Es gibt nur einen kurzen Zeitraum, in dem der stimmen kann (aber auch nicht stimmt, weil Tachos genau zu dieser Kompensation meist vor- aber nie nachgehen dürfen). Willkommen in der Realität hinter dem Display.

Gruß Xel66

[Henke]

Welcher Hersteller? Ich behaupte jetzt mal, bei mir wird nur der Wert der MOSMIX Station, geeicht und mit 2 Temperaturensensoren ausgerüstet, ausgewertet. Leider finde ich keine Herstellerdoku dazu. Das macht aber nichts, da dies kein Algorithmus ist, der versucht durch Messreihen oder durch bekannte Abweichungen bei bestimmten Werten den Wert zu optimieren. Er rechnet nur einfach aus 2 Werten 2 andere und das möglichst schnell und genau.

Allerdings nutzt ich auch Eingangswerte mit exakt 0 Messfehlern. Gibt es nicht? Oh doch. Das sind einfach generierte Werte um den Algorithmus zu testen.

Deine Vorgabe, es seien Homatic Geräte, die die Referenz darstellen ist falsch.
Da kann man genauso hingehen und Argumentieren:
Ich brauche die Ausgewertete nicht, damit sind keine Eingangswerte vorhanden und der Algorithmus ist überflüssig.

Was genau willst du eigentlich?
Darlegen das Aufgrund von Messtoleranzen ein Algorithmus problemlos ungenau/fehlerhaft programmiert werden kann/soll?
Das Abweichungen bei simplen Algorithmen von 0.2% in Ordnung sind und nicht einfach falsch gerechnet?
Und wieder so ein professioneller Autovergleich. Nimm mal das ABS und vergleiche da die Berechnungen.
Was du einfach nicht verstehst, ist das die Ausgabe/Anzeige der Werte nichts mit dem Algorithmus zu tun haben.

[Xel66]

Welcher Hersteller?

Der des Topics dieses Forums, und der den vermutlich die meisten Anwender hier einsetzen. Darum geht es hier. Wenn Du was anderes einsetzt (mache ich auch) schön für Dich. Ist aber eben leider nun mal nicht der "Standardanwendungsfall" für dieses Forum. Ich glaube kaum, dass ein nennenswerter Anteil der Anwender mit geeichter Messwerterfassung in ihrer Hausautomation arbeitet.

Allerdings nutzt ich auch Eingangswerte mit exakt 0 Messfehlern. Gibt es nicht? Oh doch. Das sind einfach generierte Werte um den Algorithmus zu testen.

Generierte Werte sind für den Praxiseinsatz nicht relevant. Hier müssen direkt ermittelte Umweltwerte (eben Temperatur/Feuchte) zum Einsatz kommen. Irgendwas aus ausgedachten Werten zu berechnen, testet zwar die Berechnung, hat aber in der folgenden Anwendung keine Relevanz.

Deine Vorgabe, es seien Homatic Geräte, die die Referenz darstellen ist falsch.

In diesem Forum und wenn es darum geht, aus den Quelldaten irgendwelche Sekundärdaten (hier absolute Luftfeuchte) mittels ReGa-Script zu errechnen schon. Darum ging es hier die ganze Zeit. Lesen und verstehen.

Da kann man genauso hingehen und Argumentieren:
Ich brauche die Ausgewertete nicht, damit sind keine Eingangswerte vorhanden und der Algorithmus ist überflüssig.

Ja, kann man, denn wenn man sie nicht verwendet, dann braucht man sie auch nicht vorzuhalten. Für eventuelle nachträgliche Auswertungen könnte man sie auch auf potenterer Hardware mit einem genaueren Algorithmus errechnen. Und um Werte lediglich anzuzeigen, kann man auch die Möglichkeiten des Visu-Servers nutzen. Der besitzt meist geeignetere Programmiersprachen. Benötigt man hier z.B. eine Feuchtewaage (vergleichende Berechnung, keine "echte Waage") für die Entscheidung, ob man lüftet und so ggf. feuchte Luft ins Haus ziehen könnte, dann braucht man das schon. Aber eben mit Berechnungen im Rahmen der Messgenauigkeit (bzw. zwei, drei Größenordnungen genauer). Das ist für den angestrebten Zweck mehr als ausreichend. Zusätzlich arbeite man dann noch mit einem Offset.

Was genau willst du eigentlich?

Habe ich bereits mehrmals geschrieben. Aber da kommst Du eben nie drauf, wenn Du nicht das liest, was ich schreibe. Es geht ganz einfach darum, dass die Aussage, dass es "übel" wäre, wenn man beispielsweise die Berechnung der absoluten Luftfeuchte mittels ReGa-Script mit "nur" sechs Nachkommastellen macht, einfach nur falsch ist. Der dadurch generierte Fehler läge weit unterhalb des Fehlers, der duruch die Missweisung der Sensorik verursacht werden kann. Es heißt ja nicht, dass die Sensoren so weit wirklich abweichen, aber das ist nun mal die Fehlertoleranz.

Und wieder so ein professioneller Autovergleich. Nimm mal das ABS und vergleiche da die Berechnungen.

Wie das genau gemacht wird, entzieht sich meiner Kenntnis. Aber in km/h rechnen die definitiv nicht. Dort wird an den einzelnen Rädern die Drehzahl in Größenordnung eines Drehwinkels mittels Hallsensoren in relativ kleiner Auflösung ermittelt, um auch kleine Unterschiede, die durch Schlupf entstehen, zu erfassen.

Was du einfach nicht verstehst, ist das die Ausgabe/Anzeige der Werte nichts mit dem Algorithmus zu tun haben.

Was Du nicht verstehst ist, dass Messwerte grundsätzlich auch unter Berücksichtigung ihres angegebenen Messfehlers beurteilt werden müssen und die Genauigkeit einer nachträglichen Berechnung nicht um Dimensionen genauer sein muss (x Nachkommastellen) als dass der Fehler in der Messwerterfassung selbst verursacht. Sie sollte keine zusätzlichen Fehler in gleicher Größenordnung verursachen, aber sechs Größenordnungen (Stellen nach dem Komma) reichen für den Anwendungszweck mehr als aus, wenn der Fehler der Datenquelle schon in der ersten Dezimalstelle und davor steckt. Das ist das "Problem". Es ist einfach falsch, Anwendern zu suggerieren, man müsse mit möglichst vielen Nachkommastellen rechnen und deren Reduzierung ergäbe ein "übles" Ergebnis. Dein Anspruch ist, als würdest Du eine Armbanduhr mit der der Anzeige in Millisekunden benutzen. Es gibt sicher einzelne Anwendungen dafür, aber im Normalfall reichen Stunden und Minuten (Sekunden) aus. Anderes Beispiel: Abwiegen eines Sandhaufens mit der Laborwaage. Die Genauigkeit im mg-Bereich ist auch vernachlässigbar, wenn das kleinste Maß die Menge auf einer Schaufel ist.

Erfahrungsgemäß findet man solche zweifelhaften Aussagen mit dem Beisatz "ich habe igendwo im Internet gelesen/ bei YT gesehen, dass..." ungeprüft und unkommentiert wieder. Und darum mein Beitrag hier. Hameln ist eben überall! Zwei Beispiele für Folgen solcher Falschdarstellungen sind, dass Anwender an der Kommastelle ihrer Thermostate kleben und mit "Vergleichsmessungen" sich beschweren, dass das System ungenau regelt. Das andere Beispiel einer solchen immer wiederholten Falschaussage ist, dass alle Programme beim Systemstart "abgearbeitet" würden. Und dann folgen alle dem Rat, den iseID950-Workaround in alle Programme zu integrieren, egal ob es einen Sinn ergibt oder nicht, weil weder die Arbeitsweise des Workarounds und seine negativen Auswirkungen (z.B. bei Verwendung einen SONST) noch die Arbeitsweise der normalen Programmabarbeitung bekannt sind.

Gruß Xel66

[Henke]

Es geht ganz einfach darum, dass die Aussage, dass es "übel" wäre, wenn man beispielsweise die Berechnung der absoluten Luftfeuchte mittels ReGa-Script mit "nur" sechs Nachkommastellen macht, einfach nur falsch ist.

Gut, dann versuche mal dich darauf zu konzentrieren.
Es muss unterschieden werden, wie schön häufig erwähnt, die Rega rechnet nicht mit 6 Nachtkomma stellen. Sie rechnet bei float mit 16 bit Genauigkeit. Das ist durchaus Ausreichend insbesondere wenn man nicht unnötig viel hin und her rechnet.

Kommen wir zum "wäre":
Würden die Berechnungen auf Basis "6 Nachkommastellen" laufen, kommt es zu fehlerbehafteten Ergebnissen, da hier unter anderem exp und pow oder exp10 und pow10 verwendet wird. Bei diesen Funktionen eine Ungenauigkeit auf 6 Nachkommastellen zu produzieren ist nicht einfach, aber auch so ist schnell demonstriert, wie ungenau es wird. Bei diesem Beispiel werden die exp und pow nicht verändert, das ist mir zu viel Aufwand und es werden die 6 Stellen gerundet, was auch harmloser ist als wenn nur mit 6 Stellen gerechnet wird. Trotzdem kommen so schon unterschiedliche Ergebnisse, auch bei einer Rundung auf 0 Nachkommastellen des Ergebnisses. D.h. selbst eine Anzeige gerundet auf Grad wäre falsch.

Code: Alles auswählen

let rund = 100;
let err = false;
function makeErr(aa) {
	if (!err) {
		//    let ret = Number(Number.parseFloat(aa).toFixed(6));
		//    console.log (aa, ret );
		return aa;
	}
	let ret = Number(Number.parseFloat(aa).toFixed(6));
//  ret = Math.floor(aa*1000000)/1000000;
	//console.log (aa, ret );
	return ret;
}

const rA = 7.5;
const rB = 237.3; // für T >= 0
const rR = 8314.3; // J / (kmol * K)(universelle Gaskonstante)
const rMw = 18.016; // kg / kmol(Molekulargewicht des Wasserdampfes)
const tpXX = makeErr(makeErr(rMw / rR) * 6.1078);
const rKelvin = 273.15;

function TaupunktFeuchte(Temp, Feuchte) {
	const tRef = makeErr(makeErr(rA * Temp) / makeErr(rB + Temp));
	//		Logg.info ( tRef );
	// obj.temp.Taupunkt = Number( Math.round ( (rB * rV / (rA - rV))*100)/100);
	// obj.huminity.AbsFeuchte = Number(Math.round(((Math.pow(10.0, 5.0) * (rMw / rR) * 6.1078 *rDD / (tInTemp + rKelvin)) * 100)) / 100);
	let Out = {};
	const rV2 = makeErr(tRef) + makeErr(makeErr(Math.log(Feuchte / 100.0)) / makeErr(Math.log(10)));
	Out.Taupunkt = Math.round(makeErr(makeErr(rB * rV2) / makeErr(rA - rV2)) * rund) / rund; 	// °C
	Out.AbsFeuchte = Math.round(Number(makeErr(makeErr(Math.pow(10.0, 3.0 + tRef)) * tpXX) * Feuchte / (Temp + rKelvin))*rund) / rund; // g/m³ 
	//	Logg.info ( Out.AbsFeuchte );
	return Out;
}

rund = 1;
  for (let feuchte = 1; feuchte <= 100; feuchte++)
		for (let temp = 0; temp < 60; temp+=0.1) {
			err = false;
			let tf = TaupunktFeuchte(temp, feuchte)
			err = true;
			let tfErr = TaupunktFeuchte(temp, feuchte);
			if ((tf.Taupunkt != tfErr.Taupunkt) || (tf.AbsFeuchte != tfErr.AbsFeuchte))
				console.log(Math.round(temp), feuchte, tf, tfErr)
		}

Einfach zu testen mit: https://developer.mozilla.org/en-US/doc ... Math/log10
Dabei ist dies nur eine Berechnung. Zur Berechnung der Wandfeuchte läuft das in der Art 3 mal und der Fehler würde sich multiplizieren.
Als Beispiel für so etwas, mal ein Kuchen der Aufgeteilt mit 6 Nachkommastellen mal wächst oder plötzlich weg ist:

Code: Alles auswählen

let rundung = true;
function KuchenTeilen ( k )
  {
    if ( rundung)
    return Math.round(k*0.333333 * 1000000)/1000000;
	    return k/3;
  }

function KuchenZusammen ( k )
  {
    if ( rundung)
    return Math.round(k/0.333333 * 1000000)/1000000;
    return k*3;
  }

function mix (stück, it)
  {
    for ( let i = 0;  i<=it; i ++ )
  {
    stück = KuchenTeilen ( stück);
  }

// console.log ( stück );

for ( let i = 0;  i<=it; i ++ )
  {
    stück = KuchenZusammen ( stück);
  }
return stück;
  }

let kuchen = 1;

rundung = true;
console.log ( "Gerundet 12 Iterationen, und der Kuchen ist nun 60% größer", mix (kuchen,12));
rundung = false;
console.log ( "Nicht gerundet", mix (kuchen,12));

rundung = true;
console.log ( "Gerundet 15 Iterationen, Kuchen weg", mix (kuchen,15));
rundung = false;
console.log ( "Nicht gerundet", mix (kuchen,15));

Also, hiermit fordere ich dich auf, die Behauptung meine Aussage ist falsch zurückzunehmen oder einen Beweis zu erbringen.

Bedenke, es geht nicht um die Qualität der Eingangswerte. Es geht ausschließlich darum, das eine Berechnung der absoluten Luftfeuchte mit 6 Nachkommastellen übel wäre. Nicht mehr, nicht weniger.

[Xel66]

Also, hiermit fordere ich dich auf, die Behauptung meine Aussage ist falsch zurückzunehmen oder einen Beweis zu erbringen.

Nö, nicht nötig. Dieser Code ist kein ReGa-Script und darum setze ich mich damit gar nicht erst auseinander. Und genau um diese Diskussion geht es hier. Referenzhardware des Normalanwenders: Hm(IP)-Sensorik und verwendetes Script ReGa auf einem CCU-OCCU-Design. Alles andere diskutiere ich nicht. Dazu eben Nuhr. Da Du Funktionen nutzt, die ReGa-Script gar nicht erst zur Verfügung stellt, ist mir deren Genauigkeit auch Schnuppe.

Noch mal, diese Forum heißt "HomeMatic-Forum" und wir befinden uns in einem Forenbereich, der sich mit der CCUx und deren Onbord-Möglichkeiten beschäftigt. Für die Diskussion externer Lösungen gibt es andere Forenbereiche. Bei meinen Betrachtungen geht es ausschließlich darum, ob die ermittelten Werte für die Automatisierung auf der CCU herangezogen werden können (in diesem Beispiel eben eine Luftfeuchtewaage zur Entscheidungsfindung, ob man sich durch das Aktivieren der Lüftung zusätzliche Feuchtigkeit ins Haus holt). Irgendwelche Anzeigefeatures sind mir ebenso egal, da ich keine Visualisierung benutze. Ich betreibe Hausautomation und keine -fernsteuerung mittels Wischi-Waschi. Und warum betrachte ich das so? Weil nämlich vormals angeführte Anwender ("... irgendwo im Internet gelesen, dass...") das genau so in diesem Kontext Homematic hier lesen.

Bedenke, es geht nicht um die Qualität der Eingangswerte. Es geht ausschließlich darum, das eine Berechnung der absoluten Luftfeuchte mit 6 Nachkommastellen übel wäre. Nicht mehr, nicht weniger.

Doch, solange der Rechenfehler unterhalb der Ergebnisschwankung durch Varianz der Messwertgenauigkeit liegt, ist alles in Butter. Und wenn man die gängigen ReGa-Scripte für die CCU zur Anwendung bringt, dann ist das so.

Gruß Xel66

[Henke]

Ignoranz pur. Es geht nicht um Rega Scripte oder Referenzhardware. Es geht um die Auswirkung von nur 6 Nachkommastellen. Wäre, hypothetisch und
daher ist es egal bei dem Beweis in welcher Sprache es geschrieben ist.

Da du wohl viel Erfahrung in der Messtechnik hast, kannst du mir bestimmt erklären wie die angegebenen Messtoleranzen von HM zu verstehen sind.
Sagt diese Toleranz aus, das der gemessene Wert eine maximale Abweichung vom realen Wert haben kann oder bedeutet es, das jede Messung um diesen Wert schwanken kann?

Beispiel, Abweichung 0.5 Kelvin:
Zeit Real Gemessen
A:
10.00 21.0 21.5
11.00 21.0 21.0
12.00 21.0 20.5

oder
B:
10.00 21.0 21.5
11.00 21.0 21.4
12.00 21.0 21.5

Meine Erfahrung ist eigentlich das die Werte nach B kommen. Es sind keine Sprünge in den Diagrammen vorhanden und auch die Steuerung des FALMOT pulsiert nicht.

[Xel66]

Es geht nicht um Rega Scripte oder Referenzhardware.

Doch, darum geht es.

Und bezüglich Deiner Tabelle und Regelung. Dir ist aber schon bewusst, dass die Messwerte erstens zyklisch übertragen werden und die Regelungen mit Hysteresen arbeiten (wie fast jede industrieelle Regelung) und wenn die Daten immer vom gleichen Sensor kommen, die Missweisung ja konstant ist.

Gruß Xel66

[Henke]

Nö