NEWS
Visu auf React Basis
-
Devices, Aliasses, Assistenten und Visualisierungen und die Zukunft
Die Einführung von Aliasses in den js-controller und die ersten Versionen des "Devices"-Adapters waren nur der Anfang. WIr haben einiges damit vor.
Dieser Beitrag soll einige der Ideen und Gründe darstellen und zur Diskussion einladen. Noch ist nichts in Stein gemeisselt und das alles umzusetzen wird auch nicht wenig Aufwand, aber gemeinsam können wir in diese Richtung arbeiten.
Aktuelle Realität und die Probleme ...
Ein grosser Vorteil von ioBroker ist seine Flexibilität. Jeder Adapter kann seine Objekte und Zustände frei strukturieren. Das wird auch fleissig angewendet :)
Die Große Herausforderung ist allerdings, das Visualisierungs-Adapter und auch die Assistenzsystem-Adapter - iot vor allem für Amazon Alexa und Google/Next Home, aber auch yahka für Homekit - Informationen brauchen was einzelne Zustände darstellen und ob/wie mehrere Zustände zusammengehören. Ziel ist ja, dass diese Adapter mit wenig zusätzlichem Aufwand für den User Ihr Arbeit verrichten und die Geräte bedienbar machen.
Über Objekttypen wie "device" und "channel" oder im Notfall "folder" kann ein Adapter Zustände gruppieren und do dem User und auch anderen Adaptern mehr Informationen zu den Zuständen geben. Die Idee von "device" und "channel" kommt aus der Homematic Ecke und funktioniert dort recht gut. Ob ein Adapter das nutzen kann hängt aber stark von den Geräten und Kommunikationsprotokollen ab. Auch Adapter wo eine Instanz nur ein Gerät anbindet hat üblicherweise dann kein "device" Objekt.
Die Rollenangabe bei den Zuständen sind ein weiterer Weg Informationen darüber bereitzustellen was ein Zustand darstellt und bedeutet. Wir ersuchen bei allen Adaptern darauf zu achten das die Rollen Sinn machen. Ob aber eine Rolleninformation zur Verfügung steht ist auch eine Frage des Kommunikationsprotokolls. Der mqtt Adapter könnte gar keine Rollen für die Zustände bereitstellen, weil er es selbst nicht weiss.
Die aktuellen Visualisierungs- bzw. Assistenten-Adapter benötigen daher aktuell entweder umfangreiche Konfiguration oder können immer nur einen einzelnen State steuern oder müssen "Zusammenhänge erraten". Material als Beispiel nutz eine sog. "type detector" Library die versucht anhang von Rollen UND Device/Channel Strukturen zu erkennen was zusammen gehört und wie man es sinnvoll darstellen kann. Damit das aber immer funktioniert müssen die Zustände auch eine entsprechenden Aufbau haben - im Zweifel müssen also Adapter aufwändig angepasst werden.
Bei Amazon Alexa gibt es inzwischen für die Smart-Home-Skills die Version 3 (ioBroker nutzt noch Version 2) - hier sind es anstelle der ca. 10 Gerätetypen von v2 plötzlich ca. 60! Das ganze auf die gleiche Weise zu Mappen wir aktuell ist unmöglich. Daher müsste man die ganze Arbeit auf den user abwälzen.Weiterhin war es bisher auch beim Tausch von Geräten (z.B. wegen Defekten) immer schwierig in Bezug auf eigene Skripte oder z.B. Szenen. Meist ändert sich mit der Seriennummer des Geräts auch die Objekt-ID - oder Sie ändert sich beim Wechsel des Protokolls ganz. Dann muss man alle Skripte und auch die Visualisierungen bzw. andere betoffenen Adapter raussuchen und anpassen. Das ist recht aufwändig.
Erste Schritte: Aliasses und der Basis-Devices Adapter
Bei der Einführung der Aliasse haben wir bisher primär den einfachen Gerätetausch und weniger nötige Anpassungen an Skripten oder Visualisierungs-Adaptern propagiert. Und ja, diese Themen können damit bereits umgangen werden.
Unter dem reservierten Namensbereich alias.0 können Objekte angelegt werden, die auf ein anderes Objekt vom Type "state" verweisen. Dabei kann das neue Objekt auch einen anderen Datentyp o.ä. anbieten und auch Werte in beide Richtungen umrechnen. Der Zustand dieses Alias-Objekts hängt immer an dem Zustand des entsprechenden Quell-Objekts.
So weit so gut.
Um das wenigstens rudimentär zu bearbeiten wurde der Devices-Adapter programmiert, der versucht Geräte im System zu finden. Er beachtet dabei "device" Objekte und unterstützt auch Quasi-Aliasse vom "linkeddevices"-Adapter. Das ganze wirkt etwas Chaotisch und da muss garantiert noch viel dran getan werden.Beim Anlegen eines neuen Geräts wird dieses in alias.0 angelegt und man kann den Gerätetyp wählen. Passed zu diesem werden dann eine Liste von "Standard"-Objekten/Zuständen angezeigt die man mit den verlinkten IDs füllt. Diese Standard-Objekte haben das Ziel das am Ende alle über Devices angelegten "Schalter" bzw. "Lampen" o.ä. identisch aussehen, die korrekten Rollen und Datentypen haben. Somit kann man auch ein Licht welches zB per mqtt angebunden ist eine Definition verpassen, sodass Visualisierungs- bzw. Assistenz-Adapter wissen was es ist und wie es dann angezeigt werden muss.
Aktuell ist die Anzahl der Gerätetypen noch eher überschaubar, aber es ist ja auch nur der Anfang. Es gibt auch Helfer-Skripte im Forum die in alias.0 einfach Erlauben verknüpfte Objekte anzulegen.
Aber ja, so richtig gross ist der Mehrwert aktuell noch nicht, das ist uns bewusst.... aber die Zukunft wird besser
In den nächsten Abschnitten möchte ich Euch so ein bisschen über die Pläne und Ideen erzählen die wir auf dieser Basis angehen wollen.
Schritt 1: Gerätetypen und "Objekt-Templates"
Wie oben schon erwähnt, definiert Amazon für die Alexa Welt aktuell über 60 Gerätetypen, die alle unterschiedliche Werte als nötige bzw. optionale Felder haben. Bei Google gibt es ähnliches. Viele davon sind auch für Visualisierungen interessant, weil man am "Typ" eines Geräts sehr gut entscheiden kann wie man es anzeigen und bedienen sollte - und das viel besser als zu raten :-)
Daher ist die Idee das wir, angefangen mit den Amazon- und Google Objekttypen den Devices Adapter um diese erweitern und in diesem Zuge für ioBroker Standardisieren - Standard bezüglich Pflicht und Standard-optionalen States(z.B. SET, ACTIUAL, COLOR, STATE ...). Gern kann man überlegen dazu weitere States "nutzerdefiniert" hinzufügen zu lassen, die aber dann von den ganzen nutzenden Adaptern ignoriert werden!
Das ganze wird dann als alias angelegt. Zusätzlich speichern wir im "device"-Objekt die Information zum genutzten Template. Dann muss man das danach nicht nochmals raussuchen.
Das bringt uns schon mal einen großen Schritt weiter: In Adaptern wählt man das "Device" Objekt aus und alle Informationen sind bekannt und ebenso welcher State-Name in dem Device Objekt was bedeutet. So muss kein Adapter mehr raten. Dem Type-Detector können wir auch so beibringen alles viel besser zu erkennen. Der grosse Vorteil ist aber das Adapter wie z.B. iot das ganze dann auch sehr gut zu den relevanten Amazon bzw Google-typen zuordnen können.
Die "Magie" liegt nur darin die Templates sinnvoll zu defineren. (Und natürlich muss iot irgendwie noch Rückwärts-Kompatibel bleiben damit alles noch so funktioniert wie aktuell - aber hier könnte man durchaus einmalig mit einer neuen Version automatisch aus allen zugeordneten Smart-Devices einmalig kompatible ALias Objekte anlegen, sodass iot danach direkt damit arbeiten kann).Weiterhin sind so angelegte Aliasse unabhängig von den originalen Objekten und ein solches Alias-Gerät kann bei einem Gerätewechsel einfach mit einem neuen Objekt-Mapping versehen werden und schon ist das Gerät getauscht - ohne das sich die Objekt-IDs des Alias-Geräts ändern.
Auch könnte man in den Templates (oder auch so generell) Objekte die im Admin nicht für "jedermann" angezeigt werden sollen über "common.expert=true" verstecken. Ein Objekt mit dieser Information wird seit Admin 3.4.8 nur noch im Expertenmodus angezeigt.
Schritt 2: Geräte-Guidance durch Adapter
Wenn das alles mal implementiert ist kann man Adapter-Entwicklen anbieten Ihre "device"/"channel"-Objekte um Meta-Daten zu erweitern. So könnte man zB seinen Geräten mitgeben was Sie für ein Gerätetype sind und wie die eigenen States zugeordnet sind zu den States die das Geräte-Template bietet. Das ist natürlich optional, aber bietet die Möglichkeit bei der Zuordnung direkt ein sinnvoll passende vorausgefüllte Maske anzubieten.
Zum Beispiel im "common" Bereich des Objekts sowas (am Beispiel einer Daikin-Adapter Objekts, State angaben relativ zum Device-Objekt):
"deviceMapping": { "template": "thermostat", "fields": { "SET": "control.targetTemperature", "ACTUAL": "sensorInfo.indoorTemperature", "HUMIDITY": "sensorInfo.indoorHumidity", "BOOST": "control.specialPowerful", "POWER": "control.power" } }Mit so einer Definition könnte müsste ein User sogar nicht einmal Alias-Geräte nutzen, weil auch hier alle Informationen für Visualisierungs- oder Assistenten-Adapter vorhanden wären. Dann könne auch das State direkt genutzt werden.
Schritt 3: Der "Geräte-Posteingang"
Aktuell haben wir 40k ioBroker Installationen, die alle noch keine solchen Gerätedefinitionen und Aliasse haben. Ebenso neue User kenne sich mit der Idee noch nicht so aus.
Die Idee wäre also hier, dass der Geräte Adapter mittelfristig standardmäßig mit installiert wird. Und wir ändern die UI: Die Standard-Ansicht zeigt nur Aliasse an und alles was keine Aliasse sind landet in einer zweiten Ansicht ... einer Liste wie ein Posteingang. Alle neuen "Device Objekte" von Adaptern werden dort aufgelistet und können zu einem Alias-Gerät gemacht werden. Am Ende ist das natürlich kein "muss" sondern ein Kann ... vllt finden wir auch einen neutraleren Namen als "Posteingang" ;-) Aber alles was hier drin ist kann man auf Klick und mit Wahn eines Gerätetyps und dann zuordnen von States in ein neues Alias-Gerät überführen. Ja die UI wird etwas Tricky das das sinnvoll bedienbar wird, da muss etwas Gehirnschmalz rein. Für einen neuen User kann man das in den Standardprozess mit einbauen: Adapter findet neues Gerät, gehe zu "Geräte" und ordne es zu (wenn er will). :-)
Schlussworte
So, das wäre die große Idee. Jetzt kommt Ihr? Macht das sinn? Ist das eine sinnvolle Richtung?
Bevor wir jetzt aber beginnen über Namen von States o.ä. zu diskutieren, lasst mal mit dem generellen Konzept beginnen. :-) Also bitte diskutiert (noch) nicht zu "Kleinteilig" ...
Nächste Schritte
Sinnvolle nächste Schritte wären genau das erste Set von Gerätetypen und deren States, Pflicht oder Optional und Bezeichnungen zu diskutieren. In meinen Augen sollten wir hier, auch in Richtung des grossen Amazon-v3-Skill-Vorhabens, mit den Geräte-Definitionen von Amazon und Google starten. Im Devices Adapter können wir ein Projekt anlegen. Pro Gerätetype ein Issue und dort einzeln finalisieren. Danach kann man die Implementieren.
Danach würde man die nächsten Schritte finalisieren.
So, jetzt... viel Spass beim (konstruktiven) Feedback geben und mitdiskutieren!
Ingo
@apollon77 Hallo.
Ich bin recht neu in der iobroker Community und wurde in einem andere threat auf Dich aufmerksam gemacht und dachte mir ich schau mal was Du hier so postest.Mir fiel auf, dass Du etwas mit dem ich Probleme habe im Bezug auf den Alias.0 hier glaube ich zum Teil beschrieben hast.
Ich entwickle aktuell eine Visualisierung in React Native und benötige dafür meine Geräte als "Baum", der die Abhängigkeiten der Geräte untereinander, sowie die Struktur zur Darstellung in Bereichen, Etagen, Zimmern, Zonen und Gruppen festlegt.
Ich nutze den Alias Baum, da dieser als einzige Struktur zum Glück eine Abkopplung vom nativen Gerät mit dem Remapping auf eigene States verbindet.Mein Frontend dient quasi nur als "dumme" Anzeige und soll gar nicht festlegen ob ein Gerät nun in der Küche ist oder ob das Bad sich im 2. Obergeschoss befindet.
Das soll über iobroker strukturiert werden.Das Problem was ich dabei habe ist, dass ich im Objektbaum im iobroker dabei an Grenzen stoße. Man bekommt per Simple Api nämlich ausschließlich objekte oder states, bei denen es sich um Datenpunkte handelt.
Sprich die gesamten Strukturinformationen um einen richten Beziehungsbaum aufzubauen gehen verloren.
Die Folder Namen dazwischen werden zwar in die ID aufgenommen sind für mich ohne Context allerdings ziemlich wertlos.Ich habe demnach jetzt einen Objektbaum mit Foldern und Geräten gebaut, bei dem ich in jedem Knoten bis auf die States am Ende noch mal zusätzlich einen Datenpunkt manuell angelegt habe, der quasi als Anker den Typ des Knotens festlegt.
Mein Parser löst diese per "states" Abfrage geholten Informationen dann auf und baut von der Root Node aus einen Abhängigkeitsbaum auf in dem jedes Strukturelement, Gerät und State seinen Platz findet.Das funktioniert so zwar, ist aber natürlich sehr mühsam, wenn man neue Elemente anlegen möchte.
Richtig tricky wird dann, wenn ich Geräte ineinander Verschachteln möchte, z.B. Wenn mehrere Geräte eine Gruppe bilden, in der alle Geräte die gleichen States und das Elterngerät Sammelstates besitzt. Das ist mir so auch gelungen, aber da musste ich dann noch ein Strukturelement dazwischen einbringen, um die Elternstates von den Kindgeräten zu trennen.Ich stecke in dem Thema jetzt noch nicht tief genug drin.
Aber meinst du es wäre möglich, die von mir Beschriebene Funktionalität zu ermöglichen ohne blindlinks X Struktur Werte ala "rooms" anzubieten? Jedes Smarthome hat ja eine andere Struktur. Das ganze nur in Räume einzuteilen ist leider etwas kurz gedacht.Die Struktur den Elementen nachvollziehbar mitzugeben wäre ideal.
Mein Wunschzustand wäre natürlich, wenn sich alle Elemente im alias Baum ineinander verschachteln lassen und diese auf eine frei konfigurierbare Typ Liste mappen lassen. (Etwas ähnliches habe ich jetzt gemacht. Meine "Type Datenpunkte verweise via Alias auf eine Liste im userdata Bereich)Beste Grüße
Chris -
@apollon77 Hallo.
Ich bin recht neu in der iobroker Community und wurde in einem andere threat auf Dich aufmerksam gemacht und dachte mir ich schau mal was Du hier so postest.Mir fiel auf, dass Du etwas mit dem ich Probleme habe im Bezug auf den Alias.0 hier glaube ich zum Teil beschrieben hast.
Ich entwickle aktuell eine Visualisierung in React Native und benötige dafür meine Geräte als "Baum", der die Abhängigkeiten der Geräte untereinander, sowie die Struktur zur Darstellung in Bereichen, Etagen, Zimmern, Zonen und Gruppen festlegt.
Ich nutze den Alias Baum, da dieser als einzige Struktur zum Glück eine Abkopplung vom nativen Gerät mit dem Remapping auf eigene States verbindet.Mein Frontend dient quasi nur als "dumme" Anzeige und soll gar nicht festlegen ob ein Gerät nun in der Küche ist oder ob das Bad sich im 2. Obergeschoss befindet.
Das soll über iobroker strukturiert werden.Das Problem was ich dabei habe ist, dass ich im Objektbaum im iobroker dabei an Grenzen stoße. Man bekommt per Simple Api nämlich ausschließlich objekte oder states, bei denen es sich um Datenpunkte handelt.
Sprich die gesamten Strukturinformationen um einen richten Beziehungsbaum aufzubauen gehen verloren.
Die Folder Namen dazwischen werden zwar in die ID aufgenommen sind für mich ohne Context allerdings ziemlich wertlos.Ich habe demnach jetzt einen Objektbaum mit Foldern und Geräten gebaut, bei dem ich in jedem Knoten bis auf die States am Ende noch mal zusätzlich einen Datenpunkt manuell angelegt habe, der quasi als Anker den Typ des Knotens festlegt.
Mein Parser löst diese per "states" Abfrage geholten Informationen dann auf und baut von der Root Node aus einen Abhängigkeitsbaum auf in dem jedes Strukturelement, Gerät und State seinen Platz findet.Das funktioniert so zwar, ist aber natürlich sehr mühsam, wenn man neue Elemente anlegen möchte.
Richtig tricky wird dann, wenn ich Geräte ineinander Verschachteln möchte, z.B. Wenn mehrere Geräte eine Gruppe bilden, in der alle Geräte die gleichen States und das Elterngerät Sammelstates besitzt. Das ist mir so auch gelungen, aber da musste ich dann noch ein Strukturelement dazwischen einbringen, um die Elternstates von den Kindgeräten zu trennen.Ich stecke in dem Thema jetzt noch nicht tief genug drin.
Aber meinst du es wäre möglich, die von mir Beschriebene Funktionalität zu ermöglichen ohne blindlinks X Struktur Werte ala "rooms" anzubieten? Jedes Smarthome hat ja eine andere Struktur. Das ganze nur in Räume einzuteilen ist leider etwas kurz gedacht.Die Struktur den Elementen nachvollziehbar mitzugeben wäre ideal.
Mein Wunschzustand wäre natürlich, wenn sich alle Elemente im alias Baum ineinander verschachteln lassen und diese auf eine frei konfigurierbare Typ Liste mappen lassen. (Etwas ähnliches habe ich jetzt gemacht. Meine "Type Datenpunkte verweise via Alias auf eine Liste im userdata Bereich)Beste Grüße
Chris@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Ich entwickle aktuell eine Visualisierung in React Native und benötige dafür meine Geräte als "Baum", der die Abhängigkeiten der Geräte untereinander, sowie die Struktur zur Darstellung in Bereichen, Etagen, Zimmern, Zonen und Gruppen festlegt.
soll heissen, du willst eine eigene visu kreieren...?
die struktur kannst du z.b. mit dem alias-adapter nach deiner vorstellung ja fabrizieren.Richtig tricky wird dann, wenn ich Geräte ineinander Verschachteln möchte
wozu was verschachteln? du benutzt die DP, die du brauchst. was willst du da "mappen"?
Jedes Smarthome hat ja eine andere Struktur. Das ganze nur in Räume einzuteilen ist leider etwas kurz gedacht.
wieso nur räume? eben, mit der alias struktur kannst du dir deine eigene zusammenstellung basteln.
entweder ich versteh dich komplett falsch, oder du hast ioB noch nicht verstanden... :) -
@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Ich entwickle aktuell eine Visualisierung in React Native und benötige dafür meine Geräte als "Baum", der die Abhängigkeiten der Geräte untereinander, sowie die Struktur zur Darstellung in Bereichen, Etagen, Zimmern, Zonen und Gruppen festlegt.
soll heissen, du willst eine eigene visu kreieren...?
die struktur kannst du z.b. mit dem alias-adapter nach deiner vorstellung ja fabrizieren.Richtig tricky wird dann, wenn ich Geräte ineinander Verschachteln möchte
wozu was verschachteln? du benutzt die DP, die du brauchst. was willst du da "mappen"?
Jedes Smarthome hat ja eine andere Struktur. Das ganze nur in Räume einzuteilen ist leider etwas kurz gedacht.
wieso nur räume? eben, mit der alias struktur kannst du dir deine eigene zusammenstellung basteln.
entweder ich versteh dich komplett falsch, oder du hast ioB noch nicht verstanden... :)@da_woody
Ich bin dabei eine eigene "visu" zu bauen.
Das Grundgerüst und die ersten Funktionen stehen. siehe: Threat dazuIch vermute Du verstehst meine Ausführungen nicht so ganz.
Selbstverständlich kann ich jede beliebige Struktur mit Ordnern und Geräten und States im kreieren. Im iobroker sieht das dann auch ganz toll aus.
Man kann diese Struktur dann aber wie von mir beschrieben über den simple api adapter nur bedingt exakt abfragen.Mir nützt eine fancy Ordnerstruktur im iobroker gar nichts, wenn ich in der Visualisierung mit aufwendigen Konfigurationen raten muss wo ich z.B.
home.innen.licht.lampen.on
home.innen.og1.keuche.licht.lampe1.ondann strukturell hin sortieren soll, weil die Datenstruktur einfach nicht hergibt, worum es sich bei den Zwischenschritten zum State handelt.
Zur Verschachtelung:
In der von mir beschriebenen Struktur ist es möglich mehrere Lichter z.B. zu einem Gerät zusammenzufassen.Unter
home.innen.og1.keuche.licht.lampengruppe
gibt es dann z.B.
home.innen.og1.keuche.licht.lampengruppe.on
home.innen.og1.keuche.licht.lampengruppe.subDevices.lampe1.on
home.innen.og1.keuche.licht.lampengruppe.subDevices.lampe2.onEin ummappen von states ist doch nur logisch. Warum solle ich weil ich unterschiedliche Leuchtmittel benutzen will die unterschiedlichen Statebezeichnungen so übernehmen?
Da ergibt es sinn diese zu vereinheitlichen und ein mapping zu implementieren.Im Alias Baum lässt sich für jedes Element ein "Typ" eine "Rolle" ein "Zimmer" und eine "Funktion" festlegen.
Durch keine dieser Zuweisungen lassen sich die Elemente sinnvoll anreichern, um eine abfragbare Struktur via Simple API zu erzeugen die auch nur im Ansatz meinen Vorstellungen diesbezüglich entspricht.
Man bekommt nämlich ausschließlich Daten von den State Elementen als Array of Objects. Die Ebenen der Struktur und damit die Eltern Kind Beziehungen gehen komplett verloren.Aber vielleicht hast Du recht. Vielleicht bin ich ja der Depp der einfach iobroker nicht versteht.
Ich bilde mir jedoch ein, dass ich als Sofwareentwickler über die nötige Erfahrung verfüge Daten zu strukturieren. -
Hallo und willkommen in der Entwicklergemeinschaft.
Ok, ich würde nochmal einen Schritt zurück gehen, weil ich denke du vermischst hier Konzepte.
Die "Baumstruktur" der Objekte und states würde ich für Visus für Strukturen wie Räume, Funktionen oder sowas nie verwenden und sind auch nicht dazu gedacht. Die sollen "Geräte"-Strukturen abbilden - alle weiteren Strukturebenen o.ö. kommen aus Adaptern (Logisch oder vom Gerätehersteller indirekt vorgegeben oder sonstwas) oder vom User selbst. Das gilt auch bei Aliases. Ja, hier macht es der Alias Adapter sehr einfach bestimmte Strukturen (Räume/Funktionen) automatisch zu bekommen aber es steht dem User frei.Um aus Strukturen mit Folder/Device/Channel die Zusammengehörigkeit zu ermitteln gibt es die "type detector" Library. Die gibt dir dann eine "Zusammenfassung" und wird schon in material und anderen visus eingesetzt und auch im iot und im Devices Adapter selbst.
Um jetzt andere Logische Ebenen von States bzw Geräten zu definieren hat ioBroker die sog. "Enums". Die beiden Standardenums sind "Räume" und "Funktionen", abgeleitet aus der Homematic Welt. Hier kann man aber einfach für weitere Strukturvarianten weitere Enums anlegen! Material basiert zB auch komplett auf diesen beiden Enums.
Von daher ist es Strukturtechnisch so, dass es Geräte gibt. Geräte (device) können Channels haben die unterschiedliche Datenpunkte der Geräte trennen (zB Sensoren in einem channel und der Schalter im anderen). Das ists auch erstmal. Ein Gerät bzw bis runter zum einzelnen State kann jetzt in verschiedenen Enums sein, was dir verschiedene, aber im ersten Schritt voneinander unabhängige Zuordnungen geben. Räume und Funktionen lassen sich gemeinsam nutzen weil sich die Bedeutung unterscheidet.
Zu guter Letzt ist simple-api bestimmt am ungeeignetsten als Datenbasis dafür - auch weil es nur "pull" kann und nicht alle Daten zugreifbar macht, wie Du bereits festgestellt hast. Hier wäre ich eher bei "socketio" bzw "ws" (=== Pure Websockets) die dir vollständigere APIs über Websockets anbieten, die auch User Authentifizierung und sowas können.
Ich weiss - ich habe vllt nicht auf jede Kleinigkeit deiner Posts oben Stellung bezogen, aber ich schlage vor überdenke es nochmal mit den Infos und dann lass konkrete Fragen gern weiter klären
Ingo
-
Hallo und willkommen in der Entwicklergemeinschaft.
Ok, ich würde nochmal einen Schritt zurück gehen, weil ich denke du vermischst hier Konzepte.
Die "Baumstruktur" der Objekte und states würde ich für Visus für Strukturen wie Räume, Funktionen oder sowas nie verwenden und sind auch nicht dazu gedacht. Die sollen "Geräte"-Strukturen abbilden - alle weiteren Strukturebenen o.ö. kommen aus Adaptern (Logisch oder vom Gerätehersteller indirekt vorgegeben oder sonstwas) oder vom User selbst. Das gilt auch bei Aliases. Ja, hier macht es der Alias Adapter sehr einfach bestimmte Strukturen (Räume/Funktionen) automatisch zu bekommen aber es steht dem User frei.Um aus Strukturen mit Folder/Device/Channel die Zusammengehörigkeit zu ermitteln gibt es die "type detector" Library. Die gibt dir dann eine "Zusammenfassung" und wird schon in material und anderen visus eingesetzt und auch im iot und im Devices Adapter selbst.
Um jetzt andere Logische Ebenen von States bzw Geräten zu definieren hat ioBroker die sog. "Enums". Die beiden Standardenums sind "Räume" und "Funktionen", abgeleitet aus der Homematic Welt. Hier kann man aber einfach für weitere Strukturvarianten weitere Enums anlegen! Material basiert zB auch komplett auf diesen beiden Enums.
Von daher ist es Strukturtechnisch so, dass es Geräte gibt. Geräte (device) können Channels haben die unterschiedliche Datenpunkte der Geräte trennen (zB Sensoren in einem channel und der Schalter im anderen). Das ists auch erstmal. Ein Gerät bzw bis runter zum einzelnen State kann jetzt in verschiedenen Enums sein, was dir verschiedene, aber im ersten Schritt voneinander unabhängige Zuordnungen geben. Räume und Funktionen lassen sich gemeinsam nutzen weil sich die Bedeutung unterscheidet.
Zu guter Letzt ist simple-api bestimmt am ungeeignetsten als Datenbasis dafür - auch weil es nur "pull" kann und nicht alle Daten zugreifbar macht, wie Du bereits festgestellt hast. Hier wäre ich eher bei "socketio" bzw "ws" (=== Pure Websockets) die dir vollständigere APIs über Websockets anbieten, die auch User Authentifizierung und sowas können.
Ich weiss - ich habe vllt nicht auf jede Kleinigkeit deiner Posts oben Stellung bezogen, aber ich schlage vor überdenke es nochmal mit den Infos und dann lass konkrete Fragen gern weiter klären
Ingo
Du hast ihn nicht direkt angesprochen.
-
Du hast ihn nicht direkt angesprochen.
@ofbeqnpolkkl6mby5e13 Muss man das? Auch wenn off topic für hier ... Wenn jemand in einem Thread postet mit nem Thema ist meine Annahme das er es auch monitored obs Antworten gab :-)
-
@ofbeqnpolkkl6mby5e13 Muss man das? Auch wenn off topic für hier ... Wenn jemand in einem Thread postet mit nem Thema ist meine Annahme das er es auch monitored obs Antworten gab :-)
Nein, muss man natürlich nicht...:face_with_rolling_eyes:
-
@da_woody
Ich bin dabei eine eigene "visu" zu bauen.
Das Grundgerüst und die ersten Funktionen stehen. siehe: Threat dazuIch vermute Du verstehst meine Ausführungen nicht so ganz.
Selbstverständlich kann ich jede beliebige Struktur mit Ordnern und Geräten und States im kreieren. Im iobroker sieht das dann auch ganz toll aus.
Man kann diese Struktur dann aber wie von mir beschrieben über den simple api adapter nur bedingt exakt abfragen.Mir nützt eine fancy Ordnerstruktur im iobroker gar nichts, wenn ich in der Visualisierung mit aufwendigen Konfigurationen raten muss wo ich z.B.
home.innen.licht.lampen.on
home.innen.og1.keuche.licht.lampe1.ondann strukturell hin sortieren soll, weil die Datenstruktur einfach nicht hergibt, worum es sich bei den Zwischenschritten zum State handelt.
Zur Verschachtelung:
In der von mir beschriebenen Struktur ist es möglich mehrere Lichter z.B. zu einem Gerät zusammenzufassen.Unter
home.innen.og1.keuche.licht.lampengruppe
gibt es dann z.B.
home.innen.og1.keuche.licht.lampengruppe.on
home.innen.og1.keuche.licht.lampengruppe.subDevices.lampe1.on
home.innen.og1.keuche.licht.lampengruppe.subDevices.lampe2.onEin ummappen von states ist doch nur logisch. Warum solle ich weil ich unterschiedliche Leuchtmittel benutzen will die unterschiedlichen Statebezeichnungen so übernehmen?
Da ergibt es sinn diese zu vereinheitlichen und ein mapping zu implementieren.Im Alias Baum lässt sich für jedes Element ein "Typ" eine "Rolle" ein "Zimmer" und eine "Funktion" festlegen.
Durch keine dieser Zuweisungen lassen sich die Elemente sinnvoll anreichern, um eine abfragbare Struktur via Simple API zu erzeugen die auch nur im Ansatz meinen Vorstellungen diesbezüglich entspricht.
Man bekommt nämlich ausschließlich Daten von den State Elementen als Array of Objects. Die Ebenen der Struktur und damit die Eltern Kind Beziehungen gehen komplett verloren.Aber vielleicht hast Du recht. Vielleicht bin ich ja der Depp der einfach iobroker nicht versteht.
Ich bilde mir jedoch ein, dass ich als Sofwareentwickler über die nötige Erfahrung verfüge Daten zu strukturieren.@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Aber vielleicht hast Du recht. Vielleicht bin ich ja der Depp der einfach iobroker nicht versteht.
oi, das hab ich nicht gesagt! im gegenteil, chapeau mit welchem elan du dich da reinknierst und als entwickler hast du natürlich deine eigene vorstellungen. allerdings hab ich das gefühl, daß du das rad neu erfinden willst. das ist aber absolut nicht böse gemeint. den anderen tread hab ich erst nach meiner AW an dich gesehn.
vllt ist dir nach @apollon77 aussage einiges klarer geworden. :) -
Hallo und willkommen in der Entwicklergemeinschaft.
Ok, ich würde nochmal einen Schritt zurück gehen, weil ich denke du vermischst hier Konzepte.
Die "Baumstruktur" der Objekte und states würde ich für Visus für Strukturen wie Räume, Funktionen oder sowas nie verwenden und sind auch nicht dazu gedacht. Die sollen "Geräte"-Strukturen abbilden - alle weiteren Strukturebenen o.ö. kommen aus Adaptern (Logisch oder vom Gerätehersteller indirekt vorgegeben oder sonstwas) oder vom User selbst. Das gilt auch bei Aliases. Ja, hier macht es der Alias Adapter sehr einfach bestimmte Strukturen (Räume/Funktionen) automatisch zu bekommen aber es steht dem User frei.Um aus Strukturen mit Folder/Device/Channel die Zusammengehörigkeit zu ermitteln gibt es die "type detector" Library. Die gibt dir dann eine "Zusammenfassung" und wird schon in material und anderen visus eingesetzt und auch im iot und im Devices Adapter selbst.
Um jetzt andere Logische Ebenen von States bzw Geräten zu definieren hat ioBroker die sog. "Enums". Die beiden Standardenums sind "Räume" und "Funktionen", abgeleitet aus der Homematic Welt. Hier kann man aber einfach für weitere Strukturvarianten weitere Enums anlegen! Material basiert zB auch komplett auf diesen beiden Enums.
Von daher ist es Strukturtechnisch so, dass es Geräte gibt. Geräte (device) können Channels haben die unterschiedliche Datenpunkte der Geräte trennen (zB Sensoren in einem channel und der Schalter im anderen). Das ists auch erstmal. Ein Gerät bzw bis runter zum einzelnen State kann jetzt in verschiedenen Enums sein, was dir verschiedene, aber im ersten Schritt voneinander unabhängige Zuordnungen geben. Räume und Funktionen lassen sich gemeinsam nutzen weil sich die Bedeutung unterscheidet.
Zu guter Letzt ist simple-api bestimmt am ungeeignetsten als Datenbasis dafür - auch weil es nur "pull" kann und nicht alle Daten zugreifbar macht, wie Du bereits festgestellt hast. Hier wäre ich eher bei "socketio" bzw "ws" (=== Pure Websockets) die dir vollständigere APIs über Websockets anbieten, die auch User Authentifizierung und sowas können.
Ich weiss - ich habe vllt nicht auf jede Kleinigkeit deiner Posts oben Stellung bezogen, aber ich schlage vor überdenke es nochmal mit den Infos und dann lass konkrete Fragen gern weiter klären
Ingo
@apollon77 Hallo und Danke!
Ok. Da hab ich so wie es aussieht einiges grundlegend falsch verstanden.
Ich war bereits früh in der Entwicklungsphase meines Projekts über die Enums gestolpert.Ich hatte zu dem Zeitpunkt bereits versucht über eigene Enums meine Struktur zu schaffen und war etwas verdutzt, als ich feststellte, dass mir diese dann in den Konfigurationen gar nicht angeboten werden. Man kann ohne manuelle Objekt Editierung ja ausschließlich "rooms" und "functions" zuordnen. Auch werden weitere Enums nicht in der Spaltenkonfiguration angeboten.
Die Bezeichnung "rooms" hatte in meiner Gedankenwelt die Erwartungshaltung ausgelöst, hier nur Räume einzusortieren.
Jetzt nach näherer Betrachtung und Deinen Informationen fiel mir nun auf, dass das gar nicht im Sinne des Erfinders ist. Man kann diesen Bereich ja quasi als Strukturgenerator verstehen, in dem man selbstverständlich auch Bereiche, Etagen, Räume und alle weiteren Ebenen einer Struktur unterbringen kann.
Wenn ich das mal so sagen darf ist die Bezeichnung "rooms" da leider sehr irreführend :)Ich bin dann jetzt tatsächlich zuversichtlich, mit Hilfe von Enums, Channels und Devices meine Struktur abbilden zu können.
Tja Simple Api war für mich ein Notbehelf, um überhaupt erst einmal an die Daten in meiner ja im Alias Baum umgesetzten Struktur zu gelangen. Ich pulle darüber auch nur initial beim laden der App und bereite alles mit einem Parser auf.
Die weitere Kommunikation läuft dann via mqtt. Das war für mich auch auf die schnelle die einfachste Lösung Daten strukturiert und performant zwischen App und iobroker per "push" auszutauschen.
Ich werde mich mal mit Websockets auseinandersetzen. Kannst Du mir da eine Dokumentation oder gar ein Projekt ans Herz legen mit Hilfe dessen ich gut nachvollziehen kann, wie man das für die Kommunikation mit iobroker sauber implementiert?Vielen Dank für die ausführliche Antwort
Beste Grüße
Chris -
@apollon77 Hallo und Danke!
Ok. Da hab ich so wie es aussieht einiges grundlegend falsch verstanden.
Ich war bereits früh in der Entwicklungsphase meines Projekts über die Enums gestolpert.Ich hatte zu dem Zeitpunkt bereits versucht über eigene Enums meine Struktur zu schaffen und war etwas verdutzt, als ich feststellte, dass mir diese dann in den Konfigurationen gar nicht angeboten werden. Man kann ohne manuelle Objekt Editierung ja ausschließlich "rooms" und "functions" zuordnen. Auch werden weitere Enums nicht in der Spaltenkonfiguration angeboten.
Die Bezeichnung "rooms" hatte in meiner Gedankenwelt die Erwartungshaltung ausgelöst, hier nur Räume einzusortieren.
Jetzt nach näherer Betrachtung und Deinen Informationen fiel mir nun auf, dass das gar nicht im Sinne des Erfinders ist. Man kann diesen Bereich ja quasi als Strukturgenerator verstehen, in dem man selbstverständlich auch Bereiche, Etagen, Räume und alle weiteren Ebenen einer Struktur unterbringen kann.
Wenn ich das mal so sagen darf ist die Bezeichnung "rooms" da leider sehr irreführend :)Ich bin dann jetzt tatsächlich zuversichtlich, mit Hilfe von Enums, Channels und Devices meine Struktur abbilden zu können.
Tja Simple Api war für mich ein Notbehelf, um überhaupt erst einmal an die Daten in meiner ja im Alias Baum umgesetzten Struktur zu gelangen. Ich pulle darüber auch nur initial beim laden der App und bereite alles mit einem Parser auf.
Die weitere Kommunikation läuft dann via mqtt. Das war für mich auch auf die schnelle die einfachste Lösung Daten strukturiert und performant zwischen App und iobroker per "push" auszutauschen.
Ich werde mich mal mit Websockets auseinandersetzen. Kannst Du mir da eine Dokumentation oder gar ein Projekt ans Herz legen mit Hilfe dessen ich gut nachvollziehen kann, wie man das für die Kommunikation mit iobroker sauber implementiert?Vielen Dank für die ausführliche Antwort
Beste Grüße
Chris@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Ich hatte zu dem Zeitpunkt bereits versucht über eigene Enums meine Struktur zu schaffen und war etwas verdutzt, als ich feststellte, dass mir diese dann in den Konfigurationen gar nicht angeboten werden. Man kann ohne manuelle Objekt Editierung ja ausschließlich "rooms" und "functions" zuordnen. Auch werden weitere Enums nicht in der Spaltenkonfiguration angeboten.
Good catch ... mach doch mal ein Admin issue ... vllt kann man sich ja was überlegen wie man das trotz platzknappheit unterbringen kann :-)
Wenn ich das mal so sagen darf ist die Bezeichnung "rooms" da leider sehr irreführend 🙂
Valide ... wie gesagt "Herkunft ist die Homematic ecke" ... Das nachträglich zu ändern ist schwierig :-)
Ich bin dann jetzt tatsächlich zuversichtlich, mit Hilfe von Enums, Channels und Devices meine Struktur abbilden zu können.
Ich denke aber es macht sinn generell auf den typedetector zu setzen, dann sparst Du Dir das manuelle parsen. Ich hab die Tage vor ein Demo projekt zu machen um zu zeigen wie das zu nutzen ist und auf der Basis können wir erweitern.
Ich werde mich mal mit Websockets auseinandersetzen. Kannst Du mir da eine Dokumentation oder gar ein Projekt ans Herz legen mit Hilfe dessen ich gut nachvollziehen kann, wie man das für die Kommunikation mit iobroker sauber implementiert?
Es gibt den https://github.com/ioBroker/ioBroker.ws.client der eine Client implementierung für pure Websockets ist. Die Funktionen sind faktisch die gleichen wie bei https://github.com/ioBroker/ioBroker.socketio/
-
@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Ich hatte zu dem Zeitpunkt bereits versucht über eigene Enums meine Struktur zu schaffen und war etwas verdutzt, als ich feststellte, dass mir diese dann in den Konfigurationen gar nicht angeboten werden. Man kann ohne manuelle Objekt Editierung ja ausschließlich "rooms" und "functions" zuordnen. Auch werden weitere Enums nicht in der Spaltenkonfiguration angeboten.
Good catch ... mach doch mal ein Admin issue ... vllt kann man sich ja was überlegen wie man das trotz platzknappheit unterbringen kann :-)
Wenn ich das mal so sagen darf ist die Bezeichnung "rooms" da leider sehr irreführend 🙂
Valide ... wie gesagt "Herkunft ist die Homematic ecke" ... Das nachträglich zu ändern ist schwierig :-)
Ich bin dann jetzt tatsächlich zuversichtlich, mit Hilfe von Enums, Channels und Devices meine Struktur abbilden zu können.
Ich denke aber es macht sinn generell auf den typedetector zu setzen, dann sparst Du Dir das manuelle parsen. Ich hab die Tage vor ein Demo projekt zu machen um zu zeigen wie das zu nutzen ist und auf der Basis können wir erweitern.
Ich werde mich mal mit Websockets auseinandersetzen. Kannst Du mir da eine Dokumentation oder gar ein Projekt ans Herz legen mit Hilfe dessen ich gut nachvollziehen kann, wie man das für die Kommunikation mit iobroker sauber implementiert?
Es gibt den https://github.com/ioBroker/ioBroker.ws.client der eine Client implementierung für pure Websockets ist. Die Funktionen sind faktisch die gleichen wie bei https://github.com/ioBroker/ioBroker.socketio/
@apollon77
Ich verstehe. Tja wenn man sich mal entschieden hat etwas so zu benennen ist es im Nachgang immer schwer :)Ok großartig. Ich schau mit den ws.client mal an und bin hinsichtlich des typedetectors gespannt :)
Beides wird mein Projekt sicher um einiges Besser machen.Sag mal wo ich Dich grad habe.... kannst Du mir eine gute Quelle empfehlen im Bezug auf Adapterentwicklung? Ich möchte mir das mal ansehen und es wenn dann gleich richtig machen.
Ideal wäre natürlich, wenn ich mich dafür nicht durch Dokumentationen wühlen muss. Es geht mir erstmal nur um ein Grundverständnis zum Aufbau und den Rahmenbedingungen. -
@apollon77
Ich verstehe. Tja wenn man sich mal entschieden hat etwas so zu benennen ist es im Nachgang immer schwer :)Ok großartig. Ich schau mit den ws.client mal an und bin hinsichtlich des typedetectors gespannt :)
Beides wird mein Projekt sicher um einiges Besser machen.Sag mal wo ich Dich grad habe.... kannst Du mir eine gute Quelle empfehlen im Bezug auf Adapterentwicklung? Ich möchte mir das mal ansehen und es wenn dann gleich richtig machen.
Ideal wäre natürlich, wenn ich mich dafür nicht durch Dokumentationen wühlen muss. Es geht mir erstmal nur um ein Grundverständnis zum Aufbau und den Rahmenbedingungen.@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
kannst Du mir eine gute Quelle empfehlen im Bezug auf Adapterentwicklung? Ich möchte mir das mal ansehen und es wenn dann gleich richtig machen.
Ideal wäre natürlich, wenn ich mich dafür nicht durch Dokumentationen wühlen muss. Es geht mir erstmal nur um ein Grundverständnis zum Aufbau und den Rahmenbedingungen.Es befindet sich eine neue Entwicklerdoku in Arbeit, ist aber noch am Anfang, von daher fürchte ich das einfachste ist aktuell "bestandscode anschauen" bzw in die Discord/Telegram Gruppe kommen und dort andere Devs mit Fragen löchern :-)
generell zum Adapter erstellen in jedem Fall den Adapter creator nehmen. DIie Resourcen die wie schon haben sind unter https://www.iobroker.dev auch zusammengefasst -
@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
kannst Du mir eine gute Quelle empfehlen im Bezug auf Adapterentwicklung? Ich möchte mir das mal ansehen und es wenn dann gleich richtig machen.
Ideal wäre natürlich, wenn ich mich dafür nicht durch Dokumentationen wühlen muss. Es geht mir erstmal nur um ein Grundverständnis zum Aufbau und den Rahmenbedingungen.Es befindet sich eine neue Entwicklerdoku in Arbeit, ist aber noch am Anfang, von daher fürchte ich das einfachste ist aktuell "bestandscode anschauen" bzw in die Discord/Telegram Gruppe kommen und dort andere Devs mit Fragen löchern :-)
generell zum Adapter erstellen in jedem Fall den Adapter creator nehmen. DIie Resourcen die wie schon haben sind unter https://www.iobroker.dev auch zusammengefasst@apollon77
Ok recht herzlichen Dank!Beste Grüße aus Berlin!
-
@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Ich hatte zu dem Zeitpunkt bereits versucht über eigene Enums meine Struktur zu schaffen und war etwas verdutzt, als ich feststellte, dass mir diese dann in den Konfigurationen gar nicht angeboten werden. Man kann ohne manuelle Objekt Editierung ja ausschließlich "rooms" und "functions" zuordnen. Auch werden weitere Enums nicht in der Spaltenkonfiguration angeboten.
Good catch ... mach doch mal ein Admin issue ... vllt kann man sich ja was überlegen wie man das trotz platzknappheit unterbringen kann :-)
Wenn ich das mal so sagen darf ist die Bezeichnung "rooms" da leider sehr irreführend 🙂
Valide ... wie gesagt "Herkunft ist die Homematic ecke" ... Das nachträglich zu ändern ist schwierig :-)
Ich bin dann jetzt tatsächlich zuversichtlich, mit Hilfe von Enums, Channels und Devices meine Struktur abbilden zu können.
Ich denke aber es macht sinn generell auf den typedetector zu setzen, dann sparst Du Dir das manuelle parsen. Ich hab die Tage vor ein Demo projekt zu machen um zu zeigen wie das zu nutzen ist und auf der Basis können wir erweitern.
Ich werde mich mal mit Websockets auseinandersetzen. Kannst Du mir da eine Dokumentation oder gar ein Projekt ans Herz legen mit Hilfe dessen ich gut nachvollziehen kann, wie man das für die Kommunikation mit iobroker sauber implementiert?
Es gibt den https://github.com/ioBroker/ioBroker.ws.client der eine Client implementierung für pure Websockets ist. Die Funktionen sind faktisch die gleichen wie bei https://github.com/ioBroker/ioBroker.socketio/
@apollon77
So. Irgendwie machen mich meine Erkenntnisse bisher nicht glücklich :)Thema Websockets:
Konnte die für iobroker angepassten socket Bibliotheken leider nicht so recht zum laufen bringen, weil sie wohl auf den Betrieb in einem Adapter hin vorgesehen sind.
Da ich aktuell keinen Adapter schreibe, hatte ich damit mehr Probleme als dass ich da voran gekommen wäre :)Ich habe mir was passendes im Netz besorgt und dann mal rudimentär ein funktionierendes Modul erstellt, von dem aus ich erfolgreich Daten via Websocket vom iobroker holen kann.
Leider bekomme ich auch hier rüber nicht die Daten die ich mir wünsche.Mit
socket.emit("getObject", 'alias.0.meinRoot', (err, obj) => { console.log(obj) }Lässt sich ja nur ein Objekt abfragen.
Mit:
socket.emit("getObjects", (err, obj) => { console.log(obj) }Bekomme ich alle Objekte. Das sind aber auch wieder nur die IDs dabei die gleichzeitig States sind. Genau so wie ich sie auch über simple API bekomme.
Wenn ich via Simple API nun explizit type "folder" abfrage bekomme ich die neu eingezogenen Enums mit.
Per Websocket Abfrage habe ich dafür noch keine Lösung gefunden.Ich habe etwas rum geschaut und gesehen, dass die ObjectBrowser Component des "adapter-react-v5" Repositories mit seiner Funktion "buildTree" etwas ganz ähnliches macht, was ich bei mir als Parser einsetze um meine simple api Abfrage aufzubereiten. Wie kommt der denn an seine Daten? Der stellt die Folders ja auch als Folders dar + Enums. Er verwendet so wie ich das sehe "getAllObjects" via Socket. Aber ich konnte da beim besten Willen keine Folders entdecken. :(
Vielleicht fehlt mir da noch ein Puzzleteil aber für das Abfragen der Objektstruktur erschließt sich mir der Vorteil Websockets zu benutzen daher noch nicht.
Auch von daher, dass man auf diesem Wege ungefiltert alle Objekte bekommt und dann noch drüber filtern muss damit man nicht von Objekten erschlagen wird :)
Ein Filtern nach "typ" oder mit "pattern" wäre hier auch schön...Gibts es da ne Möglichkeit?Für State und Objekt Updates na klar. Das werd ich dann wohl auch noch implementieren. Bin ja bisher den Umweg über den MQTT Adapter gegangen und hab meine Updates dann in einen MQTT Channel geschrieben um die an meine Client Apps raus zu geben.
Type Detektor
Der ist so wie ich das verstehe für meinen Zweck nicht wirklich nötig.
Dafür erstelle ich mir ja Verweise auf meine "echten" Devices. Ich nehme auch immer nur die States eines Gerätes mit die ich wirklich benötige.
Ich weiss zu dem Zeitpunkt quasi immer, welches Gerät in meiner Visualisierung welchen Repräsentanten im iobroker besitzt und kenne daher auch Typ und Eigenschaften.
Anhand der States zu erkennen, um was für ein Gerät es sich handelt ist daher überflüssig.Tja zu guter letzt muss ich mich entschuldigen, dass ich Dich auf diesem Wege noch mal behellige.
Ich werde vermutlich in Zukunft lieber mal auf Discord oder Telegram ausweichen. Ich wollte hier aber direkt noch mal anknüpfen und nicht dort dann meine Geschichte noch mal runter beten :)Beste Grüße
Chris. -
@apollon77
So. Irgendwie machen mich meine Erkenntnisse bisher nicht glücklich :)Thema Websockets:
Konnte die für iobroker angepassten socket Bibliotheken leider nicht so recht zum laufen bringen, weil sie wohl auf den Betrieb in einem Adapter hin vorgesehen sind.
Da ich aktuell keinen Adapter schreibe, hatte ich damit mehr Probleme als dass ich da voran gekommen wäre :)Ich habe mir was passendes im Netz besorgt und dann mal rudimentär ein funktionierendes Modul erstellt, von dem aus ich erfolgreich Daten via Websocket vom iobroker holen kann.
Leider bekomme ich auch hier rüber nicht die Daten die ich mir wünsche.Mit
socket.emit("getObject", 'alias.0.meinRoot', (err, obj) => { console.log(obj) }Lässt sich ja nur ein Objekt abfragen.
Mit:
socket.emit("getObjects", (err, obj) => { console.log(obj) }Bekomme ich alle Objekte. Das sind aber auch wieder nur die IDs dabei die gleichzeitig States sind. Genau so wie ich sie auch über simple API bekomme.
Wenn ich via Simple API nun explizit type "folder" abfrage bekomme ich die neu eingezogenen Enums mit.
Per Websocket Abfrage habe ich dafür noch keine Lösung gefunden.Ich habe etwas rum geschaut und gesehen, dass die ObjectBrowser Component des "adapter-react-v5" Repositories mit seiner Funktion "buildTree" etwas ganz ähnliches macht, was ich bei mir als Parser einsetze um meine simple api Abfrage aufzubereiten. Wie kommt der denn an seine Daten? Der stellt die Folders ja auch als Folders dar + Enums. Er verwendet so wie ich das sehe "getAllObjects" via Socket. Aber ich konnte da beim besten Willen keine Folders entdecken. :(
Vielleicht fehlt mir da noch ein Puzzleteil aber für das Abfragen der Objektstruktur erschließt sich mir der Vorteil Websockets zu benutzen daher noch nicht.
Auch von daher, dass man auf diesem Wege ungefiltert alle Objekte bekommt und dann noch drüber filtern muss damit man nicht von Objekten erschlagen wird :)
Ein Filtern nach "typ" oder mit "pattern" wäre hier auch schön...Gibts es da ne Möglichkeit?Für State und Objekt Updates na klar. Das werd ich dann wohl auch noch implementieren. Bin ja bisher den Umweg über den MQTT Adapter gegangen und hab meine Updates dann in einen MQTT Channel geschrieben um die an meine Client Apps raus zu geben.
Type Detektor
Der ist so wie ich das verstehe für meinen Zweck nicht wirklich nötig.
Dafür erstelle ich mir ja Verweise auf meine "echten" Devices. Ich nehme auch immer nur die States eines Gerätes mit die ich wirklich benötige.
Ich weiss zu dem Zeitpunkt quasi immer, welches Gerät in meiner Visualisierung welchen Repräsentanten im iobroker besitzt und kenne daher auch Typ und Eigenschaften.
Anhand der States zu erkennen, um was für ein Gerät es sich handelt ist daher überflüssig.Tja zu guter letzt muss ich mich entschuldigen, dass ich Dich auf diesem Wege noch mal behellige.
Ich werde vermutlich in Zukunft lieber mal auf Discord oder Telegram ausweichen. Ich wollte hier aber direkt noch mal anknüpfen und nicht dort dann meine Geschichte noch mal runter beten :)Beste Grüße
Chris.@tyantreides Aktuell gibt es quasi zwei Arten von Visualisierungen bei ioBroker. Einmal die die eine manuelle Konfig vom User erfordern wo er genau sagt welches Gerät oder Datenpunkt oder sonstwas wohin kommen soll. Die haben dazu Schattenstrukturen (also Objekte oder Daten in nem JSON oder sowas) die aus einem Konfigtool entstehen oder Konfiguration als "Custom" Daten an den ausgewählten Objekten.
Daneben gibt es die Tools die versuchen weitestgehend automatisch zu arbeiten. Diese lesen alle Objekte und wenden dann den Type Detector an um aus der "großen Objektmasse" zusammen mit den Enums die Geräte und ihre Enum Zuordnungen zu erhalten und nutzen das. Potentielle Sondersettings einzelner Geräte werden dann wieder am ehestens in den Custom-Daten der Objekte gespeichert und so gemerkt.
Nun zu dem was ich als Fragen aus dem obigen text verstehe (und bin ehrlich ... ICH bin jetzt nicht der Visu experte). Es ist korrekt das socketio/ws aktuellkeine dedizierten Methoden für Enums bieten aber die enums sind am Ende auch nur objekte die einen namen haben der mit enum. beginnt und haben ein "common.members" array wo die Members drin stehen und haben einen (pot Multilanguage) Namen. Also die Daten findest Du in den Objekten.
Adapter-React nutzt auch Websockets - in dem Fall direkt zum Admin, wo noch ein paar mehr Funktionen bereitstehen - wenn Bedarf besteht das auch in socketio/ws zu haben dann kann man das erweitern.
Folder sind am Ende auch nur Objekte - aber es kann hier Device/Channel oder Folder sein und ja es gibt einige Adapter die noch nicht sauber alle Strukturen anlegen was Objekte angeht, also am Ende die Objekt-ID and den "Punkten" splitten weil durch diese in ioBroker die verschiedenen Ebenen abgebildet werden. Adapter.Instance.Ebene1.Ebene2.Ebene3.State ...
Objekte spezificher Abfragen geht mit getObjectView, damit kannst du zB mit "getObjectView" und den Parametern "system", "folder" alle folder abfragen ;-) Alle Standard Views sind in https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/io-package.json#L117-L181 definiert.
Was die Kommunikation angeht - Forum hat seine Berechtigung meiner Meinunge nach wenn es "Länger" bzw "Ausführlicher" wird. Discord/Telegram ist für mich eher "hab da mal ne kurze Frage" oder zur einfacheren Diskussion ...
Ich werde aber mal deine Fragen in eigenen Thread rausgliedern das wir das Thema hier nicht zu sehr verwässern..
-
@tyantreides Aktuell gibt es quasi zwei Arten von Visualisierungen bei ioBroker. Einmal die die eine manuelle Konfig vom User erfordern wo er genau sagt welches Gerät oder Datenpunkt oder sonstwas wohin kommen soll. Die haben dazu Schattenstrukturen (also Objekte oder Daten in nem JSON oder sowas) die aus einem Konfigtool entstehen oder Konfiguration als "Custom" Daten an den ausgewählten Objekten.
Daneben gibt es die Tools die versuchen weitestgehend automatisch zu arbeiten. Diese lesen alle Objekte und wenden dann den Type Detector an um aus der "großen Objektmasse" zusammen mit den Enums die Geräte und ihre Enum Zuordnungen zu erhalten und nutzen das. Potentielle Sondersettings einzelner Geräte werden dann wieder am ehestens in den Custom-Daten der Objekte gespeichert und so gemerkt.
Nun zu dem was ich als Fragen aus dem obigen text verstehe (und bin ehrlich ... ICH bin jetzt nicht der Visu experte). Es ist korrekt das socketio/ws aktuellkeine dedizierten Methoden für Enums bieten aber die enums sind am Ende auch nur objekte die einen namen haben der mit enum. beginnt und haben ein "common.members" array wo die Members drin stehen und haben einen (pot Multilanguage) Namen. Also die Daten findest Du in den Objekten.
Adapter-React nutzt auch Websockets - in dem Fall direkt zum Admin, wo noch ein paar mehr Funktionen bereitstehen - wenn Bedarf besteht das auch in socketio/ws zu haben dann kann man das erweitern.
Folder sind am Ende auch nur Objekte - aber es kann hier Device/Channel oder Folder sein und ja es gibt einige Adapter die noch nicht sauber alle Strukturen anlegen was Objekte angeht, also am Ende die Objekt-ID and den "Punkten" splitten weil durch diese in ioBroker die verschiedenen Ebenen abgebildet werden. Adapter.Instance.Ebene1.Ebene2.Ebene3.State ...
Objekte spezificher Abfragen geht mit getObjectView, damit kannst du zB mit "getObjectView" und den Parametern "system", "folder" alle folder abfragen ;-) Alle Standard Views sind in https://github.com/ioBroker/ioBroker.js-controller/blob/master/packages/controller/io-package.json#L117-L181 definiert.
Was die Kommunikation angeht - Forum hat seine Berechtigung meiner Meinunge nach wenn es "Länger" bzw "Ausführlicher" wird. Discord/Telegram ist für mich eher "hab da mal ne kurze Frage" oder zur einfacheren Diskussion ...
Ich werde aber mal deine Fragen in eigenen Thread rausgliedern das wir das Thema hier nicht zu sehr verwässern..
Hallo,
ja ich hätte die "Befragung" längst in einen neuen Thread ausgelagert. Leider kann ich im Bereich "Entwicklung" keine Threats öffnen. Habe den im "Richtlinien" Post angesprochenen Moderator bereits angeschrieben, aber bisher noch keine Antwort erhalten.
Ich verstehe. die Daten quasi per "Parser" zu erkennen war für mich bis jetzt nicht so das Ziel. Meine App soll ja keinen globalen Ansatz zur Unterstützung aller Adapter mit ihren Geräten liefern, sondern einen kontrollierten Ausschnitt zeigen.
Daher auch mein Ansatz über den Alias Adapter. Darüber ließ sich die für mich am besten passende Struktur realisieren und ich habe ganz nebenbei noch den Vorteil der Austauschbarkeit der Geräte, weil ich immer auf für die App angepasste Datenpunkte zeigen kann. Somit spielt für mich z.B. bei einem Temperatursensor gar keine Rolle ob der nun von Aquara oder etwas anderem kommt.Die Funktion "getObjectView" hatte ich gesehen und auch direkt ausprobiert. Da bekam ich von meiner Instanz leider gar keine Daten zurück. Aber es kann sein, dass ich da mit den Parametern was falsch gesetzt habe.
Ich werd mir das noch mal anschauen.
Ich kämpfe zurzeit auch gerade mit der Inbetriebnahme einer DEV Umgebung für Adapter.
Also wenn ich BETA Tester für diesen Prozess wäre hätte ich einiges zu meckern :)Man findet ja gefühlt dutzende Anleitungen dazu. Leider ist keine davon wirklich gut.
Die Online Adapter Erstellung scheitert mit einem fatalen Fehler...
ein "out of the Box" Adapter Template habe ich unter all den Sachen die ich dazu bei github fand auch nicht finden können.
Naja ich stückle mir aktuell aus verschiedenen Anleitungen und Templates was zusammen...
Mal sehen wo die Reise da hin geht :dizzy_face:Danke für die Informationen.
Wenn Du irgendwie dafür sorgen kannst, dass ich im Entwickler Bereich was posten kann erstelle ich gern dort ein oder zwei threats um an weitere Infos zu kommen.Beste Grüße
-
Hi,
Daher auch mein Ansatz über den Alias Adapter.
Zur Info: Der Alias Adapter (du Meinst "Devices Adapter" oder ?) hilft nur den Usern einfach sinnvolle Geräte in "alias.0" anzulegen. Der Namespace an sich ist generisch - das können also auch User direkt Objekte und Strukturen anlegen. Also das darf nicht nur der Adapter in diesem Sonderfall!
Ich kämpfe zurzeit auch gerade mit der Inbetriebnahme einer DEV Umgebung für Adapter.
Versuch mal den dev-server ... https://github.com/ioBroker/dev-server
Es gibt aktuelle eine Gruppe Entwickler die an einer neuen Dev-Doku arbeiten. Ist aber nich in Arbeit. Feedback bzw Issues was rein muss gern unter https://github.com/ioBroker/dev-docs
Die Online Adapter Erstellung scheitert mit einem fatalen Fehler...
Das ist Blöd. Du meinst im Dev-Portal? Dann bitte unter https://github.com/ioBroker/dev-portal/issues ein Issue anlegen. den AdapterCreator gibts aber auch auf Kommandozeile - nimm den https://github.com/ioBroker/create-adapter . Einige Beispiels die der Creator so erzeugt gibts unter https://github.com/ioBroker/ioBroker.example (aber nimm besser den CLI creator)
Ingo
-
Hallo,
ja ich hätte die "Befragung" längst in einen neuen Thread ausgelagert. Leider kann ich im Bereich "Entwicklung" keine Threats öffnen. Habe den im "Richtlinien" Post angesprochenen Moderator bereits angeschrieben, aber bisher noch keine Antwort erhalten.
Ich verstehe. die Daten quasi per "Parser" zu erkennen war für mich bis jetzt nicht so das Ziel. Meine App soll ja keinen globalen Ansatz zur Unterstützung aller Adapter mit ihren Geräten liefern, sondern einen kontrollierten Ausschnitt zeigen.
Daher auch mein Ansatz über den Alias Adapter. Darüber ließ sich die für mich am besten passende Struktur realisieren und ich habe ganz nebenbei noch den Vorteil der Austauschbarkeit der Geräte, weil ich immer auf für die App angepasste Datenpunkte zeigen kann. Somit spielt für mich z.B. bei einem Temperatursensor gar keine Rolle ob der nun von Aquara oder etwas anderem kommt.Die Funktion "getObjectView" hatte ich gesehen und auch direkt ausprobiert. Da bekam ich von meiner Instanz leider gar keine Daten zurück. Aber es kann sein, dass ich da mit den Parametern was falsch gesetzt habe.
Ich werd mir das noch mal anschauen.
Ich kämpfe zurzeit auch gerade mit der Inbetriebnahme einer DEV Umgebung für Adapter.
Also wenn ich BETA Tester für diesen Prozess wäre hätte ich einiges zu meckern :)Man findet ja gefühlt dutzende Anleitungen dazu. Leider ist keine davon wirklich gut.
Die Online Adapter Erstellung scheitert mit einem fatalen Fehler...
ein "out of the Box" Adapter Template habe ich unter all den Sachen die ich dazu bei github fand auch nicht finden können.
Naja ich stückle mir aktuell aus verschiedenen Anleitungen und Templates was zusammen...
Mal sehen wo die Reise da hin geht :dizzy_face:Danke für die Informationen.
Wenn Du irgendwie dafür sorgen kannst, dass ich im Entwickler Bereich was posten kann erstelle ich gern dort ein oder zwei threats um an weitere Infos zu kommen.Beste Grüße
@tyantreides sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Wenn Du irgendwie dafür sorgen kannst, dass ich im Entwickler Bereich was posten kann erstelle ich gern dort ein oder zwei threats um an weitere Infos zu kommen.
Done
Support us
795
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge