UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[NEUHEIT] Modul "Zustandsautomat"

Hier stellen Foristen und Kunden Ihre EIGENEN Logikbausteine vor. Diese Logikbausteine stehen jedem im Rahmen der vom Autor eingeräumten / genannten Lizenz zur Verfügung.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln

supernode
Reactions:
Beiträge: 64
Registriert: So Aug 12, 2018 7:39 am
Hat sich bedankt: 10 Mal
Danksagung erhalten: 29 Mal

#11

Beitrag von 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.
TWS 2600 ID:172, VPN offen, Reboot erlaubt

Ersteller
S. Kolbinger
Elaborated Networks
Reactions:
Beiträge: 588
Registriert: Mi Aug 15, 2018 11:34 am
Hat sich bedankt: 82 Mal
Danksagung erhalten: 558 Mal

#12

Beitrag von S. Kolbinger »

Hi Martin,
supernode hat geschrieben: Fr Feb 28, 2020 9:32 am 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 :lol:
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.
Gruß,
Stefan K.

supernode
Reactions:
Beiträge: 64
Registriert: So Aug 12, 2018 7:39 am
Hat sich bedankt: 10 Mal
Danksagung erhalten: 29 Mal

#13

Beitrag von supernode »

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

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.
TWS 2600 ID:172, VPN offen, Reboot erlaubt

supernode
Reactions:
Beiträge: 64
Registriert: So Aug 12, 2018 7:39 am
Hat sich bedankt: 10 Mal
Danksagung erhalten: 29 Mal

#14

Beitrag von supernode »

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

Code: Alles auswählen

["$In" , "$CURRENT", "$NEXT", "$Time"],
TWS 2600 ID:172, VPN offen, Reboot erlaubt

martin
Reactions:
Beiträge: 138
Registriert: Mo Okt 15, 2018 10:07 pm
Wohnort: bei Stuttgart
Hat sich bedankt: 76 Mal
Danksagung erhalten: 69 Mal

#15

Beitrag von 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
VG Martin
TWS 2500 ID:152 + PBM ID:819 + PBM ID:1079, VPN aktiv, Reboot erlaubt"

eib-eg
Reactions:
Beiträge: 442
Registriert: Fr Sep 14, 2018 5:03 pm
Hat sich bedankt: 1457 Mal
Danksagung erhalten: 235 Mal

#16

Beitrag von 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.
TW 2600_99 seit 1.1.2018 / VPN zu

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#17

Beitrag von 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?
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

martin
Reactions:
Beiträge: 138
Registriert: Mo Okt 15, 2018 10:07 pm
Wohnort: bei Stuttgart
Hat sich bedankt: 76 Mal
Danksagung erhalten: 69 Mal

#18

Beitrag von 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.
VG Martin
TWS 2500 ID:152 + PBM ID:819 + PBM ID:1079, VPN aktiv, Reboot erlaubt"

Piranha
Reactions:
Beiträge: 47
Registriert: Sa Jan 04, 2020 10:23 pm
Danksagung erhalten: 5 Mal

#19

Beitrag von 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
TWS 975 ID:433, VPN offen, Reboot auf nachfrage

Piranha
Reactions:
Beiträge: 47
Registriert: Sa Jan 04, 2020 10:23 pm
Danksagung erhalten: 5 Mal

#20

Beitrag von 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"
TWS 975 ID:433, VPN offen, Reboot auf nachfrage
Antworten

Zurück zu „Zusätzliche Logikbausteine“