WebSocket in IPS - oder: wie bekomme ich effizient an externe Daten ?

socrates · 1. Dezember 2018 um 20:05

Hallo zusammen,

ich bin derzeit blutiger Anfänger, soweit es IP-Symcon betrifft. Bislang lief die „Automatisierung“ bei mir über eine Homematic CCU, ein RFXLAN sowie div. Perl und Python Scripte.

Nun möchte ich gerne das ganze an einer zentralen Stelle bündeln. Zunächst möchte ich alle Informationen nur im IPS haben. (Später dann ggf. die externen Scripte durch IPS interne Skripte ersetzen)

Zum Punkt Informationen in IPS sammeln:

Hier habe ich die JSON-RPC Schnittstelle gefunden:

Datenaustausch — IP-Symcon :: Automatisierungssoftware

Das ganze funktioniert auch schon in einem meiner Perl-Script. Ich kann einen Wert aus der CCU mit dem Perl-Script überschreiben.

Später bin ich dann noch hierauf gestoßen:

IP-Symcon - Wie kann ich… 2.0 - Seite 7

Dürfte genauso gut funktionieren.

Was mich bei beiden Ansätzen stört: Der Overhead. Es wird jedes Mal eine TCP-Verbindung auf und wieder abgebaut. Das dürfte bei größeren Datenmengen (nicht, dass ich die unbedingt schon habe) sehr schlecht skalieren.

Viel lieber wäre mir ein Websocket. Es scheint schon ein grundlegendes Modul für IP-Symcon zu geben:

WebSocket:
IPSNetwork/WebSocketServer at master Â· Nall-chan/IPSNetwork Â· GitHub

Ich würde die Daten aus den (Perl, Python) Scripten gerne per JSON an IPS senden.

Leider kann ich noch überhaupt nicht blicken, wie viel „Logik“ dafür noch in IPS fehlt. Wie gesagt… PHP kann ich noch kein Stück, und die Konzepte in IPS sind mir (leider) auch noch nicht klar.

Wenn die JSON Nachricht beispielsweise so aussehen würde:

msg = {
        obj : 14368, # Object ID in IPS
        val : 20.0   # Object value, e.g. temerature
     };

sollte doch ein „generisches“ Script ausreichen, welches als „Pseudocode“

    getObject(obj).setValue(val) # getObject(14368).setValue(20.0)

ausführt.

Macht das Sinn?

Gibt es sowas ggf. schon?

Gibt es etwas ähnliches, bei dem ich „abgucken“ könnte?

Erst einmal vielen Dank für das Lesen meines Posts!

Gruß,
Soc

Fonzo · 1. Dezember 2018 um 22:53

Was willst Du denn genau machen? Aktiv irgendwas in IP-Symcon von einer CCU schreiben must Du nicht. Du must nur Homematic einrichten.
Ansonsten must Du mal genauer schreiben was Du beabsichtigest durchzuführen. Sobald sich ein Wert in der CCU ändert, wird dieser auch automatisch in IP-Symcon geändert, dazu must Du nichts aktiv mit Skripten tun.

Dazu müstest Du mal näher schreiben was die Perl und Python Skripte denn genau machen, bzw. welchen Zweck die dienen, nur so kann man dann beurteilen ob das überhaupt notwendig ist.

Ich glaube es würde helfen wenn Du noch mal näher schilderst was Deine Skripte genau machen. Auf der ersten Bilck hört sich das für mich so an als ob das keinen direkten Sinn macht, da Du die Veränderungen an Datenpunkten der CCU direkt in IP-Symcon mitbekommst dazu must Du nichts mit Skripten an IP-Symcon schicken.

Beurteilen kann man das aber wie gesagt nur wenn Du schilderst was Deine Skripte zur Zeit so an Aufgaben übernehmen.

socrates · 2. Dezember 2018 um 11:09

Hallo Fonzo,

vielen Dank für Deine Antwort!

Stimmt. Ich hab Homematic auch eingerichtet und es funktioniert sehr gut. Die Homematic Variable hab ich nur zum Testen verwendet. Wie gesagt, ich versuche mich gerade erst in IPS einzulesen. Und wie ich ein „Objekt“ (z.B. ein Temperatur und Feuchtigkeitssensor) einrichte, dass mehrere Parameter (Temperatur, Feuchtigkeit, Batterielevel) hat, ist mir noch nicht klar.

Ok. Der erste Anwendungsfall ist ein RFXLAN Adapter. Es handelt sich dabei um ein Vor-Vorgängermodul von diesem: RFXCom - DomotiGa

Das ganze habe ich mit einer alternativen Firmware (vom Hersteller) geflasht, so dass es nun xPL spricht:

xPL Protocol - Wikipedia

