Erweiterung der Edomi-Remote-Schnittstelle um MQTT

[Nanosonde]

Hallo!

Wäre es möglich, die Remote-Schnittstelle zusätzlich um MQTT zu erweitern?
MQTT würde sich wirklich sehr gut anbieten, um interne und externe KOs für andere Anwendungen nach außen verfügbar zu machen.
Die Frage geht natürlich hauptsächlich an Christian.

Der PHP-Code für die HTTP-Remote-Schnittstelle liegt ja lesbar vor.
Dort sehe ich die Funktionen httpKoGet() und httpKoSet(), in denen per SELECT respektive INSERT, die KOs gelesen bzw. geschrieben werden (edomiLive.RAMko und edomiLive.RAMknxRead).
Also hätte ich ja schonmal die Möglichkeit mit meinem MQTT-Client Werte von Edomi abzufragen und zu setzen.

Was mir jetzt nur noch fehlen würde, wäre ein Trigger für Zustandsänderungen an KOs, die für die Remote-Schnittstelle freigegeben sind.
Wie könnte man das realisieren? Wie macht Edomi das eigentlich intern selbst mit den Tabellen? SQL Trigger kommen, glaube ich, nicht zum Einsatz, oder?
Wird einfach in einer Schleife die RAM SQL DB gepollt, weil sie ja im RAM liegt?

[trollmar]

Hatte ich auch schonmal nach gefragt!

MQTT hat viele Vorteile!!
z.B. IOT oder Anbindung an andere Systeme und Plattformen.

MQTT wird sich, meiner Meinung nach, als Universal-Gateway im Smarthome Bereich durchsetzten.


+1 für ein MQTT Gateway.

..aber Erstmal Danke für V1.5 von EDOMI!!!

[gaert]

Mit MQTT kenne ich mich absolut nicht aus - und ich habe auch keinerlei Gerätschaften, die diese Sprache sprechen. Damit ist für mich die Implementierung eigentlich nicht machbar

Wie wäre es, wenn Du einen LBS entwickelst!?

[Nanosonde]

Damit ist für mich die Implementierung eigentlich nicht machbar
Wie wäre es, wenn Du einen LBS entwickelst!?

Hi!
Einen LBS wollte ich eh zusammenbauen.

Ich fände es aber trotzdem schon sehr praktisch, wenn ich direkt an die internen KOs kommen könnte, ohne dafür die Logikseiten und LBS benutzen zu müssen.
Per HTTP hast Du das ja auch möglich gemacht.

Ich würde mich ja an einer MQTT-Remote Schnittstelle versuchen. Allerdings benötige ich dafür von Dir noch den o.g. Trigger.
Zum Beispiel in dem ich bei Edomi einfach nur einen Event-Handler registrieren kann, der immer dann aufgerufen wird, wenn Edomi einen internes KO aktualisiert.
Als Parameter sollte dann die Referenz auf das KO übergeben werden, so dass ich dieses dann wie beim HTTP-Getter abfragen kann.

Ich könnte die vorhandene HTTP-Schnittstelle ja theoretisch benutzen, wenn sie denn sowas wie Long-Polling oder Websockets mit Events bieten würde.
Dann wäre es komplett von Edomi unabhängiger Code, der als Daemon laufen würde.

Aktuell müsste ich ohne einen Event-Mechanismus aber alle KOs permanent in einem fixen Zeitinternall per HTTP pollen und dann selbst die Änderungen detektieren, damit ich ein MQTT-Publish durchführen kann.

Auch wäre es hilfreich, wenn ich eine Art "List KOs" Methode hätte, mit der ich alle freigegeben KOs bekäme, so dass ich das nicht manuell zusätzlich verwalten muss. Die Information hat Edomi ja bereits in der Datenbank.

[gaert]

Es gibt keine (eigenen) Event-Handler in PHP Das zyklische Abfragen ist die einzige Möglichkeit - oder eben die bereits vorhandenen "Schnittstellen" nutzen (LBS)...

Die HTTP-Schnittstelle macht letztlich auch nur DB-Abfragen, diesem Umweg (HTTP) kannst Du Dir also sparen. Wenn Du weißt was Du tust, kannst Du doch einfach auf die DB zugreifen?!

[Nanosonde]

Ok.

Ich habe in der Zwischenzeit habe ich einen "MQTT Subscription Client" LBS gebaut. Funktioniert auch schon. Stelle ich demnächst vor, sobald der "MQTT Publish Client" LBS fertig ist.

Könntest Du mir denn folgende Frage technisch beantworten?
Wenn in remote/index.php die Funktion httpKoSet() aufgerufen wird, sieht man ja nur ein SQL INSERT.
Wie genau bekommt Edomi die Änderung an diesem internen KO mit? Für einen LBS-Eingang zum Beispiel.
Versteckt sich im sql_call() noch etwas? Oder pollst Du alle möglichen DB-Einträge?

function httpKoSet($gaId,$gaValue) {
    $ss1=sql_call("SELECT id FROM edomiLive.httpKo WHERE (gaid=".$gaId.")");
    if ($n=sql_result($ss1)) {
        sql_call("INSERT INTO edomiLive.RAMknxRead (mode,gatyp,gaid,value) VALUES (4,0,".$gaId.",'".sql_encodeValue($gaValue)."')");
        return true;
    }
    return false;
} 

