Wiki-Korrektur "Plot Abriss vermeiden

Begonnen von predi-ger-many, 15 Oktober 2018, 20:46:19

Vorheriges Thema - Nächstes Thema

predi-ger-many

Hallo,

der Code in https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden ist teilweise nicht funktionsfähig und extrem umständlich.

myUtils

sub Trigger_Logging($$)
{
  my ($device, $reading) = @_; # device and reading to be used

  my $value = ReadingsVal ( "$device","$reading","" );

  my $command = "";

  Trigger_Logging_Debug ( "Trigger_Logging - Device: $device" );
  Trigger_Logging_Debug ( "Trigger_Logging - Reading: $reading" );
  Trigger_Logging_Debug ( "Trigger_Logging - Value: $value" );

  $command = "trigger $device $reading: $value";

  Trigger_Logging_Debug ( "Trigger_Logging - Command : $command" );

  fhem ( $command );
}

sub Trigger_Logging_Debug($)
{
  my ($message) = @_;

  my $enabled = "0";

  if ($enabled eq "1")
  {
    Log3 undef, 1, $message;
  }
}


... der Originalcode hat bei mir schön gedumpt. Daher überarbeitet

Vereinfachte Implementation in fhem.cfg


define Heizung_Buero_Log_Trigger at +*00:15:00 {\
  Trigger_Logging("HM_Buero_WT","2.SET_TEMPERATURE");;\
  Trigger_Logging("HM_Buero_WT","2.ACTUAL_TEMPERATURE");;\
  Trigger_Logging("HM_Buero_WT","2.ACTUAL_HUMIDITY");;\
  Trigger_Logging("HM_Buero_HKT","4.SET_TEMPERATURE");;\
  Trigger_Logging("HM_Buero_HKT","4.ACTUAL_TEMPERATURE");;\
  Trigger_Logging("HM_Buero_HKT","4.VALVE_STATE");;}
attr Heizung_Buero_Log_Trigger alignTime 00:00
attr Heizung_Buero_Log_Trigger group Trigger
attr Heizung_Buero_Log_Trigger room Heizung - Logs

Wäre super, wenn das jemand ins Wiki übertragen könnte

krikan

Habe den Originalcode aus https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden#Implementierung gerade getestet. Ich kann keine Probleme feststellen; funktioniert hier.

Könntest Du bitte
Zitat von: predi-ger-many am 15 Oktober 2018, 20:46:19
ist teilweise nicht funktionsfähig und extrem umständlich.
sowie
Zitat... der Originalcode hat bei mir schön gedumpt.
genauer ausführen, damit ich das nachvollziehen kann.

Bei Deinem Code fehlt die Sonderbehandlung von "state". Eine Unterscheidung von echten und "addLog"-Eintraegen im Logfile ist auch nicht mehr möglich: siehe "<< addLog" im Wiki.

Gruß, Christian

predi-ger-many

#2
Mir ist klar, dass ich gewisse Dinge entfernt habe. Ich schrieb ja, dass der Code teilweise nicht funktioniert hat

Der Original-Code:

if ($reading =~ m,state,i) {
    fhem "trigger $logdevice $logentry   << addLog";
  } else {
    fhem "trigger $logdevice $reading: $logentry   << addLog";
  }


Meine Log-Einträge sehen so aus:

2018-10-16_12:30:00 HM_Wohnzimmer_HKT_2 4.SET_TEMPERATURE: 22.0
2018-10-16_12:30:00 HM_Wohnzimmer_HKT_2 4.ACTUAL_TEMPERATURE: 22.0
2018-10-16_12:30:00 HM_Wohnzimmer_HKT_2 4.VALVE_STATE: 7

HM_Wohnzimmer_HKT_2 4.SET_TEMPERATURE und HM_Wohnzimmer_HKT_2 4.ACTUAL_TEMPERATURE haben mit dem Code funktioniert. HM_Wohnzimmer_HKT_2 4.VALVE_STATE nicht.
Werte mit Dezimalstelle wurden vom If-Zweig erfasst und die Werte ohne Dezimalstelle vom Else-Zweig. Und bei letzterem Error.

Die Unterscheidung per "<< addLog" habe ich entfernt. Grund war, dass es an andere Stelle Probleme gemacht hat. In den Readings der Devices stand nämlich plötzlich ganz kurz auch "<Wert> <<addLog" drin
anstatt nur "<Wert>". Die Unterscheidung habe indirekt auch wieder drin. Werte, welche exakt alle 15 Minuten kommen, sind manuell

krikan

