Ereignisse vs Pulse in Loxone

[Gast]

Hallo zusammen,

bevor ich ein Ticket eröffne, möchte ich meine Gedanken hier einbringen. Vielleicht gibt es ja schon eine Lösung für mein konkretes Problem.

Dieses ist wie folgt: Ich habe einen Dimmer. Nun möchte ich bei einem Ereignis, nämlich einem Doppelklick des + oder - Tasters, den Dimmer auf einen bestimmten Wert setzten. Der Dimmer hat ja tatsächlich einen P-Eingang, der im Prinzip genau das macht. Also habe ich einen Mehrfachklick-Baustein an die beiden Tasten gähengt, und dessen Ausgang mit dem Zielwert skaliert auf den P-Eingang geleitet. Das funktioniert so aber nicht. Denn der Mehrfachklich-Baustein erzeugt einen Puls. Das Ergebnis ist, dass der gewünschte Effekt erst eintritt, unmittelbar darauf aber der Dimmer dunkel schaltet.

Das brachte mich etwas ins Grübeln. Die Loxone ist irgendwie zustandsgesteuert, aber irgendwie eben doch auch ereignisgesteuert. Nehmen wir den Dimmer. Wäre die Steuerung rein zustandsbasiert, würde er so funtionieren:
P-Eingang offen: Dimmer wie gewohnt.
P-Eingang bedient: NUR noch dieser Wert darf genommen werden. Die Taster dürfen dann keine Funktion mehr haben. Wenn der Wert am P-Eingang 34% ist, ist er 34%. Und wenn der Dimmer auf 43% heller schaltet, ignoriert er den ZUSTAND am P-Eingang. Das heisst, eigentlich ist die Loxone ereignisgesteuert. Eine ZustandsÄNDERUNG (resp. WertÄNDERUNG) bewirkt etwas. Ein gleichbleibender Zustand oder Wert ist "unsichtbar".

Nun gäbe es einen Baustein, der in der strikten Logik der Zustandssteuerung unsinnig ist, jedoch im Hinblick auf die (faktisch realisierte) Ereignissteuerung durchaus Sinn machen kann: Ein Baustein, der bei einer 0->1 Flanke einen Puls erzeugt, der a) infinitesimal kurz ist und b) eine steigende, aber keine fallende Flanke hat. Der Ausgang wechselt also einfach auf 1. Und bei einer erneuten Flanke wechselt er wieder auf 1. Er geht aber nie auf 0 zurück. Er wechselt seinen Ausgang quasi von 1 auf 1. Ich hoffe, es ist klar, was ich meine. Er muss ein Ereignis werfen: "Hey, Eingang, mach was, ich habe einen neuen Wert für Dich! Nämlich 1." Und der nachgeschaltete Eingan muss dann tun, was immer zu tun ist, wenn eine Wertänderung anliegt.

Wie gesagt, es IST ja eigentlich schon so, dass die Loxone nicht in jedem Loop jeden Eingang neu evaluiert. Sondern eben nur immer bei einer Änderung. Deswegen kann ich den Dimmer auf 45% schalten, obwohl am P-Eingang immernoch 23% anliegt. Diese werden ignoriert, bis sie sich verändern. Der Mehrfachklick-Baustein wirft einfach zwei Ereignisse: "Hey, Eingang, neuer Wert für Dich! 1!" und dann "Hey, Eingang, neuer Wert für Dich! 0!" Und ich möchte einen Baustein, der nur noch ruft: "Hey, Eingang, neuer Wert für Dich! 1!"

Oder gibt es sowas vielleicht sogar, und ich habe es übersehen?

Gruäss
Simon

[svethi]

Nö, also wirklich verstanden was Du willst, habe ich nicht. Der MiniServer arbeitet quasi eventbasiert daher auch Deine Beschreibung. Es tritt das Event ChangeValue an P ein und Dein Wert wird gesetzt. Da wechselt Dein Doppelklick den Wert wieder zu 0 und es tritt das Ereignis ChangeValue ein und es wir wie abgeschalten. Es gibt Bausteine, die reagieren auf steigende Flanken, welche auf Analogwertänderung, welche auf fallende Flanken und welche die reagieren auf Beides. Musst halt dementsprechend die Bausteine wählen, die das machen, was Du erreichen möchtest.
Ein Dimmerbaustein arbeitet normalerweise so: kurzer Klick -> Baustein stellt die Helligkeit wie bei letztem Ausschalten ein. Langer Klick -> Baustein dimmt auf oder ab. -> Doppelklick startet volle Helligkeit

Gruß Sven

[Gast]

Hallo Sven,

