Keine eigenen Datenpunkte in mqtt.X mehr

[Speedbreaker12]

Ist es so gewollt, dass man selbst im Expertenmodus keine eigenen Datenpunkte mehr in vorhandenen Adapter Ordnern anlegen kann? Ich hab nurnoch Verzeichnis als Auswahlmöglichkeit. Gerade beim MQTT Adapter ist das ein muss.

[GermanBluefox]

Hast du auch versucht im expertenmodus die Objekte zu erzeugen?

[Speedbreaker12]

Hast du auch versucht im expertenmodus die Objekte zu erzeugen?

Expertenmodus ist an, sonst wäre das + ja ausgegraut.

[Apollon77]

@GermanBluefox It is in mqtt.0 ... There was also a longer discussion in FOrum ... many mqtt users created additional states there because also data come in ... maybe we shouls allow "full edit" in mqtt.X too?

[Speedbreaker12]

Ich habe mittlerweile verstanden, dass das Verhalten so gewollt ist und ich kann das auch gut nachvollziehen. Außer beim MQTT Adapter!

Beim MQTT Adapter sind die Datenpunkte ja gleichzeitig die Topics und viele Geräte erwarten, dass man auf bestimmten Topics schreibt, auch wenn sie sie selbst nicht anlegen. Da hat man dann natürlich ein Problem, wenn das nicht mit der von IOBroker gewünschten Struktur übereinstimmt.

Gutes Beispiel: Tasmota

Tasmota erwartet, dass Konsolenbefehle über Gerätename/cmd reinkommt, legt den Datenpunkt aber selbst nicht an.

Jetzt kann ich natürlich unter userdata_0 Gerätename/cmd anlegen. Das interessiert dann nur Tasmota nicht! 😂

[mickym2]

Gibt es hier was Neues? - Das ist nun schön über 3 Monate alt.

[Feuer-sturm]

@GermanBluefox @Apollon77 Gab es hier eine Änderung? Mit aktivem Expertenmodus kann ich manuell jetzt States unter mqtt.0.* anlegen wenn ich zuvor einen "Folder" angelegt habe.

Wenn ich per Javascript entsprechende Datenpunkte anlegen möchte, dann wird nur der "Folder" angelegt

const DP_mqtt_iobprovides = 'mqtt.0.iobprovides';
const DP_TemperaturLueftungAussen       = DP_mqtt_iobprovides + '.TemperaturLueftungAussen';
setObject(DP_mqtt_iobprovides, {common: {name: 'mqtt Daten Bereitstellung'},type: 'Folder'});
createState(DP_TemperaturLueftungAussen, 0, {name: 'Ausstemperatur der Luft welche von der Lüftung von außen angesogen wird', unit: '', type: 'number', role: 'value', def: 0});

[Feuer-sturm]

Admin 5.2.1

Mit der neuen Admin Version 5.2.1 können jetzt unter mqtt.0 folgende Typen ausgewählt werden:

@GermanBluefox Wenn ich per Skript Datenpunkte unter mqtt.0 erzeugen möchte, dann wird auch mit der neuen Admin Version weiterhin nur das Objekt iobprovieds als folder oder auch als device angelegt, aber states werden nicht angelegt.

[FMode]

Anlegen des Datenpunktes umständlich über eine Automation des Browsers möglich - ein einfacher Befehl "createState" per API geblockt - die gelben Hochhäuser lassen die roten Fahrräder nicht mit Fussball spielen...

Ich habe manchmal einfach meine Zweifel an der Menschheit facepalm

[Apollon77]

@FMode Was genau soll uns dein Post sagen?

[FMode]

Das ich gerade in Rage war über die anscheinende Bevormundung die aber ein Bug oder eine Schwäche in /opt/iobroker/node_modules/iobroker.javascript/lib/sandbox.js ist.

[Apollon77]

Ich verstehe immer noch nicht. Der Admin erlaubt im Expertenmodus auch in mqtt.X States anzulegen, soweit ich mich entsinne. Das der Javascript Adapter das nicht erlaubt hat durchaus seine gründe und am Ende mag dies als "Bevormundung" wirken folgt aber einem Konzept und hat seine Gründe.

Und solche Kommentare in so einem Ton sind wenig hilfreich für eine konstruktive Diskussion und solche Diskussionen gehören auch nicht ins GitHub sondern ins Forum (aber auch dort nicht in so einem Ton).

