Datenpunkte Allgemein und .....
-
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.
-
@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.
-
@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.
-
@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?
-
-
@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.
-
@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.
-
@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)
-
@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.
-
@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.
-
@asgothian Im Moment geht mir doch nichts kaputt - ich hoffe mal der backitup Adapter stellt sämtlich Objekte auch in dem namespace wieder her.
-
@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%
-
@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,
-
@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
-
@homoran Na über Geschmack und Benutzerfreundlichkeit lässt sich streiten - aber im Prinzip glaub ist zu dem Thema alles gesagt.
Dann schon lieber so:
-
@mickym sagte in Datenpunkte Allgemein und .....:
Dann schon lieber so:
was ist das?
den kenn ich nichtnur:
SNMP
oder parser
irgendwas in der Richtung - Brainstorming ist angesagt
-
-
@homoran sagte in Datenpunkte Allgemein und .....:
@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%
Ehrlich gesagt - bin ich davon ausgegangen, dass der BackitUp Adapter alle Objekte und States sichert. Sonst würde ja bei einem Restore nicht nur die Konfig wiederhergestellt, sondern müsste ggf. alle States neu schreiben.
-
@mickym sagte in Datenpunkte Allgemein und .....:
dass der BackitUp Adapter alle Objekte und States sichert
Gute Frage. Ich weiß es nicht, das müsste die @simatec beantworten, aber die objects.db und states.db werden wohl auch gesichert, sonst wären ja alle eigenen DP weg
-
@Asgothian @Homoran
Ehrlich gesagt, tut mir der Adapterentwickler des mqtt-Adapters jetzt schon leid, weil dem bislang wahrscheinlich die Struktur unter dem mqtt-Namespace bislang vollkommen wurscht war.Wie gesagt die Objektstruktur auslesen und nur mit Genehmigung des Adapterentwicklers schreiben ist ja OK. ;), aber gespeichert wird die Struktur sicherlich nicht.
Und falls nicht alle Objekte und States gesichert werden, dann müsste @simatec für den mqtt-Adapter ja ein ähnliches Backup, wie für den Zigbee Adapter anbieten, da da ja die Datenstruktur sich ebenfalls mit jedem dazugekommenen Gerät ändert.
