LBS19001070 - MQTT Subscription Client / LBS19001071 - MQTT Publish Client

[jonofe]

nein, da spricht grundsätzlich nichts dagegen.

[Nanosonde]

Hi!
Prima. Das sieht ja sehr gut aus!

Ich hätte noch folgende Vorschlag zur Diskussion:

Reiner API-Client + reiner API-Server

Du hast in Deinen beiden Bausteinen ja quasi "nebenbei" noch die Möglichkeit geschaffen, eigene Topics zu abonnieren bzw. zu beschreiben.
Generell verstehe ich die beiden Bausteine so, dass es nur jeweils eine Instanz wegen der iKO/KNX-GA API geben darf.

Ich fände es besser, wenn der reine Client (wie bei meinen Bausteinen), der nur eine andere API (über MQTT) steuern kann, davon entkoppelt wäre.
Auch wäre es hier dann sinnvoll, wenn man beliebig viele Instanzen der reinen Clients als LBS erzeugen kann.

Warum?
Der reine Client liesse sich so besser in den Logikseiten von Edomi benutzen. Jede Instanz würde zwar eine eigene TCP-Verbindung zum Broker halten, was aber nicht schlimm wäre, da z.B. Mosquitto mit mehr als 100.000 Verbindungen zurecht kommt laut Author.
Ich muss dann auch nicht mit anderer Logik die Topics und Payloads zusammenbauen bzw. verwalten, um sie einer Zentralinstanz zu übergeben.
Ich könnte aber auch nur eine Instanz benutzen und dann beim Topic den Wildcard-Operator "#" nehmen, um verschiedene Topics mit Ihren Payloads zu bekommen und die mit Hilfe anderer LBS extrahieren und aufteilen.
Man hätte also die Wahl.

Wenn ich mehrere Topics habe, dann möchte ich evtl. unterschiedliche Einstellungen für das "Retained Flag" haben.
Nur mal als Beispiel: https://github.com/mqtt-smarthome/mq...rchitecture.md
Du siehst dann, was ich meine.

Idealerweise stelle ich mir 3 MQTT LBS vor:

1) MQTT Subscription Client (einzeln zu benutzen)
2) MQTT Publish Client (einzeln zu benutzen)
3) MQTT Server-API Client (eine Zentralinstanz, beinhaltet Subscribe (SETter) und Publish (GETter) für Edomi iKO/KNX-GA)

Was meinst Du?

[jonofe]

Gute Idee. Denke das ist nicht viel Aufwand die Funktionen zu splitten.

Allerdings wird es neben den separaten API Clients vermutlich weiterhin zwei Server LBS geben, da es mit der gewählten Architecktur nicht ganz so einfach ist beides in einen LBS zu packen. Aber ich denke das sollte verschmerzbar sein. Insbesondere hat man dann noch die Wahl, ob man nur publishen oder nur subscriben will.

Das liegt daran, dass das EXEC Skript des Publishers eigentlich gar kein LBS ist, sondern ich die Tatsache ausnutze, dass EDOMI daraus ja ein separates PHP Skript machen. Im LBS Teil wird der mysql Trigger erstellt, der dann aus mySQL heraus das EXEC-Skript aufruft. Es ist also kein Daemon LBS, den man aber für den Subscription Server bräuchte. Über Umwege würde das vermutlich auch irgendwie kombinierbar sein, wäre dann aber ggf. nicht mehr so gut wartbar, weil man das Trigger Skript mit dem Subscription Daemon vermischen würde. Alternative wäre natürlich das Trigger Skript separat zum LBS dazuzulegen, würde dann die Installation etwas verkomplizieren.

Was wäre deine Präferenz?

[Nanosonde]

Allerdings wird es neben den separaten API Clients vermutlich weiterhin zwei Server LBS geben, da es mit der gewählten Architecktur nicht ganz so einfach ist beides in einen LBS zu packen. Aber ich denke das sollte verschmerzbar sein. Insbesondere hat man dann noch die Wahl, ob man nur publishen oder nur subscriben will.

Was wäre deine Präferenz?

Ich habe darüber auch gerade nachgedacht und wollte eigentlich noch antworten, dass das ja ruhig zwei LBS bleiben könnten.
Aus Usersicht kann man sich dann wirklich sicher sein, dass der Baustein nur IN/OUT bzw. SET oder GET ist.


Sollen wir (bzw. Du) dann eigentlich einen neuen Thread aufmachen, so dass es klarer wird, dass es nur noch um Deine MQTT LBS geht?
Ich verlinke dann oben bei mir direkt auf auf Deinen Thread und empfehle die Verwendung Deiner Bausteine.

[jonofe]

Ich habe darüber auch gerade nachgedacht und wollte eigentlich noch antworten, dass das ja ruhig zwei LBS bleiben könnten.
Aus Usersicht kann man sich dann wirklich sicher sein, dass der Baustein nur IN/OUT bzw. SET oder GET ist.

Einverstanden!

Sollen wir (bzw. Du) dann eigentlich einen neuen Thread aufmachen, so dass es klarer wird, dass es nur noch um Deine MQTT LBS geht?
Ich verlinke dann oben bei mir direkt auf auf Deinen Thread und empfehle die Verwendung Deiner Bausteine.

Okay, das können wir so machen. Werde dann mal einen neuen Thread aufmachen.

[Nanosonde]

Ok. Wann sind die gesplitteten Bausteine fertig?

[jonofe]

Ok. Wann sind die gesplitteten Bausteine fertig?

Um es mit Michael's Worten zu sagen: "Rufen Sie nicht an, wir melden uns"

[jonofe]

ok. Wann sind die gesplitteten bausteine fertig?

jetzt !

[benji]

Hi,

ich wollte eben MQTT Broker installieren. Irgendwie klappt mein apt-get nicht. Bekomme immer Fehler "command not found".

Hab es auf zwei Edomi Rechner getestet und klappt nicht. Mit yum bekomme ich Fehler, Error nothing to do

[trollmar]

Hi,

apt-get gehört zu allen Debian derivaten

https://de.wikipedia.org/wiki/Debian

Ubuntu ist der bekannteste Vertreter.
CentOS (edomi) beruht auf Red-Hat.

Das kann nicht gehen.

Würde für den Mosquitto Broker einen eigen Rechner (oder VM) nehmen.
LG

[benji]

Hi,

deine Antwort bringt mich so jetzt nicht direkt weiter.
Viel lieber möchte ich wissen warum apt-get nicht funktioniert.

Der Mosquitto Broker soll ja nur testweise auf meinem Edomi Testserver laufen.

[vento66]

Kurzform? apt-get ist kein centOS Befehl.

[Nanosonde]

Hi,

deine Antwort bringt mich so jetzt nicht direkt weiter.
Viel lieber möchte ich wissen warum apt-get nicht funktioniert.

Der Mosquitto Broker soll ja nur testweise auf meinem Edomi Testserver laufen.

Wenn Du das install.sh Skript aus der ZIP-Datei der MQTT LBS ausgeführt hast, dann hast Du bereits das YUM Repo file für Mosquitto auf CentOS6 installiert.
(siehe auch http://download.opensuse.org/reposit...ntOS_CentOS-6/)

Du müsstest dann eigentlich einfach nur noch ein "yum install mosquitto" ausführen.