vielen Dank für Deine Antwort! Das mit dem Doppelclick für volle Helligkeit habe ich erst jetzt gesehen. Insofern ist das Beispiel wohl nicht so gut. Aber das grundsätzliche Problem bleibt bestehen. Wie Du geschrieben hast: Es gibt Bausteine, resp. Eingänge von Beusteinen, die auf steigende, fallende oder beliebige Flanken reagieren. Aber genau da liegt das Problem. Was ist, wenn ich einen Eingang für einen analogen Wert habe? Loxone unterscheidet "digitale" und "analoge" Eingänge ja nicht grundsätzlich. Eine "Flanke" ist einfach ein Wechsel zwischen 0 und irgendwas anderem. Der "Event-Dispatcher" wird, wie Du beschrieben hast, bei Werteänderungen aktiv. Und ein Baustein evaluiert dann, ob und was er tun muss, abhängig von Wert zuvor und zum Wert aktuell. "Analogeingang": Jede Änderung bewirkt etwas, "steigende Flanke": Vorher 0, nun etwas anderes, etc.

Aber ich habe keine Möglichkeit gesehen, den Dimmer über ein Ereignis (vergessen wir mal den Doppelklick und denken uns irgendein anderes Ereignis, Tastendruck auf einen weiteren Taster zum Beispiel) auf einen bestimmten Wert zu setzen. Denn das ist ein "Analogeingang". JEDE Wertänderung SOFORT übernommen. Solange keine Werändrung vorliegt, kann man mit den Tastern den Dimmwert intern verändern. Ich setze den Eingang also auf 50%. Der Dimmer geht auf 50%. Nun verändere ich ihn intern auf 60%. Nun drücke ich die diese Taste wieder, die ihn auf 50% nehmen soll. Wie mache ich das? Das Problem scheint trivial, ist aber extrem mühsam.

Ansatz 1: Taster multiplizieren mit 50. Ich drücke, er geht auf 50%, ich lasse los, er geht auf 0.
Ansatz 2: Taster an einen Impulsgeber setzen, dann mit 50 multiplizieren. Ich drücke, er geht kurz auf 50% und sofort wieder auf 0.
Ansatz 3: Taster an Flipflop, S Eingang setzen, dann mit 50 multiplizieren. Ich drücke, er geht auf 50% und bleibt da. Den Taster kann ich jetzt aber wegschmeissen (oder den MS rebooten).
Ansatz 4: Taster a einen Sample and Hold Baustein hängen (Analogwertspeicherung). Mit 50 konstant am Eingang. Ich drücke, der Dimmer geht auf 50%, lässt sich verändern, aber erneutes Drücken der Taste bleibt wirkungslos. Wie oben.

Und jetzt gerade habe ich die Lösung gefunden! Und sie sieht eigentlich sehr hässlich aus, ist wohl auch nicht sehr elegant, aber die logische Konsequenz dessen, was Du ja bestätigt hast, dass Ändrungen, und NUR Änderungen etwas bewirken.

Also:
Dimmer so anschliessen: + und - an Taster, wie gewohnt.
Analog Ausgang an Analog Eingang. Schon hier könnten sich einem die Nackenhaare sträuben von wegen Race-Condition etc. Ist aber problemlos. Der Ausgang ändert sich auf einen Wert, der so nochmals übernommen wird, was den Ausgang nicht ändert sondern bloss bestätigt, und auf eine Bestätigung reagiert er nicht mehr. Stabil.
Und jetzt wird's noch hässlicher: Den Analogeingang zusätzlich an einen Sample-and-Hold Baustein mit Eingang 50 setzen, welcher vom Ereignis (Tastendruck, resp. Tasteneingang steigende Flanke) getriggert wird. Es hängen also zwei Ausgänge am selben Eingang. So funktioniert es perfekt.


Was passiert? Nach reboot ist der Analogeingang des Triggers auf 0. Ich drücke die Taste, er geht auf 50, der Dimmerausgang auch. Ich drücke nochmals, nichts passiert. Klar. Jetzt verändere ich den Dimmer durch Drücken der + Taste. Der Dimmwert geht rauf auf, sagen wir mal, 60. Der Analogeingang sieht jetzt ebenfalls diese 60. Der Ausgang des Sample-and Holds aber nach wie vor 50 (Simulation bestätigt das, und es ist auch logisch, wenn man den Mechano der Loxone versteht).
Nun drücke ich den Trigger erneut. Der Analogausgang des Sample-and Holds ändert sich nicht, der bleibt auf 50. Aber der Eingang des Dimmers, an dem just dieser Ausgang hängt, ändert sich wohl! Der geht zurück auf die 50, die vom Sample and hold gefordert werden.

Es macht also einen sehr grossen Unterschied, WO das Betriebssystem, resp. der Event-Dispatcher angestossen wird. Wenn es auf Änderungen an Ausgängen reagieren würde, würde diese Lösung nicht funktionieren. Denn dann würde das System sehen, dass sich der Ausgang des S&H Baustein ja nicht geändert hat und somit keine Rekalkulation nötig ist. Das Betriebssystem funktioniert aber wohl anders: Bei mehreren Ausgängen an einem Eingang wird IMMER der zuletzt veränderte ODER BESTÄTIGTE(!!!) Wert vom Eingang übernommen. Und dann wird, wenn sich dieser verändert hat, der Baustein aufgefordert, diesen neu zu evaluieren.

