Neues Plugin: Logikprozessor.pl

[Hammer69]

Hallo Micha,

die rrd´s stammen von dem Plugin "rrd_aufzeichnen.pl" damit hat auch alles gut funktioniert.
Nun wollte ich auf den LP umstellen.

Nachdem ich letzte Woche wieder alle mit dem rrd_aufzeichnen.pl gefüllt habe und alles funktionierte. Habe ich am Freitag ein Teil in den LP integriert. Dies hat auch bis gestern Nacht 0 Uhr ohne Probleme funktioniert.
Ich habe keine Idee woher es kommt das mit beginn der neuen Woche wieder das WG anfängt zu spinnen.

Hast du vielleicht eine Idee was die Ursache sein könnte?
Schönen Abend Stefan

[larsknx]

Hallo, kann mir vielleicht nochmal einer erklären, was man machen muss, damit eine Hilfs-GA über den eibd Cache verfügbar bleibt. Irgendwie gehen die Status-HilfsGA immer verloren. Und irgendwie verstehe ich das nicht ganz, warum, wenn einmal auf einer GA geschrieben wird, der Status einfach wieder weg ist. Bei den Aktoren und dessen Status GA bleiben die Werte ja auch erhalten, wenn man eine Read Request auf die Status GA des Aktors aufsetzt.

