zusätzliche Item-Funktionen

[Cannon]

Hallo,

ich würde mir noch 2 Funktionen in den Items wünschen.

1. Eine Blink-Funktion. Dann müsste man nicht umständlich über eine Logik gehen und könnte das auch sauberer lösen. Ich habs mal probiert, aber so tief stecke ich in den ganzen libs nicht drin. Die könnte dann so aussehen: blink(puls, pause, count, value_on, value_off):

puls = wie lange an
pause = wie lange aus
count = Anzahl blink-Impulse -> 0 oder None = unendlich
value_on = Wert für ein
value_off = Wert für aus

Das würde mir sehr helfen, da ich gern mit visuellen Quittierungen arbeite.

2. eval und eval_trigger bieten nicht die Möglichkeit Items manuell zu überschreiben, weil eval immer ausgeführt wird. Es wäre aber vorstellbar eval nur dann auszuführen, wenn es durch eval_trigger ausgelöst wird, sonst nicht. Das könnte man mit einem zusätzlichen Item-Parameter festlegen. So hätte man dann die Möglichkeit das Item sowohl mit eval_trigger, als auch manuell zu "bedienen".

Wie seht ihr das?

[Sisamiwe]

1. Eine Blink-Funktion. Dann müsste man nicht umständlich über eine Logik gehen und könnte das auch sauberer lösen. Ich habs mal probiert, aber so tief stecke ich in den ganzen libs nicht drin. Die könnte dann so aussehen: blink(puls, pause, count, value_on, value_off):

Ich finde die Idee gut, denke aber auch, dass die Funktionen besser in einem Plugin als im Core aufgehoben werden. Es existiert doch schon eine recht umfangreiche Logik für "Blinken". Das stellt doch eine Prima Grundlage für ein System-Plugin dar, oder?

2. eval und eval_trigger bieten nicht die Möglichkeit Items manuell zu überschreiben, weil eval immer ausgeführt wird. Es wäre aber vorstellbar eval nur dann auszuführen, wenn es durch eval_trigger ausgelöst wird, sonst nicht. Das könnte man mit einem zusätzlichen Item-Parameter festlegen. So hätte man dann die Möglichkeit das Item sowohl mit eval_trigger, als auch manuell zu "bedienen".

Das würde mit gerade beim Debugging auch sehr helfen. Wie aufwendig wäre hier eine Umsetzung?

[Cannon]

Ich finde die Idee gut, denke aber auch, dass die Funktionen besser in einem Plugin als im Core aufgehoben werden. Es existiert doch schon eine recht umfangreiche Logik für "Blinken". Das stellt doch eine Prima Grundlage für ein System-Plugin dar, oder?

Warum nicht direkt im Core? Es gibt doch ohnehin schon einen Fader und Timer usw. Das würde sich perfekt einreihen.

Das würde mit gerade beim Debugging auch sehr helfen

Eine Frage dazu am Rande: Gibt es denn eine Möglichkeit den Code Logiken und Items irgendwie zu debuggen, ohne dass man dafür SmartHomeNG ständig neu starten muss (muss man ja bei Logiken nicht) bzw. ohne den ItemTree zu nutzen bzw. ohne die DEBUG-Ausgaben im Code, also wie ein Debugger in anderen Sprachen auch, wo man die Werte direkt auslesen kann?

[Onkelandy]

Du könntest es mit dem eval syntax Prüfer im Admin IF oder mit dem Executor Plugin probieren, Code zu testen. .. Oder wie genau meintest du "Code Logiken und Items irgendwie zu debuggen"

Alternativ vielleicht das hier, aber ich habe keine Ahnung, ob und wie das noch funktioniert: https://knx-user-forum.de/forum/supp...m-smarthome-py

[jentz1986]