Ich weiss, dies ist sehr subtil, und man muss schon recht stark überlegen um zu verstehen, warum das einen Unterschied macht. Aber ganz zufällig und aus Versehen wird Loxone das nicht so gemacht haben, denn sonst hätte sie mehrere Ausgänge an einem Eingang verboten. Vielleicht sollte Loxone das irgendwo dokumentieren (in einer Beschreibung, die klar als "advanced" gekennzeichnet ist). Ich werde hier mal ein Ticket eröffnen.

Und ich überlege mir mal, wie ich die Problemstellung so formulieren kann, dass klarer ist, was gemeint ist, und schreibe die Lösung in ins How-To. Denn ich bin schon einige Male auf just dieses Problem gestossen, dass ich "Analogwerte" durch Ereignisse BESTÄTIGT haben wollte, ohne sie zu verändern. Im Sinne von: Jetzt musst Du MEINEN Wert wieder nehmen! Diese Kombination von Sample and hold und Rückkopplung ist wohl eine recht generische Lösung für genau dieses Problem.

Trotzdem bin ich immernoch der Meinung, ein Baustein, dessen Ausgang auch Eingänge triggern kann, wenn sich der Wert nicht verändet (eben, eine BESTÄTIGUNG) eines Werts, obwohl er sich nicht verändet hat, wäre praktisch. Aber ich kann mir vorstellen, dass man hierfür (zu) tief in die Grundmechanos der Software eingreifen müsste. Insofern ist diese obige Möglichkeit schon mal nicht so schlecht.

Gruäss
Simon

[svethi]

Hallo Simon,

Ich ertappe mich schon wieder eine Lanze für Loxone zu brechen. Ich weiß nicht wo Dein Eindruck herkommt, dass da nur selektiv der Eingang getriggert wird. Ich glaube auch nicht, dass Loxone sich da irgend etwas extra gedacht hat. Es war bisher immer so, dass der letzte Wert, der am Eingang ankam Priorität hat. Ich weiß auch ehrlich nicht, wie Du Dir Deinen Wunsch vom 1. Post vorstellst, dass Du einen Wert an den Analogeingang anlegst und dieser dann auf Biegen und Brechen behalten wird. Dann bräuchtest Du keine App-, Web- oder sonstige Steuerung. Aber gut, jeder hat so seine Ideen. Das heißt aber nicht, das Loxone es hier allen rechtmachen kann.
In 99% der Fälle, sage ich jetzt mal, ist der Dimmerbaustein so wie man ihn sich vorstellt. Für mich hört sich Dein Wunsch dann schon eher nach der Lichtsteuerung an. Da könntest Du verschiedene Szenen einrichten und kannst die dann immer wieder abrufen. Wenn Du manuell den Dimmwert änderst, geht der Baustein automatisch auf manuell und somit kannst Du die entsprechende Szene erneut triggern. Dein Wunsch der Verarbeitung geht ja eher in Richtung Messages wie bei KNX z.B. Da sendest Du z.B. den Wert 50 an den Dimmer und danach ist der Inhalt der Nachricht wieder vergessen.
Hier ist es ja aber so, dass Du die Nachricht 50 "schickst" und direkt danach "schickst" Du die Nachricht 0. Würdest Du das im KNX System genauso machen, würde das Selbe dabei rumkommen. Jetzt sagst Du bestimmt, ja, aber bei KNX kann ich den Wert 50 immer und immer wieder senden und das funktioniert. Das ist ja aber nur die halbe Wahrheit. Bei KNX ist nach dem Senden der 50 wieder "Funkstille". Bei einem System wie Loxone ist es ja aber so, dass die Nachricht ununterbrochen "gesendet" wird. Würdest Du bei KNX die Nachricht theoretisch ununterbrochen senden, ich weiß, das geht gar nicht, also ohne Unterbrechung, Absätze oder Sonstiges, dann würde KNX da sicher auch nicht mehr drauf reagieren.
Das sind völlig unterschiedliche System und Du kannst nicht erwarten, dass Du die Funktionalitäten einfach so vermischen kannst. Allerdings, und da kommen wir jetzt zu einem Lösungsansatz für Dich, bietet Loxone auch hierfür Möglichkeiten an. Du musst nur einen Weg benutzen, der ebenso nur eine Nachricht verschickt. Dieser Weg wären die Webservices. Lege Dir einen HTTP-Verbinder mit der IP und Port des MiniServer an (User und Passwort nicht vergessen) und definiere einen Ausgangsbefehl. Dort sagst Du bei Befehl bei Ein /dev/sps/io/NameDesDimmers/50. Du setzt den Haken bei nach dem Senden die Verbindung schließen und hast Deine Message. Mit einem Impuls sendest Du die Nachricht und das kannst Du so oft machen wie Du willst.

Gruß Sven

[Gast]

Hey

