HVL & Raspberrymatic 3.41.11.20181126 about homematic-virtual-interface HOT 101 CLOSED

@jens-maus na das ist einfach. Wenn aus der Interface.xml ein 127.0.0.1 als Host kommt dann Callback auf 127.0.0.1 wenn nicht dann auf die eigene LAN Schnittstelle.

from homematic-virtual-interface.

Ich würde das unentbehrliche HVL auch gerne wieder ans laufen bekommen mit der aktuellen CCU FW.

Hier geht es zum entsprechenden Eintrag, der obere funktioniert ja nicht mehr weil er geschlossen wurde.
jens-maus/RaspberryMatic#492

from homematic-virtual-interface.

Hier auch noch einmal der Hinweis das im optimalen Fall man keinerlei 3xxxx Ports in der CCU freigeben sollte (siehe jens-maus/RaspberryMatic#492 (comment)). HVL sollte also auf das Auswerten der InterfacesList.xml verzichten da hier nur die internen Ports vermerkt sind.

from homematic-virtual-interface.

Es ist ruhig um @thkl geworden, auch im Forum war er schon lange nicht mehr online. Hoffentlich passiert da noch was, ich würde es mir wünschen. HVL ist echt ne super Sache.

Habe es seit erscheinen im Einsatz und es lief immer sehr gut, und wenn nicht, hat @thkl schnell Abhilfe geschaffen.

@jens-maus seitdem es HVL gibt läuft das mit der InterfacesList.xml so, bisher gab es da nie Probleme, ist das so schlimm bzw. sollte man es unbedingt anders lösen? Also ich frage nur weil es mir interessiert.

from homematic-virtual-interface.

So ruhig ist es doch gar nicht (siehe 558e2b3). :)
Er hat da bereits einen workaround für Firmware 3.41.x eingebaut. Allerdings empfinde ich den als recht schlechten workaround. Hier sollte besser so vorgegangen werden, das ganz auf das Auswerten der InterfacesList.xml verzichtet wird oder zumindest für die jeweiligen bekannten Interfaces (BidCos, HmIP, CUxD, etc.) feste ports angenommen werden und nicht die dort vermerkten URLs 1:1 so übernommen werden wie das wohl gerade in HVL der Fall ist. D.h. man sollte auch nicht via eines ReGa-Skriptes aus der Ferne versuchen die Interfaces abzufragen. Das ist und war noch nie der offizielle Weg und das fällt HVL nun eben gerade auf die Füße.

from homematic-virtual-interface.

Ach das habe ich noch garnicht gesehen, cool das es weitergeht.

Also ich verstehe nur so halb was du meinst. Wenn @thkl das hier liest, weiß er dann was du meinst bzw. weiß es dann durch deinen text wie er es "richtig" machen sollte?

Wie gesagt, ich bin absolut überzeugt von HVL und froh das es es gibt. Daher wäre es nur cool, wenn es in Zukunft auch vernünftig läuft. Bzw. bei mir ist ja es wie gesagt immer vernünftig gelaufen.

Bis RaspberryMatic 3.37.8.20181026 musste man auch keine Ports freigeben. Aber das liegt jetzt mit der neuen Version wohl am Umbau der Firewall?

from homematic-virtual-interface.

Haaaaalt :
Die Auswertung der Interfaces.xml erfolgt nur zu dem Zweck des Tests ob das eigene HVL Interface da ist.

Die CCU (also Rega) macht nach dem Boot einen Init auf die HVL Adresse. Liefert da aber seit neuestem xml_rpc://127.0.0.1:31999 als callback URL. Dort ist aber augenscheinlich keiner zu Hause. Deswegen der Stunt mit Port - 30000 ....

from homematic-virtual-interface.

Klar wird er wissen was ich meine :)

Im übrigen hat das alles auch nichts mit RaspberryMatic zu tun. Das selbe Problem tritt auch mit einer CCU3 auf. Und ja, das alles liegt daran das es mit der 3.41.x firmware verbesserte Sicherheitseinstellungen (Firewall&Authentifizierung) gibt.

from homematic-virtual-interface.

@thkl Ah, nun verstehe ich :) Kannst du dazu bitte mal den response payload zeigen damit ich das nachvollziehen kann?

from homematic-virtual-interface.

Hi @thkl, es freut mich von dir zu hören :-)

@jens-maus, klar, habe nur RM geschrieben weil ich die schon seit ewig nutze :-)

from homematic-virtual-interface.

@jens-maus den Payload des Init Requests von Rega nach dem Boot ?

Ja ich lebe noch, viel Arbeit wenig Zeit :) und noch wenig davon, um sie in einem Forum zu verbrennen. 😀

from homematic-virtual-interface.

@thkl Ja, bitte mal deinen XMLRPC Request und die Antwort darauf zeigen.

