Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[GER55 0]

Hallo,
benötige Hilfe.
Seit Umstellung auf 5.1.23 kann ich den Bereich Datenpunkte /neues Objekt /Allgemein .... nicht finden.

Gibt es eine neue Vorgehensweise ?

Würde mich auf eine schnell Hilfe freuen.

[Thomas Braun]

@ger55-0 Ja, eigene Datenpunkte gehören nach 0_userdata, nicht in die Adapter-Verzeichnisse

[mickym]

@thomas-braun NEin bei mqtt - finde ich das absolut nicht. Aber lassen wir diese Diskussion. Immerhin kann ich den mqtt Adapter nutzen um dort Datenpunkte zu erstellen, die ich publishen möchte.

[mickym]

@ger55-0 Ja gibt es: schau mal hier: https://forum.iobroker.net/topic/46814/admin5-ich-kann-keine-objekte-mehr-manuell-anlegen. Im Prinzip musst Du den Datenpunkt Verbrauch als Verzeichnis definieren, dann kannst Datenpunkte anlegen.

[Homoran]

@mickym sagte in Datenpunkte Allgemein und .....:

kann ich den mqtt Adapter

CLIENT

[mickym]

@homoran Nein ich meine den Client -Server Adapter (als Client) - der mir ein transparentes Frontend meines mosquitto Servers abbildet.

[Homoran]

@mickym sagte in Datenpunkte Allgemein und .....:

@homoran Nein ich meine den Client -Server Adapter (als Client) - der mir ein transparentes Frontend meines mosquitto Servers abbildet.

dann nimm zusätzlich den mqtt-client. dann kannst du in den Objecten jeden Datenpunktt für MQTT aktivieren und publischen mit einem dort definierten topic

[mickym]

@homoran Ich hab ja nun die Lösung - und kann auch in meiner mqtt Struktur Datenpunkte anlegen. Das geht.
Ich könnte auch aus dem bisherigen Adapter andere Punkte publishen. Aber so wie es jetzt ist habe ich eine 1:1 Abbildung meiner mosquitto Struktur unter meinem mqtt Adapter.

Ich will nicht zu publishen wo anders schreiben, als zu lesen. Das ist alles andere als intuitiv. Wie gesagt es geht ja - ich wehre mich nur dagegen, dass es grundsätzlich nur in userdata und alias geschrieben wird. Zumindest der mqtt Adapter gehört in meinen Augen nicht dazu - da dieser auch generisch ist. Bei allen anderen Adapter sehe ich es ja ein, dass hier die Hoheit bei den Adapterentwicklern bleiben soll.
Aber man muss das schon etwas differenziert betrachten.

Ich habe ja auch ein Verständnis dafür dass man eine bestimmte Hierarchie erzwingen will. Aber man hätte das ja auch Adapter bzw. Instanzebene konfigurieren können.

Also um es kurz zu machen: Ich kann mir helfen - vielen Dank an alle und meine Meinung ob schreiben unter mqtt sinnvoll ist oder nicht, habe ich kund getan und stehe da halt etwas im Widerspruch zu den Designern des Systems.

Ich will von Euch ungern zu der Gruppe der Stänker gezählt werden - dazu seid ihr mir viel zu wichtig :heart_eyes: . Deshalb bin ich nun lieber ruhig. :)

[Homoran]

@mickym sagte in Datenpunkte Allgemein und .....:

Das geht.

wie heisst es so schön?
"das kann man machen,...."

@mickym sagte in Datenpunkte Allgemein und .....:

Ich will nicht zu publishen wo anders schreiben, als zu lesen

Das sehe ich anders, unter der Bedingung, dass ich das bei dir richtig verstanden habe
Du willst doch Datenpunkte zu deinen Clients publishen, die nicht abonniert sind, oder?

[mickym]

@homoran sagte in Datenpunkte Allgemein und .....:

@mickym sagte in Datenpunkte Allgemein und .....:

Ich will nicht zu publishen wo anders schreiben, als zu lesen

Das sehe ich anders, unter der Bedingung, dass ich das bei dir richtig verstanden habe
Du willst doch Datenpunkte zu deinen Clients publishen, die nicht abonniert sind, oder?

Um es zu verdeutlichen.

Die ganze MQTT Instanz dient als Frontend - und ich publishe nicht einzelne Datenpunkte sondern alles was unter mqtt.1.* ist.

