Zustandsautomaten

[heckmannju]

Hi Marcus,
warum gibt es eigentlich nicht einfach ein True in der Liste? Mumpf macht an der stelle immer Jahr > 0 True == True wäre doch das selbe.
Vg
Jürgen

[gaert]

So ist es - EDOMI nutzt keinerlei(!) fremden Code (alles hausgemacht).

Sorry for being off topic Ich wollte hier keine Diskussion lostreten...

[trollvottel]

1. Der Sourcecode der Logikbausteine ist frei verfügbar

EDOMI ist in PHP und hier liegt offensichtlich callidomus sein Problem

2. Wer sagt denn, dass GPL = öffentlicher Sourcecode bedeutet?

Das besagt die GPL. Allerdings reicht es, den Sourcecode auf Anfrage zur Verfügung zu stellen. Steht denn EDOMI überhaupt unter der GPL oder nur die Komponenten, die es nutzt? Denn im letzteren Fall muss nur deren Sourcecode zur Verfügung stehen - Nicht EDOMI selbst.

Ist aber völlig egal, denn um EDOMI geht's hier eigentlich garnicht.

[gaert]

1. Der Sourcecode der Logikbausteine ist frei verfügbar
2. Wer sagt denn, dass GPL = öffentlicher Sourcecode bedeutet?

[BadSmiley]

@gaert: Ok, ich konnte das nicht im Source-Code deiner GPL Anwendung verifizieren. Mea Culpa

haha, der war klasse, den hab sogar ich kapiert!

[callidomus]

@gaert: Ok, ich konnte das nicht im Source-Code deiner GPL Anwendung verifizieren. Mea Culpa

[gaert]

Und wer hat die erstellt? Abgesehen von Loxone, habe die Benutzer die erstellt.

Einspruch Die EDOMI-Bausteine sind grundsätzlich von mir erstellt worden, allerdings gibt es inzwischen zusätzlich so um die 200 "Community-Bausteine".

[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

[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]

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

[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.

[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

[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.

[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

[trollvottel]

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