[mickym2]

Ja es geht zwar – aber bestimmte Einschränkungen muss man immer noch überlisten. Wie gesagt gibt es bei mqtt keine Ordner sondern nur Topics und das können auch states sein. Das lässt der Admin aber auch im Expertenmodus nicht zu, sondern man muss halt den letzten Folder drüber suchen und dann über state.state.neu ein neuer Datenpunkt erstellt werden. Vielleicht stört das noch manche. Im Prinzip müsste halt alle diese Prüfungen im mqtt-Namensraum unterbleiben. Aber solange man bei der Anlage das über state.state.neu noch überlisten kann, hat man zumindest einen Workaround. - Schlimm wird es nur, wenn in einer der nächsten Versionen dieser Workaround auch noch kaputt gemacht würde. ;)

Im Prinzip ist halt dieses Konstrukt mit folders, channels, devices, states das mit dem Admin5 eingeführt wurde, für manche Dinge sinnvoll - aber global finde ist es viel zu starr und sorgt einfach für Verdruss. Besser hätte ich gefunden, wenn man das als Option für bestimmte Adaptertypen eingeführt hätte - aber ich will diese Diskussion nicht wieder anfachen, nachdem man ja mit dem Status Quo inzwischen einigermaßen leben kann. Gilt ja auch für userdata - das hat man zwar noch selbst in der Hand, ist aber ebenso unnötig hier so eine Struktur zu erzwingen.

[FMode]

Kann man sich den Ordner als Objekt geben lassen und dort sagen state.neu? Dann ist ja alles gut (sorry). Wo finde ich das? createState() legt ja den ganzen Pfad an... Dieser state.neu() wird dann auch von der GUI aufgerufen wenn man einen State anlegt?

Ansonsten ist natürlich die Nachfrage "Wollen sie die Systempartition wirklich formatieren? ..." sinnvoll und nicht "die Systempartition C: kann nicht formatiert werden"...

[mickym2]

Kann man sich den Ordner als Objekt geben lassen und dort sagen state.neu? Dann ist ja alles gut (sorry). Wo finde ich das? createState() legt ja den ganzen Pfad an... Dieser state.neu() wird dann auch von der GUI aufgerufen wenn man einen State anlegt?

Ansonsten ist natürlich die Nachfrage "Wollen sie die Systempartition wirklich formatieren? ..." sinnvoll und nicht "die Systempartition C: kann nicht formatiert werden"...

Ok - mein Workaround war natürlich nur auf das manuelle Anlegen via Admin bezogen. Wenn im JS Adapter die Abprüfung wieder vollständig ist, dann gibts natürlich ein Problem. Wie gesagt ich sehe als einzige Lösung, wenn man diese Abprüfung generell für bestimmte Namensräume komplett abschalten müsste (mqtt und userdata).

[mickym2]

@FMode Als Workaround kannst du aber über das SendTo einfach das topic publishen - das müsste gehen .

[mcm1957]

Bin nicht sicher ob ich das ganz durchschau. ABER wenn das nur ein issue für mqtt ist warum dann nicht dort was einbauen. In seinem eigenen Namesraum kann ein adapter ja immer schreiben.

[FMode]

Habs gefunden: https://github.com/ioBroker/ioBroker.mqtt/issues/240

---

Ein Unterschied zwischen Oberfläche und API macht niemals nirgendwo Sinn. Die Oberfläche sollte immer auch die API benutzen.

Die Blockade die C: Partition zu formatieren statt den Benutzer nochmal zu fragen führt natürlich dazu das dann Systeme wo die Systempartition nicht C ist dann nicht formatiert werden können weil der Entwickler halt daran nicht gedacht hat - deswegen am besten jede Bevormundung sein lassen. (Jede Warnung hingegen ist natürlich sinnvoll).

[Diginix]

Ich suche auch vergebens nach einer Möglichkeit neue Topics unterhalb eines mqtt.0.device per Skript anzulegen. Ich habe meine Skripte gern "rebootfest". D.h. alle states die in Skripten gebraucht werden, werden auch durch die Skripte angelegt. Prinzipiell alles unterhalb von 0_userdata.0. Aber bei Topics für ein mqtt Gerät, müssen diese natürlich im mqtt.0 Instanz Knoten liegen.