An anderer Stelle habe ich ja mal meine Struktur schon mal gezeigt.

Wenn ich als irgendwas und irgendwo in meinem mqtt - Baum was schreibe, wird Du zu meinem broker gepublished und zwar der ganze Adapter:

Das heißt, wenn ich unter mqtt.1 eine neue Baumstruktur anlege, wird das automatisch auf den Broker in dieser Struktur übertragen 1:1 transparent. Ich muss nichts konfigurieren - wie gesagt diese Instanz ist mein 1:1 Frontend der gesamten MQTT Datenbank.

Ich hab diese Grafik schon mal gezeigt.

Sprich wenn ich den Datenpunkt unter mqtt.1 ändere zum Beispiel um einen Shelly zu steuern, dann mache ich das darin. Das wird automatisch zu mosquitto gepublished und der Shelly subsribed die Datenpunkte auf dem mosquittto.

So brauche ich gar nichts mehr überlegen, was gepublisht oder subscribed wird. Alles unter mqtt.1.* wird bei mir gepublished und von root mit (#) subscribed.

Das ist einfach und transparent - und ich muss nichts überlegen, was ich publishen möchte oder nicht, sondern nur was jeder CLient subscribed oder nicht.

Ich habe noch eine 2. Instanz die published dann aus anderen Adapter unter dem Topic iobroker. Die könnte ich auch noch verwenden, um ggf. noch weitere Datenpunkte aus userdata etc. zu publishen. Aber ich will eine Instanz haben in die ich quasi 1:1 meine mqtt-Broker Datenbank sehe und auch beschreiben will.

Aber nun lassen wir das Thema besser. ;)

[Homoran]

@mickym sagte in Datenpunkte Allgemein und .....:

Aber nun lassen wir das Thema besser.

Nöö :joy:
Ich war nur gestern abend schon im Bett und wollte mir das am Handy nicht antun.

Ich hab dich ja auch vorher schon verstanden!
und wollte mit einem kurzen Frage - Antwort dir die "andere Logik" erläutern:

Datenpunkte gehören dahin wo sie herkommen.

---

Zum Thema MQTT (eigentlich wäre dafür dann ein eigener Thread zur Unterstützung deines Feature Requests sinnvoll):

Ich habe mich schon lange nicht mehr mit MQTT beschäftigt. Aber alle Datenpunkte (bzw. deren Werte), die dir deine Clients schicken nochmal zu publishen, auch wenn du sie nur im ioBroker benötigst halte ich nicht für sinnvoll, wenn auch einfacher zu verwalten.

Auch wenn du keinen zusätzlichen Client einrichten willst, mit dem du selektiv einzelne states sehr flexibel publishen willst, kannst du immer noch im Broker/Client einfach alle 0_userdata.0.mqtt* publishen.

Jetzt aber die Verständnisfrage:
Wieso musst du Datenpunkte anlegen, die du zu deinen Clients publishen willst, wenn der MQTT-Adapter sie nicht selber anlegt.
Dies müsste doch passieren, wenn der Client diese published?

Oder geht es dir nur um das Schreiben in diese Datenpunkte?

[mickym]

@homoran sagte in Datenpunkte Allgemein und .....:

@mickym sagte in Datenpunkte Allgemein und .....:

Aber nun lassen wir das Thema besser.

Nöö :joy:
Ich war nur gestern abend schon im Bett und wollte mir das am Handy nicht antun.

Ich hab dich ja auch vorher schon verstanden!
und wollte mit einem kurzen Frage - Antwort dir die "andere Logik" erläutern:

Datenpunkte gehören dahin wo sie herkommen.

Tun sie ja - die Datenpunkte kommen alle aus meinem MQTT Broker

---

Zum Thema MQTT (eigentlich wäre dafür dann ein eigener Thread zur Unterstützung deines Feature Requests sinnvoll):

Ich habe mich schon lange nicht mehr mit MQTT beschäftigt. Aber alle Datenpunkte (bzw. deren Werte), die dir deine Clients schicken nochmal zu publishen, auch wenn du sie nur im ioBroker benötigst halte ich nicht für sinnvoll, wenn auch einfacher zu verwalten.

