UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Kiwifranky]

HI,

ich bin relativ neu hier und habe den Wunsch per Scripting weitere States/Channels in bestehende Adapter hinzuzufügen.

Mit createState landen die natürlich immer als Unterelemente im entsprechenden Javascript-Knoten. Ich dachte mir einfach, wenn ich den kompletten Pfad wie z.B. "geofency.0.Franky.Home.meinState" angebe, dieser dann auch dort erzeugt wird, aber das Ergebnis lautet leider "javascript.0.geofency.0.Franky.Home.meinState".

Gibt es eine Möglichkeit die States in den gewünschten Adapter zu bekommen?

besten Dank im Vorraus

Franky

[BuZZy]

Hallo und Willkommen! ;)

Kannst du ein Beispiel nennen wozu du das brauchst?

Macht für mich eigentlich nicht viel Sinn, da man nie weiß, was der Entwickler der Adapter alles so eingebaut hat bzw. in Zukunft einbauen wird.

Eventuell werden alle Datenpunkte irgendwann mal nach einem Update gelöscht und neu angelegt etc.. Also muss man sich genau überlegen ob man das so machen will..

Gruß

[arteck]

kurz und knapp : nein nicht aus dem script heraus

[Kiwifranky]

Hi,

da war sie wieder, die Frage nach dem Sinn anstelle eines Lösungsvorschlages…. Nun gut, ich erkläre auch gerne den Sinn:

1. Ich bin Softwareentwickler und möchte gerne eine ordendliche Struktur in meinen Konstrukten sehen.

2. Meine "Erweiterungen" bereiten z.B. Daten von bestehenden Elementen auf, bzw. erweitern die Funktionalität von verfügbaren Adaptern.

3. Diese Erweiterungen möchte ich der Struktur wegen auch dort sehen, wo sie hingehören.

Ein kleines Beispiel:

Ein Script scannt Devices im MaxCube Adapter nach "thermostat...." und legt in diesen nun zusätzliche States an.

(Das diese States evtl. durch den Adapter, oder spätestens beim Entfernen des Adapters gelöscht werden ist mir klar. Das macht auch Sinn.)

Jetzt besitzt jeder "thermostat" z.B. Eigenschaften wie... .ScheduleNameWorkdayEarly, .ScheduleNameWorkdayLate, .ScheduleNameSaturday, .ScheduleNameHolyday, .ECOTemp...

Jetzt kann man jedem Thermostat zu jeder Art von Tag einen Schedule per Name zugewiesen werden, wie z.b. am Montag ScheduleNameWorkdayEarly den Wert "Fruehschicht", damit in der Woche mit Frühschicht es um 5 Uhr morgens auch warm in der Bude ist. Im dem Schedule "Fruehschicht" steht dann sowas drin wie "4:45=B23.0, 5:30=18.0 ...." = "Um 4:45 einmal Boost und Temperatur auf 23 Grad, um 5:30 absenken auf 18 Grad.... Obwohl da zusätzlich auch noch eine Anwesenheitserkennung per Geofency drin ist und ggf. eine ECO-Absenkung passiert wenn niemand zu Hause ist)

(Es gibt also an zentraler Stelle im MaxCube-Adapter auch eine Liste von Schedules zur Temperaturplanung, die jeweils auch einen Namen haben - Im simpelsten Fall A,B,C...)

Durch diese Bündelung von Eigenschaften ist es auch möglich einen speziellen Controller in VIS zu generieren, der auf diese Zusatzeigenschaften zugreifen kann. Der muss dann nicht auf zehn verschiedene Elemente, die kreuz und quer in der Objektstruktur von ioBroker verteilt sind zugreifen.

Macht Sinn, oder?

Nun wäre ich aber gerne an einem Lösungsvorschlag interessiert...

Ist wahrscheinlich ganz einfach, und bevor ein weiterer Hinweis kommt.... JA ich habe bereits gegoogelt!

Würde auch gerne den Code später hier veröffentlichen, da sicher der ein oder andere an der Automatisierung seiner MAX! interessiert ist...

@artek:

Echt nicht? Man hat also nur Lesezugriff auf die Struktur. Ist das so geregelt, dass nur der Adapter per Code (Subscribing/Publishing) in der Lage ist, Änderungen vorzunehmen?

Das manuelle Bearbeiten per Admin-Adapter ist ja auch möglich, also muss es irgenwie intern schon gehen...

