New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Encryption und Token Auth zur MS-Kommunikation #201
Comments
Ich habe das mal auf "Later Future" gesetzt. Ich hoffe mal, dass die Änderungen nicht die Restful-Api betreffen. Irgendwo hatten wir auch schonmal diskutiert einen Websocket from LoxBerry aufzubauen, sodass alle Plugins darüber direkt kommunizieren können. Find eich auch eine gute Idee. |
@Woersty hat mir per Email schon einmal erste Versuche geschickt: Hab etwas gespielt. Mit der node-lox-ws-api von https://github.com/alladdin kann man arbeiten. Funxt supi: Licht AN
Licht AUS
Einzige Anpassung erstmal zum Test in test_loxapi.js Zeile 11/12
Zeile 27
Zeile 72-78
|
Mal schauen ob ich da noch weiter komme. Hatte auch schon überlegt, ob es Sinn ergibt, alle events abzugreifen und in einer Datenbank den Status mitzuführen um Plugins einen leichten Zugriff darauf zu ermöglichen, bin mir aber nicht sicher, ob das sinnvoll ist. Bisher fällt mir kein Anwendungsfall ein. Sprich ein Daemon läuft mit und loggt alle Geräte und deren Status mit. Grüße |
Eine stehende Verbindung wäre das Optimum, aber bisher gibt es eigentlich keine Plugins oder Plugin-Wünsche, die direkt und ständig Zustände vom MS abrufen müssten. Was man auf jeden Fall drin haben sollte, ist, dass der Token gespeichert und wiederverwendet wird, und nur im Fehlerfall ein neuer Token abgerufen wird. Eine externe Funktion hätte den Vorteil, dass sie von Haus aus sprachunabhängig ist. Wenn ich was in LoxBerry::System übernehme, dann geht‘s nur unter Perl, und für PHP (oder Bash oder was auch immer) müsste es wieder extra implementiert werden. Was ich mir vorstellen könnte, wäre ein lokales Webservice (unter Apache wäre am einfachsten). Nur lokal erreichbar, mit GET, so kann jeder aus Perl, PHP oder mit Curl seine Daten senden und abrufen. |
I am now actually thinking about implementing the same for the monitoring stuff I am running on Loxberry. What I have now running on Loxberry is docker with three containers: InfluxDB, Graphana and Python Having open websocket already provided by Loxberry would be nice and maybe there will be more people interested in having light years better monitoring (i.e. Graphana) in Loxberry than what MS provides. I was afraid, it will create significant load on Loxberry, but so far it is so lightweight I can hardly spot anything. In case anyone is interested I can provide tutorial and with some help, I can even try to create Loxberry plugin from this. |
Statistic is, in fact, a use case for a open websocket connection. Michael and me had started a statistic plugin that has not reached final state and used REST as well. Honestly, I already thought of switching this plugin from RRDTool to Grafana, as the storage design and calling syntax is nearly the same (Grafana seems to have had taken some ideas from RRDTool), but it has a great, dynamic visualization engine. For such a websocket use case, it needs a service on Loxberry to fetch and cache the websocket data, and local resources could query the data locally. |
I'm pretty sure there are plenty of them. Just look at the plugin wishlist, how many wish a "Statistik Plugin". |
I'm not common with docker currently, and I don't know how it hits performance of a Raspberry. I finally mistakenly said Grafana, but meant Graphite with included Carbon as the data backend. Carbon has an excellent caching engine for writing data, therefore it won't hit the SD as a normal database would do. The Graphite/Carbon engine concentrates the data like RRDTool, with different levels of granulatity, like RRDTool. The nice thing is, that Grafana directly can use Graphite/Carbon as data backend. I think Michael and me would be the first to finalize the statistics plugin, but first LB0.3.x must be finished. If Woersty will continue invenstigations in the websocket module, this would be great preparatory work for a later statistic engine. Christian |
@christianTF I was in the same boat when I started, but it turned out to be pretty simple. I just executed one shell script provided by docker and it did everything. I do have broad experience with Grafana+Graphite+Collectd in my job. We do have it with Carbon/Whisper in HA on huge cluster, ingesting something like 900k metrics. And to be honest, that was the main motivation to try different backend then Carbon/Whisper combo, as the performance of that filesystem based "database" is really awful with high metric count as you can read here. Another thing is, that setting up Graphite stack is more complicated, than just installing Grafana+InfluxDB. This combo does have almost no dependencies, so it is really dead simple. And that was second biggest decision factor for me. I will try to find some comparison of I/O usage of InfluxDB vs Carbon/Whisper, as preserving the SD card is more important for us, then performance and simple installation. Anyway, we should probably move this discussion to the thread for developing that statistic plugin ;-) This is way off-topic here. |
Funktionierendes Beispiel in Python: https://github.com/StefanHaring/E2Lox/blob/master/websocketclient.py Funktionierendes Beispiel in Perl: https://github.com/Bluebrain2000/Loxone-Token/blob/master/loxone_get_token.pl Diskussion und Hinweise: https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/184124-rsa-key-and-iv-exchange-failing-not-found |
https://www.loxone.com/dede/kb/api/
Loxberry-Modul muss Auth abstrahieren
Token wird lokal abgelegt und ggf. erneuert.
Plugins müssen für verschlüsselte Kommunikation explizit LB-Modul-Funktionen nutzen
Enc ab MS-V8.1
Token ab 9.0
The text was updated successfully, but these errors were encountered: