Datenpunkte Allgemein und .....

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

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

[Homoran]

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

wäre wesentlich weniger intuitiv.

Naja, das haben wir in sehr vielen Adaptern, dass alle "Clients" einzeln konfiguriert werden. (shuttercontrol/snmp fallen mir jetzt spontan ein)

[mickym]

@asgothian Die anderen Adapter wie Shelly und Sonoff etc. stellen natürlich von sich aus die "kommando"-Datenpunkte zur Verfügung, weil sie eben anhand der Geräte wissen, welche zur Verfügung gestellt werden müssen.
Das Problem, das diese Adapter halt haben - kommt ein neues Gerät mit einer anderen Kommandostruktur raus, muss dieser Adapter sofort angepasst werden, sonst werden diese Geräte nicht unterstützt. Bei mqtt kann das der Anwender selbst anhand der Herstellerdokumentation machen.
Aber das habe ich auch schon oft moniert, dass der Sonoff halt kein mqtt Adapter ist.

Sobald ein Gerät ein Kommando braucht, dass der Adapter nicht kennt - gibt es meistens ein Problem. Deswegen muss man das nicht auf alle Adapter die mqtt sprechen ausweiten.

Im Übrigen gibt es ja auch eine Menge Geräte mehr, die ich über den mqtt-Adapter steuern kann, für die es gar keinen Adapter im iobroker gibt.

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

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

wäre wesentlich weniger intuitiv.

Naja, das haben wir in sehr vielen Adaptern, dass alle "Clients" einzeln konfiguriert werden. (shuttercontrol/snmp fallen mir jetzt spontan ein)

OK - dann müsste man aber die Adapterkonfig so schön machen, dass man den Namespace des Adapters quasi auch als aufklappbare Objekteansicht darstellt.

Eine weitere Idee - wäre ggf. die Objektansicht über einen eigenen Menüpunkt links auf den mqtt-Namespace zu begrenzen und darüber das Erstellen zu erlauben.

[Asgothian]

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

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.

Weniger intuitiv würde ich nicht sagen. Eine Umstellung für Dich - sicher. Du hast dich an das andere gewöhnt.
Für mich ist es eher wenig intuitiv das ich eine state von Hand (via Admin) anlegen muss damit dieser vom mqtt “published” wird. Ich hätte dafür eine Konfiguration im Adapter erwartet, und habe die andere Variante letztendlich nur in Kauf genommen da es nichts anderes gab.
Es hat meiner Meinung nach noch einen weiteren positiven Nebeneffekt. Die States die der Adapter “publishen” will sind in der adapterkonfiguration angegeben. Wenn dir also die states.db kaputt geht hast du trotzdem noch die Liste der States die der Adapter selbstständig wieder anlegt. Des Weiteren kann dann der Adapter ohne Risiko bei. Deinstallieren gleich alle seine states löschen und hinterlässt damit keine zombie states.

Aus meiner Sicht viel sauberer als das anlegen per Hand.

A.

[mickym]

@asgothian Im Moment geht mir doch nichts kaputt - ich hoffe mal der backitup Adapter stellt sämtlich Objekte auch in dem namespace wieder her.

[Homoran]

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

ich hoffe mal der backitup Adapter stellt sämtlich Objekte auch in dem namespace wieder her.

wenn es in der Instanzenkonfig steht ist die Chance 100%

[mickym]

@homoran Hier mal die Idee - wie man das genauso intutiv lassen könnte - aber halt quasi das Schreiben über den "mqtt-Adapter" ermöglichen könnte:

Das heißt man lässt quasi nur über eine eigene mqtt-Ansicht das Schreiben zu,

[Homoran]

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

Hier mal die Idee - wie man das genauso intutiv lassen könnte

Eher so:

Tabelle mit Clients und deren states, ggf noch als Untermenü zum aufklappen

[mickym]

@homoran Na über Geschmack und Benutzerfreundlichkeit lässt sich streiten - aber im Prinzip glaub ist zu dem Thema alles gesagt.

Dann schon lieber so: