Ich verwende auch Set_Property, um meine vom Splitter generierten Device-Module mit den richtigen Werten zu versorgen. Und ich habe nicht vor darauf zu vertrauen, das ein User in den Konfigurationsdialog aller generierten Instancen rein geht und erst einen Button drücken muss, damit alles funktioniert.
Weiterhin mache ich auch IO-Instancen per Splitter-Funktion mit Set_Property wieder auf und wieder zu, Das ist Teil der Funktionalität. Ich wüßte nicht, wie es anders gehen soll.
Den Vorteil der diskutierten Einschränkung ist mir noch nicht transparent. Niemand wird ohne Grund eine Property eines anderen Moduls ändern.
Das mit dem IO habe ich gerade angefangen bei mir wieder rauszunehmen.
Es geht sogar sehr gut.
Über MessageSink bekomme ich ja mit wenn der IO online geht und dann läuft mein Modul auch erst los.
Somit spare ich mir den Open Haken in meinem Splitter.
Und das ApplyChanges ist wieder schön aufgeräumt.
Dennoch habe ich ein Modul wo ich die Config des IO erst ‚berechnen‘ muss und da wird das aktuell auch so bleiben, dass ich den IO aus meinem Modul konfiguriere.
Der erste Absatz dafür ist völlig falsch.
Instanzen werden nie automatisch angelegt ohne das der User darauf Einfluss nimmt, also brauchst du auch nichts konfigurieren.
Dafür sind ja die Konfiguratoren gedacht.
Da musst du schon auf den User ‚vertrauen‘ weil bei allen anderen Modulen in IPS ist es ja auch so, dass er z.B. bei KNX, LCN oder HM diese anlegen muss.
Mit diesem üblichen Verhalten von IPS brichst du in dem Augenblick wenn es anders abläuft.
Das sorgt dann sogar noch eher für Verwirrung.
Ich lege eine Device Instance an, wenn ich ich im Datenstrom von meinem Splitter ein Device finde, was noch nicht bekannt ist. Das mache ich schon seit Delphi-Modul Urzeiten so und es gab nicht eine einzige Rückmeldung in den Jahren, das es jemand nicht so haben möchte. Im Gegenteil: es wurde als eine Verbesserung des „üblichen IPS-Verhaltens“ empfunden. Damit spart sich der User den Konfigurationsaufwand und ich bin sicher, das es funktioniert. Den Konfigurationsdialog gibt es dann hinterher immer noch, aber vorausgefüllt.
Das Steuern der IO-Instancen im laufenden Betrieb dient dazu, die Konfiguration wie z.B. Baudrate anzupassen, nur bei Bedarf eine offene Verbindung zu haben weil z.B. die Anzahl der gleichzeitigen Verbindungen meines Devices limitiert sind oder auch bei Fehlern wie eine abgebrochene Verbindung versuchen das automatisch zu fixen. Es ist ja schön, das ich über die Messages jetzt auch mitkriege, wenn sich der Status der IO-Instance ändert, für das dann fällige Öffnen und Schliessen muss ich doch wieder SetProperty verwenden.
Und ich sehe neben den genannten Nachteilen immer noch keinen Vorteil der Regelung, das nicht mehr machen zu dürfen.
Na nehmen wir mal das derzeitige Harmony Modul, das legt Dir bei Bedarf, und nur wenn der User das will, Instanzen mit den Variablen an. Das kann theoretisch eine unheimlich große Anzahl an Variablen sein je nachdem wie viele Geräte der User besitzt. Letztendlich ist es ja aber die Entscheidung des Nutzers ob er das nutzt oder nicht die Alternative wäre er sitzt stundenlang und macht das alles von Hand was da der Vorteil sein soll erschließt sich mir nicht. Das gleiche gilt ja auch für Skripte wie Homematic Easy Install, wer das ausführt weis das das unheimlich viele Variablen anlegen wird, dafür erspart es einem sehr viel Arbeit. Da kannst Du auch mal schnell die Variablenanzahl überschreiten.
Wichtig ist das es der User aktiv macht.
Aktiv ein Script ausführt, oder einen Button im Konfig-Formular drückt.
‚und nur wenn der User das will‘
Ist also OK, aber automatisch etwas anlegen wenn neue Daten reinkommen ist sehr stark grenzwertig.
Keine Ahnung wie es jetzt mit dem Harmony ist. Nur ein Haken in der Instanz oder aktiv einen Button anklicken?
Wenn IPS immer automatisch alle Geräte anlegen würde, dann können die Jungs Mal eben etwas mehr Upgrades verkaufen. Will man das? Den Unmut der User auf sich ziehen?
Nur weil ich jetzt einen Aktor, ein Gerät ergänzt habe muss ich Upgraden obwohl ich Gerät das gar nicht in IPS einbinden will?
Da ist das automatisch Anlegen klar kontraproduktiv und darum steht es auch im Draft.
Wortwörtlich sogar:
Ein Modul darf niemals automatisch andere Instanzen erstellen.
Die Funktionalität ist mM. ausreichend beschrieben.Ich sehe die Einwilligung des Nutzers dadurch gegeben, das er mein Modul bewusst installiert hat. Es zwingt ihn ja keiner dazu.
Grundsätzlich: Ich mache das als Hobby. Ich verlange im Gegensatz zu einigen Anbietern hier kein Geld für die vielen Stunden, die in manchen Modulen stecken. Wie ich etwas umsetze, muss dann doch mir überlassen werden. Schliesslich ist es meine Arbeitszeit und ich erstelle Module primär für mich selbst. Wer es anders haben will, darf sich gerne ein eigenes Modul schreiben.
Und: Überzeugende Argumente für die geforderten Einschränkungen kann ich in der ganzen Diskussion immer noch nicht finden
Machen doch alle Z-Wave-Module auch und die sind direkt aus IPS… und das nicht nur beim Create sondern auch zur Lebenszeit sozusagen… und natürlich muss ein Modul auch Variablen anlegen… was soll ein Modul ohne? Und beim Überschreiten der Lizenz ist es auch egal ob man 2 oder 200 Variablen anlegt, zu viel ist zu viel
Es geht nicht darum Statusvariablen anzulegen.
Sondern automatisch ganz neue Instanzen.
Wenn du jetzt 10 neue Z-Wave Geräte einbaust, und davon aber 3 nicht in IPS haben willst (aus welchen Gründen auch immer), dann legt IPS sie dir nicht einfach an.
Die Hoheit des Users über sein System zu waren, steht auch immer an erster Stelle.
Michael
Nach den aktuellen Richtlinien reicht der Haken zum automatisch anlegen nicht aus.
Allerdings gefällt uns diese Lösung recht gut. Mit solch einem Haken gibt der Benutzer ganz bewusst die Erlaubnis zur automatischen Erstellung. Die automatische Erstellung erhöht den Komfort des Benutzers, der jetzt nicht mehr weitere Dialoge durchklicken muss, da ihm das alles abgenommen wird. Da der Benutzer diese automatische Einrichtung explizit durch das Aktivieren des Hakens gewünscht hat bleibt hier trotz automatischer Erstellung seine Hoheit gewahrt.
Die primäre Variante sollte allerdings weiterhin sein, dass der Benutzer seine Geräte einzeln hinzufügt. Der Haken sollte also lediglich eine optionale komfortable Möglichkeit zum Anlegen sein und nicht diesen Prozess ersetzen. Also einfach nur den Haken hinzuzufügen und für die Lauffähigkeit des Moduls das Anklicken zu verlangen ist nicht der richtige Weg.
Wir werden die Richtlinien also demnächst mal entsprechend überarbeiten.
Den Haken für Autocreate gibt es bei mir auch, der ist aber default an. Das könnte ich noch ändern.
Nur reden wir jetzt schon über Richtlinien statt lt. Topic „Best Pratice“?
Ich würde dabei schon einen Unterschied zwischen kommerziellen Anbietern und Hobbyscriptern wie mir sehen.
In gewisser Weise sind die Best Practices auch als Richtlinien gedacht. Prinzipiell sind die Best Practices für zweierlei:
Wir wollen Vorschläge machen, was wir für schönen Code bzw. schöne Module halten, die sich gut in IP-Symcon integrieren lassen und unseren Vorstellungen der Hoheit des Benutzers, etc. entsprechen. Für die eigenen Skripte und Module sind sie allerdings genau das: Vorschläge. Wenn jemand für sich entscheidet, dass ein Modul ohne Bestätigung des Benutzers neue Module erstellen soll, dann darf er das natürlich gerne in seinem System so lösen. Wir werden dann nicht die Symcon-Polizei vorbeischicken, aber das Modul wird auch nicht in unsere Modulbibliothek (siehe 2.) kommen.
Wahrscheinlich wollen wir zu Version 4.4 eine Modulbibliothek implementieren. Darüber sollen Benutzer deutlich einfacher an neue Module kommen. So kann man beispielsweise durch verschiedene Kategorien schauen und sehen, ob interessante Module für einen selbst dabei sind. Damit der Benutzer eine einheitliche Erfahrung mit diesen Modulen hat, werden Module nur in diese Bibliothek aufgenommen, wenn sie die Best Practices erfüllen und werden von uns entsprechend initial gereviewt.
An Richtlinien sollte man sich halten, wenn man aber begründen kann warum es Sinn macht davon abzuweichen kann es auch OK sein. Regeln dürfen nicht überschritten werden.
Genau. Und es sind hier Richtlinien. Wenn ihr ein gutes Argument für eine Ausnahme habt, sind wie die letzten die was dagegen haben. Für manche Probleme gibt es eben zur Zeit keine „gute“ Lösung - da muss man sich etwas mit Tricks behelfen.
Für das Problem mit den Variablen und Properties muss ich mir etwas überlegen. Das Problem hatte ich bei meinem letzten PHP-Modul auch und ich missbrauche dort eine Property. Somit ist mein Modul auch nicht zu 100% konform. Sobald wir da eine Lösung haben werde ich es aber umbauen :rolleyes:
Am Ende des Tages sollt ihr Spaß am Module entwickeln haben und wir nur die Tipps liefern, wie wir unsere „offiziellen“ Module erstellen.
Ich brauche nochmal einen Tipp von euch wie man es denn (richtig) macht.
Folgendes: Ich habe ja ein Gardena Modul gebaut. Jetzt soll es um die Möglichkeit erweitert werden nicht nur das erste Gerät einer Klasse zu verwenden sondern mehrere. Wenn ich nun eine Instanz erzeugen möchte, müsste ich also zuerst die Anmelde-Daten vom User eingeben lassen, dann frage ich beim Server nach allen Geräten und zeige die zur aktuell anzulegenden Instanz an, woraus der Anwender dann die gewünschte auswählt… <- so in der Theorie… aber wie die Praxis?
Im Form kann ich ja nicht auf die Antwort vom Server reagieren, eine Listbox füllen und den Anwender auswählen lassen… wie würdet ihr das denn realisieren… da stehe ich gerade aufm Schlauch.
Einziger Weg der mir aktuell einfallen würde:
Erst Mini-Konfig für Anmeldedaten bauen per GetConfigurationForm bauen, dann die Geräte laden, dann neue Form bauen? Aber wie, er ersetzt sie dann ja nicht „on-the-fly“ oder? Konfigurator verlassen und neu einsteigen wäre für den Anwender auch nicht verständlich oder (dann könnte ich ja neues Form vorgeben)?
Letzter ist leider aktuell so in IPS, das fehlt noch.
Wobei wenn du erst den IO anlegst und dann den Konfigurator, kann dieser ja alle Daten laden und darstellen.
Aber du kannst Konfigurator und IO in einem bauen.
Sobald man übernehmen anklickt, lädt IPS die Form über GetConfigurationForm neu und dort kannst du sehr wohl Gerät von deiner Hardware abfragen und dann in einer Liste darstellen.
Die Form ist ja dadurch dynamisch.
Michael
Wir bauen die „Anmeldedaten“ ja meisten in den Splitter ein und zeigen dann im Konfigurator an, dass noch eine übergeordnete Instanz nicht korrekt konfiguriert ist.
