Hallo zusammen,
gibt es statt einem fhem ("trigger xxxxx") in einem Perl-Modul einen Resourcen schonendere Möglichkeit ein Event auszulösen?
Ich rufe in einem selbsgeschriebenem Modul gleich mehrere triggers auf, und APPTIME kommt dann über 2000ms.
Mir scheint, dass der Aufruf von trigger über die sub "fhem" viel Zeit verbraucht.....
Darf man eigentlich einen fhem ("trigger xxx") innerhalb eines "BlockingCall"s aufrufen?
Gruss
JM2012
Zitat von: JM2012 am 30 März 2017, 19:35:53
Hallo zusammen,
gibt es statt einem fhem ("trigger xxxxx") in einem Perl-Modul einen Resourcen schonendere Möglichkeit ein Event auszulösen?
Ich rufe in einem selbsgeschriebenem Modul gleich mehrere triggers auf, und APPTIME kommt dann über 2000ms.
Mir scheint, dass der Aufruf von trigger über die sub "fhem" viel Zeit verbraucht.....
Darf man eigentlich einen fhem ("trigger xxx") innerhalb eines "BlockingCall"s aufrufen?
Gruss
JM2012
Vielleicht erklärst Du lieber mal was Du mit dem ganzen Ge-trigger vor hast!?
Evtl. bist Du ja generell auf dem "Holzweg" damit!? ???
Gruß
Dan
Hallo Dan,
ja, Du hast natürlich Recht. Manchmal sieht man ja auch den Wald vor lauter Bäumen nicht.
Also...
Ich habe ca. 20 HM-Rolladenaktoren, die über drei LAN-Gateways gesteuert werden.
Ich möchte die RSSI-Werte dieser Rolladen für alle 3 Gateways in der logDB speichern.
Zusaetzlich (und damit wird es interessant) möchte ich die RSSI-Werte des Gateways und des Aktors des letzten genutzten Gateways in zwei "eigenen" Werten in der Datenbank speichern und als gplot darstellen.
Das letzte genutzte Gateway steht im "Internals IODEV".
Also habe ich mir eine readingsGruppe gebastelt,
define RssiRolladen readingsGroup <Device>,<RSSI-KG>,<RSSI-EG>,<RSSI-OG>,<IODev>,<LASTInputDev>,<ProtLastRcv> Ro.*:+.*HMLAN_KG_RSSI,+.*HMLAN_EG_RSSI,+.*HMLAN_OG_RSSI,?.*IODev,+.*LASTInputDev,+.*protLastRcv
attr RssiRolladen nameStyle style="color:black"
attr RssiRolladen room HomeMatic
attr RssiRolladen sortDevices 1
attr RssiRolladen valueStyle { if ($READING =~ m/RSSI/) { rssiValueFormat($DEVICE,$READING,$VALUE);; } }
die ich zyklisch auslese und per perl-script auswerte.
Also,
eine Loop über alle Eintraege,
gucken wer das letzte IODEV war,
dann ermitteln der RSSI-Werte (Device+Gateway) zu diesem IODEV,
...und dann, um die Daten ganz normal zu loggen, zwei trigger ......
Das sind dann pro Runde 2 x 20 triggers.....und damit etwas viel.
Warum mache ich das Ganze? Die "HM-LC-Bl1PBU-FM" haben nach meiner Meinung einen ziemlich schlechten Empfang. Um die Gateways besser "auszurichten" bzw. zuzuordnen möchte ich die RSSI-Werte grafisch dargestellen...
Gruss
JM
Das sind sehr viel spezielle Fragen die m.E. nicht in Anfängerfragen gehören.
Wohin wüßte ich aber auch gerade nicht genau. Evtl. zu readingsGroup!? Oder HomeMatic ???
Was ist das für ein Modul von dem Du im ersten Beitrag berichtet hast?
Und gib mal ein Wenig mehr preis (Code) über die sub rssiValueFormat. Wir müssen schon wissen was Du genau machst um Änderung-/Verbesserungsvorschläge machen zu können. ;)
Gruß
Dan
Meinst Du diese Module?
Blocking Call --> https://wiki.fhem.de/wiki/Blocking_Call
APPTIME --> https://wiki.fhem.de/wiki/Apptime
#########################
# groupReadings Formatierung
#########################
sub rssiValueFormat ($$$)
{
my ($DEVICE,$READING,$VALUE) = @_;
if ($VALUE <= -85) {
return ("style=\"color:red\"");
}
if ($VALUE <= -80) {
return ("style=\"color:orange\"");
}
return ("style=\"color:green\"");
}
Um die RSSI regelmäßig zu erhalten, git es noch einen:
define atRoRequestStatus at +*00:30:00 { \
fhem ("set Ro[EO]g.* statusRequest") ;;\
}
Der Rest ist schlecht geschriebener Perl-Code... :-[
Ich fummle schon ziemlich lange mit FHEM rum und über die Jahre ist da schon ein kompliziertes "Werk" enstanden, dass ich gerade aufräume.
Wenn ich darüber nachdenke,
möchte ich bei jeder RSSI-reading Änderung an einem Rolladenaktor einen eigenen reading-Wert setzen, den ich durch ein Perl-Script definieren kann. In diesem Perlscript würde ich IODEV abfragen, mir den richtigen RSSI raussuchen und diesen in meinem eignen Reading abspeichern und dann loggen.
Gruss
JM
Nicht der Trigger kostet Zeit sondern die dadurch ausgelösten Aktion. Sprich: nicht das event (an sich) verbraucht Ressourcen (Zeit). Wenn Du also tunen möchtest dann musst Du die durch das event ausgelösten Aktionen (schreiben ins filelog/dblog/events.txt etc) tunen.
vg
Joerg
Erstmal vielen Dank fuer die Antworten.
Ich habe diese Nacht nochmal drüber geschlafen und heute morgen etwas rumgespielt.
Damals bin ich über die Situation gestolpert, dass ich bei setreading kein Event generieren konnte, wenn ich es aus dem notify aufgerufen habe. Gestern habe ich den "Workaround" dazu im FHEM Reference gesehen. --> "sleep 0.1; setreading X Y Z".
Zum Testen habe ich mal folgendes gemacht:
define RoEgGaesteWc CUL_HM 1111111
attr RoEgGaesteWc IODev HMLAN_EG
attr RoEgGaesteWc IOgrp vccu:HMLAN_EG
attr RoEgGaesteWc autoReadReg 0
attr RoEgGaesteWc eventMap on:opened off:closed
attr RoEgGaesteWc expert 2_full
attr RoEgGaesteWc firmware 2.3
attr RoEgGaesteWc model HM-LC-Bl1PBU-FM
attr RoEgGaesteWc peerIDs 00000000,338D2901,338D2902,
attr RoEgGaesteWc room Rolladen
attr RoEgGaesteWc rssiLog 1
attr RoEgGaesteWc serialNr LEQ11111
attr RoEgGaesteWc sortby 1010
attr RoEgGaesteWc subType blindActuator
attr RoEgGaesteWc userReadings jmRSSIatEG
define test1 notify RoEgGaesteWc:.*rssi.* { \
test1($EVENT) ;;\
}
sub test1 {
my ($event) = @_;
if ($event =~ m/rssi_HMLAN_[KEO]G: (.*)/) {
my $value=$1;
fhem ("sleep 0.1; setreading RoEgGaesteWc jmRSSIatEG $value");
}
}
Im Prinzip fange ich das "richtige" Event vom Device ab, hole mir den Wert und lege das Ganze in einem eigenen UserReading ab.
...Und das tolle daran, jetzt wird auch ein weiteres Event generiert....
Das ist jetzt erstmal recht grob, ist aber schon mal ein Schritt in die richtige Richtung.
Warum das mit sleep 0.1 funktioniert habe ich noch nicht ganz verstanden, mehr findet man hier: https://forum.fhem.de/index.php/topic,28017.0.html
Gruss
JM
PS: Mal gucken wie die Performance unter Vollbetrieb aussieht, APPTIME wird aber glaube ich erstmal glücklich sein...