ReadingsNum und sehr kleine Zahlen wie 2e-05

[AlexMuc]

Hallo zusammen,
mein Wechselrichter liefert morgens ganz zu Anfang naturbedingt noch sehr wenig Energie. Da tauchen dann Werte wie zB 2e-05 auf.
Verwende ich ReadingsVal, so wird in weiteren Berechnungen der "Text" des Readings korrekt zu 0,00002 konvertiert. ReadingsNum dagegen liefert dann 2 als Zahlenwert... Ich hab das vorläufig abgefangen indem ich die per HttpMod eingehenden Werte formatiert ausgeben lasse aber so wirklich im Sinne des Erfinders (ReadingsNum sollte möglichst immer die korrekte Zahl zurück geben) kann das doch nicht sein.
Auf der Suche nach einer Lösung min ich über einige Beiträge gestolpert, die "intern" bei solchen Umwandlungen potentiell Einheiten "entfernen / strippen". Scheinbar gehen ReadingsVal und ReadingsNum hier eigene Wege wobei der von ReadingsVal bei diesem Beispiel der bessere / richtigere zu sein scheint.
Wer kennt sich mit den FHEM Interna aus und könnte dieses "Problem" beheben?

[Otto123]

Hi,

so wirklich im Sinne des Erfinders

oder im Auge des Betrachters das soll ReadingsNum machen:
https://wiki.fhem.de/wiki/DevelopmentModuleAPI#ReadingsNum

Interessant - aber es ist scheinbar so: Bei ReadingsVal wird die Textkette gelesen und Perl interpretiert die Zahl richtig.
ReadingsNum ist der Text egal, der extrahiert die erste Zahl in der Zeichenkette.

Gruß Otto

[rudolfkoenig]

Bin unschluessig: eigentlich hat AlexMuc recht, andererseits wuerde eine Aenderung womoeglich funktionierenden Code brechen, da ReadingsNum alt ist.

Die Frage gehoert in einem anderen Forumsbereich, sonst liest das kaum jemand mit relevanter Meinung

[betateilchen]

Da tauchen dann Werte wie zB 2e-05 auf.

Nur der numerische Wert oder auch noch mit einer Einheit dahinter?

Könnte man ReadingsNum() nicht so erweitern, dass der Wert unverändert zurückgegeben wird, wenn ReadingsVal() schon einen rein numerischen Wert liefert?

Code Auswählen Erweitern

{looks_like_number "2e-05"}
erkennt den Wert zumindest als Zahl und liefert 1 zurück.

[AlexMuc]

Wohin mit dem Thread, bin für alle Verschiebungen offen

@Otto:
Dein Link hilft nicht wirklich, da wird mein Problem nicht beschrieben. Der Wert der Zahl wird ja vom Wechselrichter geliefert, der Inhalt des Readings ist also vorhanden und praktisch auch eine gültige Zahl.
Bei meiner Ursachenforschung bin ich im Forum schon über Diskussionen gestolpert bei deren um Einheiten in Readings geht und das mancher ziemliche Verrenkungen macht, um selbige aus Readings zu entfernen. Und ich vermute, das die beiden Funktionen von unterschiedlichen Leuten betreut werden die unterschiedlich vorgehen und einer die Notation von Zahlen in Exponentioalschreibweise bei seiner Arbeit nicht auf dem Schirm hatte. Was kein Vorwurf sein soll.

@Rudolf:
Das hab ich befürchtet und mich gewundert, das ausgerechnet mir als Laie das jetzt auffällt bzw auf die Nase gefallen ist. Das sehe ich als Wunder

Was nun die genaue Ursache ist und wie man das ohne irgendwelche Kollateralschäden beheben kann, das mögen die Weisen im Forum unter sich klären. Zumindest könnte es sinnvoll sein, wenn in dem Artikel aus Ottos Link ein kleines ACHTUNG auftaucht, das ReadingsNum momentan ein "kleines" Problem mit gewissen Zahlen hat.

