openWB Forum

...da ist man mal 2h weg und die Diskussionen gehen los

JSON oder nicht ist mir eigentlich egal.
Aber eine "schöne" Struktur mit Sub-Topics kann da viel helfen.
So muss man nicht jedes Topic einzeln subscriben, aber auch nicht "openWB/#" abonnieren.

@Kevin
Das ist mir klar, dass non-local und save gerade mit dem MQTT funktioniert.

Wir müssen nur darauf achten, dass der Normaluser, der nichts von MQTT versteht (stelle mir gerade vor, was meine Frau denkt, wenn Sie etwas subscriben soll ), nicht durch "Alexa und Co."-Verknüpfungsoptionen bezüglich der Sicherheit seiner/ihrer Daten verunsichert wird.
VG

KevinW hat geschrieben: ↑Mo Nov 18, 2019 1:12 pm Nehmen wir den Zählerstand und einen Client der täglich um 15 Uhr abfragt.
Tag 1: 15 Uhr, Zählerstand 950kWh. Ladung ist noch aktiv bis 15:30.
[...]

OK. Langsam verstehe ich wie Du Dir das vorstellst. Um auf die obige Anleitung zu kommen muß man aber schon ganz schön viel Detailwissen darüber haben welche Topics es gibt und was deren "Eigenheiten" haben. Das macht es nicht gerade einfach das Interface zu nutzen.
Ich finde im Moment aber wirklich keinen Beispiel-Fall mehr wo es Probleme geben könnte und muß zugeben, daß das (bereits implementierte), separate Timestamp-Topic so also wirklich ausreichend scheint.

Ich verstehe auch die Argumente daß IoT-Geräte sparsam sein sollten. Aber die OpenWB ist ja nun sowieso alle 10 Sekunden ganz ordentlich beschäftigt um Skripte zu starten und externe Datenquelle abzufragen. Da finde ich eine Diskussion über das Sparpotential durch etwas weniger Aufbereitung der Daten nicht so ganz zielführend
Aber klar, ich will natürlich auch nicht daß sinnlos Energie verbraten wird nur weil sie im Überfluß in Form von 32A Drehstrom vorhanden ist.

Zu

aiole hat geschrieben: ↑Mo Nov 18, 2019 2:03 pm Wir müssen nur darauf achten, dass der Normaluser, der nichts von MQTT versteht (stelle mir gerade vor, was meine Frau denkt, wenn Sie etwas subscriben soll ), nicht durch "Alexa und Co."-Verknüpfungsoptionen bezüglich der Sicherheit seiner/ihrer Daten verunsichert wird.

und

aiole hat geschrieben: ↑Mo Nov 18, 2019 1:25 pm ps
Bei "Alexa-Skin" kam mir übrigens gleich die Galle, aber es war Deinerseits nur aus der Hüfte geschossen. Ich weiß, was Du meinst und Zukunftsoptionen sind natürlich wichtig.
Dennoch sollten wir immer daran denken, dass openWB vorrangig LOKAL läuft und Datensicherheit groß geschrieben wird. Bitte erwähne daher echte Zukunftsfeatures nicht mit solchen unsäglichen "Errungenschaften" wie Alexa und Co., die der Stasi in nichts nachstehen. (Ich spendiere Dir gern eine Führung in der ehemaligen "runden Ecke" in Leipzig.)

Ups. Ist wohl ein wunder Punkt. Ja, es waren wirklich nur Beispiele "aus der Hüfte geschossen".
Generell schätzt Du mich da durchaus falsch ein. Ich habe weder Alexa noch Google (vom Android auf dem Smartphone leider abgesehen) noch Facebook oder sonst was. Selbst die Registrierung für dieses Forum und vor einiger Zeit für Github hat mich Überwindung gekostet. Ich bin selbst auch ein absoluter Datenschutz-Anhänger. Deshalb betreibe ich meinen eigenen MQTT-Server, Mail-Server, etc. Alles self-hosted und natürlich mit Authentifizierung und TLS >= 1.2 Verschlüsselung.
Ich würde auch sonst nie etwas für die OpenWB fordern von dem ich den Eindruck hätte daß es die Privatsphäre aushöhlt.
Dennoch erlaube ich, daß andere Menschen da eine andere Einstellung haben. Daher meine Beispiele. Ich werde selbst niemals einen Skin für Alexa o.ä. schreiben. Wenn es jedoch Anderen, die das tun wollen, hilft, würde ich jederzeit dafür das MQTT-Interface passend vorsehen. Dadurch würde die OpenWB doch nicht zum Datenschutz-Debakel so lange sie selbst nur lokal arbeitet.
Das Bridging der OpenWB mit "seinem" Lieblings-MQTT-Broker ist jedem selbst überlassen. Wenn dieser Lieblings-MQTT-Broker öffentlich, unverschlüsselt und von einer Datenkrake ist, wäre das immer noch nicht das Problem von OpenWB.
Aber vielleicht komme ich auf Deine Einladung zurück falls ich mal in der Leipziger gegend bin

