[PATCH] - 93_DbLog.pm - Parsing/Split der Events

[Marci]

Durch das nicht ganz saubere DB-Logging der Z-Wave-Geräte, bin ich auf die Split-Funktion gestoßen, die in meinen Augen nicht ganz so funktioniert, wie sie sollte. Aber vielleicht übersehe ich ja auch etwas; ich lasse mich gerne korrigieren.

Ursprünglich findet die Splittung des Events in "Reading", "Value" und "Unit" nur an einem ": " statt. Dadurch landet bei Z-Wave-Geräten - und vermutlich allen anderen, die nicht weiter unten einen eigenen Block besitzen - in der Value-Spalte die Kombination aus Value und Unit (also z.B. "20.5 W", statt nur "20.5") und die Unit bleibt - außer bei Temperaturen - leer.

Das "if(@parts == 2)" deutet für mich aber darauf hin, dass es global weiter gesplittet werden sollte. Oder gibt es Events, die so aufgebaut sind: "<Reading>: <Value>: <Unit>"? Mit dem angehängten Mini-Patch sollte das Splitting besser funktionieren (und ggf. die meisten anderen separaten Split-Blöcke überflüssig machen). Ich weiß allerdings nicht, ob das zu Problemen führen kann, wenn zusätzlich nur an einem " " gesplittet wird. Das wäre der Fall, wenn es z.B. bei den Values oder Readings zusätzliche Leerzeichen geben könnte. Gibt es das?

Alternativ könnte ich noch einen Patch anbieten, der nur einen zusätzlichen Split-Block für Z-Wave-Geräte einfügt. Dort wären allerdings nur einige wenige der möglichen Events abgedeckt.

[rapster]

Evtl. lieber ZWave patchen? http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#X_DbLog_splitFn

[Marci]

Wieso "lieber"? Wenn die Änderung hier keine Probleme bereitet, wäre diese zentrale und global wirksame Änderung doch weitaus besser, als für jedes Device eine eigene Split-Funktion zu implementieren. Wie gesagt, das Splitting, wie es aktuell implementiert ist, wird nicht nur bei Z-Wave-Devices für diese Probleme sorgen, sondern vermutlich bei allen anderen, die Events in der Form "<Reading>: <Value> <Unit>" liefern und noch keinen eigenen Split-Block bekommen haben. Und das werden die meisten sein, denke ich.

[rapster]

Deswegen ?

Ich weiß allerdings nicht, ob das zu Problemen führen kann,

Habe zumindest bei den von mir eingesetzten Modulen noch keine Probleme feststellen können.

[betateilchen]

Ich auch nicht. Und genau für solche Spezialfälle wurde ja seinerzeit die splitFn eingeführt, die nach meinen Erfahrungen ziemlich gut funktioniert

[Marci]

Es funktioniert bei euch vermutlich, weil es dafür entsprechende eigene Split-Blöcke gibt. Z-Wave ist in dieser Hinsicht ja kein Spezialfall; die Events sehen genau so aus, wie die, die ich kenne.

Ich persönlich fixe/optimiere lieber an einer Stelle, als den Code unnötig mit "Workarounds" aufzublähen. Schade dass das hier offensichtlich anders gesehen wird, ohne dass ein konkretes Gegenbeispiel/Problem angegeben wird. Ich werde es bei mir so belassen.

Gesendet von meinem SM-P905 mit Tapatalk

[rapster]

Das wird keineswegs anders gesehen, allerdings:

Ich weiß allerdings nicht, ob das zu Problemen führen kann, wenn zusätzlich nur an einem " " gesplittet wird. Das wäre der Fall, wenn es z.B. bei den Values oder Readings zusätzliche Leerzeichen geben könnte. Gibt es das?

Und ja das gibt es, es gibt Values/Reading-Values mit Leerzeichen, solange du keinen Patch für DbLog liefern kannst der bei anderen Modulen und bisherigen Installation keine Probleme verursacht bleibt nur der Weg über die SplitFn.

[Marci]

es gibt Values/Reading-Values mit Leerzeichen

Das ist doch mal eine Aussage! Kannst du Beispiele nennen, damit ich mir das ggf. mal angucken kann?

[rapster]

Du kannst das einfach mit einem dummy und eigenem setreading ausprobieren, denke wenn du durch deine Devices mal durchklickst wirst du immer wieder mal einen Reading-Wert mit Leerzeichen finden.

z.B.

Code Auswählen Erweitern

{ fhem("setreading dummy zeit ".OldTimestamp("dummy")) }

[betateilchen]

Leerzeichen in Readings? Völlig normal...

Beispiel: in den diversen Wettermodulen stehen ganze Textblöcke mit Wettermeldungen - da sind die Wörter auch mit Leerzeichen voneinander getrennt.

Noch ein Beispiel: Homematic Temperaturregler

(http://up.picr.de/23693642vk.png)

Und mir fallen noch Dutzende andere Fälle ein.

[rudolfkoenig]

Gibt es auch Faelle, wo ein Reading ein Zahl (auch Fliesskomma) gefolgt von Text ist, was man aber nicht in Wert/Einheit splitten sollte? Das trifft auf die bisher erwaehnten Beispiele nicht zu.

[Marci]

Du kannst das einfach mit einem dummy und eigenem setreading ausprobieren

Dummy und andere, selbst formatierte Events/Readings zählen für mich nicht, da man dort alles kreieren könnte. Und das kann man nicht mehr abfangen und sinnvoll splitten.

Noch ein Beispiel: Homematic Temperaturregler

(http://up.picr.de/23693642vk.png)

Das ist schon interessanter, ist aber von der Änderung nicht betroffen, wenn ich das richtig sehe. Das wären dann fünf Strings im Array "parts", bzw. nach dem shift noch vier. Durch den else-Teil nach dem "if(@parts == 2)" würde dann alles korrekt in der Value-Spalte landen, so wie vermutlich jetzt auch schon.

Allerdings ist es natürlich auch denkbar, dass irgendwo nur zwei Zahlenpaare vorkommen. Dann würde die zweite Zahl in der Unit-Spalte landen. Das ließe sich aber auch mit Regexp abfangen.

[rapster]

Gibt es auch Faelle, wo ein Reading ein Zahl (auch Fliesskomma) gefolgt von Text ist, was man aber nicht in Wert/Einheit splitten sollte? Das trifft auf die bisher erwaehnten Beispiele nicht zu.

Ja, so auf die Schnelle z.B. current_date_time vom Weather Modul mit "13 Nov 2015 9:00 am CET"

[Marci]

So, ich bin endlich mal dazu gekommen, es etwas umzuschreiben. Die Beispiele aus diesem Thread und noch ein paar weitere, von mir ausgedachte Events, werden so gesplittet, wie es sein sollte. Ich hoffe das passt so. Wer Verbesserungsvorschläge hat; immer her damit.

[Marci]

Ich wollte mal nachfragen, was mit diesem Vorschlag ist. Sind Änderungen gewünscht? Ist es uninteressant oder nicht gewünscht, so dass ich meine DbLog in Zukunft selber pflegen muss? In dieser Form sehe ich jedenfalls keinen Grund, warum die Änderung unerwünschte Nebeneffekte haben könnte.