Und das auf :31999 keiner zuhause ist stimmt eigentlich nicht ganz. die gemeldete URL referenziert ja auf 127.0.0.1 und innerhalb der CCU lauscht Rega sehr wohl auf Port 31999 am 127.0.0.1 interface. D.h. du solltest IMHO erst gar nicht die callback URL dort auswerten und dann auch noch so einen Stunt mit -30000 versuchen, sondern du weisst ja von vorn herein das du mit der ReGa sprichst und diese IMMER auf port 1999 zu finden ist und mit der gleichen IP wie dein request rausging.

from homematic-virtual-interface.

@jens-maus den Payload des Init Requests von Rega nach dem Boot ?

Ja ich lebe noch, viel Arbeit wenig Zeit :) und noch wenig davon, um sie in einem Forum zu verbrennen. 😀

Viel Arbeit ist immer gut. Aber danke das du hier weiter machst.

from homematic-virtual-interface.

Doch ich muss auf die Callbacks hören. Denn der selbe Init kommt von HMServer (groups) daher ist das schon ok. Ich wollte mit Absicht keine festen Ports nehmen. Wenn man schon der Antwort von Rega nicht trauen kann, wem dann 😃 ... und ja ich verstehe den Zusammenhang mit internen Sports und dem was die Firewall rauslässt :)

from homematic-virtual-interface.

Auch von mir ein Danke das es hier weiter geht. Auch ich möchte nicht mehr auf HVL verzichten.

Die Tage geht mal eine Spende an @thkl und @jens-maus raus. @thkl wo kann ich für dich spenden?

from homematic-virtual-interface.

Wie gesagt, ich kann nur noch einmal anraten das auf feste Ports umzustellen denn sollten die internen Ports noch einmal umgestellt werden wird dein "-30000" workaround wieder schiefgehen. Auf die Callbackurls kann man sich defakto als externe Applikation nicht verlassen.

from homematic-virtual-interface.

Aber eigentlich ist diese Callback URL laut Doku das wo man antworten soll. Bzw wenn ich ein Init auf ein Interface mache, muss ich die ja auch mitliefern.

Die sauberste Lösung wäre, wenn Rega eine gültige Callback URL zurückliefen würde.

from homematic-virtual-interface.

@thkl Sie liefert ja im Prinzip die richtige Adresse wenn man sich auf der CCU selbst befindet. Aber für externe Applikationen eben nicht, denn da stimmt 1. die IP-Adresse nicht (die hast du ja sonst auch immer gepatcht, genauso wie xmlrpc:// und xmlrpc_bin://) und nun eben stimmt auch der Port nicht. ReGa und die anderen XMLRPC Server wissen ja nichts davon das sie über einen lighttpd proxy kommunizieren. Ergo erscheint mir momentan der einzig sinnvolle weg zu sein feste callback urls zu verwenden die sich aus "http://", externer IP-Adresse (gleiche wie im Request) und dem festen port zusammensetzen. Und wenn du übrigens jetzt noch authentifizierung implementierst dann mach bitte gleich fest das hierfür dann zwingend https:// verwendet werden sollte da ansonsten die auth Daten unverschlüsselt übertragen werden. In einer der zukünftigen CCU firmwares wird das ggf. auch erzwungen werden (wenn auth angeschaltet, dann nur https!).

Wie schon gesagt, bitte zeig mal dein Request mit dem init, usw. und den Response darauf damit ich mir davon ein Bild machen kann.

from homematic-virtual-interface.

Aaaaaah https erzwingen und kaputte Zertifikate. Don’t ich glaubt ich schmeiß den Kram gleich weg. (Sorry geht gleich wieder)

from homematic-virtual-interface.

:) Wieso "kaputte Zertifikate" bzgl. https erzwingen?!?! Vor was hast du denn Bedenken?

from homematic-virtual-interface.

Die Zertifikate sind selbst signiert. Damit ist die Chain of Trust kaputt. Das hatten wir schon mal.
Ja, geht alles TLS damit ist besser als kein TLS.
Aber ich muss dann als Client wieder Exceptions zulassen. Wenn ich mich nicht auf das Zertifikat verlassen kann, wie soll ich dann „Man in the middle“ erkennen. Ich würde die Authentifizierung sowieso über oauth oder eine Tokenlösung abfrühstücken. Und ganz darauf verzichten das man der Maschine auf der anderen Seite permanent seine Credentials geben muss.

Aber das ist ein anderes Thema.

Ich werde einfach die Ports fest einstellen. Mit einem override aus der config. Dann kann man das ggf überschreiben.

Und ja, Rega Calls können seit dem letzten Commit auch schön mit der Authentifizierung umgehen.

from homematic-virtual-interface.

