CUxD <-> BIN-RPC <-> Methode "event"

Anbindung von FS20-Komponenten, ELV-Wetterstationen, EnOcean und DMX an HomeMatic

Moderator: Co-Administratoren

ayngush
Beiträge: 345
Registriert: 02.02.2012, 12:05
Danksagung erhalten: 7 Mal

CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von ayngush » 19.04.2013, 09:25

Hallo,

ich beschäftige mich gerade damit, die Daten der CUxD Devices abzufragen bzw. einen RPC-Server anzumelden.
Das Anmelden des Servers klappt bereits, das "Schalten" der Devices auch. Jedoch habe ich echt keine Ahnung, was mir der CUxD da als Rückmeldung schickt :)

Folgendes habe ich mir da zurecht gebogen:
Aus dem HMXMLBIN Projekt auf Github die BIN-RPC Klasse extrahiert und zum laufen gebracht ;)

192.168.1.200 = CCU
192.168.1.210 = Raspberry PI

INIT auf http://192.168.1.200:8701 mit den Parametern: http://192.168.1.210:80/status/binrpc-server.php, ID123123, request
Das wird vom CUxD auch als Erfolg ins Log geschrieben

Wenn ich jetzt ein CUxD Device schalte, sah ich zunächst im Apache error.log, dass die Request Method "Bin" angefordert wurde, die nicht unterstützt wird.
Die Request URI war "/", also wurde mein Pfad zum Script ignoriert und die Anfrage direkt an http://192.168.1.210:80 gesendet.

Also per Rewrite-Condition die Request-Method "Bin" auf mein Script umgeleitet, das funktioniert auch soweit. Dort starte ich eine neue Instanz vom BIN-RPC Server, und mache folgendes:
antwort-auswerten(sende "OK" Bestätigung)

Funktioniert auch, leider ist die Rückmeldung leer.

Kann mir also jemand, Uwe :) , sagen, wie die Event-Mitteilungen von CUxD versendet werden?

Danke schonmal

Grüße

PS: Den Quelltext von CUxD, der bei Google-Codes herum liegt, habe ich mir bereits angeschaut auch eine Stelle gefunden aber wie die Rückmeldung nun genau ausschaut konnte ich daraus nicht genau ablesen. Außerdem ist der Quelltext dort von einer alten Version.

Benutzeravatar
uwe111
Beiträge: 4807
Registriert: 26.02.2011, 22:22
Hat sich bedankt: 3 Mal
Danksagung erhalten: 239 Mal
Kontaktdaten:

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von uwe111 » 19.04.2013, 11:13

Hallo ayngush,

Wenn Du mir Deine Email-Adresse gibst, sende ich Dir den aktuellen Quelltext.
Die Events gehen direkt an die beim INIT übergebene Adresse+Port.
Das ist aber kein HTTP-Protokoll, sondern BIN-RPC.

Viele Grüße,

Uwe.
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.11, SSH KeyDir

ayngush
Beiträge: 345
Registriert: 02.02.2012, 12:05
Danksagung erhalten: 7 Mal

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von ayngush » 24.04.2013, 17:15

Hallo,

also ich kann tun und lassen, was ich will aber mehr als die Meldung "Bin" bekomme ich bei einen auslösenden Event einfach nicht an meinen per INIT registrieren Server übertragen.
Und warum muss ich mit "INIT" eine URL registrieren, wenn am anderen Ende gar kein HTTP gesprochen wird? Wenn ich keine URL registriere, sondern einfach nur "192.168.1.5:80" zum Beispiel bekomme ich die Meldung "init(192.168.1.5:80) '1921681210' not supported" ins Log geschrieben.

Hat schon mal jemand erfolgreich einen RPC-Server an CUxD registriert und empfängt die gepushten Events?

Grüße

hobbyquaker
Beiträge: 3978
Registriert: 12.07.2009, 20:01
Hat sich bedankt: 17 Mal
Danksagung erhalten: 176 Mal
Kontaktdaten:

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von hobbyquaker » 24.04.2013, 18:08

Hallo,

vielleicht hilft ja auch dieses Projekt weiter https://github.com/leonsio/HMXMLBIN

Grüße

ayngush
Beiträge: 345
Registriert: 02.02.2012, 12:05
Danksagung erhalten: 7 Mal

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von ayngush » 24.04.2013, 18:12

Hallo,

danke aber nein, leider nicht, weil auch dort bekomme ich nur "Bin" zurückgeliefert.
Ich habe mir bereits ein Programm geschrieben, was einfach den gesamten eingehenden Netzwerkverkehr auf dem entsprechenden Port wegschreibt... strlen: 3, ASCII: "Bin"...