Keiner mehr ein Tipp? :-(

Franky

[BuZZy]

@Kiwifranky:

da war sie wieder, die Frage nach dem Sinn anstelle eines Lösungsvorschlages…. ` Versteh mich nicht falsch.. Aber manchmal kann man bessere Lösungsvorschläge machen wenn man den Sinn hinter einer Anfrage versteht. Das solltest du doch als Softwareentwickler wissen oder?

Kunde möchte gerne die Funktion AB und glaubt, dass der Weg XY der richtige ist..

Jetzt sagst du aber, moment mal.. Wieso den Weg XY gehen. Ist doch viel zu kompliziert und macht überhaupt keinen Sinn.. Ich habe einen Weg der nur halb so viel Code und weniger Ressourcen benötigt.. :lol:

Du kannst natürlich die Adapter auf Github forken und den Code entsprechend anpassen und um die benötigten Datenpunkte erweitern und dann deine persönlich angepasste Adapterversion über die Github URL drüber installieren.

Mal davon abgesehen, dass ich denke, wenn die Datenpunkte mit einem Script befüllt werden, dann gehören diese auch unter die javascript Instanz. Irgendwann denkt man "Mist .. wie wird denn dieser Datenpunkt befüllt??!" .. Wenn der Datenpunkt unter "javascript" liegt weiß man sofort, der Datenpunkt wird über ein Script befüllt. Aber da ist natürlich jeder anderer Meinung. :D

Gruß

[apollon77]

@Kiwifranky:

da war sie wieder, die Frage nach dem Sinn anstelle eines Lösungsvorschlages…. Nun gut, ich erkläre auch gerne den Sinn: `

Naja, wenn Du selbst Softwareentwickler bist dann weisst Du ja das es meistens "Viele Wege nach Rom" gibt und im ersten Schritt das "Was "gekkärt werden muss bevor man das "wie" definiert. Ohne Hintergründe keine guten Lösungsvorschläge.

@Kiwifranky:

1. Ich bin Softwareentwickler und möchte gerne eine ordendliche Struktur in meinen Konstrukten sehen.

2. Meine "Erweiterungen" bereiten z.B. Daten von bestehenden Elementen auf, bzw. erweitern die Funktionalität von verfügbaren Adaptern.

3. Diese Erweiterungen möchte ich der Struktur wegen auch dort sehen, wo sie hingehören. `

Das Grundkonzept von ioBroker an dieser Stelle ist, dass es sehr modular aufgebaut ist mit den ganzen Adaptern. Damit das in der Praxis funktioniert müssen bestimmte "Vereinbarungen" getroffen werden. Dies bedeutet bei States das jeder Adapter seinen eigenen "Namespace" hat und das sind die obersten zwei Ebenen: adaptername.instanznummer . Dort darf/sollte sich der Adapter bewegen und sonst niemand. Das hinzufügen von eigen States 8auch wenn es rein technisch geht) bringt ggf den Adapter durcheinander und macht Probleme bei späteren Erweiterungen. Daher muss sich ein Adapterentwickler darauf verlassen können in diesem, seinem, "Hoheitsgebiet" niemand anderes eingreift.

In dem Zuge gibt es den JavaScript-Adapter wo passend zum Ablageort der Skripte die zugehörigen eigenen States angelegt und in eigenen Strukturen verwaltet werden können. Und eigene Skripte und deren Ergebnisse "Gheören" in den JavaScript -Adapter (wo Sie hingehören) ;-)

Dadurch entsteht systembedingt ein "zersplittern" der States und die landen verteilt im System.

Es gibt aber auch beispielsweise den Adapter ioBroker.wrapper, der das versucht wieder zusammenzubringen.

Formal geht natürlich alles, wie Du korrekt schreibt, per Admin und manuell). Sei dir aber bewusst was Du damit potentiell für Probleme anziehst - und für sowas wirst Du dann von keinem Adapterentwickler support bekommen weil Du in seinem "Hoheitsgebiet" rumgepfuscht hast. Risiko halt (und das nicht zu knapp)

[Kiwifranky]

Hallo zusammen,

danke für die Hinweise. Dann werde ich mich dementsprechend anpassen und eine parallele Struktur im javascript-Knoten erzeugen.

Konzept verstanden.

Damit können wir den Thread eigentlich beenden…

besten Dank für die Mühe!

Franky

[paul53]

@Kiwifranky:

Damit können wir den Thread eigentlich beenden… `
Dann markiere bitte das Thema als [geklärt] (im ersten Beitrag).