Habe nur grob überflogen was du machen willst. So wie ich es verstandenhabe, kannst du aber mit einem Analogspeicher am Ausgang den gewünschten Wert an P vom Dimmer hängen. Damit kannst du auf Tastendruck, Doppelklick was auch immer, einen gewünschten Wert einstellen.

Hoffe das ist nicht allzuweit weg von deinem Problem

Gruss


Gesendet von iPhone mit Tapatalk

[svethi]

@climber6: ja, hättest wohl nicht nur grob überfliegen sollen ...

[Christian Fenzl]

Ich hab auch nicht alles gelesen, jedenfalls sendet der Analogspeicher bei TR auch den gleichen Wert nochmal.

Es gäbe mehrere Bausteine, die zusätzlich zum Analogeingang ein TR bräuchten, um sinnvoll arbeiten zu können, z.B. Virtuelle Ausgänge, virtuelle HTTP Eingänge, Statusbausteine, und überhaupt einen Wertänderungs-Baustein, der einen Impuls ausgibt.
Loxone ist bisher nicht sehr empfänglich, was Verbesserungen an bestehenden Funktionen angeht.
lg, Christian

[svethi]

Ja, am Status fehlt mir auch schon ewig ein TR

[Gast]

@Sven:

Bei einem System wie Loxone ist es ja aber so, dass die Nachricht ununterbrochen "gesendet" wird.

Das stimmt eben nicht. Die Loxone ist dem KNX viel ähnlicher, als Du denkst. Wenn obige Aussage stimmen würde, könnstest Du keine zwei Ausgänge an den selben Eingang hängen.

Es war bisher immer so, dass der letzte Wert, der am Eingang ankam Priorität hat.

Das stimmt einigermassen, aber eben, hier kommt die Subtilität rein. Was bedeutet "ankommen"? Wie im letzten Post geschrieben, habe ich experimentell festgestellt, wie genau die Loxone diesbezüglich "tickt". Und ich halte das für zumindest bemerkenswert, denn es ermöglicht eben obig beschriebene Verdrahtung.

Das sind völlig unterschiedliche System und Du kannst nicht erwarten, dass Du die Funktionalitäten einfach so vermischen kannst. Allerdings, und da kommen wir jetzt zu einem Lösungsansatz für Dich, bietet Loxone auch hierfür Möglichkeiten an. Du musst nur einen Weg benutzen, der ebenso nur eine Nachricht verschickt. Dieser Weg wären die Webservices.

Ich bin wie gesagt der Meinung, dass so unterschiedlich diese Systeme gar nicht sind. Intern arbeitet die Loxone genau so mit Messages. Eben, sonst wäre Deine Aussage "der Wert, der als letzter ankam" unsinnig. Und sonst könnte man keine Ausgänge parallelschalten.
Der Weg über einen Webservice ist jetzt noch einiges uneleganter als mein Lösungsansatz. Und auch ressourcenaufwändiger.

@alle:
Das Beispiel mag unglücklich gewählt sein, gerade deshalb, weil der Dimmer die Doppelklickfunktion schon eingebaut hat. Aber es gibt viele Situationen, in denen man man einen Wert aufgrund eines Ereignisses erneut an einen Eingang senden will, ohne dass sich dieser verändert hat. Eben, das Beispiel ist doch nicht sooo schlecht: Ich will einen Dimmer haben, der aber, wenn ich eine bestimmte Taste drücke, sofort auf 100% schaltet. Versucht es mal! Es tönt trivial, aber es ich habe es nur mit meiner obig beschriebenen Lösung hingekriegt. Vielleicht gibt es eine andere Lösung, dann lasse ich mich gerne belehren.
Aber meine Lösung funktioniert nur, weil sich die Loxone genau so verhaltet, und das zu wissen ist m.E. wichtig, wenn man etwas komplexere Dinge realisieren will als nur das von Loxone "vorgekaute"

Nochmals zusammengefasst:

Wenn ein AUSGANGSwert neu berechnet wird, wird eine Message in den dran hängenden Knoten, resp. an alle dran hängenden Eingänge geschickt. Egal, ob sich der Wert verändert hat oder nicht. (Und dieser letzte Satz ist EXTREM wichtig! Loxone hätte hier entscheiden können, in diesem Fall auf einen Versand der Message zu verzichten. Das wäre sogar naheliegend gewesen. Das hätte aber die Flexibilität der Loxone arg eingeschränkt, wie ich mit meinem Beispiel gezeigt habe).
Wenn sich ein EINGANGSWERT verändet hat, wird der entsprechende Baustein getriggert, seine Interna und Ausgänge neu zu berechnen.

Ein Eingang, der mit einem Ausgang verbunden ist, muss NICHT immer denselben Wert haben wie der Ausgang. Das kann man mit von mir obig beschriebener Beschaltung leicht nachvollziehen. Und das ist kein Fehler der Loxone, sondern die Folge der Tatsache, dass die Loxone ereignisbasiert ist, und eben NICHT statusorientiert. Und dies kann bewusst so genztzt werden. Eben, im Wissen um obig beschriebenes Verhalten.