Edit: So, Wireshark mal wieder ausgegraben :)
Die Daten kommen schon richtig an

Code: Alles auswählen

42696e00000000f80000001073797374656d2e6d756c ... usw.
ich bin offenbar einfach nur zu blöd den Kram auszuwerten, *gnampf* :/

Grüße
Zuletzt geändert von ayngush am 24.04.2013, 18:21, insgesamt 2-mal geändert.

Benutzeravatar
uwe111
Beiträge: 4807
Registriert: 26.02.2011, 22:22
Hat sich bedankt: 3 Mal
Danksagung erhalten: 239 Mal
Kontaktdaten:

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von uwe111 » 24.04.2013, 18:15

ayngush hat geschrieben: also ich kann tun und lassen, was ich will aber mehr als die Meldung "Bin" bekomme ich bei einen auslösenden Event einfach nicht an meinen per INIT registrieren Server übertragen.
Wie sieht denn Dein INIT-Paket genau aus? Es muss BIN-RPC sein!
ayngush hat geschrieben: Und warum muss ich mit "INIT" eine URL registrieren, wenn am anderen Ende gar kein HTTP gesprochen wird?
Weil eine URL eigentlich nicht auf HTTP festgelegt ist.
ayngush hat geschrieben: Wenn ich keine URL registriere, sondern einfach nur "192.168.1.5:80" zum Beispiel bekomme ich die Meldung "init(192.168.1.5:80) '1921681210' not supported" ins Log geschrieben.
Naja... er kann halt nur BIN-RPC und deshalb muss als Protokoll in der URL auch "xmlrpc_bin://..." stehen.
ayngush hat geschrieben: Hat schon mal jemand erfolgreich einen RPC-Server an CUxD registriert und empfängt die gepushten Events?
Ja, das habe ich schon gemacht. Und andere auch.

Viele Grüße,

Uwe.
Alle sagten: Das geht nicht. Dann kam einer, der wußte das nicht und hat's einfach gemacht.
SPENDEN :wink: Download: CUxD 2.11, SSH KeyDir

ayngush
Beiträge: 345
Registriert: 02.02.2012, 12:05
Danksagung erhalten: 7 Mal

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von ayngush » 24.04.2013, 18:25

Hallo Uwe,

danke für deine Rückmeldung. Der INIT-Aufruf stimmt soweit, ich bekomme das ganze schon registriert.
Ich habe nur ein Problem damit die Rückmeldungen auszuwerten, siehe oben.
Offenbar stimmt hier irgendwas nicht in meinem Bregen :)
Ich bin die ganze Zeit dabei Einsen und Nullen auszuwerten, dabei kommt der Kram in Bytes? an...

Der PHP-CLI-Proxy läuft bei mir nicht, weils Script wüste Fehler wirft, die ich aber nicht in der Ausgabe habe, da sichtbare PHP-Fehler abgeschaltet sind auf meinem Server... Man sollte sich zwischendurch einfach mal die Error.logs anschauen :)

Wie gesagt, ist irgendwie nicht mein Tag heute... ich gehe jetzt erst mal ein Eis essen.

Grüße

thue
Beiträge: 5
Registriert: 24.04.2013, 07:35

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von thue » 24.04.2013, 19:57

Hallo ayngush,

bin auch gerade gerade an dem Problem dran. Ich kann mich an der CCU registrieren; leider komme ich nicht an die binären Daten der CCU Rückmeldung. Im Apache eventlog sehe ich diese allerdings.
Habs schon mit einem php Socket-Server probiert, das ist aber eigentlich nicht das, was ich will. Ich hätte es gerne auf den apache in eine php-Seite eingeliefert bekommen.
Kannst Du bitte mal Deine "binrpc-server.php" posten, damit ich sehen kann, wie du über die Kombination apache->php-Seite an die Daten des multicalls vom CuxD kommst ?. Eine Konvertierung von bin nach xml sollte ich mit hmxmlbin hinbekommen; damit löse ich ja auch den init-Call aus.

Vielen Dank
Thomas

thue
Beiträge: 5
Registriert: 24.04.2013, 07:35

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von thue » 24.04.2013, 21:44

Hallo uwe111,

ich habe die CuxD Eventverarbeitung zunächst provisorisch über einen schon angesprochenen php-Socket-Server gelöst. Wenn man sich jedoch den Multicall genau ansieht, so sieht dieser z.B. als php-array wie folgt aus (Es ist ein FHT-80b):
[0] => Array
(
[methodName] => event
[params] => Array
(
[0] => CUxD
[1] => CUX0800001:1
[2] => TEMPERATURE
[3] => 20,9
)
)

