Initialstart mit FBAHAHTML / Umgang mit Einheiten bei Messwerten

Begonnen von hartenthaler, 14 Oktober 2016, 00:42:21

Vorheriges Thema - Nächstes Thema

hartenthaler

Ich habe gestern Abend in einer neuen fhem-Installation zum ersten Mal FBAHAHTML genutzt. Hat erst einmal gut funktioniert. Drei DECT200-Steckdosen und eine Gruppe wurden problemlos angelegt. Schade, dass die Readings für voltage und current nicht mehr da sind.

Heute früh bin erschrocken, als mein Wasserkocher laut SVG-Grafik 1,8 Megawatt gezogen hat. Hatte schon Bedenken, dass nun die Stromleitungen bis zum nächsten Kraftwerk durchgebrutzelt sind. Beim zweiten Hinsehen war es aber nur ein Tippfehler:
Die Achsbeschriftung im Plot muss bitte geändert werden: statt "Power (kW)" muss es dort "Power / W" heißen (bedeutet Power (gemessen in Watt) dividiert durch W ergibt eine dimensionslose Zahl, die auf der Achse aufgetragen wird; alternativ könnte man die Achse mit dimensionsbehafteten Zahlen, also 0 W ... 1000 W, beschriften). Habe ich natürlich in meinem Plot gleich geändert.

Darüber hinaus ist die Einheit des temperature-Readings falsch: dort muss es "°C" statt "C" heißen, denn Temperaturen werden in Grad Celsius und nicht in Coulomb gemessen (das war auch früher schon falsch).

Das FBDECT-Device ist eines der wenigen in fhem, das dimensionsbehaftete Werte verwendet. Ich denke, dass ein generelles Konzept zum Umgang von Größen mit Einheiten in fhem dringend nötig ist. So wie hier ist es nicht konsequent. Bei meinen 1,8 Megawatt ist ja nicht wirklich etwas passiert und es hat wohl niemand vor ein autonom fahrendes Auto mit fhem zu steuern (aber nun, warum denn nicht; was weiß ich, was morgen passiert); zumindest habe ich gestern von der Nutzung von fhem in einem Wohnmobil gelesen und auch von einem Nutzer, der mit fhem seine Chlorpumpe fürs Schwimmbad steuert, da macht es schon einen lebensbedrohlichen Unterschied, ob er 1,8 g Chlor einspeist oder 1,8 kg.