Dann gibt es einen in Perl geschriebenen „xPL-HUB“ nebst xPL-Monitor:
Install xpl hub - xPL

Damit habe ich die Werte des RFXLAN im Klartext. Diese würde ich nun gerne an einen WebSocket in IPS schicken und dort den jeweiligen Objekten zuordnen.

Wie gesagt: per json-rpc funktioniert das auch schon, nur hätte ich gerne eine permanente Session, statt für jeden Wert eine TCP Verbindung aufbauen zu müssen.

Wie gesagt: es gibt noch andere Skripte und „Aufgaben“… aber wenn ich dieses „Problem“ gelöst habe, bin ich sicher schon weiter auf der Lernkurve… ggf. erschließen sich dann Dinge von selbst

Vielen Dank und einen schönen Sonntag!

Fonzo · 2. Dezember 2018 um 12:14

Bei Homematic sind die Datenpunkte auf verschiedene Kanäle aufgeteilt. Batterielevel ist z.B. Kanal 0 und die anderen Datenpunkte hängt jeweils vom Gerät ab. In dem Moment in dem Du den Kanal in IP-Symcon importiert werden Dir die verfügbaren Datenpunkte automatisch angelegt. Du kannst also gezielt die Geräte mit den Kanälen anlegen, die Du benötigst.

Alternativ kann Du z.B. auch mit Homematic Easy Install Dir zunächst alles anlegen lassen und dann alles löschen was Du nicht brauchst.

Gehe mal im ersten Ansatz immer davon aus das Du ein Gerät direkt aus IP-Symcon ansteuern kannst, insofern Dir die Art wie mit dem Gerät kommuniziert ist bekannt sein sollte. Erst wenn dies nicht einfach oder Skripten gehen sollte würde ich mir Gedanken machen wie ich das mit zusätzlichen Skripten realisieren kann.

Bezüglich dem Einbinden von bestimmten Geräten würde ich an Deiner Stelle nach dem speziellen Gerät im Forum suchen oder speziell für das Gerät einen separaten Thread mit einer Frage erstellen, dann lässt sich das eher zuordnen bzw. wird überhaupt gelesen, bevor so ein Thema unter einer allgemeinen Frage untergeht.

Schon mal unter RFXtrx ob Du das Gerät nicht direkt über einen Clientsocket aus IP-Symcon ansprechen kannst.

Wenn Du direkt über xPL Protokoll aus IP-Symcon gehen willst legst Du einen UDP Socket unter IO Instanzen an auf Port 3865. Dann kannst Du über den UDP Socket Daten mit USCK_SendText Daten versenden und bekommst auf dem UDP Socket die Daten auch in IP-Symcon zurück.

Bei einem Modul würden die dann automatisch verarbeitet werden, per Hand machst Du das mit einer Register Variable und einem Skript in IP-Symcon.

Ergänzung:
Statt dem UDP Socket würde ich einen Multicast Socket in IP Symcon auf Port 3865 öffnen, da das Gerät auf dem Port Broadcast sendet. So solltest Du also alles was das Gerät von sich gibt auch in IP-Symcon empfangen, Du müsstest es dort dann „nur“ noch auswerten.

In dem Moment in dem Du einen Server-, Client, UDP- oder Multicast Socket in IP-Symcon nutzt, erübrigt sich die Frage nach dem ständigen Verbindungsaufbau, da die Session auf dem Port dann kontinuierlich zum Gerät bestehen sollte.

socrates · 2. Dezember 2018 um 17:25

Ja, mit HomeMatic und den TP-Link HS110 (WLAN Schaltsteckdosen mit Energiemonitor) hat das auch sehr gut funktioniert. „Plug and Play“

Super!

Das scheint genau der „Schubs in die richtige Richtung“ zu sein, den ich mir erhofft hatte. Ich teste mal ein wenig und berichte dann… wahrscheinlich aber erst nächsten Wochenende :-/

Danke & Gruß

Soc

socrates · 12. Dezember 2018 um 16:39

Hallo nochmal!

RFXtrx nutzt leider nicht das selbe Protokoll wie RFXLAN. Und ich habe (anscheinend) schon die 2. Generation RFXLAN; bei der ersten geht noch nicht einmal xPL.

Leider muss ich mir eingestehen, dass ich doch mehr „Administrator“ als „Programmierer“ bin. In der mir zur Verfügung stehenden Zeit werde ich nicht das xPL Protokoll in PHP nachbilden und das ganze in IPS einbinden können.

Um also überhaupt Fortschritte machen zu können, würde ich nun doch „JSON-RPC“ von IPS nutzen.