ZitatHM_Wohnzimmer_HKT_2 4.VALVE_STATE nicht.
Danke, das kann ich nachvollziehen. Die Bedingung ($reading =~ m,state,i) ist hier zu ungenau. Sie ist nicht nur bei "state" erfüllt, sondern auch bei Deinem Reading.
Mir ist nicht klar, warum die Bedingung nicht nur auf ($reading eq "state") prüft; dann sollte das Problem nicht auftreten.

Hat jemand dazu Ideen?

ZitatWerte mit Dezimalstelle wurden vom If-Zweig erfasst und die Werte ohne Dezimalstelle vom Else-Zweig. Und bei letzterem Error.
Sorry, kann ich anhand des Codes nicht nachvollziehen und bin zu unausgeschlafen, um es anhand Deiner Readings zu finden.

ZitatIn den Readings der Devices stand nämlich plötzlich ganz kurz auch "<Wert> <<addLog" drin
FHEMWEB? Mit müden Augen erkenne ich dort so etwas nicht. Würde mich auch wundern.

Mein Pro "< < addlog":

  • Die Events wegen realer Wertaktualisierung und addLog-Ergänzung lassen sich als trigger für notify, DOIF u. Co. unterscheiden
  • Die meisten devices haben das Reading "state" und im Log bei realer Wertaktualisierung taucht kein "state: Wert" auf, sondern nur Wert. addLog sollte das genauso machen, sonst sind Probleme bspw. bei plots zu erwarten
  • Die indirekte Unterscheidung der Logeinträge anhand der Zeit ist eine Möglichkeit. Bei vielen verschiedenen Devices wird es so mMn kompliziert. Die "< <addlog" Ergänzung ist da klarer; insbesondere auch wenn im Forum Supportanfragen aufkommen.

Bedeutet alles nicht, dass Dein Weg für Dich nicht richtig ist, aber ich habe Zweifel, ob das für die Allgemeinheit gilt. Lasse mich aber gerne überzeugen. :)

Gruß, Christian

predi-ger-many

#4
Zitat von: krikan am 17 Oktober 2018, 10:23:21
FHEMWEB? Mit müden Augen erkenne ich dort so etwas nicht. Würde mich auch wundern.


define HM_Buero_WT_Changed_02 notify HM_Buero_WT:2.ACTUAL_TEMPERATURE.* {HM_Temperature_Changed("$NAME", "$EVENT", "ModbusTCP_10_40014", "")}
define HM_Buero_HKT_Changed_02 notify HM_Buero_HKT:4.ACTUAL_TEMPERATURE.* {HM_Temperature_Changed("$NAME", "$EVENT", "ModbusTCP_10_40014", "HM_Buero_WT")}


Ich schreibe Temperaturwerte bei jeder Änderung auf einem ModbusTCP Slave. Und wenn "<< addlog" aktiv ist, steht das ganz kurz im Device wirklich "Wert << addlog" drin.
Die "HM_Temperature_Changed" hat eine Fehlerbehandlung drin und bei Fehler wird ein Error Log geschrieben und dort sehe ich dann, dass da definitiv ganz kurz "Wert < addlog" drin stand.
Wenn ich das Device öffne, sehe ich auch, dass der Wert kurz rot in FHEMWEB wird und "Wert <<addlog" drin steht.

Das Reading hat ganz kurz also das Value "Wert << addlog". Und genau deshalb habe ich es entfernt. Weil es halt nicht nur ins Log geht!


Zitat von: krikan am 17 Oktober 2018, 10:23:21
Mein Pro "< < addlog":

  • Die Events wegen realer Wertaktualisierung und addLog-Ergänzung lassen sich als trigger für notify, DOIF u. Co. unterscheiden
  • Die meisten devices haben das Reading "state" und im Log bei realer Wertaktualisierung taucht kein "state: Wert" auf, sondern nur Wert. addLog sollte das genauso machen, sonst sind Probleme bspw. bei plots zu erwarten
  • Die indirekte Unterscheidung der Logeinträge anhand der Zeit ist eine Möglichkeit. Bei vielen verschiedenen Devices wird es so mMn kompliziert. Die "< <addlog" Ergänzung ist da klarer; insbesondere auch wenn im Forum Supportanfragen aufkommen.

Was ist ein konkreter Anwendungsfall für den Zusatz "<< addlog"? Ich sehe keinen Anwendungsfall.

Zitat von: krikan am 17 Oktober 2018, 10:23:21
Danke, das kann ich nachvollziehen. Die Bedingung ($reading =~ m,state,i) ist hier zu ungenau. Sie ist nicht nur bei "state" erfüllt, sondern auch bei Deinem Reading.
Mir ist nicht klar, warum die Bedingung nicht nur auf ($reading eq "state") prüft; dann sollte das Problem nicht auftreten.