Ich plädiere dringend dafür ein Konzept für den Umgang mit Einheiten in fhem erneut zu diskutieren und dann konsequent umzusetzen. Selbst wenn ich dann alle meine fhem-Definitionen erneut anfassen muss, das wäre es mir wert. Beim FlowerPower-Modul gibt es Messwerte mit ziemlich kruden Dimensionen, deshalb gab es dort kürzlich schon eine Diskussion dazu (https://forum.fhem.de/index.php/topic,56490.msg486725.html#msg486725). Und auch unter https://forum.fhem.de/index.php/topic,46730.msg384676.html#msg384676 gibt es einen Vorschlag dazu von @justme1968. Aus meiner Sicht ist das allerdings kein Problem der Formatierung im Frontend, sondern Einheiten müssen tief im Kern von fhem verankert werden.
fhem 5.8 auf RaspberryPi 3 mit HMLAN und CCU2, ZWave, JeeLink, FHZ1000 für FS20, HMS, Fritz!Box, Fritz!DECT200, Harmony, Sonos, hue, netatmo, SSCam, Wetter- und Verkehrsmodule, Chat-Bot mit RiveScript/Telegram, IFTTT, pushover, ...

hartenthaler

@rudi
hast Du zufällig diesen etwas älteren Post von mir gesehen?

Im FBAHAHTML Modul gibt es Probleme mit den Einheiten bei den DECT-Steckdosen. Ich plädiere dringend dafür auf irgendeine Weise in fhem nicht nur reine Zahlen sondern Zahlen mit Einheiten zu verwenden. Das geht sonst regelmäßig schief.
Ansonsten läuft das FBAHAHTML Modul absolut zuverlässig.

Vielen Dank
Hermann
fhem 5.8 auf RaspberryPi 3 mit HMLAN und CCU2, ZWave, JeeLink, FHZ1000 für FS20, HMS, Fritz!Box, Fritz!DECT200, Harmony, Sonos, hue, netatmo, SSCam, Wetter- und Verkehrsmodule, Chat-Bot mit RiveScript/Telegram, IFTTT, pushover, ...

rudolfkoenig

Zitathast Du zufällig diesen etwas älteren Post von mir gesehen?
Ja, ich habe aber zu expliziten Unit-Unterstuetzung in FHEM eine Meinung, und wollte es nicht schon wieder diskutieren.

Kurz: die von den Sensoren gemeldeten Einheiten aendern sich nicht, man kann sie dokumentieren, und/oder als Suffix ans Wert dranhaengen. Wenn man das in FHEM "tief verankert", dann muss jedes Modul, das interne in externe Darstellung oder andersrum konvertiert (FHEMWEB/list/XmlList/JsonList/FileLog/SVG/save/include/etc) die explizit beruecksichtigen (sprich Code schreiben) und evtl konvertieren. Auch alle "Lieferanten-Module" muessen umgestellt werden. Das ist viel Arbeit fuer ein nicht nachvollziehbares Nutzen.

Das Achsbeschriftungs-Problem hat damit zu tun, dass das template .gplot geklaut ist. Wie Du es gesehen hast, ist einfach zu aendern.
Du kannst gerne ein Patch hier anhaengen, was das korrigiert.

hartenthaler

Danke. Ja, die Diskussionen dazu liefen schon und laufen nun - Gottseidank - wieder. Das mit der vielen Arbeit ist klar. Aber es sind schon Raumsonden verloren gegangen nur weil man die Masseinheiten nicht im Blick hatte. Und der Unterschied zwischen ein paar Gramm Chlor und ein paar Kilo Chlor kann Leben gefährden. Das wäre es mir wert hier sehr sorgfältig zu sein.

Das Problem mit Coulomb statt Grad Celsius, habe ich erst einmal so gelöst:
define rc_FB_C readingsChange FBDECT.* temp (\d).C $1 °C
Sehr elegant in einem Wutsch. Mächtiges Teil das readingsChange.

Meinst Du mit Patch für den Plot der Leistung bzw. der Energie so etwas wie

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "Leistung / W"
set y2label "Leistung / W"

#FileLog_FBDECT 4:FBDECT_fb1_xxxxx.power\x3a::

plot "<IN>" using 1:2 title 'Line 1' with lines

Nur angepasst an der Urzustand direkt nachdem man die FBDECT Devices automatisch neu angelegt hat. Ich kann das gerne für die drei Plots (Temperatur/Leistung/Energie) so erstellen und testen, sowie kennzeichnen wo ich was zum derzeitigen Stand jeweils angepasst habe.
fhem 5.8 auf RaspberryPi 3 mit HMLAN und CCU2, ZWave, JeeLink, FHZ1000 für FS20, HMS, Fritz!Box, Fritz!DECT200, Harmony, Sonos, hue, netatmo, SSCam, Wetter- und Verkehrsmodule, Chat-Bot mit RiveScript/Telegram, IFTTT, pushover, ...

rudolfkoenig

ZitatAber es sind schon Raumsonden verloren gegangen nur weil man die Masseinheiten nicht im Blick hatte.
Danke fuer die Argumentationshilfe: mit FHEM wird man keine Raumsonden steuern, und wir haben auch kein vergleichbares Budget, um die notwendigen Aenderungen durchzufuehren. Kein normaler Mensch denkt beim "temperature 21 C" an Coulomb, die meisten wissen ja nich mal, was Coulomb ist. Dafuer erspart mir C statt °C den Aerger beim fehlerhaftes bzw. nicht vorhandenes Konvertieren zwischen UTF-8 und latin1.


ZitatMeinst Du mit Patch für den Plot der Leistung bzw. der Energie so etwas wie
"So etwas wie" ja, dein Beispiel ist aber falsch, ist naemlich kein template, da mit dem SVG-Editor erstellt wurde.
Im AutoCreate Eintrag in 10_FBDECT.pm wird auf das power4 template verwiesen, und das ist hier nicht perfekt. Immer ein Power-Plot zuzuweisen ist auch nicht richtig, da inzwischen auch Heizungsregler gibt. D.h. UNDEFINED muesste mit einem spezifischeren Namen generiert werden, der Eintrag fuer AutoCreate muesste differenzierter sein, und man braucht 2 passende .gplot templates. Die muessen nicht neu sein, aber passen.

Tom111

Zitat von: rudolfkoenig am 22 November 2016, 09:17:56
[...]mit FHEM wird man keine Raumsonden steuern[...]

Puhhh, ... wie gut dass ich den Countdown noch kurzzeitig unterbrechen konnte!  ;D
FHEM 5.9 auf Raspberry Pi - 3B+ - Stretch-5.10.88+ | CUL868 CC1101 - USB - Lite module - V3 FW 1.67
Fritz!Box 7490 OS 07.29 / Fritz!Dect200 / Fritz!Powerline 546E
FS20ST-4/ FS20 DI-5/ FS20LS/ FS20 PIRI-2-KU/ FS20 TFK/ FS20S4A/FS20 SU-3/FS20 S20-3
HMS100TF/FHT80TF-2/ASH2200/S300TH/MiLight-Bridge V

Tungsten


rudolfkoenig

Zitatwas ist FBAHAHTML? oder ist FBAHA gemeint?
Nein, FBAHAHTTP.
FBAHA verwendet die Fritzbox AHA (AVM-Home-Automation) -Binaerschnittstelle, die seit ueber einem Jahr abgekuendigt ist, und unterstuetzt keine Heizkoerperventile. Dafuer muss das Modul nicht pollen, wie sein Nachfolger FBAHAHTTP.

Tungsten