Gruß
Michael

[betateilchen]

Wohin mit dem Thread, bin für alle Verschiebungen offen

Der Thread wurde schon verschoben.

Naja, ReadingsNum() hat auch in bestimmten anderen Fällen Probleme mit dem korrekte Extrahieren von Zahlenwerten. Vor einiger Zeit bin ich in einer meiner Installationen schonmal über das Thema gestolpert, weiß aber aktuell nicht mehr, was damals das konkrete Szenario war. Seinerzeit hatte ich mir mit einer eigenen Funktion in myUtils beholfen.

Und ich vermute, das die beiden Funktionen von unterschiedlichen Leuten betreut werden die unterschiedlich vorgehen und einer die Notation von Zahlen in Exponentioalschreibweise bei seiner Arbeit nicht auf dem Schirm hatte.

Nein. ReadingsNum() und ReadingsVal() sind beides Kernfunktionen von FHEM, die in der fhem.pl verankert sind.

ReadingsNum() verwendet intern zuerst ReadingsVal(), um den zu untersuchenden String zu ermitteln. Dann wird mit einer regex versucht, aus dem String numerische Teile zu extrahieren. Damit können prinzipbedingt nicht 100% aller denkbaren Darstellungsfälle abgedeckt werden.

[erwin]

pragramatischer Ansatz:
Wenn man ganz sicher ist, dass das reading ausschließlich Zahlen enthält -> readingsVal verwenden! evtl anschließend runden/formatieren...

readingsNum wurde für solche szenarien entwickelt:

Code Auswählen Erweitern

setreading Ptest test abrakadabra12.34ist Zauberei
{ReadingsNum('Ptest','test',0)}
ergibt: 12.34
das aufzudröseln / backward kompatibel zu lösen wird schwierig, zumal es ja auch module gibt, die value und unit zusammengeschrieben in readings schreiben.
Zum Nachdenken, Beispiel text: 'der wert ist zwischen hex 2e-30 gültig' ? was soll da eurer Meinung nach rauskommen?

etwas abwegig finde ich allerdings 2e-05 als Wert (W/kW)? von einem Wechselrichter - das ist jedenfalls jenseits jeder Messgenauigkeit...Da wäre mein Ansatz für einen fix!
l.g. erwin

[betateilchen]

etwas abwegig finde ich allerdings 2e-05 als Wert (W/kW)? von einem Wechselrichter - das ist jedenfalls jenseits jeder Messgenauigkeit...Da wäre mein Ansatz für einen fix!

Darauf wollte ich nicht explizit eingehen, ich sehe das aber ähnlich. Da würde ich schon in HTTPMOD oder JsonMod oder wo auch immer die Werte eingelesen werden, dafür sorgen, dass Werte < 1 als 0 interpretiert werden.

[AlexMuc]

@erwin:
Wenn das so ist, dann hab ich tatsächlich den vorgesehenen Einsatzzweck für ReadingsNum falsch verstanden. Ich dachte, man nimmt es, wann immer man eine Zahl aus einem Reading holen will. Wenn es aber ,,nur" dazu dient, möglichst einfach eine Zahl aus einem Text herauszuoperieren, dann wechsel ich wieder zurück auf ReadingsVal.

@betateilchen:
Ich müßte nochmal die Logs prüfen, ob diese Zahl erst entstanden ist, nachdem ich die Energie zweier Strings addiert hab oder die schon in den Eingangsreadings auftauchen. Klar ist auch, das in meinem speziellen Fall da eher ne klare 0 sein sollte und ich das inzwischen für mich ja auch gelöst habe.

@alle:
Wenn keiner was dagegen hat, können wir den von mir angestoßenen Sturm im Wasserglas beenden. Außer es findet noch jemand einen wichtigen Grund doch weiterzumachen

[rudolfkoenig]

Könnte man ReadingsNum() nicht so erweitern, dass der Wert unverändert zurückgegeben wird, wenn ReadingsVal() schon einen rein numerischen Wert liefert?

