Artikelstruktur zu MQTT-Themen

Begonnen von Beta-User, 18 Juni 2019, 15:42:47

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Beta-User am 24 Juni 2019, 15:07:38
In dem https://wiki.fhem.de/wiki/MQTT_Einführung gibt' jetzt auch noch ein paar weitere Aspekte und eine (hoffentlich) klarere Gliederung auch der Nebenthemen; sollte damit bis auf etwas Feinschliff demnächst zu MQTT werden dürfen?
So, jetzt dürft ihr Rückmeldung geben zum aktuellen Stand. Der Einführungs-Artikel besteht (aus Kompabilitätsgründen) jetzt nur noch als Weiterleitung zu https://wiki.fhem.de/wiki/MQTT. Da steht (imo) jetzt alles wesentliche drin, was man so im Zusammenhang mit FHEM und den diversen Modulen kennen sollte.

Ein paar Kleinigkeiten sind noch offen, die sind aber m.E. nicht tragisch, (aber in Teilen außerhalb meines aktuellen Erfahrungshorizonts). Die Stellen sind entsprechend gekennzeichnet, wer also mag und kann, darf die gerne ergänzen, dto für Schreibfehler, kaputte links usw.).

Ansonsten dürft ihr jetzt nach Herzenslust wieder kritisieren und mitteilen, was denn nicht verständlich ist, umständlich geschrieben usw...
(Mal ab davon, dass Details zu Arduin-Programmierung imo wirklich nichts im zentralen Artikel verloren haben; das könnt ihr euch sparen, werde jedenfalls ich da nicht im Detail reinbauen... (und dies nicht mangels Kenntnis/Erfahrung; das habe ich @ESP8266 schon vor längerem mal gemacht :P ).

Die Grafiken wären dann zukünftig jeweils bei der Einbindung in FHEM (IO-Beschreibung) zu finden (MQTT2_SERVER, MQTT2_CLIENT, MQTT)  wenn sie denn dann fertig sind.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

#61
Aus gegebenen Anlass (ohne das ich jetzt ins Wiki geschaut habe, ob's das schon gibt):
wunschwikiartikel -> attrTemplate (allgemein oder explizit MQTT)

Zu einen die Templates zeigen, zum andern die templates erklären und zu guter letzt, Hardware bezogen Fallstricke, bekannte Fehler Quellen ( z.b. Sowas )


***edit***
So jetzt hab ich nachgesehen und das hätt ich besser nicht gemacht.  ::)
Ich glaub das mit den templates wird ein eigner Thread... das posting hier von mir am besten schnell vergessen oder nur im Hinterkopf halten.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

DasQ

#62
mir ist eben (s.o.) aufgefallen das SonOff im wiki, auch MQTT behandeln.

in wie weit das nun doppelt im wiki behandelt werden muss, lass ich mal dahingestellt, es verwirrt aufjedenfall den laien.
vielleicht sollte man das auch noch splitten/aufteilen sinnvoller gestalten.
im prinzip ist es, wie du @Beta-user oben schon gesagt hast, wie mit dem Arduino, eigentlich gehört der so auch nicht ins MQTT-FHEM-wiki.


Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

DasQ

erster entwurf auf deiner grundlage

Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

andies

Zitat von: DasQ am 30 Juni 2019, 11:25:27
erster entwurf auf deiner grundlage
Das sieht super aus. Nur eine kleine Frage: Das Wort "Module" (Mehrzahl) suggeriert bei mir .pm-Dateien. Sind das nicht eigentlich FHEM-devices, die da stehen?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

DasQ

#65
hab ich mir auch gedacht, als ichs hochgeladen hab ...  ;)  ::)

ich kann ja den kasten "module" aufteilen und unten ein eigenen kasten für die FHEM-devices machen.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Mal eine Teilantwort:

Das Diagramm paßt ziemlich gut, evtl. sollte man den "Module"-Kasten oben deutlicher auch um MQTT2_CLIENT laufen lassen? Denn: Es sind tatsächlich so 2 .pm involviert, darunter mehrere Instanzen von MQTT2_DEVICE. Für 00_MQTT.pm+MQTT_DEVICE wäre es so ok (will heißen: erst Kopie machen und so anpassen), für MQTT2_CLIENT fehlt m.E. eine Instanz: das "Sortier"-Device auf Basis des A_00_MQTT2_CLIENT_....
Da der Bereich in der "Basisgrafik" auch so überschrieben ist, ist das m.E. ok, hier etwas "unscharf" zu sein, eine Unterscheidung zwischen "Module" und "FHEM-Device" würde ich nicht vornehmen, evtl. nur eine Art "Doppelbeschriftung", vielleicht "Module bzw. FHEM-Geräte" (zu "Gerät" gibt es einen Artikel, der den üblichen Sprachgebrauch von Device erläutert).

Es wäre evtl. die Frage, ob man den Server-Block nicht auch hier nach links packt und dann von links nach rechts andordnet statt oben/unten (und dann MQTT/Non-MQTT übereinander). Da aber die Verbindungen passen (vielleicht mit der Einschränkung, dass uU. der Arduino nur publisht, und afaik alle anderen genannten wirklich immer bidirektional arbeiten).

"Lemdkr" lese ich zum ersten Mal, muß man das kennen?