Habe beim javascript Adapter mal ein Featurerequest aufgemacht: https://github.com/ioBroker/ioBroker.javascript/issues/1288

[foxriver76]

Hier scheint es nur noch um den JavaScript Adapter zu gehen? Dann kann das hier mmn geschlossen werden.

[mickym2]

Es geht nicht um den Javascript Adapter sondern darum, dass sowohl states Kinder haben können - als auch, dass Du die Verrenkungen machen musst über "Pseudoverzeichnissen" neue topics im Admin nur über verzeichnis.topic anlegen zu können. Es geht um MQTT und daran, dass man den Möglichkeiten Rechnung trägt und den mqtt Adapter aus dem starren Korsett der Abprüfungen rausnimmt. - Wenn das aber niemand interessiert soll es mir Recht sein, solange die Workarounds noch funktionieren.

[mickym2]

Einen Punkt wie availability im Admin unter dem mqtt Adapter anzulegen muss halt ohne Verrenkungen möglich sein.

Ist es derzeit aber nicht.

[foxriver76]

Ich sehe das ähnlich wie @mcm1957 und würde am ehesten eine Funktionalität in den Adapter Setting des mqtt Adapters sehen, da ziemlich Special Logik für diesen Adapter.

Anscheinend sehr emotional geladen dieses Thema oder kommt mir nur so vor - schönen Abend.

[mickym2]

Na ja - wie gesagt die Lösung ist einfach, wenn man für diesen Adapter die Abprüfungen wie für 0_userdata.0 rausnimmt, die mit dem Admin5 eingeführt wurden. Und emotional wird es dann wenn sich hier seit Einführung des Admin 5 nichts bewegt und man das einfach schließt mit einem Verweis, dass es wohl mit dem Javascript Adapter zu tun hat. - Man kann ja der Meinung sein, dass der iobroker zukünftig der Homematic Logik folgen soll und man die Entwickler in ein entsprechendes Korsett zwingen will - aber hier geht es um mqtt und das Protokoll gibt hier die Standards vor. Wie gesagt es wäre so einfach, wie unter 0_userdata.0 die Abprüfungen rauszunehmen und für den Adapter den Zustand wie unter dem Admin 4 wiederherzustellen. Wie gesagt - von mir aus wird das zugemacht, solange die Workarounds noch gehen.

[foxriver76]

Oder du stellst einen PR dann tut sich was seit Admin 5

[mcm1957]

@mickym2

Hast du einen Issue beim Adapter mqtt gemacht? DIESER Adapter erfordert offenbar dass user states anlegen. Das ist definitiv adapterspezifisch. Und es erscheint nicht sinnvoll dass Admin / JS Controller Sonderfälle implementieren - heute für mqtt, morgen für maxi-plus, ...

Der Vergleich mit 0_userdata hinkt, da das eben KEIN Adaptervezeichnis ist.

Der mqtt Adapter kann das Anlegen beliebiger States in seinem Bereich ausführen. Ob er diese Nforderung vie UI, via sendTo, via import oder anders anders annimmt kann der Maintainer entscheiden.

Falls also noch nicht geschehen, rege ich an dass du ein Issue beim mqtt Adapter anlegst. Alternativ kannst du natürlich auch gern einen PR für mqtt erstellen.

Und der Verweis auf javascript war zu 90% ein Irrtum. Ein Verweis auf mqtt wär passender.

[mickym2]

Ich bin mir nicht sicher ob das nicht ein admin Problem ist, da es ja unter admin 4 gegangen ist. Ist mir letztlich aber auch egal, da ich ja nur ein Anwender bin. Ich verstehe auch nicht, warum man das dann nicht selbst innerhalb der Community adressieren kann. Egal - ich habe ein neues Issue aufgemacht. Man kann das gerne umbenennen - ich habe ganze Romane darüber im Forum geschrieben und wie gesagt, wenn da kein Aufwand reingesteckt werden soll, ist es OK solange der Workaround erhalten bleibt.

https://github.com/ioBroker/ioBroker.mqtt/issues/401

Der mqtt Adapter kann das Anlegen beliebiger States in seinem Bereich ausführen. Ob er diese Nforderung vie UI, via sendTo, via import oder anders anders annimmt kann der Maintainer entscheiden.