Das habe ich jetzt wie vorgeschlagen gemacht.

Ich glaube, dass wir moegliche Problem-Meldungen damit erfolgreich niederdiskutieren koennen

[betateilchen]

Ich glaube, dass wir moegliche Problem-Meldungen damit erfolgreich niederdiskutieren koennen

Das hoffe ich auch. Auf meine Unterstützung kannst Du dabei zählen

[frober]

Hi, prinzipiell eine gute Lösung, nur funktioniert das Runden so nicht mehr, wenn direkt eine Zahl geliefert wird.

Klar kann man das auch anders lösen, aber es stiftet Verwirrung, wenn Runden mal funktioniert mal nicht...

Vorschlag:

Code Auswählen Erweitern

return round($val,$round) if(looks_like_number($val));

...ich hoffe ich habe nichts übersehen.

Nachtrag,:

Code Auswählen Erweitern

if(defined $round)
fehlt, wie macht man das am besten, 2 Zeilen?

Code Auswählen Erweitern

return round($val,$round) if(looks_like_number($val) && defined $round);
return $val if(looks_like_number($val));


[noansi]

Hallo Rudolf,

Bin unschluessig: eigentlich hat AlexMuc recht, andererseits wuerde eine Aenderung womoeglich funktionierenden Code brechen, da ReadingsNum alt ist.

Wird zwei Zeilen nach dem Fix zutreffen betateilchen, octal numbers, da z.B.

Code Auswählen Erweitern

{ looks_like_number("04") }oder

Code Auswählen Erweitern

{ looks_like_number("04.3") }
eine 1 liefert.
Damit wird der Octal Fix nicht mehr erreicht.

Warum soll wissenschaftliche Notation nicht einfach auch als Num erlaubt werden?:

Code Auswählen Erweitern

  $val = ($val =~ m/([-]?\d+(?:\.\d+)?(?:[eE][-+]?\d+)?)/ ? $1 : '');statt nur

Code Auswählen Erweitern

  $val = ($val =~ /(-?\d+(\.\d+)?)/ ? $1 : "");
Gruß, Ansgar.

Edit: InternalNum ist bezüglich beider Probleme/Fragestellungen ebenfalls betroffen und die Verwirrung wäre geringer, würden sich InternalNum und ReadingsNum gleich verhalten.

[rudolfkoenig]

Offensichtlich war mein Gefuehl, dass eine beliebige Aenderung im alten Code Probleme verursacht richtig, und dass man die kleine Aenderung niederdiskutieren kann, falsch.

Warum soll wissenschaftliche Notation nicht einfach auch als Num erlaubt werden?:

Weil ein Regexp dafuer nicht einfach ist, deine Version erwischt z.Bsp. .12 nicht.
Ich habe jetzt die Version aus dem perl cookbook genommen, und looks_like_numer rausgeschmissen.

InternalNum ist bezüglich beider Probleme/Fragestellungen ebenfalls betroffen und die Verwirrung wäre geringer, würden sich InternalNum und ReadingsNum gleich verhalten.

Danke fuer den Hinweis, ab sofort wird aus allen drei "Num" Funktionen die neue numberFromString aufgerufen.

[noansi]

Hallo Rudolf,

Weil ein Regexp dafuer nicht einfach ist, deine Version erwischt z.Bsp. .12 nicht.

Korrekt und korrekt.

Ich hatte aus der alten regexp interpretiert, dass so "kaputte" Zahlen nicht erwünscht sind und waren.

Mit der von Dir gewählten C-Style Variante wäre auch ein Reading/Internal

Code Auswählen Erweitern

Das ist ein mehrdeutiges Reading.12Uhr könnte gemeint sein.eher problematisch bezüglich Kompatibilität.

Wenn sich keine Nebenwirkungen an bestehendem Code durch diese größere Offenheit ergeben, würde ich jedoch Deine Variante ebenfalls bevorzugen.