2. eval und eval_trigger bieten nicht die Möglichkeit Items manuell zu überschreiben, weil eval immer ausgeführt wird. Es wäre aber vorstellbar eval nur dann auszuführen, wenn es durch eval_trigger ausgelöst wird, sonst nicht. Das könnte man mit einem zusätzlichen Item-Parameter festlegen. So hätte man dann die Möglichkeit das Item sowohl mit eval_trigger, als auch manuell zu "bedienen".

Wie seht ihr das?

Das fühlt sich als schwer zu debuggen an.
Ich habe, wenn ich evals baue und langfristig teste, das eval zweimal: Einmal nur als Ergebnisausgabe und einmal mit den Verknüpfungen an Plugins. D.h. einmal in der Integration mit KNX oder Unifi und co und einmal "alleinstehend", ohne das Brimborium.
Ich nutze eval auch mal als Konverter von boolean nach string oder number, das wäre dann auch nicht so leicht machbar.
--> Vielleicht habe ich Deinen Ansatz aber noch nicht so ganz verstanden :-)

Ich habe mir eine utility-Sammlung als Plugin gestrickt mit der ich mir solche Sachen, die ich im Core vermisse nachbilde. Damit habe ich eine Nachrichtenverwaltung für KNX-Taster gebaut; Wollte gerade noch nachfragen, ob das noch wer gebrauchen kann... Und auch enthalten ist eine Verwaltung für getrennte Ein- und Ausschaltverzögerungen, die dann einfach an einem Item definiert werden können und sich auf ein anderes Item auswirken. Das erleichtert das Debugging. Das mit der Ein- und Ausschaltverzögerung ließe sich dann auch recht einfach auf blink überführen. - Könnte dann so aussehen:

blink(puls, pause, count, value_on, value_off)

Das sieht so aus, als ob Du die aus ner Logik heraus aufrufst. Meine Philosophie von oben wäre ein Item zu nehmen, dass den Statuswechsel entgegennimmt (type bool) und dann ein anderes Item blinken lässt. Die Konfiguration des Blinkens wäre dann am Sender, somit sind dann sehr schnell viele Blink-Modi möglich. Ich könnte mir auch vorstellen, dass man damit noch codes macht: [0,1,0,1,0,1] (einfach), [0,1,0,1,0,1,0, 1, 1, 0, 1, 1, 0, 1, 1, 0,0,1,0,1,0,1] (SOS) :-D

Beispiel, dann ganz ohne Logik:

led_meldung_im_flur:
    type: bool
    knx_elemente...
    
    garagentor_fährt:
         type: bool
         knx_elemente....
         blink_target: ..
         blink_pattern: [0,1] # kann man weglassen, wäre default
         blink_cycle: 1s # kann man weglassen, wäre default
         blink_loops: 20       # 20 x 2s = 40s blinkts, bzw. bis das Item ausgeht
    garagentor_verklemmt:
         type: bool
         knx_elemente...
         blink_target: ..
         blink_pattern: [0, 1, 0, 1, 0, 1, 0, 1, 1, 0, 1, 1, 0, 1, 1, 0, 0, 1, 0, 1, 0, 1, 0, 0]
         blink_cycle: 0.5s
         blink_loops: 0       # Für immer, bzw. bis das Item ausgeht

Mit Logiken muss man immer prüfen, ob die Rückmeldung überhaupt noch relevant ist, usw...

[bmx]

Das als Plugin fände ich gut. Implementierst Du das mal und machst einen PR?

PS: Die Idee mit dem Blink Pattern finde ich gut. Noch besser wäre es allerdings, wenn man auch Item-Werte dafür hernehmen könnte.
Und wenn man statt dem Cycle auch dort eine Liste mit Zeitabständen definieren könnte wäre das noch besser.

Mein Use-Case: Pumpensteuerung
Da habe ich ein Item mit der Dauer die eine Pumpe eingeschaltet werden soll und ein Item das die Dauer der Pause beinhaltet.

[jentz1986]

Mein Use-Case: Pumpensteuerung
Da habe ich ein Item mit der Dauer die eine Pumpe eingeschaltet werden soll und ein Item das die Dauer der Pause beinhaltet.