Noch ein Nachtrag:
Dieser Analogeingang des Dimmers ist m.E. ein sehr schönes Beispiel, dass die Dokumentation von Loxone ein bisschen "wischi-waschi" ist. Sie wollen den Anwender glauben lassen, es sei ein zustandsbasiertes System. Und dass die Linien zwischen Ein- und Ausgängen "Drähte" sind, Das Konzept der Ereignisse wird, so meine ich, sehr stiefmütterlich behandelt.
Stellt Euch mal vor, es wäre so, wie von Loxone suggeriert. Wenn am Analogeingang ein Wert anliegt, wird dieser genommen. Was heisst denn "wenn ein Wert anliegt"? Es liegt immer ein Wert an! Wie Christian geschrieben hat: Dieser analoge Eingang macht unter dieser Annahme keinen Sinn ohne einen Triggereingang! Stellt Euch einen physischen Dimmer vor. Der Helligkeitswert entspricht einerseits der Spannung an einem seiner Eingänge und kann andererseits durch andere Eingänge verstellt werden. Was denn nun? Entspricht er der Spannung am Steuereingang oder nicht?
Und eben hier sehe ich eine grosse Diskrepanz zwischen dem Mechano der Loxone in Realität und gemäss Beschreibung. Und genau deswegen war ich auch über die Massen erstaunt, als ich zum ersten Mal zwei Ausgänge an einen Eingang gehängt hatte und Loxone Config mir nicht auf die Finger geklopft hat. Ein Draht kann nicht gleichzeitig 3.4V und 2.5V haben. Und wenn man die Loxone als ein zustandsbasiertes System betrachtet und sich selber entsprechend einschränkt (im Forum wurde mir schon von jemandem gesagt, Ausgänge parallel zu schalten sei sowieso grundsätzlich nicht gut), wird die Loxone zu einem sehr sehr simplen Ding mit sehr wenigen Möglichkeiten, die von Loxone genau so vorgekaut wurden. Deswegen halte ich es eben für wirchtig, GENAU zu beschreiben (und zu verstehen), WIE die Loxone funktioniert, sobald man eine gewisse Komplexität konfigurieren will.
Jetzt, wo ich die oben beschriebene einfache Regel verifiziert habe, wird mir einiges klarer. Und ich werde mich hüten, Linien als "Drähte" zu betrachten, sondern als Ereignis-Transportleitungen. Und so ist auch plötzlich vieles klar, was vorhin überhaupt nicht klar war. Wie eben, unter welchen Bedingungen nun eigentlich ein Wert am Analogeingang eines Dimmers genommen wird, der interne Zustand also überschieben wird, oder nicht.

Eigentlich breche ich hier auch eine Lanze für Loxone. Das System kann nämlich viel mehr, als die Doku beschreibt!

Aber eben, so ein dedizierter "Ereignisbaustein" wäre eine logische Erweiterung, die einiges vereinfachen würde. Dazu müsste sich Loxone aber zu dem bekennen, was sie machen, nämlich ereignisse senden und empfangen. Und zugegeben, es ist ein bisschen komplexer, dies zu vertehen. Deswegen könnte man das als "advanced feature" anbringen. Wenn Du diesen Baustein einsetzen willst, musst Du verstehen, wie die Loxone WIRKLICH funktioniert. Aber als Belohnung bekommst Du viele neue Möglichkeiten.
Wenn Du aber die Loxone als ein zustandsbasiertes System sehen willst, darfst Du nicht nur diesen Baustein nicht einsetzen, sondern eigentlich auch keine Ausgänge parallelschalten. Dafür ist es dann sehr einfach zu verstehen, und 80% der üblicherweise zu realisierenden Dinge kann man damit abdecken.

Gruäss
Simon

[svethi]

Da Du fest auf Deiner falschen Meinung beharrst, bin ich raus.

[Gast]

@Simon:
Das hört sich für mich alles an, wie "Neu: Das geheime Liebesleben der Bäume"...

Nichts für ungut, aber was für eine Theorie-Findung! :-(

1.) Du bist dem "Ereignis- vs. Zustandsbasiertem"-Hype aufgesessen.
2.) Du schließt von einen kleinem Teilstück auf das Gesamtsystem
3.) Du verkennst, das die Loxon-Config nur eine grafische Oberfläche für eine interne Programmabarbeitung ist.
4.) Du nimmst an, die Loxone-Config ist ein homogenes System.
5.) Du verkennst, daß z.B. der Dimmer-Baustein (wie jeder Config-Baustein) nur eine beschriebene Black-Box ist.
6.) Du nimmst an, jeder Baustein ist ein homogenes Teilstück eines homogenen System.
7.) Du hangelst Dich von Annahme zu Annahmen.
usw. usw..

