letzter Wille und Testament \/ am Leben erhalten<\/h2>\n
Die Clients k\u00f6nnen eine Verbindung herstellen, eine Nachricht ver\u00f6ffentlichen und die Verbindung beenden oder eine dauerhafte Verbindung zum Server aufrechterhalten. Im Falle einer dauerhaften Verbindung werden Keepalives gesendet. Wenn der Client innerhalb des beim Verbindungsaufbau vereinbarten Zeitrahmens keine Keepalives sendet, kann der Server (Broker) eine so genannte Last-Will-and-Testament-Nachricht senden, die der Client beim Verbindungsaufbau \u00fcbermittelt hat. Diese Nachricht kann beliebig sein und kann ver\u00f6ffentlicht werden an ein einziges Thema pro Verbindung<\/b>. Der Broker sendet sie an alle Kunden, die sich f\u00fcr dieses Thema angemeldet haben.<\/p>\n
Wenn der Kunde die Verbindung ordnungsgem\u00e4\u00df beendet, wird das Testament nicht ver\u00f6ffentlicht.<\/p>\n
Die Funktion \"Keep Alive\" ist vor allem f\u00fcr mobile Clients n\u00fctzlich, bei denen die Verbindung unterbrochen werden kann (z. B. bei schlechten Netzwerken, Tunneln usw.).<\/p>\n
Siehe auch:<\/h2>\n
http:\/\/www.steves-internet-guide.com\/checking-active-mqtt-client-connections\/<\/a><\/p>\n http:\/\/www.steves-internet-guide.com\/mqtt-last-will-example\/<\/a><\/p>\n https:\/\/owntracks.org\/booklet\/tech\/mqtt\/<\/a><\/p>\n Jeder Client, der sich mit einem MQTT-Broker verbindet, sollte eine eindeutige Client-ID haben. Clients, die sich mit der gleichen Client-ID verbinden, beenden die vorherige Verbindung und \u00fcbernehmen die neue. Wenn Sie zwei Clients mit der gleichen Client-ID haben, kann dies zu einem Ping-Pong von getrennten Verbindungen f\u00fchren.<\/p>\n Die zuletzt<\/b> Eine erhaltene Nachricht an ein Thema wird gespeichert und an alle neuen Abonnenten dieses Themas zugestellt. Dies kann f\u00fcr die Kommunikation von Ger\u00e4testatus \/ Konfiguration \/ etc. verwendet werden.<\/p>\n Sie setzen den Aufbewahrungszustand als Kennzeichen pro Nachricht.<\/p>\n Zur\u00fcckgehaltene Nachrichten k\u00f6nnen f\u00fcr viele interessante Dinge verwendet werden, z. B. zur Erleichterung der automatischen Suche (siehe Vorschlag 4 unten).<\/p>\n Es gibt drei Stufen der Dienstg\u00fcte, die bestimmen, wie viel Overhead bei der Verarbeitung einer Nachricht anf\u00e4llt. Je h\u00f6her die Stufe, desto mehr Overhead. <\/p>\n Die QoS kann f\u00fcr jede an den Broker gesendete Nachricht und w\u00e4hrend des Abonnements festgelegt werden. Der niedrigere der beiden Werte wird f\u00fcr die tats\u00e4chliche Zustellung der Nachricht verwendet.<\/p>\n Weitere Einzelheiten finden Sie hier:<\/p>\n https:\/\/www.eclipse.org\/paho\/files\/mqttdoc\/MQTTClient\/html\/qos.html<\/a><\/p>\n Bei Themennamen wird zwischen Gro\u00df- und Kleinschreibung unterschieden, und es handelt sich um UTF-8-Strings. Es ist ratsam, sich auf druckbare ASCII-Zeichen zu beschr\u00e4nken, um die Fehlersuche zu erleichtern.<\/p>\n Themennamen m\u00fcssen aus mindestens einem Zeichen bestehen, um g\u00fcltig zu sein. <\/p>\n \/<\/p>\n ist bereits ein Themenname<\/p>\n Die $SYS<\/b> ist f\u00fcr die Broker-Nutzung\/Statistik gedacht.<\/p>\n Sie haben die Wahl, ob Sie die Informationen in der Themenstruktur oder in der Nachricht unterbringen. Eine JSON-Struktur f\u00fcr die Nachricht hilft Ihnen dabei, sie mit weiteren Daten zu erweitern.<\/p>\n Bedenken Sie, dass bei jedem Aufruf des Brokers das Topic in der Nutzlast des MQTT-Pakets mitgeschickt wird - versuchen Sie daher, unn\u00f6tige L\u00e4ngen zu vermeiden.<\/p>\n Wenn Sie z. B. mehrere Temperatursensoren haben, k\u00f6nnen Sie problemlos Nachrichten f\u00fcr alle von ihnen abonnieren, wenn Sie Ihren Themenbaum richtig gestalten.<\/p>\n Wild Cards sind nur f\u00fcr Abonnenten gedacht, sie sind nicht zur Ver\u00f6ffentlichung zugelassen.<\/b><\/p>\n Sie k\u00f6nnen alle Themen abonnieren mit #<\/b><\/p>\n mit Ausnahme des Themas $SYS. Verwenden Sie $SYS\/#, um alle Themen f\u00fcr $SYS zu abonnieren <\/b><\/p>\n M\u00f6glicherweise k\u00f6nnen Sie durch die Verwendung des Teils \"Funktion\" vor der Ger\u00e4tekennung bestimmte Kan\u00e4le leichter abonnieren.<\/p>\n Wenn Sie zum Beispiel Ihre Pfade wie folgt definieren tele\/room1\/sensorname1 tele\/room2\/sensorname2<\/i> usw. und stat\/room1\/sensorname1 stat\/room1\/sensorname2<\/i> Abonnements sind m\u00f6glich auf:<\/p>\n tele\/#<\/p>\n stat\/#<\/p>\n Wenn Sie es andersherum machen, mit Sensor1\/Stat <\/i>und sensor2\/stat<\/i>usw. k\u00f6nnen Sie verwenden <\/p>\n +\/stat <\/p>\n um Statistiken zu abonnieren, aber nicht in beliebiger Tiefe wie im vorherigen Beispiel. Das hei\u00dft, der Pfad zu Ihrem Sensor muss aus genau einer Komponente bestehen. <\/p>\n Wenn Sie die Aktion vorwegnehmen, werden Ihre Pfade konsistenter sein.<\/p>\n Siehe zum Beispiel https:\/\/stevessmarthomeguide.com\/setting-up-the-sonoff-tasmota-mqtt-switch\/<\/a><\/p>\n - Verwenden Sie keinen vorangestellten Schr\u00e4gstrich (z. B. \/mytopics ), um Ihren Themenbaum zu beginnen - das ist ein zus\u00e4tzlicher Aufwand, der keinen Wert hat. <\/p>\n - Nicht verwenden $SYS<\/b> als Startthema, dies ist dem Makler vorbehalten<\/p>\n - Verwenden Sie keine Leerzeichen im Thema<\/p>\n - Verwenden Sie keine nicht druckbaren Zeichen im Thema<\/p>\n - ein MQTT-Topic f\u00fcr Nachrichten mit unterschiedlicher Bedeutung verwenden - verschiedene Topics f\u00fcr sie erstellen<\/p>\n - Client-ID in den Themenbaum einbetten<\/p>\n - spezifische Themen f\u00fcr die individuelle Adressierung (z.B. von Sensoren) erstellen, anstatt alle Werte \u00fcber ein Thema zu senden - dadurch wird vermieden, dass Nachrichten an Empf\u00e4nger gesendet werden, die sie nicht ben\u00f6tigen<\/b><\/p>\n - Versuchen Sie, die Themennamen kurz zu halten (da sie bei jeder Ver\u00f6ffentlichung und Nachricht gesendet werden) <\/p>\n - \u00fcberlegen, welche Daten wie oft gesendet werden m\u00fcssen<\/p>\n o z.B. erw\u00e4gen, Metadaten in ein eigenes Thema auszugliedern und mit einem \"Retain\"-Flag zu ver\u00f6ffentlichen<\/p>\n - Befehls-\/Cmd- und Statusthemen f\u00fcr ein Ger\u00e4t trennen - auf diese Weise wird eine bidirektionale Kommunikation m\u00f6glich, und das Ger\u00e4t muss seine eigenen Nachrichten nicht filtern.<\/p>\n - eine testamentarische Nachricht verwenden, um auf eine unerwartete Trennung des Kunden hinzuweisen<\/p>\n M\u00fcssen Sie mehrere Kunden \/ Organisationen \/ unabh\u00e4ngige Anwendungen unterst\u00fctzen? Es gibt die M\u00f6glichkeit, z. B. mit VerneMQ, verschiedene Mountpoints zu verwenden. Eine weitere Alternative besteht darin, die Mehrmandantenf\u00e4higkeit in Ihren Themenbaum aufzunehmen (durch Verwendung eines entsprechenden Pr\u00e4fixes am Anfang des Themenbaums).<\/p>\n Ich bevorzuge den ersten Weg, da er eine zus\u00e4tzliche Ebene der ACL-Trennung bietet - und weniger M\u00f6glichkeiten, etwas zu \"vermasseln\".<\/p>\n Au\u00dferdem m\u00f6chten Sie vielleicht mehrere MQTT-Broker miteinander verbinden und einen Teil ihrer Themenb\u00e4ume (wie durch ihre ACLs definiert) gemeinsam nutzen. <\/p>\n Weitere Informationen zur \u00dcberbr\u00fcckung finden Sie unter https:\/\/owntracks.org\/booklet\/guide\/bridge\/. <\/p>\n MQTT kann \u00fcber verschl\u00fcsselte Netzwerke (z.B. \u00fcber Websockets \/ TLS verschl\u00fcsselt) oder \u00fcber unverschl\u00fcsselte Kan\u00e4le betrieben werden. Zus\u00e4tzlich k\u00f6nnen Sie die Nutzlast Ihrer Daten verschl\u00fcsseln und\/oder signieren.<\/p>\n Erw\u00e4gen Sie, Themen einzubauen, die die Auffindbarkeit von Diensten und F\u00e4higkeiten Ihrer Ger\u00e4te erleichtern, z. B. durch die Verwendung gespeicherter Nachrichten.<\/p>\n Wenn Sie einen Befehl ver\u00f6ffentlichen, haben Sie keinen unmittelbaren R\u00fcckkanal. Daher k\u00f6nnte es sinnvoll sein, eine Hierarchie f\u00fcr spezifische R\u00fcckmeldungen zu bestimmten Befehlen einzurichten - ob das Ger\u00e4t den Befehl erhalten hat und ausf\u00fchren konnte, um dem Benutzer eine R\u00fcckmeldung geben zu k\u00f6nnen.<\/p>\n Ein Muster, das ich hier anzuwenden gedachte, war die Vergabe eindeutiger Befehlskennungen als Teil der Nutzlast der Nachricht, die im R\u00fcckkanal mit einem Statuscode referenziert werden.<\/p>\n M\u00f6chten Sie, dass mehrere Ger\u00e4te auf eine einzige von Ihnen ver\u00f6ffentlichte Nachricht reagieren? Denken Sie daran, dass Sie keine Platzhalterthemen ver\u00f6ffentlichen k\u00f6nnen - Sie k\u00f6nnen sie nur abonnieren. In diesem Fall sollten zus\u00e4tzliche Themen erstellt werden, die es den Clients erm\u00f6glichen, auf Multicast-Szenarien zu reagieren. Alle Clients \/ alle Clients einer bestimmten Gruppe w\u00fcrden das Multicast-Thema abonnieren und auf die Nachrichten reagieren.<\/p>\n Kombiniert man dies mit meinem obigen Vorschlag zur R\u00fcckmeldung \/ Bezugnahme auf die Befehls-ID, wird eine neue Anforderung an die Client-ID als Nutzlast im (generischen) R\u00fcckmeldekanal eingef\u00fchrt. Eine andere M\u00f6glichkeit ist, die Ger\u00e4te auf ihren individuellen R\u00fcckmeldekan\u00e4len antworten zu lassen - wobei die Ger\u00e4te-ID bereits Teil des Pfades ist. (Das hei\u00dft, sie empfangen einen Befehl auf dem Multicast-Pfad, antworten aber in ihrer eigenen exklusiven Nachrichtenhierarchie).<\/p>\n Wenn Sie ein kommerzielles System betreiben, das z. B. Sensordaten f\u00fcr Benutzer sammelt, m\u00f6chten diese vielleicht genau steuern k\u00f6nnen, welche Sensorwerte \u00fcberhaupt ver\u00f6ffentlicht werden.<\/p>\n Au\u00dferdem erh\u00f6ht die automatische Ver\u00f6ffentlichung aller Sensormesswerte den Datenverkehr und die Belastung Ihres Servers bzw. Ihrer Server.<\/p>\n Daher ist es m\u00f6glicherweise nicht die beste Wahl, einfach alle verf\u00fcgbaren Sensorwerte an Ihren MQTT-Broker zu senden. Eine M\u00f6glichkeit besteht darin, ein \"Retained Topic\" mit einer Konfiguration zu erstellen, die der Client abonnieren kann. Wenn der Client eine Verbindung herstellt, empf\u00e4ngt er automatisch die Konfiguration im Retained Topic und kann die Werte, die er ver\u00f6ffentlicht, entsprechend der Konfiguration anpassen. Au\u00dferdem kann er auf Konfigurations\u00e4nderungen reagieren, indem er auf alle zus\u00e4tzlichen Nachrichten reagiert, die in diesem Konfigurationsthema eingehen.<\/p>\n Au\u00dferdem ist es wichtig zu ber\u00fccksichtigen, dass es verschiedene Arten von Sensoren gibt. Bei einem T\u00fcrsensor w\u00e4ren Sie beispielsweise an einer Status\u00e4nderung (geschlossen vs. offen) interessiert, w\u00e4hrend Sie bei einem Temperatursensor vielleicht kontinuierliche Messwerte erhalten m\u00f6chten. Es ist wichtig, dass Sie bei Ihrem Entwurf ber\u00fccksichtigen, welche Art von Werten die Teilnehmer erhalten, wenn der f\u00fcr die Sensormesswerte zust\u00e4ndige Client die Verbindung trennt. Denken Sie daran, dass Sie einen letzten Willen nur f\u00fcr ein Thema festlegen k\u00f6nnen (bei Multisensorger\u00e4ten). Im Falle einer Verbindungsunterbrechung k\u00f6nnten zur\u00fcckbehaltene Nachrichten einen falschen Eindruck vermitteln (z. B. dass die T\u00fcr offen ist, obwohl sie in Wirklichkeit geschlossen ist, aber nicht aktualisiert wurde usw.). <\/p>\n Wenn jedoch beispielsweise Ihr Webinterface, das den Client steuert, erst verbunden wird, nachdem der T\u00fcrsensor-Client bereits eine Weile verbunden war, und Sie nicht gespeicherte Nachrichten verwenden, wird die Nachricht \u00fcber die letzte Aktualisierung des T\u00fcrstatus verpasst; <\/p>\n Hier gibt es zwei M\u00f6glichkeiten: <\/p>\n In jedem Fall sollte der Benutzer darauf hingewiesen werden, ob einem Sensormesswert vertraut werden kann oder ob er m\u00f6glicherweise aufgrund eines nicht verbundenen Sensor-Clients falsch ist.<\/p>\n Siehe auch http:\/\/www.steves-internet-guide.com\/mqtt-sensors-traffic-observations\/<\/a><\/p>\n Dinge, die f\u00fcr einen Menschen von Bedeutung sind, bilden die Themenstruktur: (\"semantischer Ansatz\")<\/b><\/p>\n Haus\/Bad\/Luftfeuchtigkeit<\/p>\n Ger\u00e4tepfade (an welche Ger\u00e4te sind die Sensoren angeschlossen, wie werden sie angesprochen?) erstellen die Themenstruktur: (\"physikalischer Ansatz\")<\/b><\/p>\n pi\/00000234898324734\/i2c\/10\/pressure<\/p>\n (die Zahlen symbolisieren die BCM-Seriennummer bzw. die I2C-Adresse).<\/p>\n Neuver\u00f6ffentlichung<\/b><\/p>\n Bei dieser Idee w\u00fcrden Sie beide Ans\u00e4tze kombinieren und einen zus\u00e4tzlichen Dienst schaffen, der zwischen den beiden Welten vermittelt.<\/p>\n Siehe: https:\/\/tinkerman.cat\/post\/mqtt-topic-naming-convention<\/a><\/p>\n von: https:\/\/raspberry-valley.azurewebsites.net\/MQTT-Topic-Trees\/<\/a><\/p>\n ger\u00e4tekategorie\/ger\u00e4te-id\/zahllast-kontext\/zahllast-differentiator<\/p>\n Beachten Sie die Symmetrie zwischen Ger\u00e4tekategorie\/Ger\u00e4te-ID und Nutzlast-Kontext\/Nutzlast-Unterscheidungsmerkmal (allgemein-> spezifisch; allgemein-> spezifisch)<\/p>\n (Von Steve): http:\/\/www.steves-internet-guide.com\/mqtt-topic-payload-design-notes\/<\/a><\/p>\n Sie k\u00f6nnen die folgenden Elemente in Ihren Themenbaum aufnehmen:<\/p>\n Steves Ansatz:<\/p>\n MQTT Smarthome Vorschlag<\/p>\n https:\/\/github.com\/mqtt-smarthome\/mqtt-smarthome<\/a><\/p>\n Ein Pfad sieht in diesem Vorschlag wie folgt aus:<\/p>\n toplevelname\/funktion\/item<\/p>\n knxgateway1\/status\/K\u00fcche\/Lichter\/Vorne links<\/p>\n Das Interessante sind die Funktionen und ihre Position vor<\/b> die tieferen Pfade (beachten Sie die Platzhalter f\u00fcr das Abonnement - auf diese Weise k\u00f6nnen Sie alle Ger\u00e4testatusberichte einfach abonnieren!)<\/p>\n Verf\u00fcgbare \/ definierte Funktionen in diesem Vorschlag:<\/p>\n Die nachfolgenden Hierarchien f\u00fcr die einzelnen Verben sollten einander entsprechen, so dass Sie dasselbe Ger\u00e4t \/ denselben Knoten \/ Parameter ansprechen w\u00fcrden.<\/p>\n Es gibt ein spezielles Thema \"verbunden\" pro Gateway, das es dem Kunden erlaubt, eine testamentarische Nachricht zu setzen <\/p>\n toplevelname\/verbunden <\/p>\n sind f\u00fcr dieses Thema einfache Werte definiert:<\/p>\n Beachten Sie, dass der Wert 0 nicht zwischen freiwilligen Verbindungsabbr\u00fcchen oder einem Verbindungsabbruch (bei dem die Keepalives eine Zeit\u00fcberschreitung aufweisen) unterscheidet. <\/p>\n Es gibt auch Vorschl\u00e4ge f\u00fcr die Nutzlast:<\/p>\n Die JSON-Kodierung der Nutzdaten ist optional.<\/p>\n Im Falle der JSON-Kodierung befindet sich der Wert immer im Schl\u00fcssel \"val\". Zus\u00e4tzlich, <\/p>\n ts : Zeitstempel (Zeitstempel, Millisekunden seit Epoch)<\/p>\n lc : letzte \u00c4nderung des Wertes (Zeitstempel, Millisekunden seit Epoch)<\/p>\n https:\/\/tinkerman.cat\/post\/mqtt-topic-naming-convention<\/a><\/p>\n \u00dcberlegen Sie, ob Sie einen \"semantischen\" Ansatz (z. B. Dinge, die f\u00fcr den Menschen von Bedeutung sind) oder einen \"physischen\" Ansatz (z. B. tats\u00e4chliche Ger\u00e4tepfade, an die Ihr System angeschlossen ist) w\u00e4hlen.<\/p>\n Der physische Ansatz ist maschinenfreundlicher.<\/p>\n (Bitte beachten Sie, dass Tinkermans und mein Verst\u00e4ndnis von Mountpoints und deren Verwendung voneinander abweichen - f\u00fcr mich sind Mountpoints komplett getrennte Themenb\u00e4ume, z.B. f\u00fcr Multi-Tenancy)<\/p>\n Metadaten k\u00f6nnen als Postfix-Pfade kodiert werden.<\/p>\n z.B.. <\/p>\n \/home\/schlafzimmer\/temperatur -> 21<\/p>\n \/home\/Schlafzimmer\/Temperatur\/Einheiten -> \u00b0C<\/p>\n \/home\/bedroom\/temperature\/timestamp -> 2012-12-10T12:47:00+01:00<\/p>\n Hinweis: Da es unwahrscheinlich ist, dass sich die Einheiten und einige andere Metadaten \u00e4ndern, k\u00f6nnen sie als beibehaltene Themen gesendet werden.<\/p>\n Ein interessanter Teil dieses Vorschlags ist auch die Aggregation (Ger\u00e4teseite):<\/p>\n \/home\/bedroom\/temperature\/last -> letzter Temperaturwert<\/p>\n \/home\/schlafzimmer\/temperatur\/letzter\/zeitstempel<\/p>\n \/home\/bedroom\/temperature\/last24h\/max -> H\u00f6chstwert in den letzten 24h <\/p>\n \/home\/bedroom\/temperature\/last24h\/max\/timestamp -> Zeitstempel, an dem die Temperatur so hoch war<\/p>\n \/home\/schlafzimmer\/temperatur\/last24h\/min<\/p>\n \/home\/bedroom\/temperature\/ever\/max -> die absolut h\u00f6chste jemals gemessene Temperatur<\/p>\n Auch diese Werte k\u00f6nnten als beibehaltene Themen eingestellt werden (insbesondere \"immer\"), um Netzwerkverkehr zu sparen - das empfangende System k\u00f6nnte \u00e4ltere beibehaltene Werte verwerfen (wenn der Sensor nicht mehr angeschlossen ist, was durch ein anderes Thema ersichtlich sein sollte - m\u00f6glicherweise durch Testament & Testament eingestellt), oder das System k\u00f6nnte sie als \"veraltete\" Werte anzeigen. <\/p>\n Dies ist ein interessantes Design (f\u00fcr die Aggregation) und k\u00f6nnte als Inspiration dienen, um diese Art von Flexibilit\u00e4t zu erm\u00f6glichen.<\/p>\n https:\/\/homieiot.github.io\/<\/a><\/p>\n Home IoT konzentriert sich auf die Auffindbarkeit von Knoten in der IoT-Heimautomatisierungsumgebung. Homie verwendet keine JSON-kodierten Nachrichten, sondern eine direkte Darstellung der Nutzdaten f\u00fcr jeden Knoten. Siehe dieses Beispiel:<\/p>\n Homie definiert einen strengen Zeichensatz, den Sie f\u00fcr die Benennung Ihrer Knoten verwenden d\u00fcrfen, da Sonderzeichen (z.B. $ und der Unterstrich _) f\u00fcr besondere Zwecke verwendet werden.<\/p>\n Sie definiert Datentypen, die als (beibehaltene) Metadaten (\"Attribute\") zu $datatype der einzelnen Eigenschaft ver\u00f6ffentlicht werden (siehe unten f\u00fcr die Definition von Eigenschaft): <\/p>\n (beachten Sie die Verwendung des $ zur Kennzeichnung besonderer Themen).<\/p>\n Letzter Wille wird verwendet, um das Ger\u00e4t als verloren zu markieren:<\/p>\n Homie\/deviceID<\/i>\/$state -> verloren<\/p>\n Homie definiert 6 m\u00f6gliche Staaten<\/b> f\u00fcr das Ger\u00e4t:<\/p>\n Homie empfiehlt die Verwendung von QoS 1<\/b> (da die Natur von Homie es sicher f\u00fcr doppelte Nachrichten macht).<\/p>\n Eine R\u00fcckstellung f\u00fcr Erweiterungen<\/b> wird mit einer umgekehrten Dom\u00e4nennamensyntax erstellt, z. B. org.mycompany.homie-extension<\/p>\n Knotenpunkte und Ger\u00e4te<\/b><\/p>\n In Homie-parlance, einem Ger\u00e4t<\/b> ist die grundlegende Hardware-Einheit. Zum Beispiel ein Raspberry Pi, eine Kaffeemaschine, ein Auto.<\/p>\n A Knoten<\/b> ist eine logische, unabh\u00e4ngige Einheit des Ger\u00e4ts. Ein Auto kann beispielsweise einen Knoten \"R\u00e4der\", einen Knoten \"Motor\" und einen Knoten \"Beleuchtung\" haben. <\/p>\n Eigenschaften<\/b> stellen grundlegende Eigenschaften des Knotens\/Ger\u00e4ts dar. Ein Auto k\u00f6nnte z. B. eine Eigenschaft \"Geschwindigkeit\" und eine Eigenschaft \"Temperatur\" f\u00fcr den Motorknoten haben. Eigenschaften k\u00f6nnen beibehalten werden und\/oder einstellbar sein.<\/p>\n Attribute: <\/b><\/p>\n die Attribute sind wichtig f\u00fcr die Homie-Autodiscovery, sie sind spezifiziert und beginnen mit einem $, um ihre besondere Bedeutung anzuzeigen \/ Kollisionen zu vermeiden. Sie werden zum Speichern und Aktualisieren von Metadaten verwendet.<\/p>\n Zum Beispiel ver\u00f6ffentlicht das Ger\u00e4t eine zur\u00fcckgehaltene Nachricht auf<\/p>\n homie\/Ger\u00e4te-ID\/$nodes<\/p>\n mit einer kommagetrennten Liste der Knoten. Um anzugeben, dass es sich bei einem Knoten um ein Array handelt (kann verwendet werden, um z. B. die Vorder- und R\u00fccklichter eines Autos zu gruppieren), wird der Name mit eckigen Klammern am Ende angegeben, z. B. <\/p>\n Lichter[]<\/p>\n Ein Beispiel f\u00fcr den Teilbaum device id:<\/p>\n Homie gibt standardm\u00e4\u00dfig verschiedene Statistiken f\u00fcr das Ger\u00e4t an, die meisten davon optional (au\u00dfer der Betriebszeit). Zum Beispiel:<\/p>\n Bei Knoten wird wiederum die automatische Erkennung von Eigenschaften erm\u00f6glicht, indem diese im Attribut $properties angegeben werden:<\/p>\n Auf diese Weise m\u00fcssen Sie als Abonnent nicht alle Ereignisse erraten\/abonnieren, sondern k\u00f6nnen selektiv die Ereignisse abonnieren, die Sie interessieren.<\/p>\n In Homie werden die Metadaten (Attribute) als Suffix zum Pfad ver\u00f6ffentlicht. Z.B. f\u00fcr eine bestimmte Eigenschaft:<\/p>\n Kontrolle in Homie<\/b><\/p>\n Homie ist zustandsbasiert. Das bedeutet, dass Sie nicht \"das Licht einschalten\", sondern den Stromstatus eines Ger\u00e4ts auf \"ein\" setzen.<\/p>\n dann aktualisiert das Ger\u00e4t seinen Stromversorgungszustand, um mitzuteilen, dass der Befehl ausgef\u00fchrt wurde:<\/p>\n Sendung<\/b><\/p>\n Alarm ist eine willk\u00fcrliche Wahl - die \u00dcbertragung kann zu jedem anderen Thema erfolgen, nach dem die Ger\u00e4te filtern k\u00f6nnen. Die Nachrichten werden an alle Ger\u00e4te gesendet - die Ger\u00e4te k\u00f6nnen darauf reagieren, wenn sie dies wollen.<\/p>\n Dies ist die vollst\u00e4ndigste Spezifikation, die ich bei meiner Online-Recherche finden konnte. Ich pers\u00f6nlich finde, dass er sehr elegant konstruiert ist.<\/p>\n Lesen Sie mehr:<\/p>\n https:\/\/homieiot.github.io\/specification\/<\/a><\/p>\n https:\/\/owntracks.org\/booklet\/tech\/json\/<\/a><\/p>\n http:\/\/owntracks.org\/booklet\/guide\/topics\/<\/a><\/p>\n Owntracks ist eine Open-Source-Anwendung, mit der Sie Ihren eigenen Standort verfolgen und mit Freunden teilen k\u00f6nnen. Der Standort wird \u00fcber HTTP oder MQTT ver\u00f6ffentlicht, idealerweise zu Ihrem eigenen Makler<\/b>. <\/p>\n \" Es kann auch erkennen, wenn Sie eine bestimmte Region betreten oder verlassen, f\u00fcr die Sie einen so genannten Wegpunkt festgelegt haben. Damit kann man z. B. einen Aspekt des Hausautomationssystems steuern. (Alle haben das Haus verlassen? Wir k\u00f6nnen das Licht ausschalten.)\"<\/em><\/p>\n Wenn Sie mehr \u00fcber OwnTracks erfahren m\u00f6chten, besuchen Sie diese Website: https:\/\/owntracks.org\/booklet\/<\/p>\n \u00dcber das owntracks-Thema Design: <\/b><\/p>\n https:\/\/owntracks.org\/booklet\/guide\/topics\/<\/a><\/p>\n \"Die Grunds\u00e4tze bei der Entwicklung des OwnTracks-Themenbenennungssystems waren<\/p>\n \u201c<\/p>\n<\/blockquote>\n Name des Basisthemas (andere sind m\u00f6glich): <\/p>\n owntracks\/peter\/iPhone<\/p>\n hier ist owntracks ein Pr\u00e4fix, um anderen Anwendungen kollisionsfreie Zugriffe auf den MQTT-Broker zu erm\u00f6glichen.<\/p>\n peter ist der Besitzer von Ortungsger\u00e4ten, und das iPhone ist eines seiner Ger\u00e4te.<\/p>\n Befehle an Ger\u00e4te werden gesendet an: owntracks\/peter\/iPhone\/cmd<\/p>\n die Ausgabe der Befehle wird z.B. in relativen Themennamen ver\u00f6ffentlicht Schritt<\/i>, abladen<\/i> usw.<\/p>\n einige andere Themen werden definiert (Info, Wegpunkt, Ereignis). Ereignisse werden z. B. ver\u00f6ffentlicht, wenn ein Benutzer einen bestimmten Bereich betritt.<\/p>\n Auf diese Weise k\u00f6nnen Sie durch das Abonnieren von owntracks\/+\/+\/event sehen (f\u00fcr Benutzer, f\u00fcr die Sie berechtigt sind, sie zu sehen), wann sie einen bestimmten Bereich betreten oder verlassen.<\/p>\n Owntracks ver\u00f6ffentlicht seine Nachrichten im JSON-Format:<\/p>\n https:\/\/owntracks.org\/booklet\/tech\/json\/<\/a><\/p>\n wie Sie sehen k\u00f6nnen, sind die Funktionen nach<\/b> das Ger\u00e4t.<\/p>\n Da es eine feste \"Tiefe\" f\u00fcr Benutzer\/Ger\u00e4te gibt, die im Voraus bekannt ist, kann das Abonnement f\u00fcr mehrere Benutzer und Ger\u00e4te mit Platzhaltern erfolgen:<\/p>\n In der JSON-Datei wird die Typ<\/b> des jeweiligen JSON wird in der Nachricht mitgegeben:<\/p>\n Das ist eine gute Idee! Auf diese Weise k\u00f6nnen Sie \u00fcberpr\u00fcfen, ob Ihre Anwendung das Ereignis richtig versteht, Typpr\u00fcfungen durchf\u00fchren kann usw.<\/p>\n Die einzelnen Elemente werden in nicht-verbaler Form angegeben. Dies hilft, Datenverkehr zu sparen, insbesondere bei Nachrichten, die h\u00e4ufig ver\u00f6ffentlicht werden.<\/p>\n z.B.:<\/p>\n viele der Elemente sind fakultativ.<\/p>\n Interessanterweise ist der Ortstyp f\u00fcr verschiedene Ger\u00e4te definiert, die unterschiedliche Elemente unterst\u00fctzen.<\/p>\n Eine einfache testamentarische Nachricht wird ver\u00f6ffentlicht. Sie enth\u00e4lt lediglich den Zeitstempel tst, zu dem das Ger\u00e4t erstmals verbunden wurde.<\/p>\n tst ist ein Unix-Epochen-Zeitstempel. <\/p>\n Ein interessanter Aspekt dieses Ereignistyps\/Nutzlasttyps ist, dass mehrere Zeitstempel angegeben sind:<\/p>\n Ein Wegpunkt ist ein Punkt von Interesse, z. B. Ihre Garage - wenn Sie Ihre Garage betreten oder verlassen, wird ein \u00dcbergangsereignis ausgel\u00f6st:<\/p>\n Ein Konfigurationsereignis. Wenn diese Option aktiviert ist, akzeptieren die Anwendungen auch Fernkonfigurationsmeldungen.<\/p>\n Dieses Ereignis enth\u00e4lt viele m\u00f6gliche Elemente, die ausf\u00fchrlicher sind (z.B. validatecertificatechain) - dies ist sinnvoll, da die Konfiguration als JSON gespeichert werden kann (! -> dies kann als MQTT-Nachricht weitergegeben und gespeichert werden!), und auch, da es nicht oft gesendet wird, ist Ausf\u00fchrlichkeit kein gro\u00dfes Problem, sondern eher ein Vorteil f\u00fcr die Benutzer.<\/p>\n z.B. wird eine Aktion mit der \"action\": \"dump\" eine Ver\u00f6ffentlichung der Konfigurationsnachricht unter dem relativen Pfad dump ausl\u00f6sen<\/p>\n F\u00fcr eine Aktion k\u00f6nnen optionale Unterparameter angegeben werden, z. B. ein zu betrachtender Zeitrahmen:<\/p>\n Eine weitere interessante Design-Idee ist, dass durch eine bestimmte Variation dieser cmd-Meldung ein Browser zu einer bestimmten URL ge\u00f6ffnet werden kann. Wenn man z.B. die Garage betritt, k\u00f6nnte eine Garagenkontrollseite ge\u00f6ffnet werden, ...<\/p>\n eine Array<\/b> eines anderen Nachrichtentyps kann \/ muss hier als Parameter \u00fcbergeben werden.<\/p>\n Das Interessante an dieser Nachricht ist, dass sie auch ein Feld f\u00fcr ein Base64-kodiertes PNG-Bild enth\u00e4lt:<\/p>\n Die interessante Idee dabei ist, dass eine optionale Ersteller<\/b> mitgegeben werden, das die Entit\u00e4t identifiziert, die diese Wegpunkte erstellt hat.<\/p>\n Beachten Sie auch, dass owntracks den Unterstrich _ f\u00fcr \"spezielle\" Parameter verwendet.<\/p>\n Optional k\u00f6nnen alle diese Meldungen verschl\u00fcsselt<\/b> f\u00fcr den Transport mit einem gemeinsamen symmetrischen Schl\u00fcssel. <\/p>\n Die verschl\u00fcsselte Nutzlast (die urspr\u00fcngliche Nachricht) befindet sich im Element \"data\", Base64-kodiert.<\/p>\n Die Nutzdaten der Nachrichten sind bin\u00e4r und k\u00f6nnen beliebig sein, es ist nicht erforderlich, dass die Nachrichten in UTF-8 g\u00fcltig sind. <\/p>\n Daher k\u00f6nnen Sie auch digitale Daten, z.B. Bilder, als Nutzlast zu bestimmten Themen ver\u00f6ffentlichen. <\/p>\n Viele aktuelle IoT-Dashboards verarbeiten Daten, die als JSON kodiert sind.<\/p>\n Im Allgemeinen scheint es zwei Denkrichtungen zu geben: Nachrichten sind eigentlich Rohwerte, und Metadaten werden im Themenbaum kodiert, und JSON-kodierte Werte, die Metadaten als Nutzdaten enthalten. <\/p>\n twitter-to-mqtt - Ein Python-Daemon, der die Twitter Streaming API nutzt, um auf Tweets zuzugreifen und sie in einem MQTT-Topic zu ver\u00f6ffentlichen.<\/p>\n fritz2mqtt - FRITZ!Box mit MQTT verbinden.<\/p>\nKunden-ID \/ Kunden\u00fcbernahme<\/h2>\n
Zur\u00fcckbehaltene Nachrichten<\/h2>\n
Dienstg\u00fcte \/ QoS<\/h2>\n
\n
Themen<\/h1>\n
Fakten zu den Themen<\/h2>\n
Verwendung von Platzhaltern ber\u00fccksichtigen<\/h4>\n
\n
Nicht<\/h2>\n
Vorschl\u00e4ge \/ Tun<\/h2>\n
Mehrmandantenf\u00e4higkeit und Bridging ber\u00fccksichtigen<\/h2>\n
Verschl\u00fcsselung erw\u00e4gen<\/h2>\n
Auffindbarkeit ber\u00fccksichtigen<\/h4>\n
R\u00fcckmeldungen \u00fcber Befehle ber\u00fccksichtigen<\/h4>\n
Multicast-Szenarien ber\u00fccksichtigen<\/h2>\n
Ber\u00fccksichtigung von Verkehr und Datenschutz, Sensortypen<\/h2>\n
\n
\n
semantischer vs. physischer Themenpfad<\/h2>\n
\u00dcbersicht der Online-Designvorschl\u00e4ge<\/h1>\n
Vorschlag 1: Himbeer-Tal<\/h2>\n
\n
Vorschlag 2: Steve<\/h2>\n
\n
\n
Vorschlag 3: MQTT-Smarthome<\/h2>\n
\n
\n
\n
\n
\n
![\"clip_image001\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image001_thumb.png\" "\\"clip_image001\\"")
<\/a><\/p>\nVorschlag 4: Tinkerman<\/h2>\n
Vorschlag 5: Homie IoT Convention<\/h2>\n
![\"clip_image003\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image003_thumb.jpg\" "\\"clip_image003\\"")
<\/a><\/p>\n\n
\n
\n
![\"clip_image004\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image004_thumb.png\" "\\"clip_image004\\"")
<\/a><\/p>\n![\"clip_image005\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image005_thumb.png\" "\\"clip_image005\\"")
<\/a><\/p>\n![\"clip_image006\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image006_thumb.png\" "\\"clip_image006\\"")
<\/a><\/p>\n![\"clip_image007\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image007_thumb-1.png\" "\\"clip_image007\\"")
<\/a><\/p>\n![\"clip_image008\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image008_thumb.png\" "\\"clip_image008\\"")
<\/a><\/p>\n![\"clip_image009\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image009_thumb.png\" "\\"clip_image009\\"")
<\/a><\/p>\n![\"clip_image010\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image010_thumb.png\" "\\"clip_image010\\"")
<\/a><\/p>\nVorschlag 6: Eigene Tracks<\/h2>\n
![\"clip_image012\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image012_thumb.png\" "\\"clip_image012\\"")
<\/a><\/p>\n\n
\n
![\"clip_image013\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image013_thumb.png\" "\\"clip_image013\\"")
<\/a><\/p>\n![\"clip_image014\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image014_thumb.png\" "\\"clip_image014\\"")
<\/a><\/p>\n![\"clip_image015\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image015_thumb.png\" "\\"clip_image015\\"")
<\/a><\/p>\n\n
![\"clip_image016\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image016_thumb.png\" "\\"clip_image016\\"")
<\/a><\/p>\n![\"clip_image017\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image017_thumb.png\" "\\"clip_image017\\"")
<\/a><\/p>\n\n
\n
![\"clip_image018\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image018_thumb.png\" "\\"clip_image018\\"")
<\/a><\/p>\n![\"clip_image020\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image020_thumb.jpg\" "\\"clip_image020\\"")
<\/a><\/p>\n![\"clip_image021\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image021_thumb.png\" "\\"clip_image021\\"")
<\/a><\/p>\n![\"clip_image022\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image022_thumb.png\" "\\"clip_image022\\"")
<\/a><\/p>\n![\"clip_image023\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image023_thumb.png\" "\\"clip_image023\\"")
<\/a><\/p>\n![\"clip_image024\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image024_thumb.png\" "\\"clip_image024\\"")
<\/a><\/p>\n![\"clip_image025\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image025_thumb.png\" "\\"clip_image025\\"")
<\/a><\/p>\n![\"clip_image026\"](\"https:\/\/pi3g.com\/wp-content\/uploads\/2019\/05\/clip_image026_thumb.png\" "\\"clip_image026\\"")
<\/a><\/p>\nNachrichten<\/h3>\n
Vorschl\u00e4ge<\/h4>\n
\n
\n
Interessante Ressourcen<\/h1>\n
Awesome MQTT: Sammlung von MQTT-bezogenen Links:<\/h2>\n
\n
einzelne Projekte:<\/h2>\n
\n
\n
Ref:<\/h1>\n
\n
Wiederver\u00f6ffentlichung:<\/h2>\n