Das hab ich mit der PWM-Funktion vom MDT Logikmodul gelöst (Zirkulationspumpe).

Aber stimmt, letzten Endes ist das ja auch nichts anderes als fast eine PWM...

So hab ichs jetzt erstmal in der plugin.yaml definiert, damit ist dann auch die Zeitabstandsfrage behandelt:

    utility_blink_target:
        type: str
        mandatory: True
        description:
            de: 'Pfad zum gesteuerten Item'
            en: 'Path to the target-item'
    utility_blink_pattern:
        type: list
        default: [0,1]
        description:
            de: 'Muster nach dem geblinkt wird, hier werden die Zielwerte definiert, Standard: [0,1]'
            en: 'Pattern of blinking-sequence, here are the sent values defined, default: [0,1]'
    utility_blink_cycles:
        type: list
        default: [1,1]
        description:
            de: 'Muster nach dem geblinkt wird, hier werden die Zeitabstände für die jeweiligen Schritte in Sekunden definiert, Standard: [1,1]'
            en: 'Pattern of blinking-sequence, here are the periods defined in which the pattern is sent, default: [1,1]'
    utility_blink_loops:
        type: num
        default: 0
        description:
            de: 'Anzahl der Durchläufe bei angefordertem Blinken, 0 = Endlosschleife'
            en: 'Number of loops when blinking is requested, 0 = infinite loop'

Jetzt muss ich nur noch das Programm schreiben

[jentz1986]

So. Dreht / Blinkt.

        stehlampe:
            struct: schaltkanal_einfach
            knx_cache: xyz
            knx_send: abc
            blinker:
                type: bool
                utility_blink_target: ..
                utility_blink_loops: 3
            blinker_2:
                type: bool
                utility_blink_target: ..
                utility_blink_loops: 3
                utility_blink_cycles: [0.5,.7,1,0.5]
                utility_blink_pattern: [True,False,True,False]

Msinn / bmx: Wenn das Plugin timing_utilities heißt, müssen die Item-Attribute dazu dann timing_utlities_blink... heißen, oder darf das so bleiben?

[Msinn]

Eigentlich müssen die Attribute timing_utilities_… heissen. Wichtig ist, dass die Zuordnung zum Plugin eindeutig ist. Bei Dir ist zwar im Moment für SmartHomeNG utility_blink_… auch eindeutig dem Plugin zuzuordnen, aber jemand anders könnte auch ein Plugin mit diesem Attribut-Präfix schreiben.

Deshalb ist die Regel, dass die Attribute mit dem Namen des Plugins oder mit einem zuzuordenden Kürzel (tu_…) beginnen müssen.

Allerdings wäre ein kürzerer Plugin Name wünschenswert, da ja auch das Verzeichnis des Plugins diesen Namen tragen muss.

[jentz1986]

Wichtig ist, dass die Zuordnung zum Plugin eindeutig ist. (...) Allerdings wäre ein kürzerer Plugin Name wünschenswert, da ja auch das Verzeichnis des Plugins diesen Namen tragen muss.

Dann heißt das Kind jetzt timmy.
utility ist einfach zu generisch, timing, timer und so ist alles schon belegt. Timy war mein erster Gedanke, aber da gibts n Slack-Plugin, das so heißt.
blinker reicht nicht, weil ich halt noch Ein- und Ausschaltverzögerungen da drin habe.

Der Code ist hier:
https://github.com/jentz1986/smartho...op-timmy/timmy

