wichtiges UPDATE für controller 7.2.2 im stable

[nograx]

An dieser Stelle mal eine Warnung für alle die einen Hyper lokal nutzen und über das neuste Firmware Update nachdenken...

Die Geräte funken anschließend nur noch per SSL auf Port 8883!

[Murphy 0]

@nograx
Danke für die wichtige Info.
Bestätigt mein Vorgehen bei Zendure, so lange es läuft „never change a running system“ 😉

[nograx]

@Murphy-0 Jo hätte ich mich auch mal dran gehalten… aber so ist der Druck größer eine Lösung im Adapter zu finden.

Man kommt aber nicht mehr drum rum einen MQTT mit SSL und Zertifikat zu betreiben. Oder alte Firmware.

Bin neugierig ob der Freeze Bug und 99% Bug endlich behoben ist.

[maxclaudi]

@nograx sagte:

An dieser Stelle mal eine Warnung für alle die einen Hyper lokal nutzen und über das neuste Firmware Update nachdenken...

Die Geräte funken anschließend nur noch per SSL auf Port 8883!

Weil das neue EU-Recht (EN 18031) eine Verschlüsselung für IoT-Hardware vorschreibt, ist es vermutlich nur eine Frage der Zeit, bis Zendure auch bei allen älteren Geräten per Update nachzieht.
Früher oder später wird der Cloud-Zugang über Port 1883 gesetzeskonform deaktiviert werden müssen.

EN 18031 schreibt vor:

• Verschlüsselungspflicht (TLS): Jede Kommunikation von IoT-Geräten über das Internet (also zur Zendure-Cloud) darf nicht mehr unverschlüsselt (Klartext) erfolgen.
  Port 1883 überträgt alles (auch Passwörter und Tokens) unverschlüsselt.
  Das ist nach neuem EU-Recht für Neu- und Bestandsgeräte mit Internetzugang verboten.
  Deshalb stellt Zendure jetzt radikal auf MQTTS (Port 8883 mit SSL/TLS) um.

• Verbot von Standard-Passwörtern:
  Die Zeiten, in denen Geräte ein universelles Standard-Passwort nutzen oder Passwörter leicht erratbar im Klartext übertragen werden, sind gesetzlich vorbei.
  Jedes Gerät muss eine sichere, verschlüsselte Authentifizierung nutzen.

Zwei neue Hub 2000 der älteren Generation habe ich erst vor wenigen Tagen auf die Firmware V3.0.24 aktualisiert – dort läuft derzeit noch alles unverschlüsselt über Port 1883.

Von den ersten Geräten der neueren Generationen – speziell SF800 und 2400AC – sind allerdings noch einige Geräte mit alter Firmware im Umlauf.
Im Auslieferungszustand lohnt es sich zu prüfen, ob sie noch nicht auf SSL-Verschlüsselung (Port 8883) umgestellt sind.

Solange das der Fall ist, ist das offizielle lokale MQTT noch nicht reglementiert bzw. gedrosselt.
Noch besser: Man kann DNS umbiegen oder umschreiben und den eigenen lokalen Broker als Cloud-Broker verwenden.

[nograx]

Ja verstehe den Grund dafür und macht auch total Sinn. Für mich kam es trotzdem überraschend und war im ersten Moment total ärgerlich weil ich nicht verstanden habe warum das Gerät quasi tot war.

Aktuell läuft bei mir als Test per DNS rewrite auf lokalen MQTT mit Port 8883.

[maxclaudi]

@nograx
darf gar nicht schreiben, wie ich mich fühle...
Alles lief perfekt und schnell mit dem Cloud-Ersatz-Broker, und dann macht einem die EU einen Strich durch die Rechnung.

Wenn man wenigstens unkompliziert ein eigenes Zertifikat ausstellen und im Gerät hinterlegen könnte.
Ich bin an dem Thema Zertifikate aktuell dran – bisher ohne Erfolg.

Das ist auch der Grund, warum ich meinen 1600AC+ komplett auf das zenSDK umgestellt habe.
Den habe ich damit inzwischen soweit, dass er lokal fast alles macht, was ich will.

Ein echter, lokaler Cloud-Ersatz-Broker trotz SSL wäre bzw. ist hier natürlich das absolute Non plus Ultra.

Aber leider...

[nograx]

@maxclaudi Bei mir läuft es auf dem „mqtt“ Adapter mit einem selbst signierten Zertifikat. Der Hyper scheint das Stand jetzt zu akzeptieren. Den Adapter habe ich in einer pre-release Version umgestellt. Lasse das auf dem Hyper diese Nacht mal durchlaufen und schaue ob ich mich morgen traue meine anderen 3 Hyper zu aktualisieren.

[maxclaudi]

@nograx
ja, funktioniert noch. Nur sollte man gleich im Hinterkopf behalten, dass das vermutlich nur so lange funktioniert, wie die Firmware auf Port 8883 die Signierung des Zertifikats durch eine offizielle Behörde noch nicht streng validiert.

Sobald Zendure hier die Daumenschrauben anzieht – was durch die Vorgaben der EN 18031 für internetfähige Geräte leider über kurz oder lang zwingend vorgeschrieben ist (Stichwort Certificate Pinning oder strikte CA-Prüfung) –, könnte dieser charmante DNS-Weg mit selbstsignierten Zertifikaten leider auch ganz schnell wieder Geschichte sein.

[nograx]

Ich habe jetzt meine 4 Hyper auf dem lokalen MQTT mit TLS am laufen. Bin aber ehrlich gesagt sehr unzufrieden. Der Freeze bzw. der Connection Probleme tauchen hier jetzt viel häufiger auf. Bin jetzt absolut kein MQTT oder TLS Experte, aber folgende Meldung erscheint im Log:

connection closed: Error: XXXXXXXXXXXXXXXX:error:0A000119:SSL routines:tls_get_more_records:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/methods/tls_common.c:802:

Generell funktioniert die Kommunikation, aber ca. alle halbe Stunde meldet sich ein Hyper mit dieser Meldung und dann kommen keine neuen Daten bzw. ist eine Steuerung nicht mehr möglich. Manchmal reconnected das Gerät nach 3-4 Minuten, aber nicht immer.

[maxclaudi]

@nograx
Wenn die Verbindung grundsätzlich aufgebaut wird und MQTT-Daten zunächst funktionieren, dann sind DNS-Umleitung und Zertifikat wahrscheinlich ok.

connection closed: Error: XXXXXXXXXXXXXXXX:error:0A000119:SSL routines:tls_get_more_records:decryption failed or bad record mac:../deps/openssl/openssl/ssl/record/methods/tls_common.c:802:

bedeutet in etwa: Integritätsprüfung (MAC) fehlgeschlagen und die Nachricht deshalb nicht mehr entschlüsselt werden konnte.

ich vermute eher, dass der Fehler aus OpenSSL stammt.
Es wurden auf einer bestehenden TLS-Verbindung Daten empfangen, die nicht mehr zur TLS-Session bzw. zur aktuellen Verschlüsselung passen.
Es ist kein typischer Zertifikatsfehler.

Ob die Ursache dann Hyper, Broker, Node.js/OpenSSL oder irgendwo im Netzwerk (Verbindung bitte überprüfen) liegt?

Falls der Broker der mqtt-Adapter ist, würde ich testweise einen anderen MQTT-Broker einsetzen. So könnte der MQTT-Adapter als Fehlerquelle ausgeschlossen oder bestätigt werden.

Als wahrscheinlichste Ursachen bleiben im Wesentlichen:
Hyper-Firmware
ioBroker MQTT-Adapter (Node.js/OpenSSL)
Netzwerk/WLAN zwischen beiden

[nograx]

Ja ich denke ich werde heute Abend mal meinen emqx nutzen. Vorteil des integrierten MQTT war das ich diesen bei einem freeze eines Hypers einfach resetten konnte und er danach wieder erreichbar war.