(Zur Funktionsweise des A_00...: Das Teil ist eine Art "Helfer"-Device für autocreate. Es generiert aus dem Topic-Tree einer Nachricht, für die es noch keinen Abnehmer gibt eine CID, die dann zur Zuordnung zu einem bestehenden oder ggf. dann neuen Device dient... Ganz ähnlich dem, was die zigbee-Bridge oder die MiLight-Bridge-Devices auch tun, nur dass dort eben kein entfernter Dienst dahinter steht, sondern "typische"Topic-Strukturen analysiert werden. Zur etwas abweichenden Formatierung hatte ich schon was geschrieben...)

Was die verteilten Infos zu sonoff&Co angeht:
Wenn die Basisdinge deutlich erklärt sind, genügt in Schritt 1 m.E. mal ein Hinweis/link zu den jeweiligen Stellen in den Grundlagenartikeln, ggf. verbunden mit einem kurzen (!) Hinweis, dass das ggf. eben nur eine Variante beschreibt.

Das mit den attrTemplates würde ich zwischenzeitlich dann auch in einen eigenen Artikel auslagern wollen. Gibt ja zwischenzeitlich mehrere Module, für die entsprechende files im svn sind. Aber bitte: nicht alles auf einmal...

(Meine persönliche Devise: Wenn ich irgendwo was anfange, dann mit dem Ziel, das auch fertig machen zu können/wollen (von Randthemen wie hier SSL evtl. abgesehen). Das führt zwar uU. zu einem Flickentepich, ist aber m.E. besser, wie wenn dann überall nur noch Baustellen sind; letzteres ist dann m.E. auch nicht übersichtlicher...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

LuckyDay

Grafik an sich gefällt mir

Den ganz bösen Typo noch ändern

Beta-User

Ähm, diese nachträglichen Änderungen von Beiträgen sind ganz schön verwirrend.

Also die Herausnahme von MQTT2_DEVICE aus "Module" ist m.E. sachlich falscher, als mehrere Instanzen in "Module" zu haben. Wenn nicht jemand gute Argumente liefert, warum das so sein soll, bitte ändern (ggf. unter Berücksichtigung meiner vorherigen Anmerkung zur Namensgebung, die noch ohne Kenntnis der aktualisierten Grafik erfolgte).

@Hary: Danke für den Hinweis auf den Typo; da hatte ich wohl die Wunschlesebrille auf...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

@Beta-User das hat sich mit uns etwas überschnitten.

Zitat von: Beta-User am 30 Juni 2019, 12:33:55
"Lemdkr" lese ich zum ersten Mal, muß man das kennen?

Wir haben zu 3. versucht dein text aus dem anfangs PDF zu interpretieren und sind einhellig auf Lemdkr gekommen. ;D :D
Ganz ehrlich, ich konnts nicht lesen. Was steht da oben rechts in deim PDF?

und jetzt mit dem MQTT_CLIENT, hab ich noch nicht ganz verstanden. Kannst mir des in des Bild rein editieren/schreiben?
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

LuckyDay


DasQ

#71
 ;)


***edit****

ach jetzt hab ich glaub verstanden was du willst, mit dem links nach rechts. änderung kommt in ner halben stunde.
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Leuchte paßt ;D , dafür bitte aber nochmal:

- Der "Module"-Kasten muß auch um die MQTT2_DEVICEs rum, darf aber zusätzlich mit "/FHEM-Geräte" beschriftet sein.
- Bitte alle MQTT_CLIENT-Texte durch MQTT2_CLIENT ersetzen (Überschrift und Modul)! Wenn hier allgemein von irgendeinem Kommunikationsteilnehmer in MQTT die Rede ist, ist die Schreibweise MQTT-Client (die Großbuchstaben haben da - wie sonst auch - eine Bedeutung...). Und MQTT2_CLIENT ist ein ganz spezieller Fall eines MQTT-Clients (ähnlich wie "MQTT" als einer Instanz von 00_MQTT.pm).
- In diesem Schaubild mit MQTT2_CLIENT brauche ich bitte dieses "spezielle" weitere MQTT2_DEVICE-Gerät, das ich bereits mehrfach erwähnt hatte...



Allgemein habe ich den Verdacht, dass der aktualisierte Artikel immer noch nicht verständlich zu sein scheint, (oder nicht gelesen wurde), da sollten sich die (begrifflichen und logischen) Zusammenhänge eigentlich draus erschließen...

(Liegt es an der Hitze, oder warum habe ich den Eindruck, dass in einem Neudreh von "Täglich grüßt ..." bin und immer wieder dasselbe schreibe, und schon wieder einen Zwischenedit nicht mitbekommen habe ;D ?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Ohne Edit: Wenn du statt MQTT_CLIENT jetzt 00_MQTT.pm schreibst und die Module-Box anpaßt, ist das (bis auf die Pfeile) soweit ok.

Nur für MQTT2_CLIENT brauche ich das weitere MQTT2_DEVICE (und die sollten dann auch den "2"-er drin haben!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

DasQ

#74
 :)

links nach rechts  ?

(sollte das ok sein, bau ich deine letzten änderungen da ein)

(und gleich wieder den ersten fehler entdeckt ... den server hab ich falsch zusammengeschraubt)

(ich glaub es wird wieder zu warm) ::)
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org