Ich publishe die nicht nochmals. Der MQTT Adapter ist zum Glück schlau genug, zu erkennen ob er eine Veränderung vom mqtt-Broker entgegen nimmt oder nicht. Sonst würde er ja in einer Dauerschleife in ein paar Sekunden das System lahmlegen. Wahrscheinlich funktioniert das so mit den ACK Flags.

Auch wenn du keinen zusätzlichen Client einrichten willst, mit dem du selektiv einzelne states sehr flexibel publishen willst, kannst du immer noch im Broker/Client einfach alle 0_userdata.0.mqtt* publishen.

Nochmal das will ich nicht. Ich publishe automatisch das, was ich manuell oder mittels meiner Logikmaschinen ändere und zwar dort, wo es auch herkommt (um das mit Deiner obigen Frage zu verbinden), dort wo es auch herkommt, nämlich vom meinem Broker

Jetzt aber die Verständnisfrage:
Wieso musst du Datenpunkte anlegen, die du zu deinen Clients publishen willst, wenn der MQTT-Adapter sie nicht selber anlegt.
Dies müsste doch passieren, wenn der Client diese published?

Der Client published die Punkte nie, weil ein Client nur Zustände published und keine Punkte in den er Kommandos empfängt.
In der Regel sind im Client vorprogrammiert, welche Themen er subscribed - also auf welche er hört. Solange aber niemand auf diesen "Kanälen" was geschickt hat, gibts die im mqtt einfach nicht. Und das ein Client von sich aus schon mal die Punkte anlegt auf die er selber hört, das gibt es im mqtt nicht, weil dieser dann wiederum eine Endlosschleife erzeugen würde, da im Gegensatz zu einem iobroker Adapter im mqtt kein ACK Flag in dieser Form gibt (wir wollen jetzt nicht über Lvl 0-2 der Übertragung reden).

Wenn ich also ein Kommando schicke, was vorher noch nie geschickt worden ist, muss ich diesen Kommandopunkt anlegen auf den der Client hört und das mache ich in dem Adapter.

Es ist widerspricht diesem Protokoll oder viele haben auch nicht dieses Verständnis (s. loxone Thread), dass ein Client hier Variablen zur Verfügung stellen müsste etc. .

Oder geht es dir nur um das Schreiben in diese Datenpunkte?

So wie es jetzt ist funktioniert das Bestens.

Auch wenn es Eurer Philosopie widerspricht, aber der mqtt-Adapter in dieser Form ist ein perfektes Frontend für einen mqtt-Broker.

Wenn ihr das wegnehmt und ihr für alles lieber eigene Adapter entwickeln wollt, was mqtt spricht, dann überlege ich mir wirklich ob ich das System noch weiter betreiben will.

Für mich ist es einer der Riesenvorteile, dass er so transparent - alle mqtt Kommunikation mit allen Datenpunkten von Adapter mit eigener Kommunikation unter einer Haube transparent vereinigt. Und ich brauche auch kein Feature Request, weil alles da ist.
Ich habe auch schon oft betont, wie toll der iobroker ist, weil man neben den Adaptern - so auch alle Entwicklungen von NodeRed nutzen kann usw.
Ich nutze den mqtt Adapter auch als eine Schnittstelle zu fhem. Ich weiß es gibt für alles einen Adapter. Man kann aber auch auf eine einfache Kommunikationstechnologie setzen und damit Fehlerquellen ausschließen, auch wenn das eine oder andere dann vielleicht etwas unkomfortabler ist.

Im Übrigen auch wenn man den MQTT-(Client/Server)Adapter - oder sogar erst Recht, wenn man diesen MQTT-Adapter als Broker betreibt (und das machen auch einige), wäre doch "Schwachsinn hoch x", wenn man dann in diesen nicht mehr direkt per Logikmaschine schreiben kann, sondern mit einem extra MQTT-Client der dann aus userdata in diese Instanz published. Das wäre die Konsequenz.

Das wäre nicht nur langsam, würde das System nur unnötig belasten und nur "weil es nicht der Philosophie" entspricht. Vielleicht sollte man die Philosophie jedenfalls mal überprüfen inwieweit das mit dem Sinn oder Zweck eines Adapters noch vereinbar ist.

