[callidomus] Zustandsautomaten

[callidomus]

Hallo,

ich habe gerade die Zustandsautomaten im testing-Branch zugänglich gemacht.

callidomus.core update
callidomus.core restart
callidomus.gui build

Die Online-Hilfe ist fertig. Was fehlt ist noch eine allgemeine Dokumentation mit Beispielen und ein Zustandswidget. Das sollte die Woche noch fertig werden.

Bis bald

Marcus

[trollvottel]

Wie geil, das ging nun ja dann doch schneller als erwartet. Werde ich gleich heute abend ausprobieren!

callidomus Was meinst Du denn mit "Zustandswidget"?

[heckmannju]

Ich bin für ein Video! Hatten wir schon lange keines mehr.
VG
Jürgen

[trollvottel]

Das stimmt. Bei der Komplexität wäre ein Video vermutlich echt am geschicktesten.

[heckmannju]

Hi Marcus,

im Wunschthread steht ja folgendes


Grafischer Logikeditor / Zustandsautomat

• Beschattungssteuerung
• Alarmanlage

Wird es das beides als vorgefertigte Bausteine geben?

VG
Jürgen

[callidomus]

Hallo Jürgen,

die Beschattungssteuerung nicht sofort. Bei der Alarmanlage bin ich mir nicht sicher, ich denke das ist zu individuell.

Bis bald

Marcus

[heckmannju]

Hi,
ich hätte jetzt gedacht das eine Alarmanlage simpler ist als eine Beschattungsteurng ist. Ich habe da allerdings Waldemars Beschattungssterungsimplementierung im Kopf rumschwirren....
VG
Jürgen

[trollvottel]

Naja was heißt schon 'zu individuell'. Es gibt doch bei anderen System auch generische Alarmanlagen-Bausteine (Edomi, HS-Plugin, Loxone, ...).

[heckmannju]

Hi,

ich habe schon meinen ersten Zustandsautomaten am Laufen (mit Waldemars hilfe). Der erste eindruck ist schon mal sehr gut ich denke das ich mit ein paar kleinern UI Verbesserungen und mehr Doku gut damit arbeiten kann.

Was mir auffält ist das man schwierig so eine art Baustein machen kann. Was ich vermisste sind klare input und output parameter damit man eine einmal gemachte Zustandslogick einem anderen weiterzugeben.

Planst du da noch was in der Richtung zu machen?

Viele Grüsse
Jürgen

[callidomus]

Es gibt doch bei anderen System auch generische Alarmanlagen-Bausteine (Edomi, HS-Plugin, Loxone, ...).

Und wer hat die erstellt? Abgesehen von Loxone, habe die Benutzer die erstellt. Ich kann natürlich den und noch viele andere Automaten sofort erstellen, aber dafür andere Features nach hinten schieben.

[callidomus]

Hallo Jürgen,

Was mir auffält ist das man schwierig so eine art Baustein machen kann. Was ich vermisste sind klare input und output parameter damit man eine einmal gemachte Zustandslogick einem anderen weiterzugeben.

Planst du da noch was in der Richtung zu machen?

Die Zustandsautomaten sind Bausteine, der jedoch wesentlich flexibler als die Logikbausteine.
Ich stelle es mir schwierig vor, für den Ersteller und Nutzer, eine lange Liste von Variablen zu pflegen die an anderer Stelle verwendet werden. Oder wie stellst Du Dir das vor?

Ich halte es für sinnvoller der Nutzer passt die Automaten über die GUI an. Alternativ kann man auch relative einfach search & replace im csv machen.

Bis bald

Marcus

[trollvottel]

Und wer hat die erstellt? Abgesehen von Loxone, habe die Benutzer die erstellt. Ich kann natürlich den und noch viele andere Automaten sofort erstellen, aber dafür andere Features nach hinten schieben.

War nicht böse gemeint. Für mich klang "zu individuell" nach "nicht generisch lösbar". Deshalb widersprach ich.

Ich bin überzeugt, der Wunsch nach einem Baustein für eine Alarmanlage wird sicherlich irgendwann kommen. Nachdem andere, wichtigere Dinge bereits implementiert wurden.

[heckmannju]

Search und Replace ist schon mal das was ich überhaupt nicht will. Und ich will auch nicht alle Zustände des Zustandautomaten durch Klicken um da die Items anzupassen. Ich will das an einer definierten Stelle machen wo ich nur noch die Input Parameter mitteilen und die Output Parameter. So das es mir als Benutzer erst mal wie eine Blackbox vorkommt.

Das gleiche würde ich mir auch für logicken wünschen.

Hier noch ein graphisches Beispiel im Header würde ich die Variablen die In der Zustandsengine benutzt werden mit Platzhalternamen versehen in diesem Beispiel IN und OUT
Zustand1.png
Und diese dann im Zustandautomt konsequent benutzen hier im bild die Zustände 3 und 4 Welche Lüfterstufen repäsentieren.

Zustand4.png

Zustand3.png
die Zustände 1 und 2 sind gleichartig wie 3.

Wenn ich jetzt meinen Zustandsauotmat jemanden gebe muss der jetzt jeden Zustand durchklicken und die Items Item für Item abändern.

Ich hoffe das mit den Bildern klare wird wie ich mir das vorstelle.

VG
Jürgen

[mumpf]

Hi Marcus,

ich hatte Dir mal während des Testens einen Vorschlag zu Kapselung gemacht, der war ziemlich ähnlich zu Jürgens Vorschlag hier - ich hatte ihn damals nur auf Basis des CSV ausgedrückt.

Eigentlich braucht man nur eine Mapping-Liste zwischen internen Parametern und Items (auch relative Items). Beim instanzieren der SM könntest Du die internen Parameter alle durch die Items ersetzen. Danach könntest Du normal weiter prozessieren. Falls ein interner Parameter nicht auf ein Item gemapped werden kann, würde die selbe Logik greifen wie bei einem nicht vorhandenen Item (deaktivierung der condition und in Abhängigkeit davon Deaktivierung von Gruppen).

Ob man den Parametern noch mehr Semantik geben will (wie input/output/inout oder necessary/optional), kann man sich überlegen, macht aber das Mapping aufwändiger.

Ich würde Parameter nicht erzwingen. Wenn einer ein Item in die Machine direkt schreibt, ist das auch ok, dann wird eben nichts ersetzt.

Für eine Weitergabe von Zustandsmaschinen wäre das schon schön...

Gruß, Waldemar

[heckmannju]

Hi,
bei den Plugins hast du das eigentlich recht schön gelöst die kann man auch mehrmals reinziehen und paramterisieren. Die Beschreibung hinter den Parametern ist da auch sehr Hilfreich.
VG
Jürgen