aiole hat geschrieben: ↑Mo Nov 18, 2019 1:25 pm @truckl
Ist das so ein Aufwand, die Infos clientseitig aus den Minimaldaten zu validieren?

Nach der obigen Anleitung von Kevin sieht es so aus als würde es gehen. Also "Alles gut" soweit. Ich akzeptiere, daß das Timestamp bzw. Date Topic ausreichend ist.

Das ist ein anderes Thema. Hier kann es ein ab und an mal ein automatisiertes Aufräumen geben.

Solch eine Funktion hab ich in/für Mosquitto nocht nicht gefunden. Nur ein paar Tips wie "leere Message publishen" o.ä.
Könnte ich für andere Projekte auch ganz gut brauchen falls jemand eine Lösung hat.
Müßte aber nach meinem derzeitigen Kenntnisstand durch OpenWB erledigt werden (z.B. im Rahmen des Updates alte Topics leer publishen).

hominidae hat geschrieben: ↑Mo Nov 18, 2019 1:52 pm Aber eine "schöne" Struktur mit Sub-Topics kann da viel helfen.
So muss man nicht jedes Topic einzeln subscriben, aber auch nicht "openWB/#" abonnieren.

Das finde ich auch einen sehr wichtigen Punkt. Übrigens auch bzgl. Bridging (einfacheres Filtern wenn nicht alles gebridged werden soll). Lieber eine Subtopic-Gruppe zu viel als eine zu wenig
Aber ich denke die letzten Anpassungen an den Topics gehen sowieso genau in diese Richtung.

@truckl
Alles gut, aber wie so oft sind DEINE Kenntnisse bei weitem nicht die der meisten user. Dafür sind diese wieder auf anderen Gebieten fitter als Du. Was ich sagen will ist, dass guter Datenschutz für Ottonormalos bei weitem nicht so einfach zu händeln ist (das geht schon los, wenn der TV zur Datenschleuder wird), wie für IT-Experten.

Eine solide manual wäre beim openWB-MQTT sehr hilfreich, macht aber leider viel Arbeit und das kann Kevin nicht auch noch leisten. Es müsste aber ein Experte schreiben - kein DAU.

Der openWB-MQTT wird standardmäßig lokal arbeiten. Wenn's nach extern geht, würde ich die weitergehende Einstellungen (subscriping/publishing) nur mit Warnmeldung zulassen. Es gibt genug DAUs, die nicht wissen, was sie tun.

VG aiole

Ich gebe hier auch zu bedenken, dass es einen Unterschied macht, ob da ein Temperatursensor ist, der ein paar Bytes an Wert zu melden hat, oder eine komplexe Elektronik mit Dutzenden wichtigen Werten. Das relativiert die "Sparsamkeit" etwas. OpenWB hat nun mal viele interessante Parameter

Zudem - aus meiner Sicht - sollte man die "globalen" Daten (Energie I/O (PV, Heimakku, Grid), Zustand, ...) in eine eigene Untergruppe packen, so dass ich als Client (Ladesteuerung für einen Ladepunkt) zB. nur die "globalen" Daten zur allgemeinen Info, und den einen Ladepunkt, den die App überwachen möchte, abonniere, und nicht alle Ladepunkte haben muss, weil ich statt 50 Topics lieber wenige Untertopics abonniere, im Idealfall z.B. "OpenWB/global/#" und "OpenWB/lp1/#". Derzeit müsste ich "OpenWB/#" abonnieren, um an alle, auch "WHouseConsumption", ranzukommen. Die Hierarchie ist noch nicht ideal. Keine Daten in der obersten Ebene...

Das ist nicht Kosmetik, da ich zwar annehmen, dass auch bei "/#" nur neue Infos reinkommen, es also egal sein könnte, wenn ich auch alle anderen Ladepunkte abonniere. Außer, wenn da dauernd was passiert, dann ist es vorbei mit Datensparsamkeit, was die Datenverteilung vom Broker an die Clients betrifft. Dann bekomme ich andauernd Infos, die ich eh ignorieren kann, weil sie mich nicht betreffen.

