Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Wie schaut denn das Konzept aus, damit man sich da mal drauf einstellen kann?
Darauf gehe ich gerne am Seminar ein.
Eine Grundsatzdiskussion über das Konzept strebe hier im Forum nicht an, sicher wird aber die ein oder andere sehr sinnvolle Anregung von Euch in die Entwicklung fließen.
Hm, ich dachte das wäre klar.
Jedes eingehende Telegramm generiert ein event- egal ob Szenenaufruf, speichern, Leseanforderung etc.
Eine GA kennt einen Event, eine Gültigkeit, einen Default-Wert, einen Wert und was weiss ich noch alles. Daher ist eine Aussage: "erzeugt einen Event" nur ein Teil des "Verhaltens".
Könntest du also bitte das gesamte Verhalten der GA im Falle von Read erläutern?
Das würde ich nicht machen, da könnte schnell der ganze Tag drauf gehen.
Eine Grundsatzdiskussion über das Konzept strebe hier im Forum nicht an, sicher wird aber die ein oder andere sehr sinnvolle Anregung von Euch in die Entwicklung fließen.
Bin ich nicht interessiert dran. Ich kann Aussagen, wie: "haben wir momentan keine Leute für" oder "wir versuchen erst den einen Weg und dann evtl. den anderen" etc. verstehen, aber diesen Scherbenhaufen eines Konzeptes als Grund für das Ablehnen einer Idee zu nennen?
Featurewünsche Kommentarlos abzulehnen, die essentiel sind (siehe Stringbefehlen, Read-GAs, ntpd Befehle) und am Ende war alles nicht so gemeint?
Dann macht weiter so, Hauptsache der Webserver ist am Laufen, aber die Dimmwerte aus dem Dimm-Makro kann man nicht im eigenen Szene-Aktor speichern. Weiter so!
Ich verstehe die Frage nicht. Wie meinst Du denn das? Willst Du wissen, wie eine GA am Bus funktioniert, oder was genau ist Dein Verständnisproblem?
Also da habe ich eine Frage gestellt und die Gesamtheit der Problematik geschrieben. Ich frage nicht den eibPC Support, wenn ich wissen will, wie GAs funktionieren.
Ich versuche es auf mehrere Fragen aufzuteilen:
- Welchen Wert liefert die GA im Falle eines Reads, wenn der Event erzeugt wird?
- Welche Auswirkungen hat das Read auf die Gültigkeit der GA nach einem Reset des eibPCs?
- Gibt es evtl. weitere Besonderheiten, wenn ein Read zu einer GA auftritt, die im eibPC beachtet werden müssen?
A
- Welchen Wert liefert die GA im Falle eines Reads, wenn der Event erzeugt wird?
Die GA hat erst mal nix mit den event zu tun. event geht für einen Durchlauf der Verabeitungsschleife auf EIN, wenn am Bus irgendein Telegramm mit dieser GA gesendent wird. Der Inhalt des Telegramms wird in einem Abbildobjekt der GA im EIbPC gespeichert.
- Welche Auswirkungen hat das Read auf die Gültigkeit der GA nach einem Reset des eibPCs?
Keine. event und read haben aus Sicht des EibPC nix miteinander zu tun.
- Gibt es evtl. weitere Besonderheiten, wenn ein Read zu einer GA auftritt, die im eibPC beachtet werden müssen?
die Frage ist nicht eindeutig: Beziehst Du Dich mti Read auf eine Leseanforderung (liese das Wort "auftritt" vermuten) oder der Read-Funktion?
Wie schon gesagt, bisher unterscheidet der EiBPC bei ebent die Leseanforderung nicht vom Schreiben auf die GA. Die Leseanforderung selbst ändert aber natürlich auch nicht das Abbild im Speicher, wenn das die Frage war.
Michael
Die GA hat erst mal nix mit den event zu tun. event geht für einen Durchlauf der Verabeitungsschleife auf EIN, wenn am Bus irgendein Telegramm mit dieser GA gesendent wird. Der Inhalt des Telegramms wird in einem Abbildobjekt der GA im EIbPC gespeichert.
Gut.
die Frage ist nicht eindeutig: Beziehst Du Dich mti Read auf eine Leseanforderung (liese das Wort "auftritt" vermuten) oder der Read-Funktion?
Ich beziehe mich NUR auf die aktuell vorhandenen Funktionen.
Wie schon gesagt, bisher unterscheidet der EiBPC bei ebent die Leseanforderung nicht vom Schreiben auf die GA. Die Leseanforderung selbst ändert aber natürlich auch nicht das Abbild im Speicher, wenn das die Frage war.
Also am Beispiel:
Wie reagiert der eibPC wenn folgender Programmteil existiert, die GA als Read empfangen wird UND die GA bisher noch nie empfangen wurde?
if event(GA) AND GA == AUS then \\ write ("blah blubber", EIN) \\ endif
Nach den bisherigen Informationen würde ich erwarten, dass dieser write() ausgeführt wird.
Folglich wird man beim Abfragen der Zustände der Geräte am Bus die eigenen Leseanforderungen beim Systemstart nicht von "tatsächlichen" Schreibanforderungen unterscheiden können, wenn der Wert AUS/0/0.0/$$ ist.
Anders ausgedrückt bedeutet das auch, dass ein 1. empfangenes Telegramm "mit Wert" AUS/0/0.0/$$ einer GA auch ein Read gewesen sein kann bzw. ich event() ohne Abfrage des Wertes nur verwenden darf, wenn sicher keine Read-Anforderungen (z.B. von der Visu) auftreten können.
Evtl. bin ich ja der einzige, aber mir gefällt dieses Verhalten nicht!
Denke, dieses Verhalten sollte in der Doku beschrieben stehen, oder?
Mit dem Webinterface hat das nichsts zu tun und ist hier auch nicht vorgesehen.
Die Vorbelegung wäre dann schon eher per Funktion festzulegen... Mal drüber nachdenken...
Klar, Szenen haben zunächst einmal nichts mit anderen Interfaces zu tun. Um aber so viele Parameter editieren zu können benötigt man ein entsprechend flexibles Interface und da der EibPC in Hardware da nun mal nichts anbietet (kein Vorwurf, nur eine Feststellung), ist nun mal das Webinterface das, was den Anforderungen am ehesten gerecht werden würde. Warum sollte es also eines Tages nicht auch zum Editieren von Szenen oder Schaltuhren o.ä. dienen (können). Ich würde nicht wegen jeder Änderung gleich PC+EibStudio anwerfen müssen.
Folglich wird man beim Abfragen der Zustände der Geräte am Bus die eigenen Leseanforderungen beim Systemstart nicht von "tatsächlichen" Schreibanforderungen unterscheiden können, wenn der Wert AUS/0/0.0/$$ ist.
Ist das so? Ich meine, Schreibbefehle und Antworten auf Leseanforderungen sind nicht identisch. Bei den meisten meiner Geräte kann ich konfigurieren, ob sie Antworten wie Schreibbefehle interpretieren sollen und den Wert übernehmen oder ob sie sie ignorieren sollen. Wie ist das beim EibPC?
Ist das so? Ich meine, Schreibbefehle und Antworten auf Leseanforderungen sind nicht identisch. Bei den meisten meiner Geräte kann ich konfigurieren, ob sie Antworten wie Schreibbefehle interpretieren sollen und den Wert übernehmen oder ob sie sie ignorieren sollen. Wie ist das beim EibPC?
Es geht NOCH nicht um die Antwort (=Response) sondern bisher nur um die Anfrage (=Read). Lies dir doch bitte die Antworten von Michael noch einmal durch. Evtl. wird es mit der Info dann klarer.
Wie die Antworten auf die Reads dann behandelt werden, kann man sich zwar denken, Michael hat dazu aber noch keine "Details" geschrieben.
Er hat auch noch keinen Vorschlag für ein EventResponse() gemacht.
Es geht NOCH nicht um die Antwort (=Response) sondern bisher nur um die Anfrage (=Read). Lies dir doch bitte die Antworten von Michael noch einmal durch. Evtl. wird es mit der Info dann klarer.
Wie die Antworten auf die Reads dann behandelt werden, kann man sich zwar denken, Michael hat dazu aber noch keine "Details" geschrieben.
Er hat auch noch keinen Vorschlag für ein EventResponse() gemacht.
doch, das hab ich hier schon in die Featurelist eingetragen :
Hier für alle:
event: Eine GA wird am Bus gesendet.
eventread: eine Leseanforderung
eventwrite: ein Schreiben
eventresponse: ein Antworten.
Warum sollte es also eines Tages nicht auch zum Editieren von Szenen oder Schaltuhren o.ä. dienen (können). Ich würde nicht wegen jeder Änderung gleich PC+EibStudio anwerfen müssen.
Das sehe ich genauso. Momentan darf man für jeden "Mist" das Programm ändern. Das kann es doch nicht sein! Da sich Michael so wehement gegen den Einsatzt des Webservers als Konfigurationstool streubt, dachte ich an entsprechende Interfaces im EibStudio, aber auch das passt nicht ins Konzept.
Michael lässt sich dann aber doch zu Änderungen "überreden". Wenn der Wunsch "da" ist, müssten sich wohl noch mehr Nutzer melden.
Auch auf die Gefahr hin, das wir jetzt ziemlich OT werden:
Auch ich betrachte das Webinterface einfach als ein HMI wie es auf die ein oder andere Art die meisten komplexeren Steuerungen bieten. Als solches kann und sollte es auch möglicht weitgehend zur bequemen Konfiguration von Parametern dienen können, deren Änderung im laufenden Betrieb durch den Endnutzer (das ist nicht notwendigerweise auch der Programmierer!) sinnvoll und auch wünschenswert sind, z.B. Szenenwerte, Uhr-/Schalt-/Lauf- oder Verzögerungszeiten, Sonnenstände, Lüftungsklappen-/Rolladen-/Jalousiepositionen, Temperaturvorgaben, Helligkeitswerte, Windgeschwindigkeiten und vieles mehr. Das alles mag ein Endanwender anpassen wollen ohne gleich den "Techniker" zu rufen. Oder soll der EibPC am Ende nur in Installationen laufen, bei denen der Programmierer ständig vor Ort ist?
Wäre ich ein "normaler" "unbedarfter" Anwender, ich würde den Anlagenplaner zusammensch****** wenn der mir Technik einbaut, bei der ich eine Softwareänderung machen lassen müsste, nur weil ich es mir mit den Steuerzeiten meiner Rolläden im Urlaub nun doch anders überlegt habe.
In so fern würde ich als Verantwortlicher schon darauf achten, das ein Kunde wenigstens so etwas halbwegs einfach selbst einstellen kann.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
: 
Wenn der Wunsch "da" ist, müssten sich wohl noch mehr Nutzer melden.
Kommentar