Natürlich muss man (genauso wie Webbrowser das machen) Optionen hinzufügen um sagen zu können das ein selbst signiertes Zertifikat im Einsatz ist und er entweder die Chain of Trust ab einer gewissen Tiefe ignorieren soll, oder man erlaubt das Zertifikat entsprechend herunterzuladen und als "Sicher" zu definieren damit man in the middle Attacken ausgeschlossen werden können falls das Zertifikat sich mal ändert. Alles ein wenig aufwand natürlich, aber kein Hexenwerk und auch nicht unsicher am Schluss. Und das https erzwungen wird, wird natürlich kein default werden sondern optional. Jedoch wird dann eben das anschalten der Authentifizierung mit einem erzwingen von https verknüpft werden da ansonsten man die authentifizierung auch komplett sein lassen kann weil ja sonst jeder mitlesen kann welche credential es sind.

Und gut das du die Ports nun fest verdrahten willst, das sollte der sicherste Weg sein. 👍

from homematic-virtual-interface.

Deswegen das eigene WLAN als per default sicher erklären und den ganzen TLS und Auth Schmonz weglassen. ....😜

from homematic-virtual-interface.

So handhabe ich das natürlich selbst auch, aber "unsere Freunde" die "IT-Sicherheitsexperten" sehen sowas eben anders und verfluchen ansonsten die CCU weiterhin :-)

from homematic-virtual-interface.

Wäre iÜ toll von Seiten der "Security Freunde", wenn solche Änderungen mal irgendwie vorher mal an die Leute die sich dann damit rumschlagen müssen pulbliziert werden würden. Ich rede her von den Freunden bei eq3...

from homematic-virtual-interface.

Und was hätte das geändert? ;)

from homematic-virtual-interface.

Die Änderungen (nicht nur hier sondern zb auch im HomeBridge Modul) wären vor dem Release der FW drin. Und niemand müsste Tickets auf machen ....

from homematic-virtual-interface.

Das wäre nicht garantiert gewesen denn die Komplexität und das Verständnis hätten ggf. dazu geführt das es ohnehin nicht zu 100% klar gewesen wäre was genau diese Sicherheitseinstellungen verändern. Das einzige was etwas gebracht hätte wäre eine public beta version.
Aber auch da wäre der Aufschrei groß gewesen. Ergo muss man halt auch sagen, dass die Leute die trotz größerer Warnung (und die steht im CCU Firmware ChangeLog) direkt geupdatet haben zum teil eben besser hätten etwas warten sollen und nicht immer auf die aktuellsten Versionen gehen müssten wenn entweder das technische KnowHow nicht da ist oder das System so kritisch ist das man nicht ein paar Wochen mit eingeschränkten Funktionen (vor allem im Bezug auf externe Anwendungen) leben kann. Aber lassen wir das, GitHub ist ja kein Diskussionsforum :)

from homematic-virtual-interface.

NACK ... ich hab da noch diesen IOS Client, der auch offiziell als Partnerlösung bei EQ3 läuft. Und spätestens hier hätte ich eine Info erwartet. Und nicht das ich die Änderungen aus Tickets von Usern erfahre ... aber ok .. andere Baustelle ...

from homematic-virtual-interface.

Ist es denn wichtig, dass die Formatierung in der InterfacesList.xml für den Eintrag für HVL auch korrekt ist? Weil jetzt ist er ja laut @jens-maus nicht korrekt formatiert. Oder ist der Eintrag mit der kommenden HVL Version garnicht mehr notwenig?

from homematic-virtual-interface.

Der Eintrag wird benötigt, damit Rega auf der CCU mit HVL reden möchte.
Die Formatierung sollte aber 🌭sein. Denn das ist valides XML was jede normale XML lib versteht.

from homematic-virtual-interface.

@thkl Das gilt zwar für die ReGa, aber es gibt an verschiedenen Stellen in der WebUI Routinen die die InterfacesList.xml auch parsen und dafür keinerlei XML parser verwenden sondern line-basiert nach dingen suchen ohne xml zu beachten. Es wäre daher ratsam die InterfacesList.xml bitte (wenn diese schon ergänzt wird) mit der gleichen Anzahl an newlines und Tabulatoren/spaces auszustatten bei den eintragen die hinzugefügt werden.

from homematic-virtual-interface.

CUxD macht das iÜ genauso ...

Edit: Wo muss ich für einen Rega call like rega::addInterfaceWithName:CallURL optieren ?

from homematic-virtual-interface.

Meine sieht so aus

<interfaces v="1.0">
	<ipc>
	 	<name>BidCos-RF</name>
	 	<url>xmlrpc_bin://127.0.0.1:32001</url> 
	 	<info>BidCos-RF</info> 
	</ipc>
	<ipc>
	 	<name>VirtualDevices</name>
	 	<url>xmlrpc://127.0.0.1:39292/groups</url> 
	 	<info>Virtual Devices</info> 
	</ipc>
	<ipc>
	 	<name>HmIP-RF</name>
	 	<url>xmlrpc://127.0.0.1:32010</url> 
	 	<info>HmIP-RF</info> 
	</ipc>
	<ipc>
	 	<name>CUxD</name>
	 	<url>xmlrpc_bin://127.0.0.1:8701</url> 
	 	<info>CUxD</info> 
	</ipc>
       <ipc>
                <name>HVL</name>
               <url>xmlrpc://192.168.191.40:7000</url>
               <info>HVL</info>
       </ipc>