Hat jemand dazu Ideen?
Bei mir kommt das Problem nicht zum Tragen, da ich manuell nur für bestimmte Werte auslöse. Allerdings erschließt sich mir "=~" auch nicht und genau
deshalb habe ich es bei mir entfernt, was nicht heißt, dass es für "state" eine anderer Behandlung geben sollte.


# called by
# define addLog notify addLog {addLog("ez_Aussensensor","state");;\
#            addLog("ez_FHT","actuator");;\
#            addLog("MunichWeather","humidity");;\
#            addLog("MunichWeather","pressure");;\
#            addLog("MunichWeather","temperature");;\
#            addLog("MunichWeather","wind_chill");;}
# define a_midnight1 at *23:59 trigger addLog
# define a_midnight2 at *00:01 trigger addLog

So soll es lt. Wiki in die FHEM-Config implementiert werden. Warum man das kompliziert machen muss, hat sich mir auch nicht erschlossen.
Daher habe ich den Aufruf übrigens auch "entschlackt".





iHome

Hallo

ich bin aufgrund folgender Fehlermeldung im Systemlog auf diesen Beitrag gestossen, weil ich die Fehlermeldung auf diesen Zusatz "<<  addLog" im Wertebereich zurückführe.

Auszug Systemlog:
2020.02.22 14:43:14 1: PERL WARNING: Argument "24.2   << addLog" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2220.
2020.02.22 14:43:14 1: PERL WARNING: Argument "18   << addLog" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2220.
2020.02.22 14:43:14 1: PERL WARNING: Argument "0   << addLog" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2220.
2020.02.22 14:43:14 1: PERL WARNING: Argument "24   << addLog" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2220.
2020.02.22 14:43:14 1: PERL WARNING: Argument "23   << addLog" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2220.


Ich hab den Code wie im Wiki-Beitrag https://wiki.fhem.de/wiki/Plot-Abriss_vermeiden eingefügt und er scheint auch bis auf diese Fehlermeldungen im Log gut zu funktionieren (DANKE für den Beitrag!).

Was ich nicht ganz verstehe:
- ich frage mit diesem Code jeweils 2mal um Mitternacht 62 Readings ab.
- ich erhalte diese Fehlermeldungen zu undefinierten Zeiten im laufe des Tages (siehe Log: 14:43 Uhr)
- ich erhalte jedoch immer nur 5 Fehlermeldungen.
- (ich meine) es werden alle Readings gleich abgefragt.
- Es ist in allen Logeinträgen dieser Zusatz vorhanden aber lösen nur 5 ein Problem aus, welches einen Logeintrag generiert.

Mein Lösungsansatz den ich vermutlich verfolgen werde, ausser es kennt jemand dieses Problem:
Entweder den Zusatz '<< addLog' wegnehmen oder die 5 fehlerhaften Readings finden.


Beta-User

Glaube nicht, dass es _nur_ an dem addlog-Eintrag liegt...

Kann es sein, dass du genau um die betreffende Uhrzeit eine Seite aufgerufen hast, in der 5 plots drin sind, die auf Werte zugreifen, die mit addLog geschrieben wurden? Dann solltest du diese 5 .gplot-Definitionen mal ansehen, ob die ggf. "zu großzügig" sind, was die Analyse des geloggten Werts angeht?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ch.eick

#7
Hallo,
eventuell bin ich hier mit diesem Eintrag richtig. Ich hatte den Effekt, dass bei der hier veröffentlichten Lösung zum Plot Abriss meine Rollos mit ASC Steuerung auf "manuelle" Fahrt gestellt wurden. Das liegt natürlich an dem verwendeten Trigger und führt dann zu einer Fahrsperre.

Das eigendliche Problem ist ja der Abriss des Plots, weil halt in der logDB einige einträge zuweit zurück liegen, wenn ich es richtig verstanden habe.
Nun habe ich meine logDB asyncron laufen und kann deshalb im cache zusätzliche Einträge machen, was ich so umgesetzt habe.

In der 99_myUtils.pm

#### Log-abriss vermeiden
sub
addLog($$$) {
  my ($logdb, $logdevice, $reading) = @_; # device and reading to be used
  my $logentry = ReadingsVal($logdevice,$reading,"invalid reading");
  my $timestamp = strftime "%Y-%m-%d %H:%M:%S", localtime;

  if ($reading =~ m,state,i) {
     fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$logentry."|".$reading."|".$logentry."|";
  } else {
     fhem "set ".$logdb." addCacheLine ".$timestamp."|".$logdevice."|addlog|".$reading.": ".$logentry."|".$reading."|".$logentry."|";
  }
}

