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

[sigi234]

@paul53

Kann man im Skript auch einbauen ob und wie viele Daten geändert wurden?

[paul53]

@mickym sagte: Ich hab mich ja nur etwas an dem Wort "besser" gestört

Das bezieht sich auf eine Struktur, in der man im Trigger z.B. auf den Kanalnamen oder Gerätenamen zugreifen will.

[paul53]

@sigi234 sagte: Kann man im Skript auch einbauen ob und wie viele Daten geändert wurden?

Du meinst, einen Änderungszähler?

[sigi234]

@paul53 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

@sigi234 sagte: Kann man im Skript auch einbauen ob und wie viele Daten geändert wurden?

Du meinst, einen Änderungszähler?

Jupp

[mickym]

@paul53 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

@mickym sagte: Ich hab mich ja nur etwas an dem Wort "besser" gestört

Das bezieht sich auf eine Struktur, in der man im Trigger z.B. auf den Kanalnamen oder Gerätenamen zugreifen will.

Gut, aber halt der Nachteil dass ich dann in der Art meiner Typen der Kinder beschränke. Wie gesagt - gibt in meinen Augen hier nicht den "Königsweg" und sobald ein Objekt ja existiert, kann man es ja auch nachträglich manuell wieder ändern.

Ich würde deshalb sagen:

Wenn Kanal oder Geräte: Vorteil über diese zu Triggern
Wenn Folder: Keine Beschränkung in der Hierarchietiefe

[paul53]

@sigi234
Mit einer Zählvariablen sollte es funktionieren.

// In den Settings der Javascript-Instanz muss setObject erlaubt sein!!!
const ids = $('javascript.1.*'); // Anpassen!!
 
var arr = [];
var cnt = 0;
 
function correctObject(id, arr, level){
   if(arr.length === 2) return;
   let type = 'folder';
   if(level == 1) type = 'device';
   else if(level == 0) type = 'channel';
   if(!existsObject(id)) {
       const obj = {
           type: type,
           common:{
               name: arr[arr.length - 1]
           },
           native: {}
       }
       setObject(id, obj, e => {
           if (e) log('Fehler beim Schreiben des Objektes: '+ id + ' ' + e);
           else cnt++;
       });
   }
   arr.pop();
   id = arr.join('.');
   level++;
   correctObject(id, arr, level);
}
 
ids.each(id => {
   arr = id.split('.');
   arr.pop();
   id = arr.join('.');
   if(arr[0] === '0_userdata' || arr[0] === 'javascript' || arr[0] === 'alias') {
       correctObject(id, arr, 0);
   }
});
setTimeout(function() {
   log('Anzahl Änserungen: ' + cnt)
}, 1000);

[fastfoot]

@sigi234 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

Welche Variante ist jetzt iob (admin) konform?

Beide wurden von appolon verlinkt und sind also konform :-)

@mickym hat da aber einen guten Punkt. Hat man sich zB einen DP MeinHaus.Obergeschoss.LichtAn angelegt dann kann man mit Pauls Variante keine weitere Hierarchie unterhalb Obergeschoss (z.B. Kinderzimmer, Schlafzimmer) mehr hinzufügen, da MeinHaus als Device eingestellt ist und Obergeschoss als Channel. Unter Channels können jedoch nur noch States eingefügt werden, keine weiteren 'Ordner'. Mit meiner ursprünglichen Variante dass alles(ausser LichtAn) ein folder wird, ist man da nicht eingeschränkt. Für die meisten Nutzer, welche mit Device und Channel eh nichts anzufangen wissen(ich zähle mich dazu bzw. brauche das schlicht nicht) dürfte mein Ursprungsskript völlig ausreichend sein. Für Leute welche ihre Strukturen gut kennen, ist Pauls Alternative eine gute Lösung. Wobei, wer Devices und Channels tatsächlich braucht, der hat seinen DP von vornherein nicht so angelegt, denn mit der alten UI hatte man diese Zuordnung ja auch nicht

[sigi234]

@paul53

Danke:

12:45:21.526 info javascript.0 (1152) script.js.Sigi.Objekte_3: Anzahl Änderungen: 0

[paul53]

@sigi234 sagte: Anzahl Änderungen: 0

Ich habe noch eine Verzögerung von 1 s ergänzt (s.o.). Das Script enthält nur Schleifen, deshalb am Ende mit Verzögerung.

[mickym]

Ich habe auch gerade festgestellt, dass außer unter userdata, der admin auch im Expertenmodus sowieso verbietet, Verzeichnisse anzulegen.

Im mqtt-Adapter kann man so keine Ordner mehr anlegen (nur im userdata)

das wurde aber generell im Parallelthread schon diskutiert - das man das sowieso zukünftig ganz unterbinden will und künftig eigene Datenpunkte und Datenstrukturen (Folder) ausserhalb von userdata und alias nur noch über die Adapterkonfiguration erlaubt.

Und für die mqtt Freunde: Zukünftig muss man eigene Hierachien dann über seinen Broker machen - indem man dann halt über NodeRed (mqtt-out) oder mosquitto client weitere Hierachien durch eigene Topics erstellt - auch wenn man den mqtt Adapter als mqtt-Broker betreibt!