Gruß, Ansgar.

[betateilchen]

Zahlenwerte aus einem String zu extrahieren, ist in jeder Programmiersprache eine Herausforderung, nicht nur in perl. Das wird vermutlich nie alle denkbaren Konstellationen zu 100% abdecken können. Man sollte ReadingsNum() als mögliches Hilfsmittel betrachten, nicht als mathematische Funktion.

Eine andere interessante Konstellation ist beispielsweise die Situation, wenn in einem String zwei oder mehr Zahlenblöcke vorkommen. Dann müsste man eigentlich ein array mit Werten zurückgeben, denn ReadingsNum() kann ja nicht wissen oder entscheiden, welchen Zahlenwert ich haben möchte. Und ob das Runden dann für alle Werte gewünscht ist, ist auch noch unklar *duck-und-weg* 

[noansi]

Dann müsste man eigentlich ein array mit Werten zurückgeben, denn ReadingsNum() kann ja nicht wissen oder entscheiden

Soll sie auch nicht, denn eine solche Funktion sollte als ReadingsNums() ergänzt werden, wenn Bedarf danach besteht. 

[Otto123]

Ich will ja keine Verbesserung ausbremsen, aber für mich war ReadingsNum() immer so zu verstehen: extrahiert die erste Zahl aus der Zeichenkette...

Die Funktion ReadingsNum extrahiert den numerischen Teil des Readings $reading der Definition $name und gibt diesen zurück, wenn er existiert. Dabei werden Zeichenketten wie z.B. Einheiten eliminiert und nur die eigentliche Zahl (Ganzzahl- oder Fließkommazahl) zurückgegeben.

Insofern habe ich auch ganz am Anfang von dem Thread verstanden, dass exponential Darstellung wahrscheinlich "hintenrunterfällt"
Wird das Problem jetzt noch größer wenn ich die analoge Funktion in set magic ins Spiel bringe?

Ab featurelevel 5.7 ersetzt der set und setreading Befehl
[device:name] mit dem Wert des Readings, Internals oder Attributes für device, falls sowohl device, als auch Reading, Internal oder Attribut existiert, und nicht leer ist.
Man kann einen der Präfixe r:, i: oder a: verwenden, um die Suche einzuschränken, genau wie im devspec.
Das Suffix :d extrahiert die erste Zahl.

Das Wort Zahl am Schluss kann man ja auch wieder sehr vielfältig interpretieren.
Wieviele Zahlensysteme gibt es? hex oktal binär ...   

[betateilchen]

Bevor die Diskussion weiter ausufert, weil meine Anmerkung wieder mal völlig falsch interpretiert wird, möchte ich hiermit klarstellen, dass meine Text mit den mehrfachen Zahlenwerten lediglich ein Beispiel dafür war, was man an ReadingsNum() noch "bemängeln" könnte, wenn man wollte. Es war aber kein Feature-Request.

[noansi]

Hallo Rudolf,

Das Suffix :d extrahiert die erste Zahl.

Korrekt, hier fällt die Exponentialdarstellung ebenfalls hinten runter.

AttrNum läßt die Exponentialdarstellung ebenfalls nicht zu. Gefühlt würde ich numberFromString bei AttrNum wegen möglicher Oktal-Nebenwirkungen und default Behandlung jedoch nicht anwenden, sondern nur auf Exponentialdarstellung erweitern, solltest Du es ändern.

Gruß, Ansgar.

[betateilchen]

Die Büchse der Pandora...

[Otto123]

ich wollte auch keinen Feature-Request, ich bin eher für Büchse wieder schließen. Lasst es so wie es war und kommuniziert es so.

[noansi]

Meinerseits handelt es sich lediglich um eine Ergänzung der Code Analyse, wo AlexMuc Ausgangsproblem in der Zukunft ebenfalls mal wegen Fließkommadarstellungseinschränkung auftreten kann.