Sorry, ich weiß, wurde hier schon im Thread glaube ich auf Seite 53 diskutiert, aber ich schnalls einfach noch nicht .-(


Muss ich für jede dieser GA's eine memory Funktion setzen ?

memoryHillfsStatusGA => { transmit=>'1/2/9', reply_to_read_requests=>1 },
memoryHillfsStatusGA => { transmit=>'1/2/10', reply_to_read_requests=>1 },
memoryHillfsStatusGA => { transmit=>'1/2/11', reply_to_read_requests=>1 },

[mivola]

Hallo, kann mir vielleicht nochmal einer erklären, was man machen muss, damit eine Hilfs-GA über den eibd Cache verfügbar bleibt. Irgendwie gehen die Status-HilfsGA immer verloren. Und irgendwie verstehe ich das nicht ganz, warum, wenn einmal auf einer GA geschrieben wird, der Status einfach wieder weg ist. Bei den Aktoren und dessen Status GA bleiben die Werte ja auch erhalten, wenn man eine Read Request auf die Status GA des Aktors aufsetzt.

Sorry, ich weiß, wurde hier schon im Thread glaube ich auf Seite 53 diskutiert, aber ich schnalls einfach noch nicht .-(


Muss ich für jede dieser GA's eine memory Funktion setzen ?

memoryHillfsStatusGA => { transmit=>'1/2/9', reply_to_read_requests=>1 },
memoryHillfsStatusGA => { transmit=>'1/2/10', reply_to_read_requests=>1 },
memoryHillfsStatusGA => { transmit=>'1/2/11', reply_to_read_requests=>1 },

Um ehrlich zu sein weiß ich nicht, wie ich es noch anders erklären soll als in #784:

andere KNX-Geräte (zb Wetterstation) merken sich "ihre" Status und senden auf ein Read-Request den entsprechenden Response. Für "virtuelle" GAs gibt es aber kein passendes Gerät - außer den LP. Der kann auch auf Read-Request antworten - aber eben nicht für eigene Logiken....

Ich versuch es nochmal so: Der Status der HilfsGAs ist nicht weg. Nur: der eibd_cache rückt diesen ggf nicht raus, wenn man nicht explizit eine große Gültigkeitsdauer definiert. Und dann schickt der LP einen read-Request auf die GA raus. Nur: wer soll diesen beantworten? Es gibt kein passendes Gerät/Aktor dafür. Der LP könnte es theoretisch beantworten, ist aber momentan noch mit dem Read-Request beschäftigt. Merke: WG-Plugins (auch der LP) können niemals parallel laufen!

Eine Memory-Funktion für jede HilfsGA ist in dem Fall nur bedingt hilfreich, zyklisches Senden schon eher, denn dann kommt der benötigte Wert aus dem eibd_cache:

memoryHillfsStatusGA[COLOR=#FF0000]1[/COLOR] => { recieve=>'1/2/9', transmit=>'1/2/9', reply_to_read_requests=>1, translate=>sub{return $input}, delay=>300 },
memoryHillfsStatusGA[COLOR=#FF0000]2[/COLOR] => { recieve=>'1/2/10', transmit=>'1/2/10', reply_to_read_requests=>1, translate=>sub{return $input}, delay=>300 },
memoryHillfsStatusGA[COLOR=#FF0000]3[/COLOR] => { recieve=>'1/2/11', transmit=>'1/2/11', reply_to_read_requests=>1, translate=>sub{return $input}, delay=>300 }

Achtung: jede Logik muss einen eindeutigen Namen haben!

VG
Micha

[larsknx]

Hallo Micha, vielen Dank.

Jetzt hab ich es verstanden. Sorry, dass ich mich so blöde angestellt habe. Also einfach an die HilfsGA wie du das im Code hast, zyklisch alle 300 Sekunden ein Read Request senden, dann bleibts also im Eibd Cache.

Habe ca. 15 HilfsGA (zB Plugin Abfall -> Gelber Sack, Blaue Tonne, Biomüll etc.), für die Performance vom LP stellt das kein Problem dar, richtig ? Also was ich meine, wäre es besser, den eibd Cache zu erhöhen oder über den LP zyklisch zu senden ?


Beste Grüße Lars

[Crimson]

@mivola
Danke Micha, ich hab dir Problemchen mit dem Wecker inzwischen gelöst und schon ein paar andere Dinge mit dem Logikprozessor gemacht.

Ich lerne gerade noch mit der Timer-Syntax besser zurecht zu kommen.
Mein aktuelles Problem: Ich habe in $plugin_info{"Logik_Alarm_time"} die Weckzeit eingestellt. (Beispiel '06:00')
Jetzt möchte ich aber eine Timer-Logik bauen, die 5 Minuten vor der Weckzeit schon Dinge tut.
Also z.B. um 05:55 bereits den Audio-Zuspieler booten, damit er um 6 Uhr bereit ist.

Ist das über die Timer-Logik machbar?
Sowas wie '$plugin_info{"Logik_Alarm_time"}-5min' ?

Viele Grüße,
Tim

[mivola]

Jetzt hab ich es verstanden. Sorry, dass ich mich so blöde angestellt habe.
...
Habe ca. 15 HilfsGA (zB Plugin Abfall -> Gelber Sack, Blaue Tonne, Biomüll etc.), für die Performance vom LP stellt das kein Problem dar, richtig ?

Kein Problem wg dem Verständnis. Ich hab auch ne Weile gebraucht. Und es ist immer nicht so einfach das dann auch noch zu erklären...

15 HilfsGAs sind sicher kein Problem. Ich bin momentan bei ca 20 und >300 Logiken insgesamt. Die Anzahl bei Fry ist glaube ich bald vierstellig...

VG
Micha

[mivola]

Ist das über die Timer-Logik machbar?
Sowas wie '$plugin_info{"Logik_Alarm_time"}-5min' ?

Hi Tim,

hm, gute Frage. Sowas habe ich bisher nicht gebraucht. Aber im Prinzip ist es schon möglich in der Art und Weise die Alarm-Zeit herauszubekommen. Allerdings weiß ich nicht welches Format das dann ist (zB Timestamp: "1455303083" oder die Zeit wie sie in der Logik steht: "06:00"). Je nachdem müsste man dann versuchen die 5 Minuten abzuziehen... Ich würde mit plugin_log() arbeiten um mir die Daten/Ergebnisse ausgeben zu lassen.

Oder anderes herum: du stellst den Timer für das Hochfahren des Radios und machst dann mit followup & delay 5min später den Wecker an.

VG
Micha

[Crimson]

Die Alarmzeit einfach ein paar Minuten früher zu stellen und dann per Followup zu arbeiten ist in dem Fall am einfachsten. Gefällt mit aber irgendwie nicht so recht. ;-)

Ich hab heute mal etwas rumprobiert. Ich stelle die Weckzeit über die Visu mit 2 Slidern (einer für Stunden, einer für Minuten) ein. Das sind dann im Grunde beides Integer-Werte. Mit kleiner Logik kann ich dann von dem eingestellten Wert die 5 Minuten abziehen. Sieht irgendwie unelegant aus, funktioniert aber.

Schönes Wochenende,
Tim

[larsknx]

Ich bin momentan bei ca 20 und >300 Logiken insgesamt. Die Anzahl bei Fry ist glaube ich bald vierstellig...

VG
Micha

Ich habe derzeit 15 Logiken, überwiegend für Sprachansagen übers Multihome wie Wecker und Meldungen Abfall , Logiken für Raffstores zum Runter-/Hochfahren, Zirkulationspumpe WW zu bestimmten Zeiten einschalten. Vom Plugin bin ich total begeistert . Tolle Arbeit. Und tolle Unterstützung von vielen hier.

Nur irgendwie bin ich so unkreativ, was man noch alles so Zuhause vereinfachen kann. Wäre vielleicht auch mal ne Idee nen eigenen Thread zum LP aufzumachen, wo jeder seine Ideen bzw. Umsetzungen einbringen kann. Klar ist hier schon ne Menge dabei, aber 56 Seiten lesen will auch erst mal gemacht sein. Wenn Fry Logiken im 4 stelligen Bereich hat, würde mich echt mal interessieren, wo da so die Schwerpunkte/Gruppen aufzumachen sind.

[mmarkus]

Noch eine andere Frage, kann eigentlich ein reply_to_read_requests=>1 verzögert werden? ca 200ms wären optimal, damitt könnte ich ein falsches 0% telegramm vom DuoDMX wieder überschreiben :-D

Hm, weiß nicht so genau. Probier es mit "delay" doch mal aus ;-)

VG
Micha

Leider funktioniert es so nicht, hat jemand eine andere idee? (auch delay=>2 funktioniert nicht)

# verzögerte Antwort auf Leseanfrage
  memory1 => { transmit=>'1/1/11', reply_to_read_requests=>1, delay=>'2s' , debug=>1 },

Merci

[mivola]

Leider funktioniert es so nicht, hat jemand eine andere idee? (auch delay=>2 funktioniert nicht)

# verzögerte Antwort auf Leseanfrage
memory1 => { transmit=>'1/1/11', reply_to_read_requests=>1, delay=>'2s' , debug=>1 },

Merci

Was heißt "funktioniert so nicht"? Sendet er nicht, oder sendet er sofort ohne Verzögerung?

VG

[mmarkus]

Hallo Michael, danke für deine Hilfe

Sorri für meine unpräzise Schreibweise.

Er sendet die Antwort ohne Verzögerung. Das Delay wird einfach ignoriert. Auch im Log steht nichts vom Delay. (kann am Abend noch ein Printscreen machen)

[jensgulow]

Hilft vielleicht schon bei delay=>'2s' das s wegzulassen?

[mmarkus]

hmm, meinst du jetzt

=>'2'
oder
=>2
das letztere habe ich schon probiert. mit ' und ohne Einheit probiere ich noch am Abend
(so wie ich den LP resp Pearl verstanden habe kommt der reine Sekundenwert ohne Striche aus, bei Angabe mit Einheit müssen die '' dazu kommen. Richtig? Was bewirken diese Striche eigentlich?)

[mivola]

(so wie ich den LP resp Pearl verstanden habe kommt der reine Sekundenwert ohne Striche aus, bei Angabe mit Einheit müssen die '' dazu kommen. Richtig? Was bewirken diese Striche eigentlich?)

Die Striche machen aus dem Wert einen String den der LP auswertet. Ohne Striche ist es ein Zahlenwert (der vom LP als Sekunden interpretiert wird).

Probier doch bitte mal eine Logik wie ich sie vorher schon vorgeschlagen habe:

 
 memoryHillfsStatusGA[COLOR=#FF0000]1[/COLOR] => { recieve=>'1/2/9', transmit=>'1/2/9', reply_to_read_requests=>1, translate=>sub{return $input}, delay=>300, debug=>1 },

Genau so funktioniert es bei mir ohne Probleme.

VG
Micha