Admin5: Ich kann keine Objekte mehr manuell anlegen

[mickym]

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

@falke69 sagte: dann suche ich mir das mal mir raus.

Diese Variante erzeugt eine bessere Struktur.

Ohne jetzt eine Riesendiskussion anzuschmeißen - aber ich persönlich bevorzuge nur den type Folder für bislang nicht existierende Objekte. Gerade bei selbst angelegten Strukturen, sind das eben oft keine Geräte oder Kanäle. Sobald ich die letzten Ebenen nicht als Folder, sondern als Gerät oder Kanäle anlege beschränke ich mich dann doch von vorneherein bzw. zukünftig auf die Hiearchietiefe und das ist oft nicht gewünscht.

[sigi234]

Welche Variante ist jetzt iob (admin) konform?

[mickym]

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

Welche Variante ist jetzt iob (admin) konform?

Alles was oben in dem ToolTipp aufgeführt ist.

Und dazu gehört auch Ordner => Zustand

Ich hab mich ja nur etwas an dem Wort "besser" gestört - aber wie gesagt wollte keine Diskussion anwerfen, Nachteile habe ich ja schon gesagt und sieht man ja oben. Sobald ein Datenpunkt in der Hierarchie ein Kanal ist gehts nicht mehr tiefer und man kann nur noch Zustände anlegen.

[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.
https://github.com/ioBroker/ioBroker.admin/issues/1067

Speedbreaker12 created this issue in ioBroker/ioBroker.admin

open Keine eigenen Datenpunkte in mqtt.X mehr #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....

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