Autor Thema: Wiki-Korrektur "Plot Abriss vermeiden  (Gelesen 622 mal)

Offline predi-ger-many

  • New Member
  • *
  • Beiträge: 31
Wiki-Korrektur "Plot Abriss vermeiden
« am: 15 Oktober 2018, 20:46:19 »
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

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6120
Antw:Wiki-Korrektur "Plot Abriss vermeiden
« Antwort #1 am: 16 Oktober 2018, 06:11:46 »
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
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

Offline predi-ger-many

  • New Member
  • *
  • Beiträge: 31
Antw:Wiki-Korrektur "Plot Abriss vermeiden
« Antwort #2 am: 16 Oktober 2018, 12:51:04 »
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
« Letzte Änderung: 16 Oktober 2018, 12:55:52 von predi-ger-many »

Offline krikan

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 6120
Antw:Wiki-Korrektur "Plot Abriss vermeiden
« Antwort #3 am: 17 Oktober 2018, 10:23:21 »
Zitat
HM_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?

Zitat
Werte 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.

Zitat
In 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

Offline predi-ger-many

  • New Member
  • *
  • Beiträge: 31
Antw:Wiki-Korrektur "Plot Abriss vermeiden
« Antwort #4 am: 18 Oktober 2018, 18:47:34 »
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!


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.

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".




« Letzte Änderung: 18 Oktober 2018, 18:49:39 von predi-ger-many »