Und es geht auch nicht darum, dass der Adapterentwickler keine neuen States erstellen kann, sondern dass der Endanwender im ADMIN5 auch im EXPERTENMODUS keine Datenpunkte unter dem Adapter erstellen kann, wenn es KEIN Folder ist. Was das mit dem Adapterentwickler zu tun hat, erschließt sich mir nicht. Aber ich bin nur Endanwender.

Meines Erachtens ein Admin Problem - da ICH als ENDANWENDER den Datenpunkt erstellen will und nicht der Entwickler des Adapters. Wie gesagt - entweder es versteht jemand das Problem und dann bitte ich Euch einfach das wo auch immer zu adressieren. Das man in der Instanz des mqtt-Adapters nun neue topics erstellen soll - halte ich für die schlechteste Lösung.

[mcm1957]

Es ist eine m.E. sinnvolle Maßnahme, dass User incl Scripts NICHT irgendwo States anlegen können.

Und wenn ein Adapter das braucht, dann kann und soll DIESER Adapter dem User ein geeignetes Interface zur Verfügung stellen. Damit kann der Adapterentwickler ggF prüfen wenn etwas zu prüfen ist und der User kann die notwendigen States ggF erstellen.

@foxriver76 Wie siehst du das?

[mickym2]

Es ist eine m.E. sinnvolle Maßnahme, dass User incl Scripts NICHT irgendwo States anlegen können.

Ging auch nicht um irgendwo - sondern unter dem mqtt Adaptern und 0_userdata. Das war unter Admin 4 jedenfalls möglich. Und wie gesagt im Moment geht es mit einem Workaround auch heute, dass ich beliebige Topics im Admin 5 im mqtt Adapter anlegen kann - ohne dass das bislang irgend jemand gestört hat, noch das System Schaden genommen hat. Man kann es einem natürlich auch schwer machen - wie gesagt Diskussionen habe ich im Forum schon geführt und will das eigentlich nicht wieder aufwärmen. - Macht das einfach zu und dann lassen wir es dabei.

[mcm1957]

Ich wiederhole mich: Es macht keinen Sinn irgendwelche Sonderausnahmen für einzelne Adapter in Admin einzubauen. Und 0_userdata ist global, das ist nicht vergleichbar...

[mickym2]

Ja damit hat sich das Thema erledigt und kann zugemacht werden. Letztlich steckt nämlich genau diese Anforderung in dem Request. Aus meiner Sicht kann man, wenn man keine Ausnahmen machen will, das hier zu machen.

[mcm1957]

@foxriver76

Kleiner Einwurf in die Diskussion.

Wenn es für User so wichtig ist states in einem Adapterbaum anlegen zu können UND dies der Adapter selbst "befürwortet" wäre es ev. auch ein Denkmodell dass der ADAPTER über einen Eintrag in seine io-package.json das Anlegen von status unter seinem Instanz Obkjekten via admin, javascript, ... explizit erlaubt.

Da dazu der Adapter Entwickler aktiv werden muss kann er prüfen ob das für seinen Adapetr Sinn macht. Und in Admin müßte man keine "Extrawürste"/Sonderfälle einbauen sondern hätte ein definiertes Interface dass jeder Adapter benutzen kann,

Einfach mal zum Nachdenken ...

Und warum mqtt unbedingt states unter states braucht ist ne andere Frage. Da wär extra abzuklären ob das der Adapter nicht sauber händeln könnte.

[foxriver76]

@foxriver76

Kleiner Einwurf in die Diskussion.

Wenn es für User so wichtig ist states in einem Adapterbaum anlegen zu können UND dies der Adapter selbst "befürwortet" wäre es ev. auch ein Denkmodell dass der ADAPTER über einen Eintrag in seine io-package.json das Anlegen von status unter seinem Instanz Obkjekten via admin, javascript, ... explizit erlaubt.

Da dazu der Adapter Entwickler aktiv werden muss kann er prüfen ob das für seinen Adapetr Sinn macht. Und in Admin müßte man keine "Extrawürste"/Sonderfälle einbauen sondern hätte ein definiertes Interface dass jeder Adapter benutzen kann,

Einfach mal zum Nachdenken ...

Und warum mqtt unbedingt states unter states braucht ist ne andere Frage. Da wär extra abzuklären ob das der Adapter nicht sauber händeln könnte.

Schöne Idee, geht vermutlich nicht weit genug, weil Admin dich in bestimmte Strukturen drängt, die für mqtt auch wiederum nicht passen, State nicht auf top level etc.