Nur 'mal kurz theoretisch, z.B.
zu 5.) :
Loxone hat einen Baustein als Programmvereinfachung bereitgestellt. Der 'macht' das, was Loxone ihm 'einprogrammiert' hat.
Das ist völlig unabhängig von 1.), der 'arbeitet' intern (quasi als Black-Box) seine Funktion innerhalb der Loxone-Vorgaben ab (z.B. Eingang 1: ereignisbasierend, Eingang 2: zustandbasierend, Ausgang 3: abhängig von Eing. 1 + Eing. 2 + Parameter).
Diese Vorgaben hat Loxone dann als Doku bereitgestellt, damit das eben auch andere einsetzen können - unabhängig, ob die die Funktion der Programmvereinfachungen jetzt genau so nutzen würden.
Hält sich der Baustein jetzt nicht an die Loxone-Vorgaben, dann ist da die Doku falsch oder es ist ein Programmfehler oder eben auch beides.
zu 2.)
Deine geheime Theorie ist erst dann die Wirklichkeit, wenn Du das für alle Bausteine/Eingänge/Ausgänge usw. (und allen Varianten davon..) und genau für eine (welche?) spezielle Programmversion getestet und vorgeführt hast.
Anders gesagt: Wenn wirklich ja, stimmt das dann auch noch 100%-tig mit der Loxone-Config Version x.yz?

Genug der verqueren Theorien:
Was genau ist Dein Problem mit dem Dimmerbaustein?
Welche Schalter sollen was bewirken?
Wie viele Schalter schalten was?
Stelle doch bitte 'mal Deine Loxone-Programmierung, Deine reale Programmbeschreibung (so, wie Du es einsetzen möchtes) und ggf. einen elektrischen Beispielschaltplan ('das geht doch z.B. so mit dem xyz-Dimmer des Herstellers abc') hier als Bild ein, damit Dir jemand praktisch helfen kann.
:-)

LG,
aus

PS:
In einem Punkt stimme ich Dir auch ohne Beweise zu: die Doku von Loxone ist vielerorts (freundlich gesagt...) lieblos ;-(

[Christian Fenzl]

Gast, ich weiß nicht, was dich zu diesen ausführlichen Annahmen/Analysen treibt.

Fakt ist:

• Loxone hat mit der Einführung der Version 5 die SPS-basierte Engine durch eine eventbasierte Engine ersetzt. Das wurde auch kommuniziert, und dient der enormen Entlastung des Miniservers. Aus Anwendersicht/"Programmierer"-Sicht verhält sich das System weiterhin wie ein SPS-System.
• Loxone hat (im alten Forum) kommuniziert, dass bei Analogeingängen immer der zuletzt geänderte Wert übernommen wird. Zudem verwenden viele Bausteine immer die zuletzte Änderung (sonst würden z.B. die Analogeingänge des Jalousiebausteins überhaupt nicht funktionieren).
• Da es (auch im alten Forum) einiges an Kritik gab, dass man den gleichen Wert nicht zweimal senden kann, wurde der Analogspeicher so umgebaut, dass ein nochmaliges Tr auch den gleichen Wert nochmal ausgibt. Genau dieser Analogspeicher-Baustein ist genau für deinen anfangs erwähnten Use-Case gedacht.

lg, Christian

[Gast]

@ Sven:
Ist mir recht. Ich habe Deine Widersprüche erwähnt. Aber dann liege ich halt falsch und Deine Aussage stimmt.

@ Aus:
Zu 1) Nein, ich versuche zu verstehen, wie die Loxone funktioniert. Nicht mehr und nicht weniger.

Zu 2)
Richtig, das tue ich. Stell Dir vor, ich habe gerade herausgefunden, dass man im Windows File Explorer Files dadurch von Ordner zu Ordner verschieben kann, indem man das Icon rüberzieht. Aber dass der gleiche Vorgang zu einem Kopieren führt, wenn die Drives unterschiedlich sind. Und dass man das Verhalten mit CTRL wechseln kann. Und Du fragst mich jetzt: Mit wechen Files hast Du das probiert? - Och... mit .txt, und .doc. Ich nehme mal sehr stark an, dass das generell so ist. - Aber Du kannst doch nicht einfach darauf schliessen, dass das bei .mp3 und .xls Files auch so ist!?!
Ja, richtig, ich gehe davon aus, dass das Verhalten des Message-passing ZWISCHEN Baublöcken unabhängig davon ist, WAS das für Blöcke sind. Wenn sich das als falsch herausstellen würde, wäre Loxone das besch....eidenste System, das es gibt.

Zu 3) Nein. Ich versuche zu versehen, was die Loxone mit dem macht, das ich graphisch eingebe.

Zu 4) Nein, ich nehme aber an, dass die Inter-Block-Kommunikation nach gewissen Regeln abläuft. Wenn das nicht so wäre, siehe letzter Satz von 2)

Zu 5) und 6) Da verstehe ich nicht, was Du meinst.

