Loxone-Symcon-Anbindung über die JSONRPC-API

IP-Symcon Skripte, PHP, SQL (Fragen)
1

Morgen,

unsere aktuelle Smarthome-Wohnung besteht aus sehr vielen kleineren „Bastelprojekte“ mit Arduinos, ESP, Raspberry, Shelly, Homematic u.a. alles schön miteinander verheiratet mit Symcon.

Seit einiger Zeit bin ich auch mit einem KNX-Testboard und dem Loxone-Musterkoffer unterwegs, nachdem die KNX-Anbindung nicht wirklich ein Problem dargestellt hatte, bin ich seit dem Wochenende an einer Loxone Lösung dran.

Mir ist absolut klar, viele Wege führen nach Rom, es gibt zig Möglichkeiten wie Loxberry, MQTT, UDP oder andere, ich habe mich mal auf den Weg der „virtuellen Ausgänge mit http Aufruf“ auf Seiten Loxone und der JSONRPC-Anbindung auf Seiten Symcon befasst.

Bisher sind alle Versuche mit offiziellen Funktionen gescheitert, allerdings habe ich bereits einen funktionierenden Workaround, welchen ich gerne hier teilen werde, sobald er fertig ist.

Ich möchte aber auch zusehen, nicht gleich die erstbeste funktionierende Lösung zu präsentieren, sondern diese auch vielleicht noch etwas optimieren und wäre hier auf Eure Ideen und Vorschläge gespannt.

Mein aktuelles Thema:
Der virtuelle Ausgang von Loxone scheint ein Thema mit der Authentifizierung zu haben. Im Speziellen die Encodierung von %40 innerhalb der Emailadresse des Benutzernamens.

Frage 1:
Hab ich eine Möglichkeit einen eigenen Benutzernamen zu definieren, welcher kein @ enthält?
Frage 2:
Ich glaube, ich könnte das Webfront via JSONRPC ansteuern mit Benutzer webfront? Dadurch sollte ich auch eine Variable auf true/false ändern können, oder?

Mein aktueller Weg ist ein PHP-Skript welches auf meinem NAS-Apache läuft.
Hier habe ich auch eine HTTP-Authentication eingebaut, weiterhin nimmt es die Parameter z.B. Symcon-Variable + Schaltwert entgegen.

Der Aufruf ist:
http://admin:admin@SYMCONIP:3777/test.php?symcon_id=12345&symcon_value=true

Meine Frage 3:
Kann ich das Skript im Symcon wo ablegen und verwenden, ohne mich am Symcon selbst anmelden zu müssen?

Das mal fürs Erste…
LG

2

Nein, das ist nicht möglich.

Schau dir das mal an: WebHook Control —IP-Symcon :: Automatisierungssoftware

paresy

3

Dankeschön, dass sieht mal vielversprechend aus…

4

Hallo,

ich habe nun meinen ersten Beitrag fertig, in welchem ich wie oben schon mit einem „Hilfsskript“ aus dem Loxone Miniserver eine Variable in Symcon schalte.

Genauer gesagt steuere ich Rohrmotore, welche über DECT an der Fritzbox hängen über Symcon bzw. dem Miniserver an. Das erste Skript ist in meinem Blogbeitrag enthalten:
Rolladen via Loxone Miniserver über Symcon & Fritzbox steuern

Ein neuer Beitrag ist gerade in Arbeit, wo ich auf die Webhooks von Symcon eingehe, hier möchte ich aber auch gleich einen Schritt weiter gehen und nicht nur Informationen von Loxone nach Symcon schicken, sondern auch welche aus Symcon auslesen…

Auch hier wird ein separater Beitrag inkl. dem Skript folgen…

5

Ich möchte Euch heute über meine neuesten Erkenntnisse informieren, nachdem ich einige Stunden mit Fehlersuche verbracht habe.

In meinem neuesten Beitrag, welcher demnächst folgt, habe ich ein Skript entwickelt, welcher nicht nur eine Variable vom Miniserver nach Symcon verändert, sondern diesmal auch den Wert liest.
Hier setze ich auf die Befehle SetValue und GetValue.

Das Problem war, mit meinem externen Skript wie im vorherigen Link hatte auch das Lesen funktioniert. Mit dem Symcon Hook leider nicht.

Loxone hatte mir immer angezeigt, dass der virtuelle HTTP-Eingang keine Werte bekommt. Im Log sah man jedoch die Werte…

Ursache waren dann im Response-Header zu finden. Mein Skript hatte „HTTP/1.1 200 OK“ geliefert, der Webhook von Symcon „HTTP/1.0 200 X“
Das gefiel Loxone wohl nicht.

Dem Hook habe ich dann:
header('HTTP/1.1 200 OK');
hinzugefügt und schon klappts…

Ich werde meinen Beitrag im Blog fertigstellen und dann gerne hier verlinken.

In der Zwischenzeit meine Frage an Symcon, ob es hierfür evtl. einen schöneren Weg oder Parameter gibt, dass die Hooks mit HTTP/1.1 ausgeliefert werden???

LG

6

Das ist definitiv nicht schön, dass wir da ein X statt OK senden. Ich fixe das, sodass OK und auch direkt HTTP/1.1 gesendet wird. (Kommt zur 5.6) Danke für den Fund. Spannend, dass dies niemand seit 6 Jahren entdeckt hat :face_with_monocle:

Wobei es auch kein Fehler von uns ist, sondern klar Loxone hier nicht korrekt auswertet. Siehe: HTTP/1.1: Response. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.

paresy