Autor Thema: Vorschlag zu 98_dewpoint in Kombination mit addLog()  (Gelesen 4106 mal)

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15920
  • s/fhem\.cfg/configDB/g
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #15 am: 01 September 2013, 19:59:46 »
Zitat von: rudolfkoenig schrieb am So, 01 September 2013 19:34
fhem("attr dewall disable");
addLog("X", "Y");
fhem("deleteattr dewall disable");

was zugegebenermassen nicht sehr elegant ist.


und außerdem nicht funktioniert. Es fehlt nämlich dann der dewpoint im Log:

2013-09-01_19:58:24 out_Balkon T: 17.4  H: 59.6   << addLog

was aber eigentlich auch logisch ist.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15920
  • s/fhem\.cfg/configDB/g
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #16 am: 01 September 2013, 20:04:22 »
Zitat von: Willi schrieb am So, 01 September 2013 19:58
Dann ist ja jetzt alles klar. Das Problem tritt auf, weil ein neues Event für state generiert wird. Dann kann auch NotifyOrderPrefix nicht helfen.

Ändere doch bitte mal in 98_dewpoint.pm die Zeilen ab Zeile 292


Hallo Willi,

Das funktioniert genau so lange, wie es nicht BAT und <<addlog gleichzeitig gibt und Du den STATE deshalb zweimal umschreiben müsstest.

Genau aus diesem Grund hatte ich die addLog-Behandlung NACH Deiner BAT Abhandlung eigenständig eingebaut.

Meine vorgeschlagene Änderung ist ausgiebig getestet und funktioniert.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 594
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #17 am: 01 September 2013, 20:07:59 »
Warum sollte es nicht funktionieren?
Bei BAT wird D: vor das BAT geschrieben und stört das << nicht.

Probiere es mal aus. Bei mir funktioniert es:

2013-09-01_20:06:32 BTHR918 T: 19.7 H: 65 P: 1015 D: 12.9 BAT: low   << addLog

2013-09-01_20:06:24 Spielezimmer_7 T: 22.0  H: 59.4   D:13.7 << addLog

-- Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15920
  • s/fhem\.cfg/configDB/g
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #18 am: 01 September 2013, 20:19:52 »
Hallo Willi,

ja, ich hatte vermutlich einen Denkfehler

Mein Gedanke bezog sich nur auf die Logik der Abfrage auf << nach der BAT Abfrage. In das elsif kommt die Abarbeitung zwar gar nicht mehr, aber Du hast natürlich recht, dass der D: dann an die richtige Stelle gesetzt wird und das dann keine Rolle spielen sollte.

Die Sache mit dem BAT: konnte/kann ich hier nicht testen, weil ich keinen Sensor habe, der das mitliefert. Wenn es bei Dir funktioniert, ist doch alles ok.

$current =~ s/<</$sensor:$dewpoint <</g;

Mach bitte zwei oder drei Leerzeichen vor das <<, damit der Eintrag etwas abgesetzt und im Log einfacher zu erkennen ist.

$current =~ s/ <</$sensor:$dewpoint   <</g;

Viele Grüße
Udo
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 594
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #19 am: 01 September 2013, 20:37:14 »
Zitat von: betateilchen schrieb am So, 01 September 2013 20:19

Mach bitte zwei oder drei Leerzeichen vor das <<, damit der Eintrag etwas abgesetzt und im Log einfacher zu erkennen ist.

$current =~ s/ <</$sensor:$dewpoint   <</g;


Ok. Wenn nichts dagegen spricht, checke ich es dann gleich ins SVN ein.

Grüße

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15920
  • s/fhem\.cfg/configDB/g
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #20 am: 01 September 2013, 20:40:03 »
danke :)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 594
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #21 am: 01 September 2013, 20:45:41 »
Ist ins SVN eingecheckt und morgen per update verfügbar.

MfG Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Offline Willi

  • Sr. Member
  • ****
  • Beiträge: 594
Aw: Vorschlag zu 98_dewpoint in Kombination mit addLog()
« Antwort #22 am: 02 September 2013, 09:32:33 »
Zitat von: rudolfkoenig schrieb am So, 01 September 2013 19:34
Das Problem ist, dass addLog genauso ein Event generiert, wie ein S300TH, und dewpoint haengt (wie bestellt)  ein D: dran.

@Rudi: Hatte ich ganz vergessen: Danke für Deine Fehleranalyse/Unterstützung!
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

 

decade-submarginal