Visu auf React Basis

[da_Woody]

@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]

@da_woody
Ich bin dabei eine eigene "visu" zu bauen.
Das Grundgerüst und die ersten Funktionen stehen. siehe: Threat dazu

Ich 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.on

dann 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.on

Ein 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.

[apollon77]

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

[oFbEQnpoLKKl6mbY5e13]

@apollon77

Du hast ihn nicht direkt angesprochen.

[apollon77]

@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]

@apollon77

Nein, muss man natürlich nicht...

[da_Woody]

@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.

[Tyantreides]

@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]

@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]

@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]

@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]

@apollon77
Ok recht herzlichen Dank!

Beste Grüße aus Berlin!

[Tyantreides]

@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]

@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]

@apollon77

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

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

[apollon77]

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

[apollon77]

@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