28-09-2012, 07:44:07 (Dieser Beitrag wurde zuletzt bearbeitet: 28-09-2012, 07:57:22 von Orson.)
(27-09-2012, 19:28:56)SmarthomeMan schrieb: Wenn ich bei Obi einen Hammer kaufe, kann ich die nicht verantwortlich dafür machen, wenn ich den Nagel krummhaue.
Ok, aber wenn ich einen Lichtschalter kaufe, dann sollte der schon das Licht an/ausmachen und nicht mal an und mal aus und wenn das Licht dann tagelang, brennt ich dann auch noch schuld bin, weil der Schalter irgendwann mal schalten.
Zitat:da die Logik Profile ein mächtiges Tool sind und fast unbegrenzte Möglichkeiten an Konfigurationen bieten, haben wir leider nicht die Möglichkeit für jedes individuelle Problem ein Profil zu erstellen.
Die Funktionsweise der erstellten Profile, kann nur im begrenzten Maße von uns unterstützt werden, da Logik Profil in der Verantwortung des Anwenders liegen.
Ich finde diese Aussagen schon bedenktlich.
Wenn man von diesem "mächtigen Tool" reichlich Funktionen nutzen möchte, ist doch bei Problemen die Standardantwort "Sie haben aber auch viele Profile und Zustandsvariablen....."
Das Schlimme ist, das nichts dokumentiert ist und wahrscheinlich vieles auch garnicht genau bekannt ist. Der zeitliche Ablauf scheint nicht genau vorhersehbar zu sein. Ich habe die Erfahrung gemacht, dass Logikprofile, bei denen eine Variable oder ein Aktor als Eingangsparameter verwendet werden und gleichzeit verändert werden immer wieder zu Problemen führen.
Von meinem Ablaufprofil um 10 Rollläden in bestimmten Zeitabständen zu fahren, habe ich vorerst Abstand genommen.
Positiv ist, dass offensichtlich die Funkverbindung und der Zugriff per Smartphone deutlich stabiler geworden sind.
(27-09-2012, 19:28:56)SmarthomeMan schrieb: Wenn ich bei Obi einen Hammer kaufe, kann ich die nicht verantwortlich dafür machen, wenn ich den Nagel krummhaue.
Ok, aber wenn ich einen Lichtschalter kaufe, dann sollte der schon das Licht an/ausmachen und nicht mal an und mal aus und wenn das Licht dann tagelang, brennt ich dann auch noch schuld bin, weil der Schalter irgendwann mal schalten.
Wenn man auf Nummer Sicher gehen will, verwendet man halt ausschließlich Ereignisprofile und lässt die Finger von Logikprofilen.
Ereignisprofile sind einfach gestrickt, einfach zu durchschauen und einfach anzulegen.
Sie werden beim Anlegen auf Plausibilität geprüft, sodass man wenig Fehler machen kann.
Damit einher geht natürlich eine eingeschränkte Flexibilität.
Bei Logikprofilen gibt es keine Plausi-Prüfung, und entsprechend heftig kann man sich ins Knie schießen. Aber man ist ungleich flexibler als mit Ereignisprofilen, und man kann irre Sachen damit realisieren. Aber man muss heftig mitdenken.
28-09-2012, 16:38:13 (Dieser Beitrag wurde zuletzt bearbeitet: 28-09-2012, 16:42:35 von Orson.)
Ärgerlich ist wirklich, dass nirgendwo steht wie das Logikprofil die Ereignisse abarbeitet. Leider habe ich derzeit keine Idee, wie ich mein Problem anders lösen kann.
Heute hatte ich versucht, mit einer Hilfsvariable die Schaltung zu verzögern, aber auch hier hat man das gleiche Problem. Die Variablen werden nicht gleichzeitig gesetzt bzw. werden Änderungen unterschiedlich schnell ausgewertet.
Am Schreiben von RWE stört mich am meisten, dass man mehr oder weniger im Regen stehen gelassen wird. Scheinbar wissen die selber nicht, wie ihr System genau funktioniert. Der Punkt "Zufall" scheint einen größeren Einfluss zu haben, anders kann ich die verschiedenen Ergebnisse bei gleichem Vorgehen, nicht erklären.
Die Sache ist im Grunde schrecklich einfach. Und gleichzeitig einfach schrecklich.
Zustandsvariable sind ja nur Speicherzellen in der Zentrale. Man muss sie nicht über ein kompliziertes Funkprotokoll antriggern.
Also werden Zustandsvariablen unverzüglich gesetzt, wenn die Bedingungen eines Logikprofils erfüllt sind.
Ein realer Aktor aber muß seine Befehle über Funk erhalten.
Wenn jetzt ein Logikprofil einen Aktor schaltet, dann wird dieser Schaltbefehl erstmal in eine Warteschlange eingereiht.
Diese Warteschlange wird nach dem FIFO (First in First out)-Prinzip abgearbeitet.
Über den Funkkanal kann immer nur eine Funktelegramm gleichzeitig abgesetzt werden.
Wenn unser armer kleiner Schaltbefehl an der Reihe ist, geht er über die Antenne raus an den Aktor.
Wenn dieser ihn empfängt, führt er die Schalthandlung aus und sendet eine Vollzugsmeldung an die Zentrale.
Wenn die Vollzugsmeldung in der Zentrale empfangen und verarbeitet ist, hakt die Zentrale den Schaltbefehl ab und setzt den Zustand des Aktors auf "Schaltbefehl ausgeführt". Erst dann ist der Aktor für die Zentrale im neuen Zustand.
Auf diesem Weg kann es eine ganze Reihe von Verzögerungen geben:
* Viel Funkverkehr. Wie im Straßenverkehr muß unser armer kleiner Schaltbefehl zuerst mal abwarten, bis er eine Lücke im laufenden Funkverkehr findet.
* Der Aktor ist schwerhörig - es gibt Übertragungsfehler. Dann muss die Zentrale den Schaltbefehl wiederholen.
* Die Zentrale ist schwerhörig. Dann muss der Aktor die Vollzugsmeldung nochmal schicken.
Während all das abläuft, ist die gleichzeitig geschaltete Zustandsvariable längst in ihrem neuen Zustand.
Logik, die darauf baut, dass Variable und Aktor gleichzeitig schalten, fällt da auf die Nase.
Da ist in der Tat Zufall im Spiel, das ist aber prinzipbedingt und kein Mangel der Software.