Danke!

[gaert]

Die (RAM-)DB dient quasi als globale Queue - dies ist der einzig sinnvolle Weg, denn wenn Du den Wert eines KOs direkt ändern würdest, würde die Logik etc. dies nicht korrekt verarbeiten. Beim "Setzen" eines KOs wird ja nicht nur der Wert gesetzt, sondern auch die Logik ggf. angeworfen oder die Visu verändert usw...

Aber: Vorgesehen ist es eigentlich nicht, dass man direkt in der DB "rumwurschtelt" (im LBS-Kontext). Vernünftiger wäre also die übliche Vorgehensweise mit Eingängen und Ausgängen...

[Nanosonde]

Ok, danke! So langsam nähern wir uns.

Du schreibt, dass Du die RAM-DB quasi als eine globale Queue benutzt.
Wie sieht denn das Ende der Queue aus? Woher weiß das Queue-Ende denn, dass es etwas in der Queue zur Abholung gibt?
Schaut das Queue-Ende stumpf einfach regelmäßig nach oder ist das irgendwie in der sql_call() Funktion mit eingebaut: jemand hat per sql_call() etwas an einer DB gemacht, also schauen alle mal in der Queue nach, ob es etwas zu tun gibt.

Ich "wurschtel" im LBS auch nicht in der DB rum. Keine Angst.
Wenn, dann würde ich es auch nur so machen, wie es die Remote-Schnittstelle macht.

[gaert]

Ich kann jetzt nicht in 3 Sätzen das gesamte interne Konzept erläutern - ich bitte um Verständnis

Die Remote-Funktion zu kopieren würde zwar im Prinzip funktionieren, wird dann aber intern auch als "Remote" behandelt (in den Statistiken, etc.). Daher nochmal: Benutze möglichst die Funktionen, die für LBS gemacht sind - also insb. Eingänge und Ausgänge. Damit bist Du auf der sicheren Seite, auch hinsichtlich evtl. zukünftiger Weiterentwicklungen (von EDOMI selbst). Es ist nicht unwahrscheinlich, dass ich irgendwann am "Logik-Kernel" schraube und dann funktioniert plötzlich Dein LBS nicht mehr... Wenn das dann Schule macht und zig LBSe am Grundkonzept vorbei implementiert werden, gibt's schnell Chaos

[Nanosonde]

Naja, eine einfache Antwort hätte schon gereicht.

Dann frage ich mal anders als LBS-Ersteller, der nur die offziellen Schnittstellen benutzt:
Wie kann ich denn einen Massenexport der internen KOs in einem LBS ermöglichen, ohne Logiken zu bauen, in denen ich zig manuell generierte Ausgangsbausteine von Hand grafisch von Hand einbaue? Ich kann ja im Ausgangsbaustein immer nur EIN KO anfassen und das ist bei vielen KOs (>50) sehr umständlich!!!

Deine Antwort kenne ich vermutlich schon:
Ich soll auf die Import/Export Funktion warten, damit ich Logiken per Skript generieren kann, richtig?

[vento66]

Meinst Du sowas:

https://knx-user-forum.de/forum/proj...-ausgangsboxen


Oder sowas:
http://service.knx-user-forum.de/?co...ad&id=19000604

[Nanosonde]

Meinst Du sowas:

Geht schon irgendwie in die Richtung. Aber ich möchte ja nichts selbst anlegen, sondern vorhandene KOs abonnieren.
Warum?

Nochmal zum Problem:
Bei MQTT ist es so, dass die Clients sich mit dem Broker verbinden und dann ein Topic abonnieren, wenn sie an bestimmten Infos interessiert sind.
Ein anderer Client postet (PUBLISH) eine Information auf ein Topic. Dabei weiß er jedoch nicht, wer und ob überhaupt jemand zuhört.
Beim Abonnieren (SUBSCRIBE) wissen die Clients ebenfalls nicht, ob und wann jemand etwas auf diesem Topic mitteilt.
-> Keiner weiß vom anderen etwas (*).

Ein MQTT Client, der die internen KOs von Edomi zur Verfügung stellen möchte, muss also in der Lage sein, immer ALLE KOs bzw. deren sich änderende Informationen per MQTT PUBLISH auf dem Broker zur Verfügung stellen zu können.

(*)
Natürlich könnte man sowas über eigene proprietäre Kommunikation mittels Topic/Payloads (über MQTT) selbst generieren. Dies Ist aber nicht Bestandteil der MQTT Spezifikation. Auch müssten sämtliche MQTT Clients diese speziellen Eigenarten kennen. ->blöd.

[Nanosonde]

Sooo, wie angekündigt, habe ich gerade die beiden MQTT Bausteine veröffentlicht:
https://knx-user-forum.de/forum/proj...publish-client

Jetzt muss halt für jedes gewünschte interne KO einzeln mit Hilfe der Logik etwas gebaut werden:
Viele Instanzen von einem der MQTT Bausteine, dann jeweils mit einer Ausgangbox und dem entsprechenden KO.

Aktuell muss das Topic immer fix sein. Bei deiner Änderung muss eine Projektaktivierung erfolgen.
Könnte man auch so umbauen, dass das Topic änderbar ist. Eine Logik müsste dann aber den String für das Topic zusammen bauen.