Was bedeutet, das der betroffene Code bis dahin noch älter ist und damit die Wahrscheinlichkeit für Nebenwirkungen durch Änderung zu diesem Zeitpunkt nicht kleiner wird.

Konkrete Probleme habe ich derzeit nicht mit den genannten Funktionen, da ich sie nicht oder nicht in der Problemform benutze.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

über das Geplänkel, ob an anderer Stelle noch Änderungen sinnvoll sein könnten, ist leider der Test der Änderung selbst zu kurz gekommen.

Und mir ist noch was bezüglich Default Behandlung aufgefallen.

An den relevanten Stellen wird numberFromString in der Art aufgerufen:

Code Auswählen Erweitern

vergiss esDadurch, dass in diesem Beispiel ReadingsVal mit $default aufgerufen wird, wird ReadingsVal $default zurück liefern, wenn das Reading nicht existiert.
Ist $default selbst eine Zahl oder enthält eine Zahl, dann wird in numberFromString der zurück gelieferte Default als
- gültiges Zahlergebnis behandelt, also um den ggf. enthaltenen Text beraubt
- und manipuliert, also ggf. gerundet

Das widerspricht der von Otto schon angemerkten Beschreibung https://wiki.fhem.de/wiki/DevelopmentModuleAPI#ReadingsNum und wohl auch der Intention.

Vorschlag:

Code Auswählen Erweitern

vergiss esReadingsVal würde mit dem Default undef undef liefern, wenn das Reading nicht existiert. (natürlich singemäß an den anderen beiden Verwendungstellen auch)
Und

Code Auswählen Erweitern

vergiss eswürde dann und wenn das Reading keine Zahl enthält den $default unmanipuliert zurück liefern, entsprechend Beschreibung.

Edit: Und da das im alten Code auch schon so war, wäre die Alternativlösung die Beschreibung dem Code anzupassen.
Edit2: Sorry, im Kleingedruckten habe ich doch noch entdeckt, dass das Runden den Defaults beabsichtigt ist. "Der ermittelte Wert, ob Standard oder aus einem Reading, wird auf $round Anzahl Stellen gerundet." Jedoch passiert dies nicht, wenn im Reading keine Zahl vorkommt.
Edit3: Letzteres, also das uneinheitliche Rundungsverhalten hat mich überhaupt motiviert einen Bug zu vermuten. Jedoch bietet es die Möglichkeit, mit Runden zu unterscheiden, was beim Reading schief gelaufen sein könnte, wenn der Default auf die ein oder andere Art zurück geliefert wird. Das könnte Absicht gewesen sein, ist jedoch nicht aus der Beschreibung oder Code Kommentaren ersichtlich.

Gruß, Ansgar.

PS: Und zu dem Oktal Problem, gebe ich im Webbrowser

Code Auswählen Erweitern

{ReadingsNum("bla","blub","0672.9840")}ein, erhalte ich 0672.9840 als Antwort. Device "bla" und Reading "blub" exisitieren in meinem System nicht

Code Auswählen Erweitern

{ReadingsNum("bla","blub",0672.9840)}liefert dagegen das unerwünschte 4429840, d.h. in diesem Fall wirkt der Oktal Fix nicht (auch nicht in der aktuellen code Version im SVN). Die Oktal-Interpretation passiert in diesem Fall schon vorher. Getestet mit perl Version 5.14.2. Das als Randbemerkung, falls es mal relevant sein sollte.

[rudolfkoenig]

liefert dagegen das unerwünschte 4429840

Meine Meinung dazu: der Benutzer hat in der Hand die default Werte zu setzen.

[betateilchen]

Wenn ReadingsNum() in einem existierenden reading keinen Zahlenwert findet, weil da z.B. "abc" drinsteht, wird der angegebene default-Wert von ReadingsNum() zurückgegeben. Ich grüble seit zwei Tagen, ob das Verhalten wirklich richtig ist. Außerdem habe ich noch nie verstanden, warum ReadingsNum() überhaupt alphanumerische default-Werte zulässt.