[1] => Array
(
[methodName] => event
[params] => Array
(
[0] => CUxD
[1] => CUX0800001:1
[2] => MISS_24H
[3] => 3
)

)

....

Ein Event ist in der Dokumentation wie folgt definiert:
void event(String interface_id, String address, String value_key, ValueType value)

Der erste Parameter "interface_id", der immer "CUxD" ist, ist jedoch aus meiner Sicht falsch. Zwar ist in der Homematic-Dokumentation beschrieben, dass sich dort der Interface-Prozess einträgt, der das Event sendet, in der Praxis bekomme ich jedoch über den Standard xml-rpc Callback immer meine eigene Registrierungs-ID zurück, die ich bei "init" angegeben habe; hier scheint es, dass die HM-Doku falsch ist. Dass der CuxD die Information sendet, wird bereits durch die Geräteadresse klar.
Das macht auch Sinn, da ich z.B. mehrere CCUs habe, aber allen die gleiche Callback-Url mitteile. Ich gebe jeder CCU Registrierung eine eigene ID mit. Welche CCU dann das Events gesendet hat, kann ich dann wieder durch die interface_id ermitteln.

Es wäre Super, wenn das geändert werden könnte; notfalls auch durch einen weiteren Parametereintrag im Events array.

Viele Grüße
Thomas

ayngush
Beiträge: 345
Registriert: 02.02.2012, 12:05
Danksagung erhalten: 7 Mal

Re: CUxD <-> BIN-RPC <-> Methode "event"

Beitrag von ayngush » 24.04.2013, 23:39

thue hat geschrieben: bin auch gerade gerade an dem Problem dran. Ich kann mich an der CCU registrieren; leider komme ich nicht an die binären Daten der CCU Rückmeldung. Im Apache eventlog sehe ich diese allerdings.
Habs schon mit einem php Socket-Server probiert, das ist aber eigentlich nicht das, was ich will. Ich hätte es gerne auf den apache in eine php-Seite eingeliefert bekommen.
Kannst Du bitte mal Deine "binrpc-server.php" posten, damit ich sehen kann, wie du über die Kombination apache->php-Seite an die Daten des multicalls vom CuxD kommst ?. Eine Konvertierung von bin nach xml sollte ich mit hmxmlbin hinbekommen; damit löse ich ja auch den init-Call aus.
Hallo und herzlich willkommen im Club...
Ich stehe vor GENAU den selben Problem.
Meine Lösung soll es vorsehen ein C-Programm als Proxy zu verwenden, was auf der einen Seite die BIN-Calls entgegen nimmt und diese, lesbar formatiert per POST an ein PHP Script weiterleitet, damit man damit in einen Webfrontend und Datenlogger weiterarbeiten kann.

Mein Problem ist aber auch das gleiche wie du es hast: Ich kann zwar meinen Server per INIT Anmelden (aktuell über ein PHP-Script bestehend aus Teilen des hmxmlbin-Scripts) aber die Rückmeldung macht nur Stress.

Das Problem welches ich habe ist, dass ich erstens "C" circa 1 Jahr lang mal auf einen Din-A4-Zettel "programmieren" durfte und zweitens, dass diese Binärdaten, die da übermittelt werden keinen gültigen "String" / ("array of character", wie ich mal wieder lernen musste), ergeben und deswegen jede halbwegs schlaue Routine den Input nach "Bin" abschneidet.

Beispiel:

Code: Alles auswählen

long rc = empfangene Bytes
char buffer[1024] = Daten vom Socket... fängt an mit 42696e00000000f80000001073797374656d2e6d... usw. also 42:69:6e:00 hex-to-ASCII-String ergibt das "Bin\0"

for(i=0;i<rc;i++) {
	printf("%c",buf[i]);
}
printf("%s %d",buffer,strlen(buffer));
Das printf("%c",buf); gibt alle Zeichen korrekt als ASCII aus.
Das printf("%s %d",buffer,strlen(buffer)); gibt nur "Bin" aus, die strlen wird als "3" ausgewiesen.
Muss wohl daran liegen, dass nach "Bin" das String-Ende-Zeichen kommt.

Eventuell hat ja jemand eine Idee, wie ich in C meinen Empfangspuffer in eine ordentlich lesbare Ausgabe umwandle, ich bin jetzt den ganzen Tag nicht drauf gekommen...

Grüße

Antworten

Zurück zu „CUxD“