Auflistung von Zuständen einer bestimmten Funktion
-
@ben1983
Hab sowas ähnliches, aber via Blockly, bei mir am Laufen, jedoch mit einem etwas anderen Ansatz.In meinem Fall kann ich je nach Anwendungsfall auf false/true bzw. von-bis-Werte reagieren und schreib die Ergebnisse dann in Summen (nur zählen bzw zusätlich aktiv, inaktiv) und auf Wusnch automatisch erstellte Räume je Gewerk. Zudem kann ich für bis zu vier dieser Scripte nochmals die Räume zu einem bit-maskierten Wert zusammenführen um damit die optische Anzeige der Räume in der Visualisierung zu steuern.
Nutz das Ganze ohne große Anpassung für alles mögliche (Fenster, Rollläden, Lichter, Firmwareupdates, Batterien etc.)
Einen passenden Adapter, der mir alles was ich haben möchte so 1:1 umsetzt, hab ich dazu leider aber keinen gefunden.
-
@wolfi913 Die Idee war ja bei Bedarf daraus einen Adapter zu machen.
Ist halt die Frage ob es Interessenten gibt, bzw. was User sich für Nutzen wünschen. -
@ben1983 sagte in Auflistung von Zuständen einer bestimmten Funktion:
@wolfi913 Die Idee war ja bei Bedarf daraus einen Adapter zu machen.
Ist halt die Frage ob es Interessenten gibt, bzw. was User sich für Nutzen wünschen.Sorry. Da hab ich mich vermutlich falsch ausgedrückt. Wäre von meiner Seite her schon wünschenswert wenn das in einem Adapter zusammengefasst wird. Mein Einwurf war halt darauf gemünzt, dass auch zusätzliche Anwendungsmöglichkeiten da wären die da mit aufgenommen werden könnten.
Selbstredend hätte ich lieber einen Adapter der das für alle Gewerke abbilden kann als >10 verschiedene Scripts die einzeln zu pflegen sind. -
@wolfi913 OK.
Könntest Du vielleicht nochmal "genauer" beschreiben, was Du machst?
Sorry, aber aus deinem ersten Post verstehe ich nur Bahnhof
-
@ben1983
Ist vielleicht mit Screenshots einfacher zu erklären:
Ich bau aus den Funktionen automatisch für die jeweiligen Gewerke (hier z.B. Fenster) einen Objektbaum auf, in dem die Geräte (gesamt, aktiv, inaktiv und optional (für Batterien macht das ja bspw. keinen Sinn) nach Räumen aktiv, inaktiv) sowie optional für jeden Raum noch ein Datenpunkt ob dort das jeweilige Gewerk aktiv oder inaktiv ist. Zusätzlich wird noch für jeden Raum für max. 4 Gewerke ein zusätzlicher Datenpunkt (wie oben beschrieben) erstellt mit einem Wert von 0 bis 15.
Mit diesen Datenpunkten hab ich dann die entsprechenden Informationen für die Visualisierung und kann dort die Anzeige der Räume "einfärben"
(hier z.B. oben in gelb "Licht", rechts in schwarz "Rollo", links in rot "Fenster")
und auch eine Gesamtübersicht der aktiven Geräte ausgeben
und weil's gerade passiert ist Info's zu bspw. Firmwareupdates anzeigen
-
@wolfi913 ok.
Vielleicht erkenne ich es nicht… Aber ich sehe irgendwie keinen Mehrwert zu dem Vergleich die ursprünglichen States zu Nutzen. Nur zum darstellen in der Visu kannst Du Dich auch die nehmen.
Sonst ist es doch nur eine verschachtelte Darstellung der Enums. Oder? -
@ben1983
Zumindest für das was ich vorhatte brauchte ich je ohnehin je einen DP für jeden Raum. Möchte ja anzeigen, dass Fenster offen sind oder Licht brennt (und da hab ich ja immer mehr als eins). Und das lässt sich in der Visualisierung mit einem zusammengefassten fixen DP je Raum auf den ich zurückgreifen kann am (für mich) einfachsten zu realisieren. Hatte die Vermutung, dass Du in diese Richtung was machen möchtest. Scheint aber, dass es nicht der Ansatz ist den Du verfolgst. -
@wolfi913 nein alles gut, aber erkenne noch nicht den Sinn… Ich kann doch in der Visu für das Fenster (oder die Fenster) auch den originalen SAP nutzen, oder meinst Du die Anzahl?
-
@ben1983
Ein Anwendungsfall ist z.B. wenn ein neues Licht in einem Raum hinzukommt. Dann muss ich nur noch die Funktion und den Raum angeben und läuft ab sofort automatisch in die Datenpunkte (Raum je Gewerk, Bitmaske je Raum, Stockwerk). Die Visualisierung brauch ich zu diesem Zweck dann gar nicht mehr anrühren. Ansonsten müsste ich ja zuerst überall nachschauen, wo ich den neuen DP überall in der Visualisierung hinterlegen müsste. Und bei 5 oder mehr Leuchten in einem Raum wird's irgendwann mit Oder-Verknüpfungen so unübersichtlich das der Überblick komplett verloren geht. Außerdem hätten ein neuer DP bei mir immer auf 4 Bereiche eine Auswirkung (Raum, Geräteübersicht, Stockwerke und Kurzübersicht auf der Startseite).
Die Tabs in meiner Visualisierung (ich nutze jarvis) reagieren jetzt sofort auf diese neue Leuchte.
Mitgezählt wird natürlich auch, aber das könnte über ein json-Array auch gelöst werden.
Funktioniert auch mit anderen Gewerken, aber bei den Fenster-Sensoren oder Rollläden kommt ja selten was dazu oder weg. Da wäre es wenig bis kein zusätzlicher Aufwand.
-
@wolfi913 also dir geht es hauptsächlich darum, dass man Enums definieren kann und die Kombination dieser dann angibt, wieviele welchen Zustand haben? Richtig?
Die dps an sich benötigst Du doch eigentlich nicht, oder? -
@ben1983 sagte in Auflistung von Zuständen einer bestimmten Funktion:
@wolfi913
Die dps an sich benötigst Du doch eigentlich nicht, oder?Korrekt, die sind prinzipiell nur ein Abfallprodukt
Könnte ich theoretisch genausogut abschalten. Laufen aber noch aus einem Zwischenschritt in der Entwicklung des Blockly's mit.PS: Nur bei den Stockwerken (miss-)brauche ich die Raumliste die nur true/false liefert.
-
@wolfi913 also die Hauptfrage ist, ob für User ein Adapter da sinnvoll ist, oder man da lieber ein Skript nutzt, was man für sich anpassen kann.
-
@ben1983 Ich habe auch das Gefühl, dass die Konfiguration des Adapters ähnlich komplex wird, wie das herunterschreiben eines Skriptes für den Zweck...
Da ist das vermehrte Schreiben von Skripten vielleicht ein "universelleres" Wissen, was man sich aneignet.
Aber das ist wahrscheinlich eine Mentalitätssache...
Ich halte meinen Werkzeugkasten lieber klein, kenne mich aber dafür mit den Werkzeugen darin gut aus ...
Wie man Werkzeuge bedient, die man selten benutzt, hab man vielleicht wieder vergessen, wenn man sie dann wieder braucht ... -
@martinp ok.
Kann ich verstehen… wobei ich nur an 1-2 dropdowns gedacht hätte… aber ok.