Sehr hilfreich ist dabei für mich, dass es bereits ein in Perl geschriebenen xPL-Hub nebst Monitor gibt (http://www.dspc.ch/xPL/index.php/Install_xpl_hub)

Die Ausgabe dieses xpl-monitor.pl sieht so ähnlich aus:


--------------------------------------------------------------------------------
xpl-trig
{
hop=1
source=rfxcom-lan.0004a31bb6c4
target=*
}
sensor.basic
{
device=th1 0x3801
type=temp
current=15.8
units=c
}
--------------------------------------------------------------------------------
xpl-trig
{
hop=1
source=rfxcom-lan.0004a31bb6c4
target=*
}
sensor.basic
{
device=th1 0x3801
type=humidity
current=62
description=normal
}
--------------------------------------------------------------------------------

Diese Informationen im Script weiterzubearbeiten und per JSON-RPC an IPS zu senden, ist selbst für mich fix erledigt
Auch wenn das mit Overhead verbunden ist: Betrachtet man den xpl-monitor eine zeitlang, so ist ersichtlich, dass sich da gar nicht sooo viel tut (rel. langsame Updates).

Eine Frage hätte ich jedoch noch: Gibt ein einen einfachen Weg, ein „Leeres Objekt“ (eine Art „Java-Bean“) zu erzeugen?

Für ein TASMOTO Gerät, z.B. habe ich das Objekt, und dazu die Variablen POWER,RSSI,Status: -> https://imagebin.ca/v/4Pl8tnpoQUXt

Ich würde gerne ein Objekt „Sensor“ erzeugen, welches dann die Attribute TEMPERATURE,HUMIDITY,BATTERY,(NAME) hat. Diese Attribute dann per JSON-RPC füttern.

PS: Das ist eigentlich eine neue Frage und sollte in einen neuen Thread. Mache ich auch, wenn gewünscht, gerne. Nur scheint mir auch der Kontext der Frage hier sinnvoll…

Vielen Dank!

GerhardBS · 12. Dezember 2018 um 22:22

Hallo,

Du könntest statt eines Objektes auch eine Funktion aufrufen mit den Attributen. In der Funktion erzeugst Du das JSONRPC Objekt und übergibst die Daten. Ob mit diesem Objekt soviel overhead erzeugt wird, kann ich nicht sagen. Bei mir geht dies recht zügig:

$rpc = new JSONRPC(„http://user:password@127.0.0.1:3777/api/“);
$rpc->SetValueFloat(id1, value1);
$rpc->SetValueFloat(id2, value2);
$rpc->SetValueFloat(id3, value3);

Statt Float kannst Du natürlich auch Integer oder Boolean nehmen.

Grüße, Gerhard

socrates · 17. Dezember 2018 um 10:25

Hallo

So, nun bin ich wieder einen Schritt weiter… Es läuft (aber ich habe schon wieder eine Modifikation im Sinn…)

Wie rufe ich denn eine Funktion in IPS von aussen auf? Gibt es noch einen anderen Weg als JSON-RPC?

Zu meinem Status:

i) wie kann ich mehrere Variablen zu einem Objekt zusammenfassen?

–> Dafür gibt es das Dummy Modul. Anlegen, und am Modul dann wieder Variablen erzeugen.

ii) RFXLAN vs RFXtrx:

RFXtrx scheint tatsächlich ein anderes Protokoll zu nutzen. Daher scheint die beste Möglichkeit für den RFXLAN über die xPL Firmware zu sein. Zunächst hatte ich die o.g. Perl Scripte xPL-hub und xPL-mon. Den xPL-mon habe ich dann umgeschrieben, um die Daten per JSON-RPC in IPS zu bekommen.

Problem: In Perl gibt es keine expliziten Datentypen. Perl ‚entscheidet‘ on the fly den Datentyp. Daher ist es auch möglich, zwei Zahlen-Strings zu addieren: „2.22“ + 1.11" -> erzeugt einen String „3.33“.
Aber: Das JSON-RPC ist sehr „pingelig“ mit den Datentypen. Da es auch keine „cast“ Funktion in Perl zu geben scheint, kamen die Daten nicht verlässlich in IPS an.

Lösung: Das ganze in Python machen. Auch hier gibt es xPL und JSON-RPC libs.

Aus div. Gründen (u.a. kein LAN Anschluss in der Nähe des Punktes an dem der RFXLAN strategisch am sinnvollsten wäre) bin ich auf das hier gestoßen:

433-mhz-aussentemperatur-sensor-mit-raspberry-pi-auslesen/

Raspberry PI und ‚software defined radio‘ für 433MHz Sensoren

…falls das Protokoll der Sensoren nicht bekannt ist:

https://alexbloggt.com/funkthermometer-sdr/

…sowie für die Antenne:
https://crycode.de/diy-433-mhz-dipol-antenne

PS: Ich bin mir durchaus bewusst, dass der Post hier vllt off-topic ist. Aber vllt hilft es ja dennoch (irgendwann) jemandem