UZSU nächsten Schaltpunkt als Tooltip anzeigen

[bmx]

Hat schon mal jemand für die UZSU etwas geschrieben um den nächsten Schaltzeitpunkt als Tooltip über dem UZSU Icon anzuzeigen?

[wvhn]

Moin bmx Bernd,

aktuell geht das nicht, weil die Info über den nächsten Schaltzeitpunkt im Widget nicht vorliegt. Man müsste wie bei device.uzsugraph eine komplette Timeline über alle Einträge einschl. Schaltserien, sonnenabhängigen Zeiten und Wochentagen aufbauen, um den nächsten Schaltzeitpunkt bestimmen zu können. Das ist grundsätzlich natürlich machbar, erfordert aber einen Umbau der UZSU-Widgets.

Da der nächste Schaltzeitpunkt immer im Scheduler von shNG angelegt ist, wäre die Frage, ob man diesen auslesen und in einem Hilfsitem zur Verfügung stellen kann. Zumindest für das WebIF ist der Wert ja lesbar. Aus meiner Sicht ist es sinnvoller, den tatsächlichen Wert zu nehmen, als ihn in der Visu nochmal nachzubilden.

Gruß
Wolfram

[Maexle]

Moin bmx Bernd,

…das WebIF ist der Wert ja lesbar

das wäre mMn eine feine Sache - ich stelle mir das ganz unabhängig vom Rest vor. Eine eigene Info-Seite wo die UZSU‘s angezeigt werden können. Muss nicht ins WebIF gewechselt werden um zu sehen, wann zB der Rollo abends fahren wird

[AndreK]

HI,

man kann die Web-IF-Daten über eine Logik oder Eval in ein Item schreiben. Das kann dann zumindest mit basic.print dargestellt werden. Für den Tool-Tipp bräuchte es dann
eine Erweiterung des UZSU-Widget.

Abfragen der der Daten mit folgendem Code :

import json
test=sh.uzsu._webdata
print(json.dumps(test['items']['indego.active_mode.uzsu.schaltuhr']['planned'],indent=2))​

liefert :

{
  "value": 10.0,
  "time": "18.04.2024 14:00"
}​

Viele Grüße
Andre

[bmx]

Danke für die Ideen. Ich vermute den neuen Schaltzeitpunkt kann man auch in ein Hilfsitem packen und dann anzeigen. Nur wenn es da schon eine Lösung gegeben hätte würde ich die einfach kopiert haben. Eventuell kann man das in einem Struct mit abhandeln und mit dem uzsu Plugin mitliefern, dann muss das Rad nicht jeder selbst erfinden.

[wvhn]

Onkelandy, AndreK,

könnt Ihr das als Feature Request für das UZSU-Plugin aufnehmen: den nächsten Schaltzeitpunkt und den zugehörigen Wert vom Plugin aus standardmäßig in eine erweiterte item-Struktur schreiben?

Ich habe derweil mal gespielt und basic.print so erweitert: dass es einen dynamischen Tooltip in einem angebundenen Widget anlegt:

{{ device.uzsuicon('uzsu1', 'myItem.uzsu', '', '', '', 'num') }}
{{ basic.print('', 'myItem.uzsu.active', 'text', 'VAR?"Schaltuhr ist aktiv":"Schaltuhr ist inaktiv"', '', '', 'uzsu1', 'tooltip')​ }}

Dazu wird im Parameter "href" die id des anzubindenden Widgets angegeben und im Parameter "rel" der Wert 'tooltip'. Das Beispiel verwendet ein heute verfügbares item. Natürlich kann auch die geplante Schaltzeit dargestellt werden, wenn diese als item vorliegt.

tooltip.gif

Die Erweiterung ist im develop branch.

Gruß
Wolfram

[Onkelandy]

Damit ich das richtig verstehe, da müsste Zeitpunkt und geschalteter Wert in das gleiche Item geschrieben werden.. oder könnte man auch ein struct liefern mit einem "next_time" und "next_value" oder so?

[wvhn]

"next_time" und "next_value" ist aus meiner Sicht die beste Lösung. Das kann man in der Visu immer sauber verarbeiten.

Gruß
Wolfram

[Onkelandy]

Folgender Eintrag unter "uzsu" Item im Struct müsste eigentlich reichen.

            next:
                remark: The next value and time
                type: dict
                visu_acl: ro
                eval: sh...planned()
                crontab: init = None
                eval_trigger: ..

                value:
                    remark: The next value
                    type: str
                    visu_acl: ro
                    eval: sh...property.value['value']
                    crontab: init = None
                    eval_trigger: ..

                time:
                    remark: The next time
                    type: str
                    visu_acl: ro
                    eval: sh...property.value['next']
                    crontab: init = None
                    eval_trigger: ..

