Also, angesichts der Motivation einiger Leute (z. B. @StephaneB ), schlage ich eine Weiterentwicklung der Dashboard-Blöcke vor!
Aktuell wird der folgende Block angezeigt, und ich kann die Bewässerung ein- und ausschalten. Aber das sollte nur möglich sein, wenn das Gerät, das sie steuert, online ist, der Wasserstand im Brunnen ausreichend ist, die Temperatur sommerlich ist und … usw., usw. …
Wäre es also möglich, Anzeigebedingungen für einen Block zu setzen, mit Deaktivierung des Inhalts, wenn die Bedingungen nicht erfüllt sind, und Anzeige der nicht erfüllten Bedingung(en)?
Hallo!
Also, die bedingte Anzeige eines Blocks, ich kann mir ein bisschen vorstellen, wie das funktionieren könnte. Aber bevor ich irgendetwas layouten, möchte ich, dass @pierre-gilles zuerst bestätigt, dass dies eine Richtung ist, die er akzeptieren würde, und dass ihn das nicht in Bezug auf die Reaktivität der Anzeige eines Dashboards beunruhigt, wenn eine oder mehrere Bedingungen für jeden Block überprüft werden müssen.
Aber dass es eine Anzeige gibt, die die Bedingungen kennzeichnet, die die Anzeige eines Blocks blockiert haben, kann ich mir nicht so recht vorstellen. Und ehrlich gesagt, kommt mir das seltsam als Anforderung vor: Es ist ein bisschen so, als ob du möchtest, dass das Dashboard als technisches ‹ Log › dient…
Danke, dass du dir die Zeit genommen hast, um auf meine Anfrage zu antworten
Der Sinn der vorgeschlagenen Anzeige besteht darin, den Grund dafür zu haben, warum eine Aktion nicht möglich ist. Beispiel: Ich kann das Gerät nicht bedienen, weil es offline ist. Ein weiteres Beispiel: Ich werde eine Pumpe nicht laufen lassen, wenn kein Wasser in meinem Brunnen ist. Oder noch einmal: Ich werde nicht bewässern, wenn der Bereich bereits ausreichend feucht ist …
Stellen wir uns vor, wir setzen keine Bedingung auf den Block, sondern verlagern die Bedingungen in eine Szene, die durch eine Aktion auf ein Blockelement (z. B. einen Schalter, der eine Szene startet) ausgeführt wird, wie sollte man dann vorgehen?
Persönlich sehe ich nicht viel Sinn darin, Anzeigebedingungen für das Armaturenbrett hinzuzufügen.
Das Armaturenbrett stellt manuelle Befehle dar. Wenn du also auf den Knopf des Armaturenbretts drückst, kannst du sofort sehen, ob es funktioniert oder nicht. Wie bei einem physischen Schalter in deinem Haus.
Andererseits wäre es sinnvoller, eine Steuerung in einer Szene hinzuzufügen.
Aktuell kann man das nicht direkt in Gladys, man müsste virtuelle MQTT-Geräte erstellen und einen kleinen Befehl mit NodeRed schreiben. Und mit dem zukünftigen „Sonst…Dann“-Block in den Szenen.
Ich habe die Angewohnheit, so weit wie möglich vorauszudenken: Wenn Gladys weiß, dass das, was ich einschalten möchte, nicht verfügbar ist, warum sollte dann etwas verfügbar sein, das nicht eingeschaltet werden kann? Der Schalter ist dumm, Gladys nicht (naja, das ist im Endeffekt das, was ich bei mir zu Hause versuche zu erreichen!).
Und wir kommen immer wieder zu dem, was ich vermeiden möchte: die Abhängigkeit von Gladys zu NodeRed Ich wage zu hoffen, dass, angesichts der Anzahl der wirklich klugen Köpfe, die an Gladys arbeiten, wir uns irgendwann davon trennen können?
Jedenfalls danke ich euch für diesen Austausch, der mich dazu bringt, mich eher auf gesteuerte Szenen zu konzentrieren… Jetzt muss man nur noch sehen, wie
), schlage ich eine Weiterentwicklung der Dashboard-Blöcke vor!
Ich wage zu hoffen, dass, angesichts der Anzahl der wirklich klugen Köpfe, die an Gladys arbeiten, wir uns irgendwann davon trennen können?