[noansi]

Hallo betateilchen,

statt "abc" könnte da auch, z.B. beim FHEM Start oder Wiederverbinden vom Device, "noch nicht empfangen" drin sein und denoch würde ReadingsNum den default liefern. So weit gut.

Der default Wert wiederum kann statt einer Zahl auch undef sein, was effizient wäre zur unspezifischen Fehlerbehandlung, kann aber auch ein Fehlertext sein, auf den verglichen werden kann. Der default kann z.B. auch wiederum ein Aufruf von ReadingsVal oder einer anderen Funktion sein, was ggf. wiederum verschiedene Texte oder Fehlertexte liefern könnte, auf die verglichen werden kann.

Mal so ein paar Gedanken zur Intention und Flexibilität und, wie Rudolf schon geschrieben hat, "der Benutzer hat in der Hand die default Werte zu setzen".
Wenn das schon mal so genutzt wurde und das Verhalten wird geändert, dann hüpft die Büchse der Pandora vor Freude...

Blöd nur, wenn der Text oder Fehlertext doch mal eine Ziffer oder Zahl enthält und das Reading nicht existiert im Vergleich zu Reading existiert aber enthält puren Text wie "abc" oder ist einfach nur "". Dann kommt nur die Ziffer oder Zahl (ggf. mit Rundungserweiterung) statt des vollständigen default Textes oder es kommt der vollständige default Text mit Nummer und wenn das nicht beachtet wird oder nicht bewusst ist, dann heist es mühsames Debuggen von Ausnahmefällen.
Das ist quasi die Steigerung der "Default Rundungsvarianz", die ich oben bereits beschrieben hatte.

Gruß, Ansgar.

PS: Es fällt schwer, einen nicht numerischen Default bei ReadingsNum in den Modulen zu finden, in 10_CUL_HM.pm habe ich es jedoch exemplarisch in Form von

Code Auswählen Erweitern

      my $d = ReadingsNum($name,'temperature','');
      CUL_HM_Set($hash,$name,"virtTemp",$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
      $d = ReadingsNum($name,"humidity","");
      CUL_HM_Set($hash,$name,"virtHum" ,$d) if($d =~ m/^[-+]?[0-9]+\.?[0-9]*$/);
im SVN gefunden. Die Büchse der Pandora steht also in den Startlöchern. 
Und ich habe nicht sämtliche Module durchsucht.

PS2: In numberFromString

Code Auswählen Erweitern

  $val = ($val =~ /(([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?)/ ? $1 : "");
  $val =~ s/^([+-]?)0+([1-9])/$1$2/; # Forum #135120, dont want octal numbers
  return $default if($val eq "");
würde mit Texten ein wenig effizienter den default mit

Code Auswählen Erweitern

  $val = ($val =~ /(([+-]?)(?=\d|\.\d)\d*(\.\d*)?([Ee]([+-]?\d+))?)/ ? $1 : "");
  return $default if($val eq "");
  $val =~ s/^([+-]?)0+([1-9])/$1$2/; # Forum #135120, dont want octal numbers
liefern.

PS3: In 59_HCS.pm habe ich ebenfalls ReadingsNum mit Text default gefunden:

Code Auswählen Erweitern

    $devs{$d}{tempDesired}  = ReadingsNum($d,"setpointTemp","n/a",1)          if($t =~ m/(ZWave)/);... und "Fehlerauswertung"

Code Auswählen Erweitern

    if($mode eq "thermostat" && ($devs{$d}{tempMeasured} eq "n/a" || $devs{$d}{tempDesired} eq "n/a")) {Und ich habe nicht sämtliche Module durchsucht.

[betateilchen]

ReadingsNum() mit alphanumerischen Defaultwerten sind mir bisher hauptsächlich in Code-Auszügen von fragestellenden Forumteilnehmern untergekommen, und genau da finde ich es besonders problematisch, dass das überhaupt funktioniert.