Von smartVISU auf FHEM über ReverseProxy und mehrere Bediengeräte

[Sinclair]

Hallo,

ich habe mittlerweile folgenden Aufbau zusammen:

- FHEM auf Raspberry PI mit I2C-Verbindung zur Eigenbau-Rollladensteuerung (15 Rollladen)
- smartVISU auf separatem APACHE-Webserver mit https-Zugang
- Verbindung vom Endgerät (z.B. Notebook oder Tablet) über ReverseProxy auf dem APACHE-Server:
        #Proxy für Verbindung zu rpi2 (für EW-Zwecke)
        ProxyPass /fhem ws://rpi:2121/
        ProxyPassReverse /fhem ws://rpi:2121/
- Alle Einträge im fronthem laufen über ein fronthemDevice, egal welches Bedien- bzw. Endgerät darauf zugreift.
- Alle Daten (von smartVISU und FHEM) von und zum Bediengerät sind verschlüsselt
- Alle Rollläden sind bedienbar und die aktuelle Position (über Zeit geschätzt) wird zurückgegeben.

So weit funktioniert das Ganze. Bedienbar sind auch die Rollläden von mehreren Geräten gleichzeitig.Es kann also eine Person A vom Gerät A den (oder alle) Rollladen runterfahren und während der Rollladen läuft, kann Person B an Gerät B den Rollladen stoppen oder wieder hoch fahren.

Nun mein Problem:
Nur das Gerät, was als letztes die ganze snartVISU-Seite neu geladen hat, bekommt die aktuelle Position des Rollladen zurückgeliefert und auch animiert. Das andere Gerät kann zwar den Rollladen auch bedienen, bekommt aber keine Positionsanzeige.

Hat dazu jemand eine Idee? Eigentlich will und brauche ich nicht mehrere fronthemDevice (und Berechtigungen) bei mir im Haus. Die Lösung über den ReverseProxy erschien mir in Verbindung mit der etwas höheren Sicherheit (FHEM kann hinter Firewall und lässt nur den APACHE-Server zugreifen) die Praktikabelste.
Ich vermute, hab ich aber noch nicht getestet, dass nicht nur die Positionsrückmeldung nicht geht, sondern dass so alle Readings immer nur an einem Gerät aktualisiert werden.. Das wäre dann nicht nur unschön, sondern so garnicht zu gebrauchen.

Viele Grüße
Sinclair

[herrmannj]

Alle Einträge im fronthem laufen über ein fronthemDevice, egal welches Bedien- bzw. Endgerät darauf zugreift.

Da liegt der Fehler. fronthemDevice sind statefull, ergo pro device.

Eigentlich will und brauche ich nicht mehrere fronthemDevice (und Berechtigungen) bei mir

Was spricht objektiv dagegen ? 

[Sinclair]

Danke für die schnelle Antwort!

Da ich trotzdem den Webserver als Proxy verwenden will, hab ich etwas weiter experimentiert.
Aktuell greift dieser über 2 verschiedene IP-Adressen auf den Raspberry, spricht FHEM zu, je nach Device über die eine oder die andere IP.
Somit sieht es für fronthem aus, als würden 2 verschiedene Devices zugreifen und die gleichzeitige Darstellung der Rollladenanimation funktioniert auch.
Trotzdem habe ich die Funktion (Webserver als Front-Server, Raspberry mit FHEM als Backend-Server ) nicht aufgeben müssen und ich vermute mal, dass ich dadurch auch die Einschränkung "Zugriff nur aus Intranet oder per VPN mit interner IP" umgehen kann.
Wichtig ist es ja nur, dass das Client-Device vom Webserver eindeutig identifiziert wird und entsprechend dem die Proxy-Route auf die verschiedenen IP's umgeleitet wird. Aktuell mache ich das in der smartvisu-config (als Cookie) durch verschiedene Unterpfade zum FHEM-Server. Aber auch andere Identifikationsmöglichkeiten (z.B. Client-Zertifikat o..ä.) denke ich sind so machbar.

Habe ich richtig gelesen, dass es mal einen Entwurf gab die Devices nicht nur durch die IP-Adresse zu identifizieren? Ist da noch was geplant oder wird das nicht weiter verfolgt?

[herrmannj]

doch, Kategorie "wenn mal Zeit ist" also eher unten auf meiner Liste. Aber drauf

[WumpE]

Mit Docker hat man das gleiche Problem, die externe IP (BrowserDevice) wird genattet in den FHEM Container, somit ist mein FronthemDevice die GatewayIP des Dockernetzwerkes. ohne dem geht garnichts.

Kann man nicht die Public-IP des Browser-Gerätes auswerten ? Oder aber im Treiber von Smartvisu ne Kennung für das Endgerät mitschicken?

Grüße

[herrmannj]

Kann man nicht die Public-IP des Browser-Gerätes auswerten ?

njet

Oder aber im Treiber von Smartvisu ne Kennung für das Endgerät mitschicken?

Ja, siehe ein post darüber. Docker sind aber ein Beispiel dafür wie vermeintliches "einfacher" dann am Ende zu Problemen führt. Die Probleme gibt's auch bei Multicast etc. Ich rate dazu hier den docker zu hinterfragen ...