aiole hat geschrieben: ↑Di Nov 19, 2019 12:30 am Der openWB-MQTT wird standardmäßig lokal arbeiten. Wenn's nach extern geht, würde ich die weitergehende Einstellungen (subscriping/publishing) nur mit Warnmeldung zulassen. Es gibt genug DAUs, die nicht wissen, was sie tun.

Ich würde das in der openWB gar nicht konfigurierbar machen, insbesondere das die openWB client zu einer anderen Broker-Instanz wird.
Wenn, dann nur über einen externen Broker, der als client die openWB subscribed.
Absichern mit Warnmeldung...wie würde das gehen, ohne eine user-ACL einzuführen (auf UI oder Broker-Basis)?

hominidae hat geschrieben: ↑Di Nov 19, 2019 10:01 am Ich würde das in der openWB gar nicht konfigurierbar machen, insbesondere das die openWB client zu einer anderen Broker-Instanz wird.
Wenn, dann nur über einen externen Broker, der als client die openWB subscribed. ......

Bitte vorab um Enschuldigung für meine Unwissenheit bezüglich MQTT.

Wie wird das in Praxis realisiert? Wenn ein externer broker bei openWB subscribed, dann muss der openWB_MQTT-broker (als client) doch sicher eine Erlaubnis erteilen. Die muss vom user kommen oder sendet openWB etwas von allein?

Eine Komponente, die zu einem Broker verbindet ist - ist der Perspektive dieses Brokers - immer die Client Seite. Die kann topics publishen (sozusagen das "write") und auch subscriben (bekommt dann einen push/notification, wenn das topic geändert wird, zB durch das publish eines anderen).

Der Broker der openWB sieht also eigentlich nur Clients.
Man kann auf Seiten des Brokers für Clients eine Authentifikationsmethoide konfigurienen...die Standard-Methode ist "keine Authentifizierung".
Details hier: https://mosquitto.org/man/mosquitto-conf-5.html

Wenn sich ein externer Broker beim Broker der openWB subscribed, baut er eine Client-Verbindung auf (auch wenn er ein Broker ist).
Dann gelten die gleichen Möglichkeiten, auch für ihn.
Wenn Du die Topics der openWB also gegen unbefugten Zugriff absichern willst, musst Du das auf der openWB tun.
Also, wenn ein Client die Daten mal hat, kann man für die Weiterverwendung nix unternehmen.
Ist der Client ein anderer Broker, können sich weitere Clients an diesem bedienen; dort gilt aber die Authentifizierungsmethode dieses anderen Brokers.

Die Authentifizierung und Authorisierung wirkt immer lokal im Broker in der Client-Session und nicht auf die Daten (topics) selbst, wird also nicht mit Weitergabe der Daten an den Subscriber "vererbt".
Wer die Daten von der openWB bekommen hat ist selbst verantwortlich für die Sicherheit über die openWB hinaus.
Zum Beispiel bei einer Broker-Bridge, diesen/seinen eigenen Broker selbst so abzusichern.

Ich zB nutze es, um die relevanten Topics der openWB, über meinen lokalen Broker in (m)eine Broker-Instanz bei CloudMQTT zu bridge-en und im Internet für mich zugänglich zu machen.
Im CloudMQTT Broker nutze ich TLS als Eingangs-Port (damit abhörsicher) und eine dort hinterlegte User-ACL mit User und starkem PW.
Diese Zugangsdaten sind in der Bridge-Config meines lokalen Brokers hinterlegt.
CloudMQTT nutzt auf der TLS Seite offizielle Root-Zertifikate, sodass mein Broker, client-seitig beim Verbindungsaufbau diese auch prüfen kann und was ich in der Bridge-Konfiguration auch eingeschaltet habe.
Damit bin ich, mit den Bordmitteln, die mir MQTT bietet so sicher wie es geht (eigentlich müsste ich User+PW auch regelmässig wechseln )

Danke für die ausführliche und gut verständliche Darstellung!

D.h. wenn die openWB standardmäßig keine Authent. implementiert hätte, kann sich da jeder Client bedienen (Topics subscriben)? Wäre dann ja offen wie ein Scheunentor. Ist das in den aktuellen betas/nightlys der Fall?

VG aiole

Ja, natürlich...das Web-UI ist ja auch offen.
Ein "fremder" Client müsste ja erstmal in Dein Heimnetz, wie jemand mit einem Browser (zB Smartphone) auch.
ich sehe hier kein anderes Scheunentor, wie es bisher bei der openWb auch schon gewollt war.