hominidae hat geschrieben: ↑So Dez 01, 2019 5:08 pm
aiole hat geschrieben: ↑So Dez 01, 2019 4:44 pm
Nochmal zum Verständnis:
* MQTT wird normal nur lokal von openWB genutzt
* statt VPN-Zugang ist alternativ der Datenaustausch mit Apps (nativ) und externen MQTT-Servern (per bridging) möglich
Nein, Apps - wenn sie im I-Net, zB auf dem Phone via 3G/4G - laufen müssen auch zur openWB verbinden.
Das ist kein Ersatz für VPN.
Ja ok - da hatte ich nur die APP-Nutzung im HomeLAN gemeint.
Über eine MQTT-Bridge kannst Du aber, ausgehen von der openWB zu einem anderen MQTT-Broker verbinden.
Wenn der im I-Net ist - und dafür brauchst Du eben keine Port-Weiterleitung, da die openWB-Seite client/ausgehende Verbidnung ist - kann die App (wenn sie MQTT spricht/ mqtt-client ist) direkt zu diesem MQTT-Broker im I-Net verbinden. Die Kopplung zur realen openWB läuft über die MQTT-Server Verbindung.
Soweit habe ich das verstanden, aber
a) muss dieser externe MQTT eingerichtet werden (Welcher Normaluser hat einen womöglich noch extern gehosteten MQTT laufen? Dann muss das auch noch verschlüsselt werden. Da braucht man 'nen admin.) und
b) muss auch das bridging in der openWB vorgenommen werden.
a) + b) kommt mir (aus DAU-Sicht) vom Aufwand her keinesfalls einfacher vor, als ein VPN. Deshalb hinterfrage ich.
Dass MQTT eine bessere (sicherere) und moderne Kommunikation bei Nutzung von Verschlüsselung bietet, ist unstrittig (zumindest bis uns der Quantenrechner in die Suppe spuckt).
Aber ich vergleiche ext. MQTT mit einem sicheren VPN und nicht mit unsicherem Port-Forwarding. Prinzipiell bin ich bei Euch mit dem MQTT.
Jedoch insbesondere das Nutzen eines externen MQTT birgt für "Normalos" m.E. Risiken/Nachteile. Klar kann ich einen admin beauftragen, aber der kostet Geld - ggf. noch Jahresmiete für's hosten. Zum Schluss befindet man sich in einer neuen Abhängigkeit (ähnlich z.B. SMA beim Portal, auch wenn das dort anders geartet ist), weil irgend jemand ext. MQTT-support verkauft. Sowas stört mich, weil es kein MUSS ist.
App ist sicher ein nettes Spielzeug, mehr aber auch nicht (für die meisten).
MQTT als VPN-Ersatz muss zwingend abgesichert werden, sonst war's das mit geschützten Daten.
=> Außer dass openWB ev. etwas schneller mit MQTT läuft, sehe ich, ehrlich gesagt, keinen Zugewinn an features.
Denke es ist nicht schneller, sondern eher Ressourcen-Spatender...
...und flexibler (statt synchrone Verbindungen sind es nun events/asynchrone Verbindungen).
Es ist für manche eine phylosophische Frage
vermutlich
Ich kann Euch SW-chiefguides sowieso nur warnen - der Durchschnittsuser ist ein DAU, aber das ist für Euch eigentlich nichts neues. Dennoch will er/sie existierende features in openWB nutzen.
Kevin plant es m.E. schon richtig, diese Klientel nicht zu überfordern.
Das max. aus der Schnittstelle kitzeln ist auch verständlich, aber es muss abgeschottet werden. Z.B. extra Warnhinweis beim Aufruf der Bridge-Seite? - wie bei der Einstellseite -> Modulkonfiguration? + die roten Warnmarker in der Config-Seite.
Ich persönlich möchte keine Hilfe für einen ext. MQTT zukaufen, weil ich Unabhängigkeit liebe und es lokal auch ohne geht (und ein VPN den Zugang auch absichern kann).
ps
http-UI ist ok.
Es ist eine klare Sache, dass der user kein portforwarding nutzen darf und bei Remotecontrol von außen einen sicheren VPN zu installieren hat.
...das gilt ja auch für mqtt....am ende geht es auf dem Layer da auch um IPs und Ports.
Die technische Verbindung ist eigentlich ähnlich, nur das ebenen in der Anwendung statt get/put - requests die publish/subscribe events drüber wandern.
Ja - nur dass bei Portforwarding bei deutlich mehr Leuten die Alarmglocken angehen, während bridging bei Ungeübten schnell den Überblick verlieren lässt. Da nützen dann auch die roten Warnungen nur noch bedingt etwas - vor allem wenn die mehr als 1x in der Config beachtet werden müssen. In dieser Bridge-Config sehe ich das größte Risiko.