zu 2.)
Deine geheime Theorie ist erst dann die Wirklichkeit, wenn Du das für alle Bausteine/Eingänge/Ausgänge usw. (und allen Varianten davon..) und genau für eine (welche?) spezielle Programmversion getestet und vorgeführt hast.
Anders gesagt: Wenn wirklich ja, stimmt das dann auch noch 100%-tig mit der Loxone-Config Version x.yz?

Wie gesagt: WENN das so wäre, wäre das eine Katastrophe, beides.

Genug der verqueren Theorien:
Was genau ist Dein Problem mit dem Dimmerbaustein?

Das konkrete Problem hat sich für mich gelöst. Es geht darum, dass ich aufzeigen (nicht behaupten!) wollte, wie die Loxone tickt. Weil ICH das sehr spannend finde.
Und auch wenn die Funktionsblöcke selber individuelle Funktionalität haben, so MUSS die Interblockkommunikation Regeln gehorchen, die a) einheitlich sind und b) möglichst viel Flexibilität zulassen. Es ist ein bisschen wie bei LEGO. Es gibt 4er Blöcke, 8er Blöcke etc. Und es gibt Spezialbausteine. Mit denen kann man z.B. sehr schöne Autos bauen. Aber Lego MUSS sich bei aller Vielfalt der Spezialblöcke auf ein Grundschema committen. Stellt Euch mal vor, bei jedem Block wäre der Nockendurchmesser ein bisschen anders. Natürlich kann ich auf ein Steuerrad keinen Block aufbringen. Aber das Steuerrad kommt auf einen Block. Und hier ist es egal, ob es ein 4er oder ein 8er Block ist.
Loxone macht wunderschöne Spezialbaustene. Einen für ein Auto (Dimmer), einen für ein Startrek Raumschiff (die Heizungssteuerung) etc. Aber Loxone bietet auch 4er und 8er Blöcke an. (Logikfunktionen, Addierer, etc....). Und sagt: Baut Euch Euer eigenes Auto-Raumschiff! Und zu verstehen, wie das Messaging GENAU funktioniert, eröffnet halt VIEL mehr Möglichkeiten!

Eben, das konkrete Problem existiert gerade nicht (mehr), aber wenn Ihr Lust habt, dann macht doch mal folgendes:

Badezimmer. Ein Dimmer, mit dem man das Licht schummrig machen kann um romantisch mit wem auch immer zu baden. Standard Dimmer Funktionalität halt.
Am Spiegelschrank hat es einen Taster. Wenn ich den drücke, wird das Licht auf 100 geschaltet. Also gleichwertig wie ein Doppelklick auf die "Standard-Dimmer-Taster".

Ja, mit einer Lichtsteuerung würde das gehen. Aber eben: Es geht auch mit einem ganz gewöhnlichen Dimmerbaustein. Und der hat dann den Overkill der Lichtszenen in der Visualisierung nicht. Aber es funktioniert nur, weil sich die Loxone so verhält, wie sie sich verhält. Ich will kein Startrek-Raumschiff, sondern ein Auto, bei dem ich ein zweites Steuerrad draufsetze.

Und halt wieder auf der theoretischen Seite:
Erklärt mir mal, was der Analogeingang des Dimmers macht.
a) Was an seinem Eingang anliegt, wird vom Dimmer übernommen. Punkt.
b) Immer der zuletzt veränderte Ausgang wird übernommen.
c) so wie ich es erklärt habe.
d) er übernimmt den Wert irgendeines Ausgangs, nach Lust und Laune der Loxone.
e) irgend eine andere Regel.

Zu a) So ist es in der Doku beschrieben. Wenn es so wäre, könnte man den Dimmer auch gleich weglassen, warum soll ich + und - Tasten haben, wenn ja eh der Analogeingang übernommen wird? Das kann also NICHT sein.
Zu d) Das wäre mal so richtig besch...eiden.
Zu b) Davon ging ich bis gestern aus, und das hätte obig beschriebenen Taster für den Dimmer verunmöglicht (zumindest fand ich auf die Schnelle keine Lösung).
Zu c) Die Simulation gab mir recht.

Nochmals zu c) Richtig, ich gehe jetzt einfach davon aus, dass dieses Verhalten sich nicht auf den Dimmerbaustein beschränkt, sondern generell für Eingänge gilt. Alles andere wäre unsinnig.

Wie geschrieben, für mich stimmt es. Ich will ein System, das ich verwende, verstehen. Und ich denke, das tue ich jetzt auch. Ich möchte Euch das nicht aufdrängen. Für 80% der Anwendungen und wohl 100% der Standard-Anwendungen reicht es aus, wenn man zu obiger Frage weiss, dass es irgendwas zwischen a) und e) ist.
Aber mir reicht das halt nicht. Ich will GENAU wissen, wie die Loxone arbeitet, um eben möglichst elegant und nachvollziehbar Funktionalitäten zu bauen können, die nicht von Loxone vorgekaut sind.

Gruäss
Simon

[Gast]