Pull Request ist im Draft-Zustand (https://github.com/smarthomeNG/plugins/pull/521).

Nur für den Fall das jemand mittesten möchte und nicht so richtig weiß, wie er/sie/es das anstellen soll:

(hab den Text von bmx kopiert und hier angepasst)

Um den Entwicklungsstand herunterzuladen ist es am einfachsten ein neues privates Plugin zu erstellen.

1. Unterverzeichnis in smarthome/plugins mit Namen timmy erstellen (da das ganz neu ist, kann man nun einfach den Namen verwenden)
2. Eine Zip Datei des Plugins vom Entwicklungsstand erstellen lassen, dazu auf Downgit gehen und dort als URL https://github.com/jentz1986/smartho.../timmyeingeben.
3. Den Inhalt der Zipdatei dann in timmy reinkopieren, darauf aufpassen, das dort dann nicht nur timmy drinsteht sondern die gleiche Struktur wie in anderen Plugin Ordnern auch.
4. Jetzt kann die etc/plugin.yaml um das hier ergänzt werden:
   

   	timmy:
   	    plugin_name: timmy

5. Dann können die Items in der items.yaml angelegt werden und anschliessend kann SmartHomeNG neu gestartet werden.

[jentz1986]

Beispiele:

        stehlampe:
            type: bool

            blinker:
                type: bool
                timmy_blink_target: ..
                timmy_blink_loops: 3
            blinker_2:
                type: bool
                timmy_blink_target: ..
                timmy_blink_loops: 3
                timmy_blink_cycles: [.3,.3]
                timmy_blink_pattern: [True,False]

        sonnenschutz_noetig:
            type: bool
            eval: sh.wetter.luft_temperatur() > sh.wetter.luft_temperatur.sonnenschutz_noetig.grenzwert()
            eval_trigger:
                - ..self
                - .grenzwert
            timmy_delay_target_item: .schalter_nach_hysterese
            timmy_delay_off_delay_seconds: 1800
            timmy_delay_on_delay_seconds: 300
                
            schalter_nach_hysterese:
                type: bool

Ich hab nur nen 1-Wire Sensor draußen hängen, keine Wetterstation, daher brauche ich ne Hysterese. Die ist damit dann hier gebaut (ist natürlich für Arme).

[Cannon]

Ich habe das blinken ja bisher über eine Logik gemacht und direkt auf eine KNX-Adresse geschrieben. Nun habe ich das mal zum testen eingebaut. Dadurch, dass das Ziel ist ja das Item blinken zu lassen, schneint das etwas langsamer zu sein, als meine Logik. Ich kriege das auch nicht beschleunigt und es sind definitiv keine 300 ms:

        quittieren:
            type: bool
            enforce_updates: yes
            visu_acl: deny
            timmy_blink_target: .target
            timmy_blink_loops: 7
            timmy_blink_cycles: [.3, .3]
            timmy_blink_pattern: [True, False]
            target:
                type: bool
                knx_dpt: 1
                knx_send: 0/2/7
                enforce_updates: yes
                visu_acl: deny

Auch, wenn ich die Cycles noch niediger stelle wird es nicht schneller. Lässt sich das irgendwie beschleunigen?

[jentz1986]

Mir ist das aufgefallen, dass das lahm ist, aber nur in der Phase in der sich SHNG initialisiert. D.h. Vom KNX und von den Wetterdiensten und so Fakten sammelt. Danach war das bei mir schneller als ich es spezifizieren konnte. Ich betreibe SHNG auf ner Synology DS918+. Ein Pi hat viel weniger Power… Kann eins von beidem die Ursache sein?

[jentz1986]

Ansonsten müsste ich mich mal mehr mit den Schedulern in SHNG auseinandersetzen…

[Cannon]

Mir ist das aufgefallen, dass das lahm ist, aber nur in der Phase in der sich SHNG initialisiert. D.h. Vom KNX und von den Wetterdiensten und so Fakten sammelt. Danach war das bei mir schneller als ich es spezifizieren konnte. Ich betreibe SHNG auf ner Synology DS918+. Ein Pi hat viel weniger Power… Kann eins von beidem die Ursache sein?

Ich teste das noch mal .. möglicherweise, weil ich neu gestartet habe. Wobei die Logik-Sachen ja parallel auch schneller laufen. Eher unwahrscheinlich, dass es an der Initialisierungsphase liegt. Aber ja ich nutzte einen Raspberry 3B.