anbei ein kleiner patch der die sonderbehandlung der state readings auf presence ausdehnt. sonst ist es nicht möglich presence aus dblog zu plotten.
noch ein vorschlag: wie wäre es wenn man im <reading> in der column_spec auch _ und % erlaubt und im fall das diese auftauchen oder es in der <fn> irgendwie aktiviert wird dann like statt = verwendet?
gruss
andre
Hi Andre,
Zitat von: justme1968 schrieb am Do, 18 Juli 2013 09:30noch ein vorschlag: wie wäre es wenn man im <reading> in der column_spec auch _ und % erlaubt und im fall das diese auftauchen oder es in der <fn> irgendwie aktiviert wird dann like statt = verwendet?
ganz einfach....
1. läuft dann die Datenabfrage auf der historyTabelle nicht mehr performant da die selektivität des Indices nicht mehr vorhersagbar ist, bzw diese steigt.
2. ist die Anzahl der Readings nicht mehr konstant (bei Änderungen), wäre tödlich in den Plots denn dort muss jedes Reading auf ein Plot gematched werden.
3. kannst du doch einfach alle benötigten Readings in der Plotfunction angeben.. ;)
1.) ja das kann unter umsänden probleme machen. deshalb die idee nicht generell like zu verwenden sondern nur für spezifische queries.
aber ein % alleine sollte z.b. recht wenig probleme machen weil alles zurück kommen soll.
2.) ich wollte damit nicht meherere plots (kurven) erstellen sondern die readings von unterschiedlichen events in einem plot (kurve) haben.
-> das problem ist das devices die nur ein state reading haben im db log für jeden möglichen zustand einen eigenen
readings typ bekommen. ohne den patch also statt data mit den möglichen werten absent und present jeweils
absent mit dem wert absend oder present mit dem wert present.
deshalb gibt es ja die ganzen sonderlösungen wie z.b. für dummy und oben im patch auch für presence die daraus dann ein
reading data mit dem wert absent oder present machen.
bei presence könnte man das jetzt z.b. einfach umgehen in dem man einfach als reading % verwendet und beide möglichen zustände
wieder in einen plot bekommt. ohne den patch.
3.) s.o. nicht mehrere readings jeweils in einer eigenen kurve sondern zusammen in einer kurve.
Hi Andre,
kann für diesen Fall eine structure für dich eine möglich Lösung sein? Damit kannst du die Zustände mehrerer Devices zusammenfassen
hallo tobias,
ich glaube wir reden gerade aneinander vorbei :)
es geht nicht um mehrere devices sondern um ein einziges device. das problem wird unter anderem hier beschrieben. http://forum.fhem.de/index.php?t=msg&goto=86348&rid=430#msg_86348 (//forum.fhem.de/index.php?t=msg&goto=86348&rid=430#msg_86348).
dbLog hat im gegensatz zu file log zur zeit das prinzipielle problem das alle events die state produziert nicht in einem einzigen reading mit namen state landen sondern für jeden möglichen wert den state haben kann in einem reading mit diesem wert als namen. um das zu vermeiden muss jedes mal eine sonderbehandlung in dblog eingebaut werden. für dummy gab es die schon. im patch oben ist sie für presence.
also ein einziges device das den state absent oder present haben kann erzeugt ohne den patch von oben dblog einträge für zwei unterschiedliche readings:
sqlite> select * from history where device='iPhoneAndre';
2013-07-18 10:42:30|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 11:12:33|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 11:42:36|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 12:12:40|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 12:42:43|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 13:12:48|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 13:42:55|iPhoneAndre|PRESENCE|absent|absent||
2013-07-18 08:59:19|iPhoneAndre|PRESENCE|present|present||
2013-07-18 09:00:19|iPhoneAndre|PRESENCE|present|present||
2013-07-18 09:04:19|iPhoneAndre|PRESENCE|present|present||
2013-07-18 09:34:23|iPhoneAndre|PRESENCE|present|present||
2013-07-18 10:04:27|iPhoneAndre|PRESENCE|present|present||
2013-07-18 10:34:30|iPhoneAndre|PRESENCE|present|present||das lässt sich nicht in einer kurve plotten.
mit dem patch wird nur noch ein einziges reading vom typ data mit den möglichen werten absent oder present. das lässt sich in einer kurve plotten.
eine möglichkeit das bei neuen devices ohne patch in den griff zu bekommen wäre % als reading namen zu erlauben um die unterschiedlichen readings in einer kurve zusammen zu fassen wie es bei filelog auch möglich ist.
gruss
andre
Ich habs kapiert...
kannst du damit auch leben? bzw funktioniert es so bei dir? Ich möchte vermeiden jede einzelne Sonderbehandlung einbauen zu müssen
--- 93_DbLog.pm 2013-07-18 14:11:09.000000000 +0200
+++ FHEM/93_DbLog.pm 2013-07-18 14:16:30.000000000 +0200
@@ -288,8 +288,8 @@
}
}
- # DUMMY
- elsif($type eq "DUMMY") {
+ # anything else
+ else {
if( $value eq "" ) {
$reading= "data";
$value= $event;
ich probiere es aus.
gruss
andre
ich hatte es jetzt auf einem test recher laufen und das war erst mal ok. ich schiebe es nachher auf das produktivsystem. da gibt es mehr devices die loggen.
wie waere es den allgemeinen else zweig nicht statt dem dummy sonder zusätzlich einzubauen. dann könnte man da das reading 'state' nennen was eigentlich besser ist als 'data' und der dummy wären noch kompatibel.
gruss
andre
Hi Andre,
berichtige mich, aber der dummy war vorher auch so und jetzt läuft der dummy in den letzten Else zweig.
Also IMHO funktioniert dummy immer noch so wie vorher.
ja. und mein vorschlag war beides genau nicht zusammen zu fassen sondern den dummy wie bisher zu lassen und den else zweig zusätzlich dran zu ängen. dann würde das reading beim dummy wie bisher data heissen (rückwärtskompatibel) und im else zweig könnte man statt 'data' dann 'state' als namen verwenden was eigentlich besser passt.
Update:
- dummy: Readings heißt wieder "data"
- default: Reading ist "state" wenn kein Reading übergeben wurde
- + OWMULTI: Units für Temperatur/Luftfeuchte angepasst
- + MAX: Units für Temperatur/Valveposition angepasst