Also wenn das so kommt, dann werde ich mich zumindest hier verabschieden. Ich habe auch schon mehrfach gesagt, dass ich durchaus verstehe, dass manche lieber Sonoff Adapter etc. verwenden, weil sie mit JSON Strings etc. nicht zurechtkommen, aber gerade auch mit dem neuen Javascript Adapter der ja nun automatisch JS-Objekte daraus macht wird die Luft immer dünner, wenn da nicht viel mehr passiert, als JS-Objekte in einzelne Datenpunkte aufzubereiten.

Begreif meine mqtt-Instanz einfach so, wie jeden anderen Adapter in dem ich Datenpunkte schreibe, wie in jedem anderen Datenpunkt und ggf. noch einen zustätzlichen Datenpunkt ohne einen Feature Request an einen Entwickler zu stellen.

[Homoran]

@mickym sagte in Datenpunkte Allgemein und .....:

Auch wenn es Eurer Philosopie widerspricht, aber der mqtt-Adapter in dieser Form ist ein perfektes Frontend für einen mqtt-Broker.

alles gut!
Wie geschrieben, bin ich nicht sooo tief in MQTT drin.

Ich wusste also nicht, dass die Struktur in die du Werte in States des Clients publishen kannst nicht von Anfang an existieren, bzw. war davon ausgegangen, dass der Client bereits vorher einen Status o.ä gepublished hätte.

Jetzt wo ich nochmal drüber nachdenke, hast du natürlich Recht:
@mickym sagte in Datenpunkte Allgemein und .....:

Es ist widerspricht diesem Protokoll

Ich bin damals ohne jegliche Erfahrung zu MQTT gekommen, nachdem ich in Kassel einen Vortrag von @hobbyquaker zum Thema MQTT gehört hatte, in dem dieser so begeistert von diesem leichten Protokoll war, dass ich es mir einfach mal ansehen musste.

@mickym sagte in Datenpunkte Allgemein und .....:

wie jeden anderen Adapter in dem ich Datenpunkte schreibe

und genau jetzt wieder dieselbe "Unpräzision" wie ich eben ;-)
Du schreibst doch nicht wirklich die Datenpunkte in den Adapter-Namespace, oder?

[mickym]

@homoran

und genau jetzt wieder dieselbe "Unpräzision" wie ich eben ;-)
Du schreibst doch nicht wirklich die Datenpunkte in den Adapter-Namespace, oder?

Doch das mache ich!!

Beispiell Shellies:

Diese command Datenpunkte musst Du selbst anlegen, um dann die Shellies darüber steuern zu können. Und dann schreibe ich in diese Datenpunkte über NodeRed (geht natürlich auch mit Blockly oder JS), um so das Licht an und auszuschalten.

Der Datenpunkt existiert am Anfang nicht - und klar man muss in der Shelly Dokumentation nachlesen, welchen Datenpunkt man anlegen muss, den der Shelly dann auch versteht.

So geht es auch mit der gesamten Tasmota cmnd Ast den musst Du auch selbst anlegen. Ich habe mir das Leben hier nur vereinfacht, indem ich mal den Tasmota Device Manager genutzt habe, der all die Datenpunkt einmalig nach mqtt veröffentlicht und ich sie automatisch unter meinem Mqtt-Broker habe.

[Asgothian]

@mickym @Homoran
Ich hab bei dem ganzen Thema aus Neugierde mitgelesen. Die Argumentation von @mickym erscheint mir schlüssig. Trotzdem finde ich es sauber wenn der Admin ein anlegen von states im namespace eines Adapters blockiert.

Letztendlich geht es hier ja um eine kernfunktionalität des Mqtt Protokolls. An dieser Stelle sollte dementsprechend dann auch das Anlegen der states gesteuert werden - sprich von dem Adapter der das mqtt Protokoll bereit stellt. Das sollte in Form einer “publish” Liste auch kein Problem sein und auch keine Dauerschleife auslösen, da diese states dann auch nicht “subscribed” werden sollten.

Damit ist dann auch gleich mit gesichert das die states vom adapter automagisch wieder angelegt werden wenn ein der mit der adapterkonfig wieder aufgesetzt wird.

A.

[mickym]

@asgothian sagte in Datenpunkte Allgemein und .....:

@mickym @Homoran
Ich hab bei dem ganzen Thema aus Neugierde mitgelesen. Die Argumentation von @mickym erscheint mir schlüssig. Trotzdem finde ich es sauber wenn der Admin ein anlegen von states im namespace eines Adapters blockiert.

