[NEUHEIT] Modul "Zustandsautomat"

[supernode]

Vielen Dank für die Bearbeitungs des FR. Schön dass das Ganze nicht untergegangen ist.
Ich denke dass dieser Baustein einer der Wichtigsten werden wird wenn es darum geht Abläufe zu definieren.

Eine Frage hätte ich noch: Wäre es möglich dass die States in Strings angegeben werden oder man Enums o.ä. definiert und nutzt? Man sieht ja schon im Beispiel dass neben der Integer-Nummer eine Bezeichnung AUS, AN, DUNKEL und RESTLAUFZ das ganze deutlich besser beschreiben. Bei vier States mag das noch in Ordnung sein - werden es mal 10 oder mehr dann wirds etwas unübersichtlich.

Gerne können auch die übrigen Nutzer sagen wie sie das sehen und lösen.

[S. Kolbinger]

Hi Martin,

Eine Frage hätte ich noch: Wäre es möglich dass die States in Strings angegeben werden oder man Enums o.ä. definiert und nutzt? Man sieht ja schon im Beispiel dass neben der Integer-Nummer eine Bezeichnung AUS, AN, DUNKEL und RESTLAUFZ das ganze deutlich besser beschreiben. Bei vier States mag das noch in Ordnung sein - werden es mal 10 oder mehr dann wirds etwas unübersichtlich.

Da bin ich ja erleichtert, dass du nur noch eine Frage hast
Aber Spaß beiseite, der Vorschlag ist gut, aber leider in der aktuellen Version nicht so einfach umsetzbar.

Bis wir hier eine bessere Lösung gefunden haben, würde ich vorschlagen, die Wartbarkeit der Tabelle mittels Kommentaren zu verbesseren.
Z.B:

Code: Alles auswählen

...
["$In" , 0 /* AUS */, 1 /* AN */, "$Time"],
...

Ich weiß, es ist nicht optimal und man muss genau aufpassen, dass die Kommentare auch wirklich zu den Werten passen.
Aber es hilft sicherlich, wenn man nach ein paar Monaten die Logik überarbeiten möchte.

[supernode]

Danke Stefan für die Comment-Hinweise. Fürs erste kann man sicher damit leben.

Wenn man später mal an eine Beschriftung denkt wäre dann auch eine Alternative für den Multiplexer am Ausgang gefordert.
Da wär dann irgend ne Map / LUT toll um das eindeutiger hinzuschreiben.

Da du ja noch ein paar Fragen willst, hab ich noch was für dich.

Wärs möglich ne Wildcard für den aktuellen Zustand zu nutzen?
Ich stelle mir als Anwendung einen zentralen Reset/Stop Signal vor. Im Beispiel wäre das das Abschalten über den Eingang. Somit könnte mit einer Zeile am Anfang die Zustandsübergangstabelle vereinfacht werden. Aus 10 Zeilen würden so 8.

Code: Alles auswählen

["-$In" , *, 0, 0],     // ausschalten
["$In" , 0, 1, "$Time"],    // einschalten, Timer starten
[  0   , 1, 2, "$Dark"],    // Zeit abgelaufen
["$In" , 1, 1, "$Time"],    // Zeit neu starten
[  0   , 2, 3, "$Warn"],    // Dunkelzeit abgelaufen -> Warnzeit
["$In" , 2, 1, "$Time"],    // Zeit neu starten
[  0   , 3, 0,   0    ],    // Warnzeit abgelaufen
["$In" , 3, 1, "$Time"]     // Zeit neu starten

Für größere FSMs wäre das ein wirklicher Gewinn.

[supernode]

Noch ne Frage: Kann man bei den State-Werten auch Variablen verwenden?

Code: Alles auswählen

["$In" , "$CURRENT", "$NEXT", "$Time"],

[martin]

Hallo zusammen,

bei der Entwicklung eines eigenen Zustandsautomaten beobachte ich bei mir im knx-busmonitor, dass die Ausgangswerte nicht einmal, sondern 4mal auf dem Bus gesendet werden. Um hier Fehler einzugrenzen habe ich das Beispiel Kellerlicht aus diesem Thread kopiert und den Ausgang "Status" mit einem knx-objekt verküpft. Wenn ich nun im Debugmode den Eingang "Input" auf True setze, dann tauchen bei mir die entsprechenden Stati 0, 3, ... jeweils 4mal im knxlog auf.
Hat dieses Verhalten jemand von euch schonmal beobachtet, oder könnte das bitte bei sich mal kurz testen?


Vielen Dank und viele Grüße
Martin

aktuelle Version ist 1.6 RC6

[eib-eg]

Hallo @martin Martin

Im knx wird ein Telegramm maximal 4 mal wiederholt wenn der Empfänger nicht antwortet.

Soll heißen :
1. Der TW sendet ein Telegramm und hat im Gegenzug kein Empfänger, ergo wird das Telegramm wiederholt.
2. ein Busteilnehmer Sendet ein Telegramm zum TW ( der nicht über die ets programmiert wurde) Somit wird das Telegramm wiederholt. Wird aber jedoch im Busmonitor angezeigt.
3. der TW sendet ein Telegramm an sich selbst, Hierfür muss er erst über die ets programmiert werden.

Aber ich glaube das Stefan Werner darüber genauere Auskunft geben kann.

Ich hoffe das ich ein klein wenig dazu beitragen konnte.

[gbglace]

Ja erste Frage wo geht das Telegramm hin, gibt es ein Empfänger KO dafür im Bus? Wenn es nur ein TWS-KO ist, warum dann überhaupt auf den Bus senden?

[martin]

Vielen Dank für eure Hinweise zur fehlenden Senke.
Mit einem empfangenden Busteilnehmer bekomme ich das Telegramm nur noch einmal im Busmonitor angezeigt.
Der Ausgang aus der Custom-Logik mit Statemachine soll natürlich auch von anderen Busteilnehmern verarbeitet werden. Das von mir geschilderte Verhalten hat demnach nichts mit dem Statemaschine-Block, sondern allgemein mit der Realisierung des knx-stacks im Timberwolf zu tun.

[Piranha]

Hallo Zusammen,

ich habe gerade folgendes Szenario:

Eine Treppe an der jeweils oben und unten ein Bewegungsmelder angebracht ist. Nun soll das Treppenlicht (für 15 Sek) auch jeweils von oben nach unten oder von unten nach oben ausgelöst werden. Allerdings der Timer nicht neu gesetzt werden (Licht weitere 15 Sek. an), wenn am Treppenausgang der jeweils andere Bewegungsmelder ausgelöst wird.

Ich habe das soweit mit der Statemachine umgesetzt, allerdings wird diese ja neu gestartet sobald der andere Bewegungsmelder am Treppenausgang erreicht wird.

Könnt ihr mir da weiterhelfen? Ein Break würde ja vermutlich auch den Timer anhalten.

LG

Alex

[Piranha]

Oder anders gefragt, kann ein bestehender und laufender Timer irgendwie beibehalten werden ohne von einer anderen Aktion überschrieben zu werden? Oder benötige ich da zwei unabhängige Statemachines?

Siehe Zeile 2?

Code: Alles auswählen

    
    ["Statemachine",
      [
        ["$EG_ON" , 0, 1,"$Time" ],
        ["$UG_ON" , 1, 1,   0    ],        
        [   0     , 1, 0,   0    ],     
        ["$EG_ON" , 1, 1,"$Time" ],
        ["$UG_ON" , 0, 2,"$Time" ], 
        [   0     , 2, 0,   0    ],
        ["$UG_ON" , 2, 2,"$Time" ]        
      ],
      "$State"