Hallo @ke-nexi @LittleNo @schwarms ,
ich habe unter https://github.com/ioBroker/ioBroker.vis-2/issues/94 einen Feature Request erzeugt. Ich denke, dass es unter VIS 2 am besten eingeordnet ist. Bei Gefallen gerne upvoten und mitdiskutieren (Daumen hoch oder Kommentar).
VG
Hallo zusammen!
Ich bin ein ioBroker-Neuling und arbeite viel mit Geräten, die JSON-Dokumente veröffentlichen. Also habe ich nach Möglichkeiten gesucht, Werte aus JSON-Dokumenten automatisch als separate Datenpunkte zu speichern. Das Ganze so konfigurativ wie möglich, also ohne für jeden neuen Sensor etc. Skripte anpassen zu müssen. Da ich mit mäßig umfangreicher Recherche keine Lösung finden konnte, die meinen Vorlieben und Arbeitsweisen am besten entsprach, und ich parallel dazu ohnehin in die Tiefen und Untiefen von ioBroker eintauchen wollte, habe ich eine eigene Softwarekomponente (ein TypeScript-Modul) entworfen. Im Sinne eines Proof of Concept, um zu sehen, ob sich mein Wunsch realisieren lässt. Wahrscheinlich gibt es da draußen auch bessere Lösungen. Vielleicht ist mein "Flow" auch nicht der der Allgemeinheit, weshalb meine Lösung für andere möglicherweise nicht so gut passt. Aber: Da das Modul schon etwas an Größe gewonnen hat und bei mir schon eine Weile erfolgreich im Einsatz ist, dachte ich, ich könnte den aktuellen Stand der Arbeit teilen. Als Inspiration, wie man es machen kann, nicht machen sollte oder was auch immer 
Das Modul liegt hier:
https://github.com/stevenengland/iobJs-JsonStateMapper
Aktuell ist alles auf Englisch dokumentiert. Mir ist erst auf dem Weg zur Lösung aufgefallen, wie viel umfangreicher die Deutsche Community für ioBroker ist Mal ganz was neues für mich... Wenn sich irgendwer hierfür interessiert und es auf Deutsch braucht, schaue ich einmal, dass ich das nachziehe.
Zur Lösung: Grob gesagt konfiguriert man, welche Änderungen welcher Datenpunkte, bestehend aus JSON-Dokumenten (Quelldatenpunkte), man abonnieren möchte und wohin (Zieldatenpunkte) Werte aus der Quelle bei jeder Änderung der Quelle geschrieben werden sollen. Bildlich dargestellt:
Es handelt sich hierbei um eine Tasmota Steckdose, von der ich die Leistung (Power), welche im Datenpunkt SENSOR steckt in einen eigenen Datenpunkt CURRENT_POWER übertragen möchte.
Wie genau es funktioniert und was benötigt wird, ist in der README im Repo dokumentiert. Da ist viel Hinführung drin, am besten einmal zum Beispiel ganz unten springen. Viel mehr mag ich hier gar nicht schreiben, da ich aus Aktualitätsgründen die Dateils lieber im Repository pflege.
VG
@apollon77 Hi, gerade einmal ins Blaue bei Siegenia nachgefragt, auch mit Verweis auf dich und diesen Thread. Die Antwort lautete: "nach Rücksprache mit unserem zuständigen Produktmanager geben wir die API nicht an Privatpersonen heraus."
Hast du damals eine andere Rolle über das ioBroker Projekt gehabt?
VG
Long story short: I opened this issues to solve the root cause: https://github.com/ioBroker/dev-server/issues/471
Small update: I realized that browser-sync is the one interfering with my React component.
If one takes a closer look at the screenshot I provided, than one can see that browser-sync is loaded where it should'nt:
On the left side it is loaded as part of the IFrame containing the tab. On the right side it is not loaded as part of the tab. Instead it is loaded in the parent frame:
The effect that browser-sync has here is that it injects the code one can see for all admin/*html files like it does in my case but thats a misbehavior and I guess only intended to happen in the parent frame?
Now I thought that might be because I installed dev-server as a local dev-dependency and this somehow pulls in the browser-sync script. But thats not the reason as far as I could test.
Hi there!
Situation:
I am in the process of developing an adapter. I terms of a UI I began with no extra tab for the adapter. Now I want to create a tab and want to realize it with React. Therefore I created a fresh adapter with the help of adapter-creator with all relevant options set for a React tab. When I launch a dev-server instance for this newly created adapter everything is fine.
So I began to adapt all the neccessary settings that I could find from all the different files from the newly created adapter to my adapter in development.
Problem:
The adapter in development does not render the react page but does render something different. For a better view here are two comparisons as a picture:
Source: Here you see what effectively is deployed within a dev-server instance. On the left hand side for the adapter in development and on the right the newly created adapter.
Runtime-Markup: Here you can see, what effectively gets rendered. On the left hand side for the adapter in development and on the right the newly created adapter.
From my understanding something is going on during the compile step that breaks things. Maybe somewhere there it is not clear to the build chain that a React tab is the goal and instead some boilerplate for... maybe Materialized tabs or so... is pulled?
Is somebody out there that has a clue, what I need to check?
Maybe a few settings that I guess are important for the build step...
// io-package.json
"adminUI": {
"config": "json",
"tab": "materialize"
},
"adminTab": {
"singleton": false,
"name": {
// ...
},
"link": "",
"fa-icon": "info"
},
// package.json
"build": "build-adapter all",
"build:backend": "build-adapter ts",
"build:admin": "build-adapter react",
// admin/tsconfig.json
// Specialized tsconfig for the admin directory,
// includes DOM typings and configures the admin build
{
"extends": "../tsconfig.json",
"compilerOptions": {
"noEmit": false,
"outDir": "./build",
"sourceMap": true,
"sourceRoot": "./src",
"noImplicitAny": false,
"lib": ["es2018", "DOM"],
"jsx": "react"
},
"include": ["./**/*.ts", "./**/*.tsx", "../src/lib/adapter-config.d.ts"],
"exclude": ["./**/*.test.ts", "./**/*.test.tsx"]
}
@blockmove Vielen Dank 
Deine Zusammenfassung ist echt um Längen besser als all meine vielen erklärenden Worte 
Ich werde das Wording glaube ich so oder so ähnlich übernehmen
@ticaki Das stimmt. Die einzige Aufgabe ist das "Mappen" von JSON Quelldatenpunkten auf eigene Zieldatenpunkte.
Hi, @ticaki danke für deine Ausführung. Das würde ich auch nicht als Kritik auffassen, sondern als Hinweise. Im Prinzip genau wie du sagst + ein anderer Aspekte:
Ansonsten ist natürlich der Sonoff Adapter sicher eine feine Sache, keine Frage.
Hallo zusammen!
Ich bin ein ioBroker-Neuling und arbeite viel mit Geräten, die JSON-Dokumente veröffentlichen. Also habe ich nach Möglichkeiten gesucht, Werte aus JSON-Dokumenten automatisch als separate Datenpunkte zu speichern. Das Ganze so konfigurativ wie möglich, also ohne für jeden neuen Sensor etc. Skripte anpassen zu müssen. Da ich mit mäßig umfangreicher Recherche keine Lösung finden konnte, die meinen Vorlieben und Arbeitsweisen am besten entsprach, und ich parallel dazu ohnehin in die Tiefen und Untiefen von ioBroker eintauchen wollte, habe ich eine eigene Softwarekomponente (ein TypeScript-Modul) entworfen. Im Sinne eines Proof of Concept, um zu sehen, ob sich mein Wunsch realisieren lässt. Wahrscheinlich gibt es da draußen auch bessere Lösungen. Vielleicht ist mein "Flow" auch nicht der der Allgemeinheit, weshalb meine Lösung für andere möglicherweise nicht so gut passt. Aber: Da das Modul schon etwas an Größe gewonnen hat und bei mir schon eine Weile erfolgreich im Einsatz ist, dachte ich, ich könnte den aktuellen Stand der Arbeit teilen. Als Inspiration, wie man es machen kann, nicht machen sollte oder was auch immer Das Modul liegt hier:
https://github.com/stevenengland/iobJs-JsonStateMapper
Aktuell ist alles auf Englisch dokumentiert. Mir ist erst auf dem Weg zur Lösung aufgefallen, wie viel umfangreicher die Deutsche Community für ioBroker ist Mal ganz was neues für mich... Wenn sich irgendwer hierfür interessiert und es auf Deutsch braucht, schaue ich einmal, dass ich das nachziehe.
Zur Lösung: Grob gesagt konfiguriert man, welche Änderungen welcher Datenpunkte, bestehend aus JSON-Dokumenten (Quelldatenpunkte), man abonnieren möchte und wohin (Zieldatenpunkte) Werte aus der Quelle bei jeder Änderung der Quelle geschrieben werden sollen. Bildlich dargestellt:
Es handelt sich hierbei um eine Tasmota Steckdose, von der ich die Leistung (Power), welche im Datenpunkt SENSOR steckt in einen eigenen Datenpunkt CURRENT_POWER übertragen möchte.
Wie genau es funktioniert und was benötigt wird, ist in der README im Repo dokumentiert. Da ist viel Hinführung drin, am besten einmal zum Beispiel ganz unten springen. Viel mehr mag ich hier gar nicht schreiben, da ich aus Aktualitätsgründen die Dateils lieber im Repository pflege.
VG
Hi all!
I am ioBroker newbie, working a lot with devices that publish JSON documents. So I was looking for ways to automatically persist values from the JSON document as separate data points. The whole thing as configurable as possible (and in some way scalable, meaning only once per same device type and not for each device individually). Effectively without the need to customize scripts. Since with moderate research I couldn't find a solution that best served my preferences and working methods, and I parallely wanted to delve into the depths and shallows of ioBroker anyway, I designed my own software component (a TypeScript module). In the spirit of a proof of concept so that I can see if my wish could be realized. Likely, there are better solutions out there, too, or my flow is not that of the general public, which is why my solution may not be a good fit for others. But: Since on my way to a working solution I got lost in details, the component has therefore already gained some size, I thought I could share the current state of work. It can be found here:
https://github.com/stevenengland/iobJs-JsonStateMapper
Roughly speaking, one configures which data points containing JSON documents (source data points) one wants to subscribe to and where (target data points) which values from the source should be written to:
Here's an example image of a Tasmota socket from which I want to transfer the consumed power from SENSOR (natively from TASMOTA) to CURRENT_POWER (specially created data point).
How exactly it works and what is needed is documented in the README in the repo.
Cheers
@paul53 Danke dir. Finde ich irgendwie unglücklich, da man nach Umsortierung von Funktionen in andere Ordner dann auch die Abfragen ändern muss. Aber gut, gibt schlimmeres.
