Datenpunkte Allgemein und .....
-
-
@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.
-
@asgothian Noch eine Ergänzung zur Datensicherheit:
Der mqtt-Adapter ja nicht als mqtt-Broker konfiguriert, sondern als mqtt-Client, der mir den Inhalt meiner mqtt-Datenbank zur Verfügung stellt - sowohl zum Schreiben, wie zum Lesen.
Solange ich also den mqtt-Adapter nicht als Broker betreibe (hat andere Gründe), sondern als Client und FrontEnd - kann ich den Adapter komplett löschen. Sobald ich den neu anlege und mich mit meinem mosquitto Broker wieder verbinde, sind alle Daten und Strukturen wieder aktuell und vollständig!
-
@mickym sagte in Datenpunkte Allgemein und .....:
@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.
- Aktuell werden die states mit gesichert.
- ich hatte den fall das sich eine Sicherung der states nicht sauber zurück spielen liess.
- wenn die vom adapter selber verwalteten States im Adapter konfiguriert sind dann sollten sie als Teil der internen Konfiguration ohne die Notwendigkeit weiterer Sonderbehandlung im Backup verfügbar sein.
A.
-
@asgothian sagte in Datenpunkte Allgemein und .....:
@mickym sagte in Datenpunkte Allgemein und .....:
@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.
- Aktuell werden die states mit gesichert.
- ich hatte den fall das sich eine Sicherung der states nicht sauber zurück spielen liess.
- wenn die vom adapter selber verwalteten States im Adapter konfiguriert sind dann sollten sie als Teil der internen Konfiguration ohne die Notwendigkeit weiterer Sonderbehandlung im Backup verfügbar sein.
A.
OK - wie gesagt ich betreibe den mqtt-Adapter nur als FrontEnd und somit als Client, deswegen kann ich den beliebig löschen, da die Daten alle im mosquitto gespeichert sind.
Dafür schuftet dieser Adapter aber auch ordentlich.
Aber danke hab es glaub schon verstanden.
-
Im Prinzip ist das ganze mqtt eingentlich von der Konzeption sowieso darauf ausgerichtet, eigentlich keine Objekte und Daten zu speichern, sondern nur aktuelle Zustände. Man kann zwar mit retain - States speichern, aber das sollte man eher vermeiden. Das widerspricht der Konzeption. Insofern einmal was publishen und dann ist es vergessen. Das erkennt man auch daran, dass man States in einem mqtt-Broker nicht löschen kann. Sprich wenn man States als Retain speichert (weil diese von den Clients vielleicht nur alle heiligen Zeiten veröffentlich werden), dann muss man die gesamte mosquitto Datenbank löschen. Wenn man das macht, muss man sowieso auch alle Datenpunkte in dem mqtt-Adapter manuell löschen, da sonst Datenpunkte existieren, die es im mqtt-Broker nicht gibt bzw. die bei Aktualisierung dann im mqtt-Broker wieder angelegt werden.
Im Prinzip verwaltet so ein mqtt-Broker nur, welche topics welche Clients bekommen sollen und informiert diese einmal bei einer Aktualisierung und sonst nicht mehr. Wurden alle abonnierenden Clients benachrichtigt und der Zustand mit retain nicht zur Speicherung gezwungen, existiert der State ab diesem Zeitpunkt quasi nicht mehr und es ist Aufgabe des Clients diesen Zustand dann ggf. zu speichern bzw. zu verarbeiten. Man muss sich also auch nicht um Bereinigung von Daten etc. kümmern - ich finde diese Einfachheit der Idee eigentlich super genial.Das man das aus Debug Gründen gerne sehen möchte, welche States als letztes gesendet werden, ist eine andere Geschichte. Auch dass sich ein mqtt-Broker deshalb nicht eignet um Konfigurationsdaten zu speichern, versteht sich von selbst.
Ansonsten finde ich das mqtt-Konzept eigentlich ziemlich genial mit der Philosophie nur Momentaufnahmen zu liefern und jeder Client sich das selbst abholen muss. Gibt natürlich auch keine History - sodass es keine DB im herkömmlichen Sinn ist.