Aber wie gesagt für die 0_userdata Strukturen ist das Argument bzgl. der Hierarchieebenen vielleicht doch zu bedenken!

[paul53]

@mickym sagte: Alles was oben in dem Dialog aufgeführt ist.

Außerdem:

• Gerät.Datenpunkt
• Ordner.Gerät.Datenpunkt

[Fabian1]

@mickym said in Admin5: Ich kann keine Objekte mehr manuell anlegen:

Und für die mqtt Freunde: Zukünftig muss man eigene Hierachien dann über seinen Broker machen - indem man dann halt über NodeRed (mqtt-out) oder mosquitto client weitere Hierachien durch eigene Topics erstellt - auch wenn man den mqtt Adapter als mqtt-Broker betreibt!

Das finde ich absolut bescheuert. :) Und hab dazu ein Issue erstellt was gerne hoch gevoted werden darf. :D
https://github.com/ioBroker/ioBroker.admin/issues/1067

[mickym]

@paul53 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

@mickym sagte: Alles was oben in dem Dialog aufgeführt ist.

Außerdem:

• Gerät.Datenpunkt
• Ordner.Gerät.Datenpunkt

Und natürlich ....

Ordner.Ordner....

:grinning:

[paul53]

@mickym sagte: Ordner.Ordner....

Nur in "erlaubten" Strukturen.

[mickym]

@fabian1 Ich glaube man war sich einfach in dieser Form nicht bewußt, dass man einen vollwertigen mqtt-client nun halt in der Funktion auf vorhanden topics beschränkt und wie man aus der Paralleldiskussion erkennen kann, eben nur über das Adapterinterface.

Ich hätte es gleich besser gefunden, wenn der Adapterentwickler selbst entscheiden kann mit einer Art Rechtestruktur wo und wie man in seinen Namespace schreiben darf (was ja auch prinzipiell noch geht - nur halt nicht mit dem Admin). Aber egal - da haben sich wohl sicher einige schon die Köpfe heiß geredet und das abgewogen.

[Dutchman]

@mickym sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

Ich hätte es gleich besser gefunden, wenn der Adapterentwickler selbst entscheiden kann mit einer Art Rechtestruktur wo und wie man in seinen Namespace schreiben darf (was ja auch prinzipiell noch geht - nur halt nicht mit dem Admin). Aber egal - da haben sich wohl sicher einige schon die Köpfe heiß geredet und das abgewogen.

Grundgedanke ist nur der adapter darf in seinem namespace schreiben und ja das hat seine gründe :)
fuer eigene Datenpunkte hat man den userdate_0 un per script die Möglichkeit daten zu synchronisieren.

Alles in der Ordner structuur des adapter is. dem adapter. vor behalten

[Fabian1]

@dutchman said in Admin5: Ich kann keine Objekte mehr manuell anlegen:

@mickym sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

Ich hätte es gleich besser gefunden, wenn der Adapterentwickler selbst entscheiden kann mit einer Art Rechtestruktur wo und wie man in seinen Namespace schreiben darf (was ja auch prinzipiell noch geht - nur halt nicht mit dem Admin). Aber egal - da haben sich wohl sicher einige schon die Köpfe heiß geredet und das abgewogen.

Grundgedanke ist nur der adapter darf in seinem namespace schreiben und ja das hat seine gründe :)
fuer eigene Datenpunkte hat man den userdate_0 un per script die Möglichkeit daten zu synchronisieren.

Alles in der Ordner structuur des adapter is. dem adapter. vor behalten

Ich bin da auch absolut für, nur nicht beim MQTT Adapter.

[Homoran]

@fabian1 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

nur nicht beim MQTT Adapter.

...und bei javascript!

...und bei node-red?
...oder scenes?
...oder andere Logikmaschinen?

[Fabian1]

@homoran said in Admin5: Ich kann keine Objekte mehr manuell anlegen:

@fabian1 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

nur nicht beim MQTT Adapter.

...und bei javascript!

...und bei node-red?
...oder scenes?
...oder andere Logikmaschinen?

Das war so nicht gemeint! Ich meinte damit, ich finde die Idee dahinter generell gut, wie ich auch schon im Github Issue geschrieben habe. In z.B. Hue.x, Nuki.x usw. haben eigene Datenpunkte nichts zu suchen. Das hätte aber eigentlich auch schon vorher jedem klar sein dürfen und man darf sich dann nicht wundern, wenn etwas nicht klappt oder die eigenen Datenpunkte weg sind.

Bei MQTT als NUR ALS Beispiel, schränkt man damit aber enorm die funktionsweise ein. Da die Geräte ja die Struktur die sie erwarten vorgeben und nicht IOBroker.

[Homoran]

@fabian1 Wenn ich jetzt vollständig darauf antworten würde müsste das ein seeehr langer Post werden.
Einerseits wäre das mal nötig um die Hintergründe darzustellen, andererseits habe ich da jetzt keine Zeit zu.

Aber nur mal gaaaanz bisschen provokativ:

@fabian1 sagte in Admin5: Ich kann keine Objekte mehr manuell anlegen:

Da die Geräte ja die Struktur die sie erwarten vorgeben

Was spricht dann gegen die Nutzung des MQTT-Client Adapter, wo du jedem State ein Topic mit beliebigem Format zuweisen kannst?