Letztendlich geht es hier ja um eine kernfunktionalität des Mqtt Protokolls. An dieser Stelle sollte dementsprechend dann auch das Anlegen der states gesteuert werden - sprich von dem Adapter der das mqtt Protokoll bereit stellt. Das sollte in Form einer “publish” Liste auch kein Problem sein und auch keine Dauerschleife auslösen, da diese states dann auch nicht “subscribed” werden sollten.

Damit ist dann auch gleich mit gesichert das die states vom adapter automagisch wieder angelegt werden wenn ein der mit der adapterkonfig wieder aufgesetzt wird.

A.

Ich hab das @Homoran gerade via PN auch geschrieben. Wenn man das Anlegen von states in der mqtt Adapter verhindern will, dann habe ich als NodeRed User die geringesten Probleme, weil ich die States über meine mqtt-out Nodes anlege.

Für alle Blockly und JS User sieht es dann aber blöd aus. Die müssten dann entweder über Kommandozeile eine mosquitto Clients das lösen oder Du würdest halt vorschlagen, dass man über die Konfig des mqtt Adapters states anlegt.

Ich finde das trotzdem umständlicher und frage mich halt, warum es nicht möglich ist, diese Instanzen wie userdata oder alias zu behandeln. Man muss ja nicht in alle Namespaces schreiben können, aber bei diesen "generischen Instanzen", die keine festgelegte Datenstruktur haben, fände ich es auch konsequent und sinnvoll.

[Homoran]

@asgothian sagte in Datenpunkte Allgemein und .....:

Die Argumentation von @mickym erscheint mir schlüssig

mir auch!
Deswegen habe ich immer wieder nachgefragt um seine Sichtweise verstehen zu können.

@asgothian sagte in Datenpunkte Allgemein und .....:

An dieser Stelle sollte dementsprechend dann auch das Anlegen der states gesteuert werden - sprich von dem Adapter der das mqtt Protokoll bereit stellt.

und da bin ich nicht tief genug im MQTT Protokoll drin.
Soweit ich das verstanden habe ist dieses Protokoll extrem schlank und sendet nur das allernötigste.
Wenn jetzt ein Client (Selbstbau-Sensor/Aktor/Wasauchimmer) sich über MQTT meldet wird er nicht alle möglichen "states" melden, mit denen man etwas steuern könnte (wenn ich jetzt @mickym richtig verstanden habe) Trotzdem möchte man über einen Datenpunkt genau dieses erreichen. Dieser gehört zum "Gesamtbild" des Clients und somit in den Objektbaum, wo er von "dem Adapter" nicht angelegt wird.

oder habe ich

@asgothian sagte in Datenpunkte Allgemein und .....:

in Form einer “publish” Liste

so zu verstehen, dass der Adapter dahingehend aufgebohrt werden sollte, dies Punkte anzulegen?

[mickym]

@homoran :+1: :+1: :+1:

[mickym]

@homoran sagte in Datenpunkte Allgemein und .....:

@asgothian sagte in Datenpunkte Allgemein und .....:

in Form einer “publish” Liste

so zu verstehen, dass der Adapter dahingehend aufgebohrt werden sollte, dies Punkte anzulegen?

Das hab ich so verstanden, habe auch schon darauf geantwortet. Das ist zwar richtig, aber wäre wesentlich weniger intuitiv. Ich muss ja jedes Mal die Adapterkonfig aufmachen, um Datenpunkte zu erstellen.

Ist zwar ein Weg, aber halt nicht so schön wie heute - ich fände es besser hier lieber für generische Adapter generell eine Ausnahme zu machen. :)

[Asgothian]

@homoran sagte in Datenpunkte Allgemein und .....:

so zu verstehen, dass der Adapter dahingehend aufgebohrt werden sollte, dies Punkte anzulegen?

So war das zu verstehen. Wenn ich mqtt korrekt verstanden habe ist derjenige der Informationen published dafür verantwortlich diese dem Server kund zu tun. Nur weil ein Client einen bestimmten “Pfad” subscribed heißt das nicht das der Server bei allen Clients nachfragt wer den bereitstellen kann.

Da ich das selber nur in extrem geringem Maße nutze macht es wenig Sinn das als PR in die Adapter (sonoff, mqtt, hab ich einen vergessen) zu bringen.

A.