Sporadisch aktive Datenpunkte -> Wie?
-
Okay. Das Problem das ich sehe ist nur, dass der Nutzer, die betreffenden Buttons (oder anderen Aktionen) ja jederzeit drücken (aktivieren, ausführen) kann - unabhängig davon wann ich zuletzt aktualisiert habe. Und dann rauscht das Ganze eben in einen Fehler - und genau den möchte ich eben gerne von vorn herein verhindern.
-
@grizzelbee sagte: Buttons (oder anderen Aktionen) ja jederzeit drücken (aktivieren, ausführen) kann - unabhängig davon wann ich zuletzt aktualisiert habe.
Ohne konkretes Beispiel kann ich schlecht nachvollziehen, was Du meinst.
-
Das ist ein Auszug aus dem Aktions-Zweig des Miele Adapters.
Mit Ausnahme der Power-Aktion kann zum Beispiel jede dieser Aktionen nur verwendet werden, wenn die Maschine auch an ist (oder sogar noch andere Nebenbedingungen erfüllt sind). Um Zu zeigen welche Aktionen gerade ausgeführt werden können, sendet Miele regelmäßig ein JSON mit den gerade möglichen Aktionen. Da die Datenpunkte aber permanent im Tree sind (und sein müssen) kann der Benutzer sie auch jederzeit klicken - unabhängig davon ob Miele sie gerade freigegeben hat oder nicht. Bedeutet: Ich kann zum Beispiel Long_Coffee jederzeit klicken - selbst wenn die Maschine aus ist - und laufe dann eben in einen Fehler. Den könnte ich einfach ins Log schreiben - das bekommt der Nutzer aber nicht mit, weswegen ich es für die schlechteste Lösung halte. Bislang schreibe ich eine Meldung in einen DatenpunkteLastResult, was ich aber auch blöd finde. Am liebsten würde ich das Klicken/Ändern des entsprechenden Datenpunktes unterbinden um erst gar keinen Fehler auszulösen. Wie gesagt: In einer GUI würde ich das entsprechende Element ausgrauen (disablen) - aber das geht hier ja nicht. -
@grizzelbee
Man kann die Zustände von Datenpunkten mittels expire löschen. Dann sieht man nur(null). -
Danke für den Tipp. Ich bin mir zwar noch nicht ganz sicher, ob das mein Problem löst, aber ich spiele mal ein bisschen damit rum.
-
Naja die Frage ist was Du genau erreichen willst.
Geht es darum das ein User im "Admin als Steuerkonsole" (was ja nicht wirklich der Usecase von Admin sein sollte) sieht was gerade geht?
Dann bist Du bei Objekte lösen und neu anlegen - wenn sich das aber zu oft ändert nervt das nur
Ich denke da wäre es das beste zu sagen "kommandos werden bestätigt (wert mit ack setzen) wenn die Aktion ausgeführt werden konnte" und halt nicht bestätigt wenn nicht - und im Log steht ggf warum. Das ist zumindestens der Teil wo einige User wissen "wenns nicht grün wird ging es nicht"
Alternative zu Objekte anlegen/löschen ist das "common.write aktualisieren" (was am ende "Objekte ändern") heisst. Dann kann es sein das Admin es korrekt als inaktiv anzeigt.Weiterhin könnte man einen "lastResult" State machen woman textuell reinschreiben kann "OK" vs "Geht nicht weil Gerät aus" ... dann könnte ein User das im Admin sehen.
Wie man das aber in Wirklichkeit Sinnvoll macht damit Skripte, iot und alle Herren Visualisierungen damit klarkommen ist ne gaaanz andere Story
Und das wäre die "eigentlich Relevante" Thematik.Weil hier (wenn wir mal das von oben durchgehen):
- Objekte löschen/neu anlegen bringt denke ich alle Visus und Skripte durcheinander und sorgt für blöde "state gibts nicht Logs" und sonstwas für unklarheiten
- common.write leider fast das gleiche. Skripte ignorieren es bzw dann loggt der controller ein warning und visus müssten Objektupdates alle mitlesen und ihre UIs aktualisieren, was keine tut
- Da wäre das ack vllt das beste, wobei auch das wieder komische effekte haben wird, aber wäre mal mindestens für Skripte möglich
Am Ende glaube ich das wir für sowas aktuell keine saubere Lösung haben die ich kennen würde. Ich denke der "ack bestätigen vs nicht" ist der sinnvollste und sichtbarste - ggf kombiniert mit nem "lastResult" was man auswerten kann. Visus und andere Logiken die dem User vorher sagen das ne Aktion nicht gehen wird ist am Ende eh speziell zu bauen.
-
PS: Die ganz große Alternative - die dann aber Admin ausschliesst und viele Visus auch wäre die Aktionen auch/nur per Messages anzubieten. Da könntest Du eine Response mitgeben
Vllt für Skripte sogar der sehr komfortable weg. Aber für Visus und Admin leider komplett ungeeignet meistens -
@apollon77 sagte in Sporadisch aktive Datenpunkte -> Wie?:
Naja die Frage ist was Du genau erreichen willst.
Die Idee war eigentlich den Adapter zu härten und Nutzer vor komischen/unerwarteten Reaktionen (oder eben Nicht-Reaktionen) des Adapters zu bewaren. Nicht mehr, nicht weniger.
Geht es darum das ein User im "Admin als Steuerkonsole" (was ja nicht wirklich der Usecase von Admin sein sollte) sieht was gerade geht?
Nein gar nicht. Meine Frage ging ja eher in die Richtung, ob es eine Eigenschaft/Technik in der Art
common.enabled={true|false}fürcommon.write=trueObjekte gibt, die Skripte und GUIs prüfen können um von vornherein Aktionen unterdrücken zu können von denen der Adapter weiß, dass sie kaputt gehen werden weil sie aufgrund des aktuellen Status' des Gerätes gar nicht funktionieren können.Für den Augenblick denke ich, ist die Idee mit dem ACK, lastResult und Log tatsächlich das machbarste.
Vielen Dank für die gute Diskussion und vielleicht ist common.enabled ja eine Idee für die Zukunft.
-
@grizzelbee sagte in Sporadisch aktive Datenpunkte -> Wie?:
Nein gar nicht. Meine Frage ging ja eher in die Richtung, ob es eine Eigenschaft/Technik in der Art common.enabled={true|false} für common.write=true Objekte gibt, die Skripte und GUIs prüfen können um von vornherein Aktionen unterdrücken zu können von denen der Adapter weiß, dass sie kaputt gehen werden weil sie aufgrund des aktuellen Status' des Gerätes gar nicht funktionieren können.
Wäre durchaus ne Interessante idee ... aber am Ende ... wenn Du das Objekt aktualisierst um "enabled" zu setzen kannste auch gleich write ändern
Man könnte jetzt noch die Idee von https://github.com/ioBroker/ioBroker.admin/issues/1383 weiterspinnen und dann würde ich (weil am Ende eh die visus angepasst werden müssen) ein common.statusStates.enabledId sehen wo eine State Id drinsteht ob das State "aktiv" ist oder nicht
Ist aber so ein "müssen vor allem die Visu Devs gut finden" Thema weil wenns keiner macht ... blöd... setze es doch mal auf die Liste fürs nächste Dev-Meeting
closed Farbgebung für Objectliste #1383
-
wenn ich aus dem verlauf richtig entnommen habe, bietest du einem nuter die objektbaum-Ansicht an?
Besser wäre es eine konkrete visualisierung (mit vis oder einer der anderen visualisierungsadaptern anzubieten)
dort lässt sich dann logik hinterlegen, ob ein knopf angezeigt werden soll oder nicht (bspw in vis per binding im reiter sichtbarkeit) -
@oliverio sagte in Sporadisch aktive Datenpunkte -> Wie?:
wenn ich aus dem verlauf richtig entnommen habe, bietest du einem nuter die objektbaum-Ansicht an?
Nein, da hast Du den Verlauf falsch interpretiert. Ich biete Nutzern außer dem reinen Adapter gar nichts an. Aber Adapter sind eben die Brücke zwischen den Geräten und den Visus (egal ob Admin, VIS, lovelace oder welche auch immer) und wissen über die Geräte bescheid (zumindest mehr als die GUI). Und im vorliegenden Fall geht es bei den Steuerungsfunktionen um mehr als nur an/aus. Es geht um Haushaltsgeräte. Manche Funktionen stehen nur unter gewissen Nebenbedingungen zur Verfügung. Da die Buttons aber dauerhaft vorhanden sind und jederzeit (unabhängig von den Nebenbedingungen) gedrückt werden können - lösen sie halt Fehler aus, wenn die Nebenbedingungen nicht erfüllt sind. "Normale" GUIs unter Windows, Linux, MacOs lösen das Problem dadurch das sie Buttons, die gerade nicht funktionieren abschalten (ausgrauen).
Meine Frage war also im Kern, ob es einen vergleichbaren Mechanismus auch im Broker gibt um den Adapter zu härten und den Nutzern Fehlerbehandlung in der GUI zu ersparen.
