Datenpunkte Allgemein und .....
-
@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.
-
@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.
