Wie Shelly per MQTT Abfragen, Steuern

[Homoran]

@mickym sagte in Wie Shelly per MQTT Abfragen, Steuern:

Nur um das etwas zu relativieren.

war auch so gemeint. Aber auch da hat niemand gesagt dass @Tobi82 dafür zu dumm ist!

Soweit zum Kontext

[mickym]

@homoran Sagen wir mal meine Wortwahl war provokant, für das was hier manche auszudrücken versuchen:

@SpacerX

@tobi82 mal mein Senf dazu. Du willst nicht mit JSON rumhantieren? Dann den Shelly-Adapter nutzen.

Im Umkehrschluss, wenn Du doch mit JSON rumhantieren willst, dann ....

@reutli

Mit meinem Worten: Wenn Du schnell und effizient sein willst, dann nutzt Du den Shelly Adapter.

Wenn nicht, dann ....

Na ja. Lassen wir das. - Ich denke jeder kann zwischen den Zeilen lesen.

[Homoran]

@mickym sagte in Wie Shelly per MQTT Abfragen, Steuern:

Lassen wir das.

jepp!
ich kann die Argumentation mit einer zentralen MQTT Infrastruktur ja verstehen. Bin da auch auf "eurer Seite". Aber shelly ist nicht der einzige, der MQTT Pakete im Rahmen der Datensparsamkeit als JSON verschickt.
Da muss man dann die JSONs aufarbeiten, egal wie.

[mickym]

@mickym sagte in Wie Shelly per MQTT Abfragen, Steuern:

{"id":123, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}

Im Übrigen will ich auch mal was zu der Syntax sagen dieser Generation 2. Ich mag dies auch nicht besonders, aber für die Fehlersuche hat das durchaus seine Vorteile.

Mit der id und der src (Source) kann man im Status später, wenn man diese unterschiedlich nutzt nachher noch nachvollziehen, welcher Befehl diese Schaltung vorgenommen hat. Deswegen hat man das wahrscheinlich eingeführt.

Das vielleicht mal, um auch Verständnis dafür zu generieren, warum solche Infos in einem Befehl durchaus sinnvoll sein können.

Hier der Auszug aus der Original-Dokumentation.

[mickym]

@homoran sagte in Wie Shelly per MQTT Abfragen, Steuern:

Aber shelly ist nicht der einzige, der MQTT Pakete im Rahmen der Datensparsamkeit als JSON verschickt.
Da muss man dann die JSONs aufarbeiten, egal wie.

Inzwischen ist ja auch Blockly in der Lage mit den Attributen direkt aus Objekten arbeiten zu können. Insofern ist das im Prinzip kein Ding mehr. Man muss es nur EINMAL lernen, wie so vieles andere im Leben auch und auch mir ist es nicht in die Wiege gelegt worden.

[mickym]

Nachdem das mit dem Shelly Adapter einfach ist, könnt ihr ja vielleicht hier helfen: https://forum.iobroker.net/topic/62219/mqtt-fehler-mit-shelly-gen-2

[SpacerX]

@mickym es ging mir im wesentlich darum einen zweiten Weg aufzuzeigen bei dem man ohne JSON hantieren auskommt. Jeder muss seinen Weg selber finden. Nachdem der Beitragsstarter meinte das er sich erst damit auseinander setzen müsste, ging ich davon aus das er nicht glücklich damit ist.
Ich habe da eine etwas andere Sichtweise als du. Wenn mir der Adapter das auseinander nehmen der JSON Strings abnimmt dabei vieleicht auch ein paar mehr Datenpunkte bereitstellt als ich brauche soll mir das recht sein. Mein ioBroker lauft auf einem Nuc und hat genug Power und Memory um den einen Adapter auch noch zu verkraften. Wie viele User haben nur Adapter laufen um was in der Vis Anzeigen zu können. Also der eine zusätzliche Adapter ist für mich kein Argument um auf den Komfort zu verzichten.

[da_Woody]

@mickym hüstel. wenn wer eine "zentrale MQTT-Infrastruktur besitzt", dann sollte er sich auch damit auskennen.
da ist nix mit unlust, oder gewalt.

[mickym]

Liebe Shelly-Adapter Fans - ich kenn ja einige namentlich (z.Bsp. @da_Woody ) auch schon aus früheren ähnlichen Diskussionen. Mir gings nur darum, dass ihr Leute, die mit originärem MQTT arbeiten wollen, nicht gleich mit Eurem Shelly Adapter Enthusiasms überflutet und in die Nerd-Ecke verfrachtet, um denjenigen zu erklären, wie einfach das Leben doch sein kann, wenn man nur will.

So wie ich Eure Sichtweise zulasse, so akzeptiert einfach, dass nicht jeder Eure Sichtweise teilt und JSON Strings oder JS Objekte nicht als was zum Auseinandernehmen sehen, sondern als das sehen, was es ist. Ein Objekt, dass Eigenschaften besitzt, die zu diesem Objekt gehören. Und nochmals - vielleicht macht es eben in meinen Augen mehr Sinn die Eigenschaften eines Objektes direkt abzufragen, als die Eigenschaften eines Objektes in Bestandteile zu zerlegen.

Ich finde ein Auto halt nützlicher, als wenn ich 20000 Einzelteile eines Autos vor mir habe und mir nicht sicher bin, ob sie überhaupt zu dem Auto gehören.

Andere Dinge wie, dass ein Adapter halt alle Geräte kennen muss und bei jedem neuen Gerät erst mal aufgeschmissen ist, haben wir alles schon diskutiert.

Mir geht es wirklich nicht darum, wieder die Diskussion über Vor- und Nachteile bestimmter Adapter zu diskutieren - wobei ich mich sicher nicht scheue. Mir ging es nur darum, dass wenn jemand eine Lösung zu einem Problem sucht, man nicht immer gleich denjenigen mit dem Adapter überfällt.

Das ist, wenn ich in eine Pizzeria gehe und mir eine Pizza bestellen will, mir jemand erklärt, dass ich doch lieber Pasta oder was anderes essen sollte.

[da_Woody]

@mickym deine sichtweise sei dir unbenommen! allerdings, warum benutzt du dann ioB?
wozu werden dann adapter dafür entwickelt?

Liebe Shelly-Adapter Fans

nur weils da um den shelly adapter geht?
IMHO gehts bei deiner aussage um alle adapter?
wie ich dich verstehe, dann gehts mit "originärem MQTT" ja ohne ioB auch.
ich will auch keinen überfluten, aber wenns in meinen augen einen guten adapter gibt, werd ich das rad nicht neu erfinden.

[Homoran]

Kinders, jetzt ist genug mit dem Thema!
BTT bitte!