bmx hast du dir das so vorgestellt?

[AndreK]

Hi Onkelandy Andy,

ach so ,

die "Funktion" - planned() hatte ich auch gesehen. Diese wird vom Logik-Editor und vom Executor-Plugin als Plugin-Funktion vorgeschlagen.

sh.uzsu.planned()

Das ergibt aber kein Ergebnis da es sich um eine zusätzliche Item-Funktion, ergänzt durch das Plugin, handelt.
Wie die db-Funktion bei Items mit database-Zuordnung. Hier liefert sh.database_plugin.db eine Instanz auf die Datenbank, sh.item.db(xxx) liefert Werte aus der DB.
Es lässt sich Stand heute nicht erkennen wie mit der Funktion umzugehen ist.

In der plugin.yaml ist das als "plugin_functions" definiert und wird so auch in den autocompletes vorgeschlagen. Das sind aber eher "additional_item_functions" - welche es meine ich, so oder so ähnlich, in der plugin.yaml nicht gibt, oder vielleich doch ?

Viele Grüße
Andre

[Onkelandy]

Hast recht, das sind eigentlich item Funktionen, funzt nur, wenn man direkt das UZSU Item damit bestückt, also so wie oben angegeben. Theoretisch könnte mans auch als Pluginfunktion aufbauen, wo man dann halt noch das uzsu item als Parameter mitgeben muss - aber da würde ich jetzt den Vorteil nicht wirklich sehen, außer dass es mehr im Sinne des Erfinders wär

[wvhn]

Moin Onkelandy,

mit der Erweiterung des Structs klappt es prima. Es gibt nur ein Problem: beim Neustart von shNG wird uzsuitem.next nicht korrekt initialisiert, obwohl die UZSU aktiv ist. Es erscheinen folgende Meldungen im Log während der Initialisierung:

2024-04-18  19:30:52 WARNING  lib.item.item       Item 'test.varuzsua.uzsu.next.time': problem evaluating 'sh.test.varuzsua.uzsu.next.property.value['next']' - KeyError (in dict)
2024-04-18  19:30:52 WARNING  lib.item.item       Item 'test.varuzsua.uzsu.next.value': problem evaluating 'sh.test.varuzsua.uzsu.next.property.value['value']' - KeyError (in dict)
​

Ich muss dann die vorhandenen Einstellungen im UZSU-Widget nochmal aufrufen und abspeichern.

Danach bekomme ich den Tooltip mit folgendem Code (basic.print aus der aktuellen develop-Version):

{{ device.uzsuicon('uzsu1','test.varuzsua.uzsu') }}
{{ basic.print('',['test.varuzsua.uzsu.next.time','test.varuzsua.uzsu .next.value'],'text', '"Nächste Schaltzeit: "+VAR1+" Wert: "+VAR2', '', '', 'uzsu1', 'tooltip') }}

Ergebnis:
grafik.png

Gruß
Wolfram

[Onkelandy]

Das sieht ja 1A aus. Bei mir klappt die Initialisierung schon, aber vermutlich werden alle 3 Items quasi zeitgleich getriggert bzw. das Unteritem zu früh.
Klappt es, wenn du crontab: init = None bei time und value raus nimmst? Bei mir sieht das gut aus.

[wvhn]

Moin Onkelandy Andy,

ich bekomme das mit der Initialisierung nicht hin. Wenn ich die beiden Crontab-Einträge raus nehme, dann verschwinden die Fehlermeldungen in den child items. Aber das Mutter-item item.uzsu.next bleibt immer leer, bis ich einmal manuell die UZSU deaktiviert und wieder aktiviert habe. Habe schon versucht, das Crontab-init um 2 Minuten zu verzögern oder mit item.uzsu.active zu triggern - alles erfolglos. Zudem werden item.uzsu.next und Kinder nicht aktualisiert, wenn die UZSU Schaltbefehle ausführt.

Wenn ich den eval-Trigger für item.uzsu.next zusätzlich an den "Großvater" hänge, also ans item für den Aktor, dann klappt es wenigstens mal mit der Aktualisierung. Beim init bleibt item.uzsu.next weiterhin leer.

Basis: smarthomeNG v1.10.0.1-f3e33c67b.develop mit plugins v1.10.0.1-629e601d.develop (UZSU-pligin v2.0.1) unter Raspbian Bookworm und Python 3.9.2. Deine oben gepostete Erweiterung habe ich einfach in der plugin.yaml des UZSU-plugins an das bestehende Struct drangehängt.

grafik.png

Gruß
Wolfram

[Onkelandy]

Mhm muss ich mir ansehen. Prinzipiell muss der evltrigger definitiv optimiert werden Eventuell muss ich noch einen anderen Weg suchen