Ich bekomme aktuell ca. 15000-18000 Zeilen pro MAX! Gerät pro Tag in die Datenbank ... innerhalb von 10 Tagen sind so über 5GB Daten dazu gekommen.
Kann man die Häufigkeit der Meldungen irgendwo reduzieren ?
wie immer und überall : attr verbose ist den Freund :)
Ohne List eines devices:
* event-min-interval
* event-on-change-reading
Und so ganz ohne "Beispiel" des zugemüllten logs...
Ich müsste die Datenbank sowieso mal bereinigen und für die Zukunft nur die benötigten Werte eintragen ...
Im Falle von MAX! wäre das
- state (für Fensterkontakte)
- battery (bzw. mein userReading batteryPercent)
- desiredTemperature
- mode (eventuell)
- temperature
- valveposition
Allerdings brauche ich die Werte auch nicht minütlich, sondern 1 Mal pro Tag oder dann, wenn sie sich ändern
Gibt es irgendwo ein verständliches Beispiel zu event-min-interval und event-on-change-reading ? verbose bringt hier glaub' ich nicht wirklich was ...
edit
Ein Beispiel hab' ich angehängt
List eines MAX! Thermostats folgt:
Internals:
DEF HeatingThermostat 18054a
FUUID 5c8cccdd-f33f-b646-e458-1c757302c630f775
IODev MAX
LASTInputDev MAX
MAX_MSGCNT 112
MAX_TIME 2019-03-27 17:10:46
MSGCNT 112
NAME MAX_18054a
NR 273
STATE 18.8°C - 2019-03-27 17:10:46
TYPE MAX
addr 18054a
backend MAX
dstsetting 1
mode 0
rferror 0
serial NEQ1741282
type HeatingThermostat
Helper:
DBLOG:
MAXLAN_error:
logdb:
TIME 1553703046.84873
VALUE 0
MAXLAN_errorInCommand:
logdb:
TIME 1553703046.84873
VALUE
MAXLAN_initialized:
logdb:
TIME 1553703046.84873
VALUE 1
MAXLAN_isAnswer:
logdb:
TIME 1553703046.84873
VALUE 0
MAXLAN_valid:
logdb:
TIME 1553703046.84873
VALUE 1
battery:
logdb:
TIME 1553703046.82063
VALUE ok
batteryPercent:
logdb:
TIME 1553703046.84873
VALUE 100
batteryState:
logdb:
TIME 1553703046.82063
VALUE ok
boostDuration:
logdb:
TIME 1553696510.77404
VALUE 5
boostValveposition:
logdb:
TIME 1553696510.77404
VALUE 80
comfortTemperature:
logdb:
TIME 1553696510.77404
VALUE 22.0
decalcification:
logdb:
TIME 1553696510.77404
VALUE Sat
desiredTemperature:
logdb:
TIME 1553703046.82063
VALUE 21.0
ecoTemperature:
logdb:
TIME 1553696510.77404
VALUE 16.5
firmware:
logdb:
TIME 1553696510.74513
VALUE 1.0
groupid:
logdb:
TIME 1553696510.72516
VALUE 2
maxValveSetting:
logdb:
TIME 1553696510.77404
VALUE 100
maximumTemperature:
logdb:
TIME 1553696510.77404
VALUE 23.0
measurementOffset:
logdb:
TIME 1553696510.77404
VALUE 0.0
minimumTemperature:
logdb:
TIME 1553696510.77404
VALUE off
mode:
logdb:
TIME 1553703046.82063
VALUE
state:
logdb:
TIME 1553703046.82063
VALUE 21.0
temperature:
logdb:
TIME 1553703046.82063
VALUE 18.8
testresult:
logdb:
TIME 1553696510.74513
VALUE 160
valveOffset:
logdb:
TIME 1553696510.77404
VALUE 0
valveposition:
logdb:
TIME 1553703046.82063
VALUE 88
weekprofile-0-Sat-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-0-Sat-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:00
weekprofile-1-Sun-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-1-Sun-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:00
weekprofile-2-Mon-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-2-Mon-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:30
weekprofile-3-Tue-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-3-Tue-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:30
weekprofile-4-Wed-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-4-Wed-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:30
weekprofile-5-Thu-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-5-Thu-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:30
weekprofile-6-Fri-temp:
logdb:
TIME 1553696510.77404
VALUE 17.0
weekprofile-6-Fri-time:
logdb:
TIME 1553696510.77404
VALUE 00:00-06:30
windowOpenDuration:
logdb:
TIME 1553696510.77404
VALUE 15
windowOpenTemperature:
logdb:
TIME 1553696510.77404
VALUE 12.0
READINGS:
2019-03-27 17:10:46 MAXLAN_error 0
2019-03-27 17:10:46 MAXLAN_errorInCommand
2019-03-27 17:10:46 MAXLAN_initialized 1
2019-03-27 17:10:46 MAXLAN_isAnswer 0
2019-03-27 17:10:46 MAXLAN_valid 1
2019-03-27 17:10:46 battery ok
2019-03-27 17:10:46 batteryPercent 100
2019-03-27 17:10:46 batteryState ok
2019-03-26 12:34:18 batterynum 100 %
2019-03-27 15:21:50 boostDuration 5
2019-03-27 15:21:50 boostValveposition 80
2019-03-27 15:21:50 comfortTemperature 22.0
2019-03-27 15:21:50 decalcification Sat 12:00
2019-03-27 17:10:46 desiredTemperature 21.0
2019-03-27 15:21:50 ecoTemperature 16.5
2019-03-27 15:21:50 firmware 1.0
2019-03-27 15:21:50 groupid 2
2019-03-27 15:21:50 maxValveSetting 100
2019-03-27 15:21:50 maximumTemperature 23.0
2019-03-27 15:21:50 measurementOffset 0.0
2019-03-27 15:21:50 minimumTemperature off
2019-03-27 17:10:46 mode auto
2019-03-27 17:10:46 state 21.0 °C
2019-03-27 17:10:46 temperature 18.8
2019-03-27 15:21:50 testresult 160
2019-03-27 15:21:50 valveOffset 0
2019-03-27 17:10:46 valveposition 88
2019-03-27 15:21:50 weekprofile-0-Sat-temp 17.0 °C / 21.0 °C
2019-03-27 15:21:50 weekprofile-0-Sat-time 00:00-06:00 / 06:00-00:00
2019-03-27 15:21:50 weekprofile-1-Sun-temp 17.0 °C / 21.0 °C
2019-03-27 15:21:50 weekprofile-1-Sun-time 00:00-06:00 / 06:00-00:00
2019-03-27 15:21:50 weekprofile-2-Mon-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-03-27 15:21:50 weekprofile-2-Mon-time 00:00-06:30 / 06:30-08:50 / 08:50-17:00 / 17:00-21:05 / 21:05-00:00
2019-03-27 15:21:50 weekprofile-3-Tue-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-03-27 15:21:50 weekprofile-3-Tue-time 00:00-06:30 / 06:30-08:50 / 08:50-17:00 / 17:00-21:05 / 21:05-00:00
2019-03-27 15:21:50 weekprofile-4-Wed-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-03-27 15:21:50 weekprofile-4-Wed-time 00:00-06:30 / 06:30-08:50 / 08:50-17:00 / 17:00-21:05 / 21:05-00:00
2019-03-27 15:21:50 weekprofile-5-Thu-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2019-03-27 15:21:50 weekprofile-5-Thu-time 00:00-06:30 / 06:30-08:50 / 08:50-17:00 / 17:00-21:05 / 21:05-00:00
2019-03-27 15:21:50 weekprofile-6-Fri-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C
2019-03-27 15:21:50 weekprofile-6-Fri-time 00:00-06:30 / 06:30-08:50 / 08:50-17:00 / 17:00-00:00
2019-03-27 15:21:50 windowOpenDuration 15
2019-03-27 15:21:50 windowOpenTemperature 12.0
internals:
interfaces thermostat;battery;temperature
Attributes:
IODev MAX
alias Heizkörper Anbau
icon hc_wht_regler
room MAX
stateFormat {ReadingsVal('MAX_18054a','temperature','')."°C - ".ReadingsTimestamp('MAX_18054a','temperature','')}
userReadings batteryPercent {if(ReadingsVal("MAX_18054a","battery","low") eq "ok") {return "100"} else {return "1"}}
dblogexclude (oder dbloginclude), jenachdem was Dein default ist.
Das entsprechende Beispiel gibt es hier:
https://wiki.fhem.de/wiki/Event-on-change-reading
Dort steht die Wechselwirkung zwischen event-on-change und event-min-interval.
Damit sollte Dein Datenproblem gelöst sein.
Habe ich das so richtig verstanden ?
der Eintrag
attr MAX_18054a event-on-change-reading state,batteryPercent,desiredTemperature,mode,temperature,valveposition
attr MAX_18054a event-min-interval .*:86400
würde nur für MAX_18054a bewirken, daß state,batteryPercent,desiredTemperature,mode,temperature und valveposition bei Veränderung und alle readings 1x pro Tag erzeugt würden.
Die logdb ist aktuell nicht mit include/exclude eingeschränkt
define logdb DbLog ./db.conf .*:.*
Wäre das bei Verwendung von event-... (wie im Beispiel oben für alle Devices) noch nötig oder nicht ?
Könnte man event-... auch Gruppieren z.B. für alle MAX Devices ?
Die Attribute müssen je Max-Device gesetzt werden. Aber mit einer geeigneten DEVSPEC (e.g. TYPE=MAX) kann man attribute ja auch in einem Schwung für mehrere Devices auf einmal setzen.
Der erste Schritt kann ja mal die ÜBerprüfung dessen sien, was Du jetzt für ein Device umgesetzt hast. Wenn das klappt, kann man "ruckzuck" die anderen Devices beglücken.
Was dblog angeht: Ich habe im dblog-Device als selectionmode "Include" gesetzt. Das verursacht (laut commandref), dass ich bei jedem Device explizit die Readings angeben muss, die in die Datenbank geschrieben werden sollen.
Zitat von: dt2510 am 27 März 2019, 17:28:41
attr MAX_18054a event-on-change-reading state,batteryPercent,desiredTemperature,mode,temperature,valveposition
attr MAX_18054a event-min-interval .*:86400
mach das nicht , sondern ein einfaches
attr MAX_18054a event-on-change-reading .*und du wirst sehen das es gut ist :) , denn manche Dinge willst du mehr als 1x am Tag aktuell haben , vllt. jetzt noch nicht aber später bestimmt ...
noch ein Tipp der das Leben leichter macht :
gewöhne dir an statt sowas -> ReadingsVal('MAX_18054a','temperature','') eher ReadingsVal($name,'temperature','') oder ReadingsNum($name,'temperature',0) zu verwenden, dann kann man die Zeile leicht mit copy & paste von einem Device zum nächsten kopieren ohne jedesmal den Namen editieren zu müssen :)
Zitat von: sledge am 27 März 2019, 18:11:11
Was dblog angeht: Ich habe im dblog-Device als selectionmode "Include" gesetzt. Das verursacht (laut commandref), dass ich bei jedem Device explizit die Readings angeben muss, die in die Datenbank geschrieben werden sollen.
da kann ruhig alles rein, man weiß ja nie, wozu man es braucht ;)
Zitat von: Wzut am 27 März 2019, 19:17:45
mach das nicht , sondern ein einfaches
attr MAX_18054a event-on-change-reading .*
und du wirst sehen das es gut ist :) , denn manche Dinge willst du mehr als 1x am Tag aktuell haben , vllt. jetzt noch nicht aber später bestimmt ...
noch ein Tipp der das Leben leichter macht :
gewöhne dir an statt sowas -> ReadingsVal('MAX_18054a','temperature','') eher ReadingsVal($name,'temperature','') oder ReadingsNum($name,'temperature',0) zu verwenden, dann kann man die Zeile leicht mit copy & paste von einem Device zum nächsten kopieren ohne jedesmal den Namen editieren zu müssen :)
Mein System läuft schon seit ein Paar Jahren mit x Aktoren/Sensoren - Tagesaktuell reicht oft (nicht immer, aber man setzt event-... eh' je device oder TYPE). Wichtig wäre halt, dass nicht jede Minute alles rein kommt - sollte so aber gehen, da hast du recht ;)
Den Namen im ReadingsVal angeben war jetzt nur auf die Schnelle, das pass ich eh' noch an
edit
dazu hätte ich allerdings noch eine Frage: Für Doppelfenster nutze ich eine Structure
define Wohnzimmerfenster structure MultiWindow MAX_17fe6e MAX_18012b
attr Wohnzimmerfenster stateFormat {substr(ReadingsVal('MAX_17fe6e','state',''),0,1).substr(ReadingsVal('MAX_18012b','state',''),0,1)}
attr Wohnzimmerfenster userReadings batteryPercent {GetMultiWindowBatteries('MAX_17fe6e','MAX_18012b')}Die Funktion "GetMultiWindowBatteries" ist in der 99_myUtils.pm und liefert den niedrigsten Batteriestatus der angegebenen Devices
sub GetMultiWindowBatteries($$) {
my ($myLeftWindow,$myRightWindow) = @_;
my $myResult = 100;
if (ReadingsVal($myLeftWindow,"battery","") eq "low") {$myResult = 1;}
if (ReadingsVal($myRightWindow,"battery","") eq "low") {$myResult = 1;}
return($myResult);
}Über stateFormat wird abhängig von open/close entweder "cc", "oc", "co" oder "oo" eingestellt. Damit kann ich in TabletUI ein Symbol mit bis zu 2 offenen Fenstern darstellen (siehe Bild). Da in der Structure 2 Devices sind, kann ich ja nicht $name benutzen - gibt es dazu was analoges ?
Was möchtest Du denn erreichen? Die Einzeldevices gibt es ja nach wie vor??
Ich nutze die structure aus Platzgründen. Ich habe viele Doppelfenster im Haus und müsste ansonsten für jeden Fenstersensor 2 Symbole (Fenster- und Battetiestatus) anzeigen. So hab' ich ein Symbol für das Fenster, da ich beide Zustände in einem reading abfragen kann, und ein Batteriesymbol zur Anzeige der schwächsten Batterie. Ein klick auf die Batterie öffnet ein Popup, welches dann in einer Chart beide Ladezustände anzeigt.
Wie du oben bereits erwähnt hast sollte ich z.B. $name benutzen um das Device kopieren zu können - wie aber mache ich das bei der structure ? Gibt es sowas wie $item1, $item2 oder so ?
Zitat von: Wzut am 27 März 2019, 19:17:45
mach das nicht , sondern ein einfaches
attr MAX_18054a event-on-change-reading .*
und du wirst sehen das es gut ist :) , denn manche Dinge willst du mehr als 1x am Tag aktuell haben , vllt. jetzt noch nicht aber später bestimmt ...
Ich habe die Datenbank mal ausgedünnt und "attr <device>event-on-change-reading .*" eingefügt. Das passt alles soweit, ich hab' nur ein Problem: Ein Bewegungsmelder, der kein "Event cleared" melded (PST02-A), meldet dann natürlich auch keine Bewegung, da sich das reading "alarm_HomeSecurity nicht ändert. Könnte ich das mit einem "attr <device> event-on-change-reading !alarm_HomeSecurity.*" lösen ?
Nun event-on-change-reading .* ist vermutlich in 95% aller Fälle erst einmal eine gute Wahl, bei den restlichen 5% muß man halt schauen was man am Besten macht.
Zitat von: dt2510 am 28 März 2019, 21:03:34
Könnte ich das mit einem "attr <device> event-on-change-reading !alarm_HomeSecurity.*" lösen ?
Wie kommst du auf die Idee ?
Für ein Reading das seinen Wert nicht ändert man aber Events benötigt git es doch event-on-update-reading, die Syntax !alarm_HomeSecurity.* verstehe ich auch nicht. Wenn das Reading den Namen alarm_HomeSecurity hat dann würde ich ein simples
attr <device> event-on-update-reading alarm_HomeSecurity
dazu setzen.
Zitat von: Wzut am 29 März 2019, 09:50:50
Nun event-on-change-reading .* ist vermutlich in 95% aller Fälle erst einmal eine gute Wahl, bei den restlichen 5% muß man halt schauen was man am Besten macht. Wie kommst du auf die Idee ?
Für ein Reading das seinen Wert nicht ändert man aber Events benötigt git es doch event-on-update-reading, die Syntax !alarm_HomeSecurity.* verstehe ich auch nicht. Wenn das Reading den Namen alarm_HomeSecurity hat dann würde ich ein simples
attr <device> event-on-update-reading alarm_HomeSecurity
dazu setzen.
Das ist doch genau das Problem.
alarm_HomeSecurity wird bei Bewegung ausgelöst, aber durch event-on-change-reading .* (oder auch nur alarm_HomeSecurity) wird es unterdrückt, weil sich der Wert nicht ändert - nur der Timestamp ! Dadurch wird auch keine Bewegung ausgelöst (es gibt beim PST02-A wie gesagt kein "Event clear").
Ich wollte erreichen, dass alle Ereignisse ausser alarm_HomeSecurity nur bei Veränderung (event-on-change-reading) ausgelöst werden und alarm_HomeSecurity immer.beim zweiten durchlesen hab' ich es verstanden ;)