State Machine im Logikeditor

[Zugschlus]

Hallo,

ich habe mir gerade im Büro eine neue Schreibtsichlampe an die Decke geschraubt und habe das Problem, dass ich nicht genug Schalter habe, um die auch vernünftig bedienen zu können. Mache das im Moment über die Comet Visu.

Dabei ist mir die Idee gekommen, dass ich vielleicht mit _demselben_ Schalter durch verschiedene Lichtfunktionen "durchdrücken" kann. Einmal drücken: Nur Deckenlicht. Das nächste Mal drücken: Decke und Schreibtisch. Das nächste Mal drücken: Nur Schreibtisch. Das nächste Mal drücken: Alles aus.

Dabei müsste die Logik mit _einem_ Eingang, der auch nur "Ein"-Telegramme empfängt, intern eine Statevariable pflegen (oder die Statusrückmeldungen der Aktoren auswerten) und auf jedes Ein-Telegramm mit passenden Ein- und Aus-Telegrammen an zwei Ausgängen reagieren.

Wird das im Timberwolf gehen? Wenn ja, dann wie? Hat schon jemand ein Beispiel gebaut?

Grüße
Marc

[Chris M.]

Die CometVisu kann mit einem Toggle ( http://www.cometvisu.org/CometVisu/de/l ... index.html ) durch mehrere Zahlen sich durchiterieren. Fehlt also nur noch die Logik, die zu jeder dieser Zahl einen anderen Zustand zuweist.

Könnte das ein Multiplex machen?
Ansonsten sollte ein klassischer Szenen-Baustein das hinbekommen (der Toggle würde dann durch die Szenen-Nummern durch toggeln)

[gurumeditation]

Wenn ich das richtig verstanden habe, geht es ja um die Umsetzung OHNE CometVisu auf einem klassischen Taster.

Kommt auf die Applikation deines Tasters an: eine einfache Toggle Funktion wie von Chris beschrieben sollte dort enthalten sein, dann kannst du das exakt so abbilden.

[Zugschlus]

Kommt auf die Applikation deines Tasters an: eine einfache Toggle Funktion wie von Chris beschrieben sollte dort enthalten sein, dann kannst du das exakt so abbilden.

Der Taster kann entweder immer "ein", immer "aus" oder abwechselnd "ein" und "aus" senden. Die CometVisu müsste also auf KNX-Telegramme reagiert. Irgendwie gehört das gefühlt eher in eine Logik, nicht in die Visu.

Grüße
Marc

[gurumeditation]

Vielleicht hat er deshalb auch nach dem Zustandsautomaten der Logikmaschine gefragt?

[Chris M.]

Der Taster kann entweder immer "ein", immer "aus" oder abwechselnd "ein" und "aus" senden. Die CometVisu müsste also auf KNX-Telegramme reagiert. Irgendwie gehört das gefühlt eher in eine Logik, nicht in die Visu.

Ich hatte überlesen, dass es um einen normalen Taster geht.

Dann ist das klar eine Aufgabe für die Logik und nicht für die CometVisu.

[Zugschlus]

Vielleicht hat er deshalb auch nach dem Zustandsautomaten der Logikmaschine gefragt?

Genau.

Allerdings bin ich in der gesamten Thematik noch eher neu, bin "nur" Informatiker und deswegen vorbelastet. Das bedeutet nicht, dass meine ersten Ideen nicht doch das falsche Werkzeug berücksichtigen.

Aber nachdem wir uns hier jetzt ja einig sind, dass die Logikmaschine das richtige Werkzeug ist, könnten wir ja mal mit der eigentlichen Problemlösung anfangen ehe ich mich an meine Grundausbildung zurückbesinne und einen zwei-Bit-Binärzähler aus NAND-Bausteinen zusammenklöpple...

Grüße
Marc

[S. Kolbinger]

Hallo Marc,

Dabei ist mir die Idee gekommen, dass ich vielleicht mit _demselben_ Schalter durch verschiedene Lichtfunktionen "durchdrücken" kann. Einmal drücken: Nur Deckenlicht. Das nächste Mal drücken: Decke und Schreibtisch. Das nächste Mal drücken: Nur Schreibtisch. Das nächste Mal drücken: Alles aus.

Dabei müsste die Logik mit _einem_ Eingang, der auch nur "Ein"-Telegramme empfängt, intern eine Statevariable pflegen (oder die Statusrückmeldungen der Aktoren auswerten) und auf jedes Ein-Telegramm mit passenden Ein- und Aus-Telegrammen an zwei Ausgängen reagieren.

Versuch es bitte mal mit dieser Benutzerdefinierten Logik:

Code: Alles auswählen

{
      "Level": [
        ["$Weiter","bool",false],
        ["$Null","integer",0],
        ["$Eins","integer",1],
        ["$Status","integer",0],
        ["$MaxStatus","integer",3],
        ["$ResetStatus","bool",false],
        ["$DeckenLicht","bool",false],
        ["$DeckenLicht_S0","bool",false],
        ["$DeckenLicht_S1","bool",true],
        ["$DeckenLicht_S2","bool",true],
        ["$DeckenLicht_S3","bool",false],
        ["$SchreibtischLicht","bool",false],
        ["$SchreibtischLicht_S0","bool",false],
        ["$SchreibtischLicht_S1","bool",false],
        ["$SchreibtischLicht_S2","bool",true],
        ["$SchreibtischLicht_S3","bool",true]
      ],
      "Module": [
        ["Polynomial","$Status","$Status",["$Eins","$Eins"]],
        ["Comparator","$Status","$ResetStatus","$MaxStatus"],
        ["Multiplexer",["$Status","$Null"],"$Status","$ResetStatus"],
        ["Multiplexer",["$DeckenLicht_S0","$DeckenLicht_S1","$DeckenLicht_S2","$DeckenLicht_S3"],"$DeckenLicht","$Status"],
        ["Multiplexer",["$SchreibtischLicht_S0","$SchreibtischLicht_S1","$SchreibtischLicht_S2","$SchreibtischLicht_S3"],"$SchreibtischLicht","$Status"]
      ],
      "Input": [
        ["Taster","Jeder Wert schaltet eins weiter","$Weiter","a"]
      ],
      "Output": [
        ["Decke","Schaltzustand für das Deckenlicht","$DeckenLicht","c"],
        ["Tisch","Schaltzustand für das Schreibtischlicht","$SchreibtischLicht","c"]
      ]
}

Gruß,
Stefan K.

[Eraser]

ehe ich mich an meine Grundausbildung zurückbesinne und einen zwei-Bit-Binärzähler aus NAND-Bausteinen zusammenklöpple...

7400 lässt grüßen...

[Zugschlus]

Versuch es bitte mal mit dieser Benutzerdefinierten Logik:

Tut, danke. Aber nachdem ich jetzt ein wenig darauf rumgeklickt habe komme ich zu dem Schluß, dass es wohl keine so schlaue Idee ist, den State innerhlab der Logik zu speichern: Das führt nämlich zu interessanten Ergebnissen, wenn man das Licht über explizite Schalter und Knöpfe in der Visu geschaltet hat. Die Logik weiß davon natürlich nichts und macht stumpf dort weiter, wo ihr interner State steht.

Vielleicht wäre es doch eine ganz gute Idee, die Statusrückmeldungen der Aktoren zu verwenden, damit die Logik immer weiß, in welchem Zustand die Leuchten wirklich sind.

Grüße
Marc