Hier wird auch der Device Type mit "addlog" überschrieben, damit ich die einträge besser filtern kann. Seiteneffekte sind mir noch nicht bekannt.

Der Aufruf mit DOIF im RAW Format

defmod DF_addLog DOIF ## Stündliche Einträge\
([:59])(\
   {addLog("LogDB", "AR_O_Rollo_FSB61", "position")}\
   {addLog("LogDB", "BA_N_Rollo_FSB61", "position")}\
   {addLog("LogDB", "KU_S_Rollo_FSB61", "position")}\
   {addLog("LogDB", "SC_W_Rollo_FSB61", "position")}\
   {addLog("LogDB", "WO_S_Rollo_FSB61", "position")}\
   {addLog("LogDB", "WO_W_Rollo_FSB61", "position")}\
   {addLog("LogDB", "KU_S_Fenster"    , "state")}\
   {addLog("LogDB", "WO_W_Fenster"    , "state")}\
  )\
## Tägliche Einträge\
DOELSEIF\
([00:01])(\
   {addLog("LogDB", "AR_O_Rollo_FSB61", "position")}\
   {addLog("LogDB", "BA_N_Rollo_FSB61", "position")}\
   {addLog("LogDB", "KU_S_Rollo_FSB61", "position")}\
   {addLog("LogDB", "SC_W_Rollo_FSB61", "position")}\
   {addLog("LogDB", "WO_S_Rollo_FSB61", "position")}\
   {addLog("LogDB", "WO_W_Rollo_FSB61", "position")}\
   {addLog("LogDB", "KU_S_Fenster"    , "state")}\
   {addLog("LogDB", "WO_W_Fenster"    , "state")}\
  )\
DOELSEIF\
([+:05] and\
[PV_Anlage_1:Home_own_consumption_from_battery] eq 0) (\
   {addLog("LogDB", "PV_Anlage_1", "Home_own_consumption_from_battery")}\
  )
attr DF_addLog DbLogExclude .*
attr DF_addLog do always
attr DF_addLog room System


Das Ergebnis, natürlich nach einem "set LogDB commitCache"

MySQL [fhem]> select * from history where (DEVICE like '%Fenster%' or DEVICE like '%Rollo%') and TIMESTAMP > '2020-03-06 11:28:00' order by TIMESTAMP,DEVICE;
+---------------------+------------------+---------+-------------------------------+-----------------------+----------+------+
| TIMESTAMP           | DEVICE           | TYPE    | EVENT                         | READING               | VALUE    | UNIT |
+---------------------+------------------+---------+-------------------------------+-----------------------+----------+------+
| 2020-03-06 11:28:20 | AR_O_Rollo_FSB61 | addlog  | position: 0                   | position              | 0        |      |
| 2020-03-06 11:28:20 | BA_N_Rollo_FSB61 | addlog  | position: 0                   | position              | 0        |      |
| 2020-03-06 11:28:20 | KU_S_Fenster     | addlog  | closed                        | state                 | closed   |      |
| 2020-03-06 11:28:20 | KU_S_Rollo_FSB61 | addlog  | position: 0                   | position              | 0        |      |
| 2020-03-06 11:28:20 | SC_W_Rollo_FSB61 | addlog  | position: 0                   | position              | 0        |      |
| 2020-03-06 11:28:20 | WO_S_Rollo_FSB61 | addlog  | position: 0                   | position              | 0        |      |
| 2020-03-06 11:28:20 | WO_W_Fenster     | addlog  | closed                        | state                 | closed   |      |
| 2020-03-06 11:28:20 | WO_W_Rollo_FSB61 | addlog  | position: 0                   | position              | 0        |      |
+---------------------+------------------+---------+-------------------------------+-----------------------+----------+------+


Lustig ist, dass man so auch schon Einträge für die Zukunft eintragen kann, da nie stattfinden werden :-) , das sollte man natürlich berücksichtigen.
Heißt es dann, mein Rollo wird um 12:10 rauf gefahren worden sein???

MySQL [fhem]> select * from history where (DEVICE like '%Fenster%' or DEVICE like '%Rollo%') and TIMESTAMP > '2020-03-06 10:00:00' and timestamp > '2020-03-06 12:05:00' order by TIMESTAMP,DEVICE;
+---------------------+------------------+--------+-------------+----------+-------+------+
| TIMESTAMP           | DEVICE           | TYPE   | EVENT       | READING  | VALUE | UNIT |
+---------------------+------------------+--------+-------------+----------+-------+------+
| 2020-03-06 12:10:00 | AR_O_Rollo_FSB61 | addlog | position: 0 | position | 0     |      |
+---------------------+------------------+--------+-------------+----------+-------+------+


Viel Spaß
    Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick