Neue innovative Ladebox: go-e

[Dentec]

Bitte bei der Wahrheit bleiben :

Kombination aus openWB und go-e fahren, weil sonst überhaupt kein PV-Laden möglich wäre

Das stimmt schlicht nicht. OpenWB ist eine Möglichkeit, den GoE zu steuern. Es funktioniert aber auch mit NodeRed, mit IOBroker, mit Loxone und mit vielem mehr. Es gibt also viele Möglichkeiten, den Go-E per ModbusTCP zu steuern !

[buddha]

Da gebe ich Dir Recht. OpenWB ist nur ein EM-Option, dafür ein sehr nutzerfreundliche, die ohne Programmierung auskommt.

[c2j2]

Eine technische Information zur neuen Hardware:

...
Wobei password gebildet wird aus:

Code: Alles auswählen

const enc = await NativeModules.Aes.pbkdf2(plaintext_pasword, serial, 100000, 256);
hashed_password= Buffer.from(enc, 'hex').toString('base64').substr(0, 32);

plaintext_password ist hier das Passwort das man beim einrichten setzt. Die App hasht dieses und speichert es dann in pbkdf2 gehashter Form ab. Mit eben diesem Passwort kann man den HMAC bilden und damit jede Message signieren - wenn man den websocket verwenden will.

Liebe Grüße,
Peter Pötzi

@peter.poetzi Guten Morgen,
Wirklich 100000 Iterationen? Da ist mein Powerhorse (Huawei P30) fast eine Minute beschäftigt...

Ich freue mich auf das WebSocket-Protokoll - aber hier stehe ich und drehe Däumchen...

(Und die Auth-Sache mit den 3 Tokens ist mir auch nicht klar...)

Ich würde die go-e V3 ja gerne so gut wie möglich unterstützen, aber die Instabilität der HTTP-APIs gehen mir auf die Nerven, und WebSocket ist nicht dokumentiert - Hacken ist nett, aber ich bin eigentlich zu alt dafür.

[Jockelflo]

Oh je, der kleine Buddha macht auch hier Werbung für openWB! Erfreue dich doch an deiner supadupa WB ohne deinen penetranten Werbefeldzug dafür.

Wiese nur eine ?
Ohne steuernden Energiemanager ist go-e nur eine simple WLAN connected WB mit extrem reduzierter Funktion. Ich behaupte, dass hier einige genau diese Kombination aus openWB und go-e fahren, weil sonst überhaupt kein PV-Laden möglich wäre. Warum man sich deswegen jedoch einer Cloud offenbaren muss, verstehst wahrscheinlich nur Du.

zur Info
OpenWB braucht Null Werbung oder siehst Du hier Banner etc.? Bei >8 Wochen Lieferzeit dürfte das bei denen ein Selbstläufer sein.

Ich nutze 2 go-e Charger mit OpenWB Software wegen der Einfachheit. Es sollte ja schon länger in go-e App eine PV Funktion integriert werden. Warum wird das nicht endlich gemacht? Aber ansonsten gibt es wirklich genügend Möglichkeiten auch ohne OpenWB die PV Funktion zu nutzen. Seit es den ioBroker Adapter gibt, muss man auch nicht mehr viel "programmieren". Wobei ich den Gästen eigentlich immer zu OpenWB schicke, wenn Sie eine funktionierende und zukunftsweisende Wallbox haben wollen. Go-E ist halt doch nur die billige Version mit gebastel. Aber es funktioniert.

[peter.poetzi]

@peter.poetzi Guten Morgen,
Wirklich 100000 Iterationen? Da ist mein Powerhorse (Huawei P30) fast eine Minute beschäftigt...

Ich würde die go-e V3 ja gerne so gut wie möglich unterstützen, aber die Instabilität der HTTP-APIs gehen mir auf die Nerven, und WebSocket ist nicht dokumentiert - Hacken ist nett, aber ich bin eigentlich zu alt dafür.

Mein Huawei P20 benötigt dafür nicht einmal eine Sekunde, eventuell liegt das an einer ineffizienten Implementierung (z.B. in Java oder Javascript). Hier muss man unbedingt System APIs bzw. nativen Code verwenden.

An der Instabilität haben wir bereits gearbeitet, hier gibt es eine neue Software Version die bereits intern getestet wird und das behebt.

Liebe Grüße
Peter

[c2j2]

Das mag sein.... Hmmm... ich schaue mich um.

Code: Alles auswählen

                SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
                KeySpec          spec    = new PBEKeySpec(password.toCharArray(), serialNumber.getBytes(), 100000, 256);
                SecretKey        tmp     = factory.generateSecret(spec);
                SecretKeySpec    key     = new SecretKeySpec(tmp.getEncoded(), "AES");

                hashed_password = new String(Base64.encode(key.getEncoded(), Base64.NO_WRAP)).substring(0, 32);

Vielleicht habe ich auch nicht das Richtige erwischt ("NativeModules.Aes.pbkdf2" sagt mir nichts). Danke für die Antwort.

[c2j2]

Na, da habt ihr uns Entwicklern ein Ei gelegt.. ;|

"PBKDF2withHmacSHA512" (das oben war falsch, weil das die einzige Version ist, die Android früh implementierte) gibt es ohne Zusatzbibliothek nur ab Android 8.

Und die Android-Implementation braucht hier also - mitgeloggt - etwa 30 Sekunden auf einem State-of-the-art-Smartphone. Jetzt muss man also nur dafür eine extra Bibliothek einbinden (vergrößert die App!) und hoffen, dass die schneller ist (laut Doku "in Java implementiert" - ich würde also nicht drauf wetten).

Ich würde sagen, damit ist die NetSocket-API schon mal weg aus meinem Fokus, und ich bleibe bei der ressourcenverbrauchenden HTTP API - hoffentlich hält eure CPU das aus, diese "api/status"-Datenmengen alle paar Sekunden.

Schade um das schöne Konzept, nur wegen des Hashes.

Es ist ja erstrebenswert, dass ihr die NetSocket-API absichert, aber 100000 (!) Iterationen mit einer limitiert verfügbaren Engine ist mit Kanonen auf Spatzen schießen - und damit forciert ihr, dass man die "offene", ungesicherte API nutzen muss, und das Scheunentor ist offen.

PS: Seid mir nicht böse, wenn ich solche Kritik übe, ich bin Software-Entwickler und habe meine eigenen Erfahrungen damit, was man denkt, was die Leute brauchen (oder wie man es macht) und dann liegt man daneben

[k_b]

c2j2,

das hört sich gerade wie ein Bewerbungsgespräch an, ich drücke die Daumen

[peter.poetzi]

Hi,

bezüglich dem pbkdf2 muss man aber auch dazu sagen, dass es ja nur 1x berechnet werden muss, bei der Einrichtung des Chargers in der App und dann nie wieder. Es soll ja mit Absicht lange dauern um brute-force Angriffe zu erschweren.

Bei der offiziellen go-e App hatten wir das gleiche Problem mit cryptojs, das hat mehr als 10 Sekunden gedauert, aber mit dem nativen crypto Modul geht es in deutlich unter einer Sekunde.

Liebe Grüße
Peter

[c2j2]

c2j2,

das hört sich gerade wie ein Bewerbungsgespräch an, ich drücke die Daumen

Bestimmt nicht mehr

Ich habe nun fast 40 Jahre Erfahrung in Software-Entwicklung und kenne alle 3 Seiten (Planung, Entwicklung und Anwendersicht) und weiß, dass sich das nicht immer deckt Gut gemeint ist nicht immer gut gemacht, da kann es unerwartete Seiteneffekte geben. Alles schon vorgekommen.