Gast
Da es (auch im alten Forum) einiges an Kritik gab, dass man den gleichen Wert nicht zweimal senden kann, wurde der Analogspeicher so umgebaut, dass ein nochmaliges Tr auch den gleichen Wert nochmal ausgibt. Genau dieser Analogspeicher-Baustein ist genau für deinen anfangs erwähnten Use-Case gedacht.

Ooookeey, DAS ist interessant. Davon wusste ich nicht (bin Neuling und bin erst dabei die Loxone in meiner neuen Wohnung einuzurichten). Das hört sich sehr spannend an!
Was jetzt einfach bemerkenswert ist, ist, dass das einem Eingang (zumindest dem des Dimmers) egal ist. Wenn der einen Wert vom S&H (Analogspeicher) neu bekommt, reagiert er nicht darauf, weil sich der Wert ja nicht verändert hat. Und deswegen eben meine Rückkopplung vom Ausgang zum analogen Eingang. Versuch's mal in der Simulation!

Das widerspricht nicht meiner obigen Annahme. Aber natürlich muss man sich bezüglich meiner Aussage "Wenn Ausgang neu berechnet wird, wird er an alle Eingänge geschickt" die Frage stellen: "WANN wird denn ein Ausgang neu berechnet?" Und hier, und da gebe ich Euch natürlich recht, reden wir wiederum von bausteinINTERNER Funktionalität. Dass genau dieser Baustein in genau diesem Kontext in der Kritik stand und verändert wurde, zeigt wohl, dass das Verhalten im Endeffekt schon abhängig vom (ausgangsseitigen) Baustein ist. Aber eben, es ist im Loxone-Event-System zumindest möglich, dass ein Baustein den gleichen Wert neu sendet! Das ist nicht selbstverständlich! Welche das tatsächlich tun, hier gebe ich Euch recht, hängt dann eben vom Baustein ab.

Die Frage, die ich mir stellte, war halt ganz einfach: ich sah, dass ich nicht einfach den Analogspeicher an den Dimmereingang hängen konnte. So funktionierte es nicht. Ich fragte mich dann, warum. Aha: Der Wert ändert sich ja nicht. Also "sieht" der Dimmer keinen neuen Wert an seinem Eingang. Warum nicht?
a) Weil kein neuer Wert gesendet wird?
b) Weil ein Knoten in Loxone grundsätzlich nur auf Wertänderungen reagiert? (also gar keine Bestätigungen desselben Werts gesendet werden KÖNNEN
c) weil ein Eingang nur auf Wertänderungen reagiert?

Die Simulation mit der Rückkopplung zeigte dann, dass c) stimmt. Ich gehe davon aus, kann mich aber irren, dass das generell so ist.
a) ist bei diesem Baustein (!) falsch.
b) ist (und ja, hier gehe ich davon aus, dass man das allgemein sagen kann) falsch. Hätte aber auch die korrekte Antwort sein können. Und das hätte das Loxone System stark eingeschränkt.

Loxone hat mit der Einführung der Version 5 die SPS-basierte Engine durch eine eventbasierte Engine ersetzt. Das wurde auch kommuniziert, und dient der enormen Entlastung des Miniservers. Aus Anwendersicht/"Programmierer"-Sicht verhält sich das System weiterhin wie ein SPS-System.

Hmmmmm.... Wie das vorher war weiss ich halt auch nicht. Aber wenn es wirklich zustandsbasiert war, dann hat Loxone, diede frechen Kerle, einfach ohne zu fragen uns Kunden viel mehr Flexibilität gegeben! :-) Durfte man denn zuvor Ausgänge parallelschalten?

[Christian Fenzl]

Wenn der einen Wert vom S&H (Analogspeicher) neu bekommt, reagiert er nicht darauf, weil sich der Wert ja nicht verändert hat. Und deswegen eben meine Rückkopplung vom Ausgang zum analogen Eingang. Versuch's mal in der Simulation!

Stimmt, das funktioniert nicht. Das ist dann ein Bug des Dimmer-Bausteins.

Hmmmmm.... Wie das vorher war weiss ich halt auch nicht. Aber wenn es wirklich zustandsbasiert war, dann hat Loxone, diede frechen Kerle, einfach ohne zu fragen uns Kunden viel mehr Flexibilität gegeben! :-) Durfte man denn zuvor Ausgänge parallelschalten?

Man konnte Analogwerte parallel an Eingängen anschließen, aber ob's funktioniert hat, weiß ich nicht mehr. Aber auch zustandsbasiert liese sich das realisieren. Vergleiche: ODER-, UND-und ALARM-Baustein: Dort kann man an einem Eingang auch mehrere Sachen anschließen, und intern werden alle Anschlüsse einzeln verarbeitet (alles geODERt, geUNDet oder das offene Fenster angezeigt).

Der Miniserver ist mit der zustandsgesteuerten Logik an seine Leistungsgrenzen gestoßen. Der Miniserver hat selbstständig seine SPS-Frequenz reduziert, wenn er's nicht mehr gepackt hat.