[darkblu]

Hallo, ich hab da mal eine Frage zu den Posts hier drüber.
Bei meinen Hyper2000 mit AB2000X stehen seit heute mehrere upgrades
und updates an. Soll das heissen, wenn ich diese mache, dass ich den Hyper
dann nicht mehr mit dem Zendure Solarflow Adapter in ioBroker benutzen kann ?
Ich habe meinen Hyper per AuthKey im Adapter verbunden.
Okay, @nograx schreibt ja „Warnung an alle die den Hyper lokal nutzen…“
Per AuthKey nutze ich ihn ja nicht lokal.
Kann/soll ich die upgrades und updates machen ?
Ich bin da echt hilf- und ahnungslos.
Die iOS App wurde auch aktualisiert und fordert mich nun auf,
das HEMS zu aktualisieren, obwohl ich das ja ausgeschaltet habe.
Ich erbitte Hilfe

[Murphy 0]

Mein Rat wäre: auf jeden Fall mal ein paar Wochen warten und im offiziellen Forum mitlesen wie die Erfahrungen mit dem Update sind.
Leider hat Zendure in der Vergangenheit mit Updates teilweise „verschlimmbessert“

Ausserdem wird es nach dem Update mit echtem Offlinebetrieb kompliziert.

[nograx]

Wenn du gerade akut keine Probleme hast würde ich tatsächlich auch etwas abwarten. In der Firmware hat sich meiner bisherigen Erfahrung nur die MQTT Verbindung auf TLS geändert. Die Bugs 100% Standby und MQTT freezes sind noch vorhanden.

[darkblu]

Alles klar und danke, dann mach ich erstmal nix und beobachte hier weiter.

[lesiflo]

Moin,
ich habe meine 3 Hyper gestern komplett upgedatet, hat zwar etwas gedauert lief aber ohne Probleme durch. Bisher auch noch keine Auffälligkeiten und Fehler gehabt. Bin komplett in der Cloud. Den 100% Standby Bug konnte ich bisher nicht feststellen, war aber vorher bei mir auch kein Thema.

Bei mir hängen sich die Hyper nur dann auf wenn ich über setDeviceAutomationInOutLimit regele. Gehe ich über acMode mit setInputLimit/setOutputLimit laufen sie durch. Alles in der Cloud.

Ich habe heute Nacht mal die Regelung komplett dem HEMS von Zendure im neuen "Eigenverbrauchsmodus" überlassen und bin doch positiv überrascht. Die Werte sehen so aus:

[nograx]

@lesiflo Wie lautet denn dein productKey? Gibt ja vom Hyper 3 Stück, ggf. gibts da ne Serie die besser funktioniert?

Btw. gute Wahl vom Auto

[lesiflo]

Die sehen so aus. Sind zwei relativ alte und ein etwas neuerer.

@nograx: Gibt es die Möglichkeit den Schalter "Zu HEMS hinzufügen" aus der App im Adapter abzubilden?

[nograx]

@lesiflo Meine 4 Hyper sind jeweils auch diese beiden productKeys.

Die Frage bzgl. HEMS hinzufügen müsste man komplett schauen was da im Hintergrund passiert.

[Rico Sander]

@nograx @maxclaudi

Bezüglich der hier diskutierten Umstellung auf ssl und port habe ich auf Anfrage vom Zendure-Support gerade folgende Antwort erhalten:

vielen Dank für Ihre Nachricht und den interessanten Hinweis aus der Community.
Aktuell liegen uns intern keine bestätigten Rückmeldungen vor, dass Geräte der SolarFlow-Serie nach dem Update ausschließlich über SSL und Port 8883 kommunizieren.
Ich würde Ihr Feedback jedoch sehr gerne an unser Entwicklungsteam weitergeben. Falls Sie entsprechende Screenshots oder konkrete Hinweise aus Ihrer Umgebung haben, wären diese sehr hilfreich für die weitere Prüfung.

Dies nur zur Info, keine Ahnung, ob das für Euch irgendwie relevant ist.