Ich hätte zur Diskussion von hier gern noch eine Antwort von Michael (parsey), da ich aktuell gerade wieder über die Umsetzung verschiedenster Themen in Modulen nachdenke, obwohl der Fehler im SMTP Modul immer noch vorhanden ist und IPS auf dem PI zum Absturz bringt.
Die Aussage von Michael (Nall chan)
Das hat nix mit dem Modulen zu tun, sondern mit der Darstellung und Logik in IPS.
finde ich sehr unbefriedigend und in der Android App wird das auch so gehandhabt, wie ich es mir vorstelle.
Im Objektbaum ist folgende Struktur vorhanden, das Withings Modul ist hier nur als Beispiel gedacht.
In der Android App wird Kategorie, Instanz und Kategorie so dargestellt, wie es aus meiner Sicht gut und nutzbar ist.
Und im Webfront wird die Kategorie komplett ignoriert.
Das ist zumindest Inkonsistent und führt zu unschönen Effekten.
Wenn ich die Aussage „alle Variablen direkt unter die Instanz“ umsetzen würde, dann müsste ich die Variablen anders benennen und die Darstellung wäre absolut unübersichtlich. Z.B. aus meinem DWD Wetterbeobachtungen Modul kommen pro Messstation 26 Variablen, es gibt aktuell 79 Stationen, in Summe könnten das also mehr als 2.000 Variablen werden.
Ohne Kategorien pro Station absolut nicht sinnvoll darstellbar.
Ich bin zwar nicht Paresy… aber mal ein Vergleich:
Bei Homematic wird auch nicht eine Instanz angelegt und darunter 532 Kategorien für deine ganzen Geräte.
Der Weg ist es noch immer eine IO-Instanz zu haben (welche z.B. die Daten beim DWD abholt) und dann einzelne Geräte-Instanzen zu haben welche z.B. immer nur eine Messstation darstellen.
Michael
PS: Es ist ja nicht neu das Kategorien unterhalb von Instanzen nicht visualisiert werden können
Kategorien dürfen nur unterhalb von Kategorien sein. Dass die Apps dies anzeigen ist ein Fehler den ich korrigieren werde (=bald einfach nicht sichtbar)
Warum ist „Ralf“ eine Instanz und keine Kategorie? Normalerweise würdest du 68 Instanzen machen und jeder User wählt aus, welche Wetterstation er hinzufügt.
Weil das Modul nun mal eine Instanz ist :eek: und keine Kategorie.
Und da ich die Variablen in Modulen nicht oberhalb bzw. parallel zu Instanz anlegen kann, werde ich wohl doch bei Scripten bleiben. Die Einschränkungen und der Aufwand für die Modulentwicklung überzeugt mich einfach nicht :(.
Um bei deinem Beispiel zu bleiben…da müsste einfach nur die Kategorie „Waage“ weg und alle Variablen unterhalb der Modul-Instanz anordnen.
Das „Problem“ kommt immer nur bei den Leuten hoch, die ihre WebFronts nicht ordentlich mit Kategorien, Dummy-Instanzen und Links aufbauen, sondern die Ordner mit den Modulen, Skripten, Variablen direkt im WebFront verwenden. Was in meinen Augen der falsche Weg ist.
Mir ist das sowas von egal, wie die Module oder Skripte ihre Variablen haben. Weil ich ALLE Variablen selbst in meine WebFronts verlinke und optisch so aufbaue wie ich es gern hätte. Dann noch eigene Icons, eigener Text, … In meinen WebFront Ordner gibt es nicht eine Variable, nur Kategorie, Dummy-Instanzen und Links.
Auch bei Scripten werden die Variablen unter dem Script nicht dargestellt, also auch schlecht. Aber bei einem Script kann ich zumindest die übergeordnete Kategorie nehmen und die Variablen dort anlegen und updaten.
Für den Ansatz mit I/O, Splitter und Instanz fehlt mir das Verständnis. Da ist das Squeeze Modul zu mächtig, um zu verstehen, wie es gehen soll.
I/O - müsste die Daten timergesteuert per FTP holen
Splitter - müsste die Instanzen (Station) anlegen und die Daten dann verteilen
Instanz - wäre eine Station
Und eine I/O Instanz mit Timer habe ich auch noch nicht im IPS gesehen.
Da das Beispiel bei mir unvollständig ist, ist deine Aussage leider falsch bzw. nicht zielführend.
Es gibt zu der Person weitere Daten, nicht nur Waage, die entsprechend gruppiert/kategorisiert werden müssen.
Das hatten wir schon und ich finde es auch absolut unpassend. Natürlich kann man das alles manuell aufbauen.
Aber es ist viel einfacher für „Nutzer“, wenn es eine sinnvolle Struktur gibt, die ich an einem sinnvollen Einsprungpunkt verlinke, beim Withingsmodul z.B. die Instanz der Person.
Ich halte es für absolut unsinnig alle Variablen, die meine Scripte vollständig mit Kategorien und sinnvoll sortiert anlegen, nicht nutzen zu können, da ich sie „alle einzeln so wie ich will verlinken soll“ :eek:.
Das ist ja ok, wenn du „alles anders“ haben möchtest, dafür ist die Flexibilität von IPS ja da, aber welches wirkliche Argument spricht dagegen, eine nützlich Struktur direkt als Link im Webfront zu verwenden?
Die Antwort hast du dir mit diesem Thread selbst gegeben Weil es nicht möglich ist ALLES einheitlich so „auszugeben“, dass es direkt sinnvoll/praktikabel im WebFront verwendet werden kann
Das ist problemlos möglich, nur nicht mit Modulen und Instanzen, da es vom Hersteller nicht gewünscht ist :mad:.
Mit einem Script und passend angelegten Kategorien kann man die „Ausgabe Kategorie“ als Link direkt in sein Webfront einbinden, wenn man mit der Struktur und Sortierung des Script-Erstellers zufrieden ist.
Du kannst auch in einem Modul programmieren, dass die Variablen unter ROOT-KategorieMitModulName-Waage-… angelegt werden sollen und nicht unterhalb der Modul-Instanz…
…aber da verliert man dann total den Zusammenhang und von daher ist von dieser Methode dringend abzuraten.
Sobald man mehr als 1 WebFront hat (unterschiedlicher Inhalt je WebFront), muss man sowieso mit Links arbeiten. Oder installierst du ein Skript/Modul dann 2x?!
Um beim Withings Modul zu bleiben, in meinem Webfront geht der Link direkt auf „Waage“, die anderen Daten kenne ich ja und im gemeinsamen „Wettkampf Webfront“ geht der Link auf die Ebenen darüber.
Und es wurden Links genutzt, aber nicht für jede Variable einzeln ;), das spart Arbeit und wenn ich alles einzeln verlinken würde, wäre die Darstellung auch nicht anders, wie die bereits vorhandenen :p.
Nur das es im IPS bei Modulen und Instanzen so nicht funktioniert.
Nicht nur dies, es wird irgendwann entweder gewaltig in deinem System ‚krachen‘ wenn irgendwer irgendwo irgendwas verschiebt; oder gar nicht mehr funktionieren weil IPS dem vielleicht mal einen Riegel vorschiebt.
Die ‚alten‘ SDK-Nutzer waren da auch sehr sorgsam
Du meinst wohl Skript/Instanz
Module sind keine Instanzen !
Nur mal so… zur Grundsätzlichen Logik vom Aubau in IPS des logischen Baum.
Kategorien bündeln Instanzen (auch Dummy-Instanzen, ja das ist eine Instanz).
Unterhalb der Instanzen liegen deren Variablen oder auch mal ein Ereignis, wenn es denn die Instanz steuern soll.
Die Dummy-Instanz + Variablen soll es einem ermöglichen mit einen PHP-Script diesen grundsätzlichen Aufbau von Instanzen nachzustellen.
Wenn du dich nun entscheidest unterhalb deines Scriptes oder unterhalb deiner Dummy-Instanz Kategorien anzulegen… tja geht halt nicht zu visualisieren. Musst du wohl anders lösen.
Da nutzen aber viele lieber die Dummy-Instanz, ansonsten ist das auch ‚mein‘ üblicher Weg für kleine Scripte.
Diese lassen sich sofort visualisieren und auch in Kategorien bündeln.
Das Squeezebox-Modul ist keine Referenz, im Gegenteil… nicht nachbauen!!!
Das Ding heißt Testversion… aus gutem Grund
Aktuell würde ich es anders bauen (= werde noch umbauen).
Was mich aber nicht von der ‚Pflicht‘ befreit, sich mit dem Datenaustausch auseinander zu setzen, wenn ich Module entwickeln möchte.
Bis auf das Splitter nie automatisch Unterinstanzen anlegen, korrekt. (Stichwort ist dort dann Konfigurator)
Doch, nur sind diese Timer ‚versteckt‘ im Gegensatz zu den IPS-Ereignissen welche wir aktuell nutzen müssen für die Module.
Das was du beschreibst, ist sogar ‚einfach‘ mit dem Datenaustausch umzusetzen.
Du musst ja immer nur von oben (I/O) nach unten (Splitter bzw. Gerät) durchschieben. Der Rückkanal entfällt.
I/O enthält die Zugangsdaten und holt die Nutzdaten per FTP/WWW whatever, verpackt die Daten (z.B. ein Array) in ein JSON-String und wirft es mit IPS_SendDataToChildren weiter.
Das ‚Gerät‘ (die Station) schaut einmal nach ob seine konfigurierte Station enthalten ist und visualisiert die enthaltenen Nutzdaten der Sensoren, der Rest wird verworfen.
Hier wäre dann ein Splitter angebracht, welche die ‚Person‘ darstellt.
Rest wie oben, nur ein Weg ohne Rückkanal.
Für die Visu kann sich der Nutzer dann eine Kategorie erstellen (z.B. mit einem Namen) und dort alle ‚Geräte‘-Instanzen einsortieren.
Das ist einfach falsch. Du musst nur bestimmte ‚Regeln‘ einhalten. Warum Kategorie unterhalb Instanzen… braucht keiner. Für Scripte kannst du gerne Kategorien unterhalb Kategorien erzeugen…
Etwas übertrieben:
Wenn eine Instanz eine Maus wäre…
Dann passt sie in den Käfig (Kategorie), aber der Käfig nicht in die Maus.
Und wenn ich mir dann die Variablen als Einzelteile der Maus vorstelle…die in einen Käfig zu packen, welcher in der Maus ist… uuähhh… Kopfkino
Gar kein, es geht aber nicht wenn der Modul-Entwickler sich nicht an die Spielregeln in IPS hält
Aber PHP-Instanzen sollen ja ‚nur‘ die Funktion bereitstellen.
Der Aufbau einer eigenen Struktur im logischen Baum, sowie Visualisierung ist noch immer Aufgabe der Nutzer; und nicht der Module-Entwickler.
Genau aus dem Grund gibt es ja den Datenaustausch per physikalischen Struktur; damit beides unabhängig ist.
So ähnlich könnte ich mir die Auswahl der Stationen auch vorstellen. Und mit „Instanzen aktualisieren“ werden alle ausgewählten Stationsinstanzen (irgendwo, z.B. unter auswählbarer Parent-Instanz oder -Kategorie) angelegt.
Aber bitte nicht die Mäuseinnereien… ich hätte ein anderes Beispiel nehmen sollten…böakst…
Das ist auch wieder so extrem speziell…
Und auch der Grund warum ich mich weigere das als Modul zu bauen.
Das Ding hatte ich angefangen da war von den PHP-Modulen noch keine Rede.
Dennoch stand der Import und ein einfach zu handhabendes Update (per RS Script-Exporter) im Vordergrund.
Die Aufteilung ergab sich dann auch durch z.B. die ganzen User-Configs, welche ja bei Updates nicht geändert werden.
Und auch hier sind dann alle Variablen in eigene Dummy-Instanzen gruppiert, so dass es direkt im WF angezeigt werden kann (nicht schön aber es geht).
Allerdings musste ich dafür auch diverse Funktionen bauen um immer zuverlässig die richtige Dummy-Instanz zu finden (2x hoch, 1x runter und fallen lassen oder wie war das).
Das spart man sich bei den Modulen alles ein.
Aber die ganzen Abhängigkeiten zwischen z.B. dem Anrufbeantworter, der Anrufliste, dem Anruf-Monitor und dem Telefonbuch als einzelne Modul zu bauen… nein danke. Ich hatte es mal versucht aufzumalen… und aufgegeben.
Dann ist das Thema Datenaustausch wirklich exorbitant aufwendig, dass es sich einfach nicht ‚lohnt‘.
Kannte ich noch nicht nicht.
Wobei alles unterhalb der Trennlinie das ‚Testcenter‘ zu sein scheint.
Klar so eine Funktion wie ich sie z.B. bei der SqueezeBox mit LMS_CreateAllPlayer gebaut habe, kann man natürlich einsetzen.
Mir ging es um das vollautomatische Anlegen (= im laufenden Betrieb ohne Einwirkung des Users).
Weil das könnte User welche am Variablen-Limit hängen arg stören
(Nicht das wir bei den PHP-Modulen gerade sparsam mit Vars umgehen würden :rolleyes: )
Schon richtig, deshalb möchte ich ja gern die Auswahl anbieten und nicht wirklich begrenzen.
Ich habe vorhin noch mal mit Dummy Modulen (Instanz) und dem Modul (Instanz) rumgespielt. Das geht auch und die Dummy Module lassen sich ja auch direkt ins Webfront verlinken.
Ich muss mir dann nur noch eine passende Schleife basteln, um alle Häkchen auszuwerten, die Dummy Module anzulegen und die richtige Variable unter dem richtigen Dummy Modul unter dem Modul (Instanz) zu finden :D.
Kannte ich noch nicht nicht.