Datenpunkte Allgemein und .....
-
@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.
-
So, ich habe den Thread per Link gefunden, ist ja auch hier recht "Heiss" geworden.
Zu "mqtt" als "Sonderfall den man nochmal diskutieren sollte" haben wir glaube Samstag schon gerschrieben und ein GitHub Issue angelegt weil es auch in meinen Augen sinn macht hier Objekterstellung ala javascript.0/0_userdata.0 zu erlauben.
Das Thema wurde im ganzen mehrere Monatigen dmin5 Beta test VON KEINEM auch nur einmal aufgebracht ... jetzt gebt uns auch paar Tage das zu lösen.
Alle tief durchatmen bitte, GitHub Issue voten und Geduld haben und im Notfall über zweite Admin Instanz alte UI vorerst nutzen.