</interfaces>

Habe mich gerade schon gewundert warum das so komisch aussieht ^^ wollte gerade schon einen Screenshot hochladen wie es in BBEdit aussieht.

thkl: ich habs mal hübsch formiert jedes Statement auf einer Zeile ... damit sollte das WebUI ja zurecht kommen

from homematic-virtual-interface.

@AdlerCentauri Mach drei ` vor/nach dem text in den GitHub Eintrag rein dann wird es auch hier ordentlich formatiert wie das im Original sieht :)

from homematic-virtual-interface.

@thkl Was meinst du genau?

from homematic-virtual-interface.

@jens-maus na das ich dem Rega sagen kann leg mir mal bitte ein Interface mit der URL ..... und der Info .... an ... dann muss ich nicht wild in Dateien schreiben, die mich nichts angehen ... der Rega kann dann gleich einen DOM Reload machen und einen init call drauf machen. Spart man sich auch den Reboot der CCU

from homematic-virtual-interface.

@thkl Ich weiss immer noch nicht was du meinst? Es gibt solch eine Funktion meines Wissens nicht. Jeder muss selbst in der InterfacesList.xml Datei ablegen was er gerne will. Die Datei ist ja per se auch keine ReGa Datei sondern eine generelle Schnittstellenbeschreibungsdatei.

from homematic-virtual-interface.

@jens-maus eben deswegen die Frage wo ich für so eine neue Funktion einen Change Request machen muss .. oder sind die Rega Funktionen in Stein gemeisselt und keiner fasst das mehr an.
"Never ever touch an running System Style ..."

from homematic-virtual-interface.

@thkl Na wenn, dann bei mir bzw. im RaspberryMatic GitHub Tracker. Allerdings hilft das nicht für ältere Systeme, etc. Deshalb ja auch mein Hinweis das du bitte die Art&Weise änderst wie du da dein xml reinschreibst. Bitte verwende Spaces/Tabs/NewLines in genau der gleichen Anzahl und Art wenn du die HVL Einträge da reinmachst.

from homematic-virtual-interface.

Also so wie ich das verstehe, möchte er mit einem Befehl den entsprechenden Eintrag in die InterfacesList.xml eintragen, damit das nicht manuell gemacht werden muss, sondern automatisch geschieht sobald man HVL installiert und man dann auch nicht mehr die CCU rebooten muss.

So wie es auch einen Rega Befehl zum anlegen eines Programms gibt, Irgendwie so verstehe ich das ^^

from homematic-virtual-interface.

Ich schreibt es mit auf die Liste

from homematic-virtual-interface.

@thkl wann ungefähr kann man mit dem update rechnen? Und danke das es hier weiter geht.

from homematic-virtual-interface.

Das mit dem - 30000 beim Port halte ich auch nicht für sinnvoll, denn mein xmlRPCServer macht einen separaten INIT auf HMVI und dort ist der Port immer grösser als 30.000 was aber auch so beabsichtigt und korrekt ist. Hier muss als entweder durch HMVI geprüft werden, ob HMVI dem Port vertrauen kann, weil sich ein Script an die Spezifikation hält, oder eben nicht, weil es ein (re)init der CCU ist der unsichtbar geproxied wird. Wenn das so bleibt sollte die - 30000 zumindest in den "case '127.0.0.1':" Bereich rein, damit es nur dann geändert wird, wenn auch die URL geändert wird. Besswere wäre es tatsächlich an der Stelle wo du auf 127.0.0.1 und undefined prüfst direkt den Port auf 1999 zu setzen.

from homematic-virtual-interface.

Naja die Frage ist wie bekomme ich raus, welcher Call von wo kommt. Dafür ist ja eigentlich die URL in dem Init Call da.

from homematic-virtual-interface.

Ohne es geprüft zu haben; evtl. über die "callbackid" - das ist zwar auch nicht reichlich zukunftssicher aber evtl. hat ja @jens-maus eine Idee wie man den "fehlerhaften" init-call der CCU eindeutig erkennen kann

from homematic-virtual-interface.

Bis dahin vielleicht an die Stellen den Port fest auf 1999 an denen du ohnehin die CCU-IP-Adresse durch den Host-Namen der Config ersetzt ?

from homematic-virtual-interface.

Die Callback ID ist variabel laut Doku.
Rega schickt eine 4 Stellige Zahl. Der HM Sever immer irgendwas mit Java.

Darauf kann ich nicht zählen ...

from homematic-virtual-interface.

Ne, ich kann den Port nicht fest setzten. Denn ich bekomme aus der CCU 2 Inits. Wie schon oben geschrieben. Einen von Rega und einen vom HM Server. Ich muss mal schauen, ob ich ggf eine Art Übersetzungstabelle nutzen kann. Also 127.0.0.1:1999 -> ccuhost:1999
127.0.0.1:31999 -> ccuhost:1999

Usw.

Der Idealfall wäre wenn die Callback Url korrekt wäre.

from homematic-virtual-interface.

Also das eine Callback URL auf den Loopback Adapter zeigt ist meiner Meinung nach absolut unüblich.
Und ein XML nur richtig parsen zu können, wenn die TABs, Leerzeichen und Zeilenumbrüche OPTISCH schön sind hört sich für mich nach einer Bastellösung an.

from homematic-virtual-interface.

😀 die Rega Leute haben halt nie damit gerechnet , das jemand ihr Protokoll benutzt und außerhalb der CCU im Netzwerk ein Interface betreibt. ¯_(ツ)_/¯

from homematic-virtual-interface.

@thkl Das hast du vollkommen richtig erkannt. Ich kann auch leider nicht erkennen wie ich im Nachhinein die callback url anders machen könnte in ReGa&Co damit sie auch abwärtskompatibel ist. Wenn einer eine Idee hat, her damit :)

from homematic-virtual-interface.

@JensBonse Sagen wir mal so, es war schon initial falsch XML zu verwenden :), denn hast du mal probiert ein xml mittels shell skript sauber zu Parsen, das wir ein großes unterfangen...

from homematic-virtual-interface.

Wie schon vorher bereits mehrfach gefordert. Zeig mal bitte deinen gesamtem XMLRPC payload für solch ein Beispiel

from homematic-virtual-interface.

@jens-maus: Ich hoffe das trifft auch auf HMVI zu; aber das ist das, was ich (mit einem anderen Connector) aus der CCU bekommen, falls es bei dir anders sein sollte @thkl korrigiere mich bitte:

<?xml version="1.0" encoding="ISO-8859-1"?><methodCall><methodName>init</methodName><params><param><value>xmlrpc://127.0.0.1:31999</value></param><param><value>1234</value></param></params></methodCall>

das ist die Antwort darauf - die AN die CCU gesandt wird:

<?xml version="1.0" encoding="ISO-8859-1"?><methodResponse><params><param><value></value></param></params></methodResponse>

from homematic-virtual-interface.

pragmatischer Ansatz: die neue Version nicht abwärtskompatibel gestalten. Wer HVL nutzen will, darf doch bitte gleich noch von Jens' Arbeit profitieren.... Und wenn's dann wirklich der alte Kram sein soll, dann einfach eine alte Version über git ziehen?!? Wär das nicht eine Option? Weder Jens noch Thomas sollen hier doch unlösbare Probleme mit solch enormen Zeitaufwand lösen.

Wenn ich auf der 3.41 bin, was ich sicher sein werde, wenn Thomas auch noch den KS550er Bug gelöst hat, dann interessiert es mich doch herzlich wenig, ob HVL mit einer alten Version von Homematic kompatibel ist.

Oder bin ich jetzt so falsch unterwegs?

from homematic-virtual-interface.

@bvol das wird so nicht funktionieren, weil es geht nicht daraum, dass HMVI zwischen "alt" und "neu" unterscheiden muss sondern zwischen "kommt von der CCU" oder "kommt von woanders", weil sich "woanders" eben an die Spezifikation hält und die CCU nur so ein bischen daran :-)

Als menschenlesbares Beispiel:
Bisher hat dir die CCU gesagt: geh auf die Web-Seite http://www.heise.de. Jetzt sagt Sie geh auf die Seite http://www.verratichdirnicht.de, du sollst aber weiterhin auf heise.de gehen. Andere Programme, die HMVI nutzen sagen HMVI aber weiterhin die richtige URL. Was nun ?

from homematic-virtual-interface.

ist ja gut....
wenn das über den lighttpd geht, könnte man da nicht auf dem im header was mitgeben? Beim HA Proxy kann ich das jedenfalls.

from homematic-virtual-interface.

@thkl hast Du mal die cat /etc/lighttpd/conf.d/proxy.conf geparsed? Ich glaub, das steht die gewünschte Info drin.

from homematic-virtual-interface.

@jens-maus hier der Payload, den ich nach einem Reboot der CCU bekomme:

<?xml version="1.0"?> <methodCall><methodName>init</methodName> <params><param><value>xmlrpc_bin://127.0.0.1:31999</value></param><param><value>1238</value></param></params></methodCall>

Wobei ich mich frage, warum xmlrpc_bin .. ich denke das ist abgeschafft ?

from homematic-virtual-interface.

man könnte hier natürlich für die externe CCU IP einen festverdrahteten Eintrag für die xmlrpc reinpflanzen, so das der Port immer gleich bleibt...

from homematic-virtual-interface.

jain .. denn ich bekomme vom HM Server einen 2. Init Call:

<?xml version="1.0" encoding="ISO-8859-1"?><methodCall><methodName>init</methodName><params><param><value>http://127.0.0.1:39292/bidcos</value></param><param><value>HVL_java</value></param></params></methodCall>

Ich habe dann also 2 Logikschichten, die über Events meiner Geräte informiert werden wollen.
Und theoretisch könnte sich auch jeder andere andocken und würde Events bekommen.
Ich muss schon den Host verbiegen, wenn er 127.0.0.1 ist und darauf hoffen, das es die CCU ist (ok ich könnte jetzt noch checken ob der Call von der CCU kommt) aber leider ist die CCU die jenige, die sich nicht an ihr eigenes Protokoll hält.

Doku:
4.2.1 init
void init(String url, String interface_id)
Mit dieser Methode teilt die Logikschicht dem Schnittstellenprozess mit, dass sie gerade gestartet wurde. Der Schnittstellenprozess wird sich daraufhin selbst initialisieren und z.B. mit listDevices() die der Logikschicht bekannten Geräte abfragen.
Der Parameter url gibt die Adresse des XmlRpc-Servers an, unter der die Logikschicht zu erreichen ist.
Der Parameter interface_id teilt dem Schnittstellenprozess die Id, mit unter der er sich gegenüber der Logikschicht identifiziert.
Zum Abmelden von der Ereignisbehandlung wird interface_id leer gelassen.

Und das ist bei oben genannter CCU Antwort nur bedingt richtig.

from homematic-virtual-interface.

@bvol zum Thema Proxy.conf .. da HVL nicht auf der CCU läuft (also nicht zwingend) ist das keine Option. Ich mach schon Stunts mit dem Parsen der Interfaces.xml um meinen eigenen Interfacenamen zu ermitteln. Aber hier müsste ich auch wieder Rega und einen Exec Call misshandeln um die Daten aus der CCU zu lesen ...

from homematic-virtual-interface.

@thkl nur für mein Verständnis, wer initialisiert den request? die CCU oder HVL? Ich würde mich dann tatsächlich mal mit der Reverse Proxy Thematik der CCU beschäftigen... Wenn HVL den Request gegen die CCU absetzt und die CCU dann murks zurückliefert kann man das sicher mit einer Rewrite Regel auf dem lighttp korrigieren. Anschliessend könnte @jens-maus dann den Patch bei sich aufnehmen.

from homematic-virtual-interface.

@bvol die CCU ... HVL ist als Interface in der Interfaces.xml eingetragen. Beim Start von Rega ließt dieser die Datei und macht einen Init Call an alle dort eingetragenen Interfaces ... HVL bekommt den Init Call, merkt sich die CallBack ID und schickt alle Events über geänderte Geräteparameter ab diesem Zeitpunkt an die im Init Call stehende Callback URL ...(die ich umbauen muss, um die CCU zu erreichen) ... die Parameter des Init Calls speichere ich auch für den Fall das HVL neu startet. Dann kann ich weiter Events senden, ohne das die CCU neu booten muss, denn die CallbackID ist ja weiter gültig.

from homematic-virtual-interface.

Ich verstehe das Problem, was @jens-maus hat. Für Rega ist es ok das da 127.0.0.1:31999 steht.
Denn diese URL ist innerhalb der CCU erreichbar. Von außen wird der Port 31999 nur durch die FW geblockt. Bzw wird 1999 durch lighthttp auf den neuen RegaPort 31999 umgeleitet.

Rega müsste erkennen ob er einen Init Call an 127.0.0.1 (localhost) macht, oder an ein Interface außerhalb localhost und dementsprechend seine Callback URL so mitliefern, das sie valide ist.

from homematic-virtual-interface.

Das geht hier langsam zu weit und zu sehr in die breite. Der Punkt ist einfach das die URL die via init mitgeteilt wird von ReGa oder von HMIPServer schon die richtige ist und auch der Port (3xxxx) ist im Prinzip der richtige port. Aber eben nur wenn die Applikation die das init empfängt selbst auf der CCU betrieben wird und es da eben 127.0.0.1 gibt und auch den offenen 3xxxx Port. Für externe Applikationen ist das nicht der Fall und es gibt momentan einfach keine Möglichkeit das die ReGa oder HMIPServer, oder CUxD bei dem init die URL für externe Anwendungen anders ausliefert und dann eben statt 127.0.0.1 die IP-Adresse von eth0 nimmt und statt des rein internen 3xxxx port eben der externe xxxx port. Das müsste nun für jeden dieser Schnittstellenprozesse nachgepatcht bzw. abgeändert werden und das ist zwar theoretisch möglich, praktisch aber eher nicht da dies ja auch CUxD und andere potentielle Schnittstellenprozesse betreffen könnte betreffen könnte. Das XMLRPC vom RFD wird ja vmtl. genau gleich reagieren. Es bleibt also vmtl. nichts anderes üblich das die externen Anwendungen eben selbst eigene Intelligenz darin stecken zu identifizieren mit WEM sie gerade reden und wie sie die URL abzuändern haben damit diese für ihre Anwendung passen. Also @thkl hat hier schon prinzipiell recht. Das CCU Ecosystem war nie davon ausgegangen das es externe Anwendungen im LAN gibt die von aussen events schicken könnten sondern ist immer davon ausgegangen (und das tut es noch immer) das Anwendungen immer auch auf dem 127.0.0.1 interface laufen auf der selbe Maschine wie ReGa, HMIPServer & Co.

from homematic-virtual-interface.

Jain, ... schuldige sind die Logikschichten (REGA und HMServer) diese haben Init nicht so implementiert, wie es die Doku festschreibt. Ich werde eine Übersetzungstabelle mitliefern, die kann dann auch jeder anpassen, wenn selber Änderungen gemacht wurden.

from homematic-virtual-interface.

Ich werde aber trotzdem mal in ReGa schauen ob ich in kompatibler weise vielleicht zumindest dafür die callback URL in einfacher art für externe Anwendungen anders ausliefern lassen kann.

Wer ausser ReGa und HMIPServer schickt denn noch basierende auf der InterfacesList.xml ein init momentan an externe Anwendungen raus?

Und übrigens @thkl: xmlrpc_bin ist nicht generell obsolete, sondern lediglich für externe Anwendungen weil lighttpd das nicht als proxy bedienen kann (muss HTTP basiert sein). D.h. auch xmlrpc_bin geht wenn man auf 127.0.0.1 sitzt, aber eben nicht wenn man eine externe app ist wie HVL.

from homematic-virtual-interface.

@jens-maus wäre es denn für Dich möglich, die Mappings aus der /etc/lighttpd/conf.d/proxy.conf für Daus irgendwo auf dem WebUi rauszuschreiben, so dass auch Dummys ggf. die Konfiguration auf HVL entsprechend anpassen können? Cool wäre natürlich ein Patch für ReGa

from homematic-virtual-interface.

@jens-maus soweit ich weiß niemand außer rega und hmserver innerhalb der ccu, denn das sind die einzigen Logikschichten ... CuxD ist, wie HVL, ein Interface ...

Und ja, natürlich geht xmlbin weiter, nur blöderweise nicht von Außen. (Ich verstehe warum, lighthttp wird hier als universeller Gatekeeper und HTTPS Tunnel (miss/ge)braucht). Dann sollte aber auch der Init Call nicht xmlbin liefern ...

(ich bin schon ruhig ... :) )

from homematic-virtual-interface.

Funktioniert mittlerweile eigentlich die Roku wenn man HVL als AddOn direkt auf der CCU installiert? Das ging ja (bisher?) nicht weil die beiden sich wegen dem SSDPD Dienst in die Quere gekommen sind.

@thkl wollte sich ja mal mit @jens-maus (bzw. beide) zusammen hinsetzen damit die Roku auch läuft wenn HVL direkt auf der CCU installiert ist. Nur wegen der Roku habe ich HVL im Moment extern installiert. Gibt es dazu was neues? Das wäre auch Mega wenn das mittlerweile oder in Zukunft läuft.

from homematic-virtual-interface.

@bvol man kann sich das Proxy File schon über Rega liefern lassen, darüber kann ich mir (fast) jedes File aus der CCU schicken lassen, das ist kein Akt. Aber das ist der falsche Ansatz ...
Genau wie das Erweitern der Init Response, wer weiß ob die anderen Interface Prozesse dann damit klar kommen.

Wie geschrieben, ich schau mal, ob ich das eleganter (also -30000 [was zugegebenermassen der quick and dirty fix war]) lösen kann.

from homematic-virtual-interface.

@thkl Achtung: proxy.conf ist kein XML :-)

from homematic-virtual-interface.

@iBoarder nein, denn die CCU selber announct sich per UPNP und daher kann ich keine eigenen Dienste mehr rausblasen ... ist halt so ... das würde ich auch nicht ändern wollen, da HVL ein Addon ist und nicht die CCU Aufgaben übernehmen soll ...

from homematic-virtual-interface.

Oh ja das die Roku läuft wenn HVL direkt auf der CCU installiert ist, wäre ein Traum. HVL zusammen mit der Roku und der Harmony ist einfach ein Traum. Den Roku als gerät in der Harmony und die schaltet direkt den Zwischenstecker ein wenn eine Aktion auf der Harmony gestartet wird 😍

from homematic-virtual-interface.

Oh ja das die Roku läuft wenn HVL direkt auf der CCU installiert ist, wäre ein Traum. HVL zusammen mit der Roku und der Harmony ist einfach ein Traum. Den Roku als gerät in der Harmony und die schaltet direkt den Zwischenstecker ein wenn eine Aktion auf der Harmony gestartet wird 😍

No Way ...

from homematic-virtual-interface.

Ok, ist ja auch kein Problem wenn es extern läuft. Klappt alles wunderbar.

from homematic-virtual-interface.

ssdpd lösst schon seit geraumer Zeit einen zweiten UPnP Announcee neben sich zu. Wenn der andere sich also auch konform verhält sollte das also eigentlich gehen ohne das ssdpd gestoppt werden muss

from homematic-virtual-interface.

@jens-maus, bisher geht es leider nicht (ich habe die Änderungen ssdpd auf der RM verfolgt). Das Roku Device wird in der Geräte-WLAN-Suche in der Harmony App nicht gefunden.

Wenn HVL extern z.B. auf einem Pi läuft, dann wird das Roku Device in der Geräte-WLAN-Suche in der Harmony App sofort gefunden.

from homematic-virtual-interface.

wie auch immer ich höre auf Port 1900 auf upd Broadcasts mit M-SEARCH * Messages.
Ich kann das leider momentan nicht weiter verfolgen, da ich keine Harmony mehr habe ....

from homematic-virtual-interface.

@jens-maus und @thkl : Beim Abendbrot noch 'ne Idee gehabt:

Wenn die CCU initial einen http request an den HVL schickt, können wir ja doch die Homematic Logik verwenden und die Anfrage via Localhost und reverse Proxy auf den HVL schicken. Somit wäre in der interfaces.xml nur noch 127.0.0.1: zu definierender lighttp port einzutragen und die in der proxy.conf packen wir einen Eintrag 'rein, der dann auf HVL zeigt. Somit könnten wir den init string mit der richtige IP und dem richtigen Port an HVL senden. Somit müsste HVL nicht die interfaces.xml abgrasen, der init string würde korrekt an HVL gesendet werden und wir wären eigentlich dort, wo wir sein wollen?!? Wenn ich die Doku zu lighttp richtig verstehe, dann müssten wir noch nicht einmal die proxy.conf anfassen, sondern einfach eine zusätzliche hvl_proxy.conf ins vonfig Verzeichnis packen.

Was meint Ihr zu dem Vorschlag?

from homematic-virtual-interface.

@bvol .. ich halte das alles für zu viel des Guten. Zumal das auf alle (im Sinne von *) CCU Installationen Auswirkungen hat. Die CCUs an der ein HVL hängt sind dagegen verschwindend gering.

Ich hab das jetzt in
7f288fd über eine Replacement Table abgefrühstückt .. diese wird inital im config Verzeichnis angelegt (rega_fail.json) und man kann die ggf. selber bearbeiten.

from homematic-virtual-interface.

ist die replacement Table schon im NPM drin? Ich würd dann nochmal testen.

from homematic-virtual-interface.

nein für den neuen core gibt es noch keine neue npm Version.

from homematic-virtual-interface.

Also bleibt die Version auf Version 0.2.67? Und beim WeatherUnderground Plugin wird mit das Update noch nicht angezeigt, Version 0.0.6

from homematic-virtual-interface.

Naja irgendwann in Kürze werde ich den wohl mal updaten aber nicht heute

from homematic-virtual-interface.

@thkl und @jens-maus : ich bin jetzt mit meiner produktiven Umgebung auf 3.41.11.20181126 gegangen und habe HVL manuell auf 0.2.68 gepatched. Funktioniert alles. Danke nochmals für Euren Einsatz hier! Gruss Volker

from homematic-virtual-interface.

Das ist super das alles funktioniert.

Danke für die Arbeit!

@thkl, wann kann man offiziell mit dem Update rechnen?

from homematic-virtual-interface.

npm publish
npm notice
npm notice 📦 [email protected]

Jetzt

from homematic-virtual-interface.

Hab’s über die webui gemacht. Für das KS500 ist noch nicht online?

from homematic-virtual-interface.

Doch, aber siehe Beschreibung des commits ( 4a2dc2f ) das .dev File muss gelöscht werden. Damit HVL die Gerätedefinition neu ließt und das Gerät mit den geänderten Parametern an die CCU schickt.

from homematic-virtual-interface.

Welches von den oberen soll das sein? :/ Leider steht da nichts von KS500 dabei

from homematic-virtual-interface.

welches plugin generiert Dir denn die KS550 Wetterstation? Schau mal im Plugin nach den devices. dort findest Du dann die generierten Device Namen. Das, das die Wetterstation generiert, löschst Du dann gemäss Anleitung von THKL. Bei mir war's das Netatmo plugin und das zu löschende Device war NA00C1

from homematic-virtual-interface.

WeatherUnderground, aber auch davon sehe ich nichts. Siehe die Liste oben.

from homematic-virtual-interface.

und im WebUi von HVL siehst Du auch nix, wenn Du links auf Weatherunderground klickst? Bei Netatmo sehe ich dann auf der rechten Seite im WebUi die generierten Gerätenamen.

from homematic-virtual-interface.

from homematic-virtual-interface.

siehst Du in der CCU eine Seriennummer für die Wetterstation?

from homematic-virtual-interface.

from homematic-virtual-interface.

@bvol Hast Du noch eine Idee?

from homematic-virtual-interface.