Beiträge von ostfriese

Laut:

Klick

kann der auf dem WGM160P22A verbaute WF200 Roaming:

"Roaming

When operating in Wi-Fi client role, the device is capable of autonomously switching to a different access point when the current access point is either lost or the signal strength drops below the roaming threshold. The device will only consider access points that have the same SSID and that otherwise have the same security capabilities as the previous access point. The autonomous roaming functionality can be disabled by setting the corresponding option in sl_wfx_connect_req_t message. The various roaming parameters may be adjusted using sl_wfx_set_roam_parameters_req_t message. Parameter changes will be applied at the next connection."

Also gehe ich davon aus, dass da ein Fehler bei der Implementierung vorliegt.

Lässt also die selbe Annahme zu, die ich irrtümlich zum ESP32 getroffen habe.

Bleibt das Problem, dass wir das nicht ändern können.

Ok, wer lesen kann ist klar im Vorteil.

Wäre ja auch zu schön gewesen

Dann sollten wir uns den WGM160P22A mal vornehmen.

Ich bin verwirrt.

hier hat Devil doch den ESP32 erwähnt.

Was ist denn nun verbaut?

Das habe ich hier gefunden:

Klick

45. [Connect] The ESP32 and ESP8266 failed to connect to router, what could be the reasons？

...

The settings of bssid_set. If the MAC address of the router does not need to be identified,

the stationConf.bssid_set should be configured to 0.

...

und noch das:

Klick

Match with known access points by SSID¶

"By default, AutoConnect uses the BSSID to search for known access points. (Usually, it's the MAC address of the device) By using BSSID as the key to finding the WiFi network, AutoConnect can find even if the access point is hidden. However BSSIDs can change on some mobile hotspots, the BSSID-keyed searches may not be able to find known access points.

If you operate inconvenience in aiming at the access point by BSSID, you can change the collation key from BSSID to SSID by uncommenting AUTOCONNECT_APKEY_SSID macro definition in AutoConnectDefs.h library source code.

#define AUTOCONNECT_APKEY_SSID

Allow you to use PlatformIO as a build system and give the following description to the platformio.ini, you can enable AUTOCONNECT_APKEY_SSID each build without modifying the library source code:

build_flags=-DAUTOCONNECT_APKEY_SSID

"

Was bedeutet das?

Offensichtlich ist der Wifi-Chip by default so eingestellt, dass er das er bei einem Reconnect nach der BSSID (Mac-Adresse) der letzten Verbindung sucht. Das klappt aber nicht bei einem Mesh, da zwar die SSID gleich ist, aber die BSSID nicht passt. Dieses führt dann zu endlosen Reconnects und letztlich zum Absturz.

Die Lösung ist schon im ersten lLink beschrieben.

Der Chip lässt sich softwareseitig so konfigurieren, dass er nicht die BSSID berücksichtigt, sondern NUR die SSID.

Jetzt ist nur noch die Frage, wie man die Developer dazu bewegt, dort mal einen Blick drauf zu werfen und das evtl. anzupassen, ohne vom Support die Standard-Antwort zu erhalten.

Dachte, du hättest das Datenblatt. Hätte mir das Suchen erspart

Devil

Du scheinst ja gut informiert.

Weißt du den Stromverbrauch von dem Wifi Teil im TRV.

Ich meine, bei dauer AN.

Ich befeuere meine TRV seit 5 Tagen alle 60 Sekunden mit dem 'bleib wach für 180 Sekunden' Befehl.

Und was soll ich sagen, kein einziger Ausfall oder Reboot.

Kein Sleep und Reconect bedeutet wohl, kein Fehler in der Verbindung, kein Absturz.

Im WebIf sofort da und ansprechbar. Wunderbar.

Der Akkustand bei einem wenig regelndem TRV ist seit 5 Tagen auf 100 % bei durchgängig wachgehaltenem Wifi. Also fällt der werkseitig eingestellte Sleep-Mode wohl nicht so sehr in's Gewicht.

Wäre schön, wenn du da Infos hättest, dann könnte man ja mal rechnen.

Mobile Wallbox --> Paradoxon

Super

Freut mich sehr!

Zitat von thgoebel

Die Leiterbahnabstände sind beim Shelly 1 viel zu gering!

Wie aus dem Plan ersichtlich, ist auf PP gar kein PWM. Es wird nur ein Widerstand auf PE geschaltet.

Wie gesagt, es funktioniert seit einem Jahr. Und grundsätzlich kann man ja den 1 Plus nehmen, wenn man will. Ändert ja nichts an der Logik

Hätte ich das gewusst, hätte ich den 1 Plus genommen. Aber dafür ist ja dieses Forum gut. Man wird schlauer

Habe den Tip von thgoebel in meinem ursprünglichen Tipp aufgenommen. Danke dafür

Wenn du CP verwenden willst, hast du folgendes Szenario:

Stecker gesteckt wird über PP Leitung erkannt. Wallbox versucht über CP die Kommunikation zu starten.

Ist die CP-Leitung über den Shelly noch getrennt, schlägt die Kommunikation fehl.

Gesteckter Stecker, keine Kommunikation --> löst Fehler aus.

Ob da irgend etwas zertifiziert ist, spielt keine Rolle, weil, durch den Eingriff in die Wallbox bist du eh selbst verantwortlich.

Warum so kompliziert.Wallbox aufschrauben. Shelly1* an Phase/Null. PP-Leitung finden. Durchkneifen und die beiden Enden an I und O vom Shelly.

*(Nur Shelly1 da potenzialfreie Kontakte!!!)

Nach Hinweis von thgoebel sollte man den

Shelly Plus 1 verwenden.(siehe weiter unten im Thread)

An der PP-Leitung erkennt die Wallbox, ob ein Auto angeschlossen ist.

PP-Leitung unterbrochen + Stecker gesteckt --> kein Auto angeschlossen, keine Kommunikation, kein Ladestrom

PP-Leitung geschlossen + Stecker gesteckt --> Auto angeschlossen, Kommunikation beginnt, Schütz der Wallbox zieht an, Ladestrom fließt

Erklärung mit Schaltplan

Man schaltet nur eine Signalspannung und auf dem Shelly hängt keine Last. Die Ladebox hat ja schon die fetten Schütze. Läuft bei mir seit einem Jahr problemlos.

Gruß aus Ostfriesland

@ThomasKA

Prima, dass es läuft.

Hast du GMX oder anderen Provider.

Ich würde noch empfehlen

delay = 60

zu setzen.

Falls ihr die Möglichkeit habt, irgendwo Python laufen zu lassen.

Das Skript überwacht die TRV und versucht rechtzeitig zu rebooten.

Den Teil

# config TRV #

müsst ihr anpassen.

Wenn ihr per Email über die Aktivitäten des Skrpts informiert werden wollt, müsst ihr auch den Teil

# config MAIL #

anpassen.

Es schickt dann auch Mails bei dem definierten Mindestbatteriestand.

Habe das nur für GMX getestet. Für andere Mail-Provider müsste, falls es nicht funktioniert, die

sendmail

Routine angepasst werden.

Erwartet jetzt bitte nicht, dass ich hier große Python Kurse gebe. Dazu fehlt mir leider die Zeit.

Wer's gebrauchen kann, soll's verwenden.

Grüße aus Ostfriesland

Devil Freut mich tatsächlich!

Also ich hätte beruflich eine komplette Hochschule mit diesen Dingern ausgestattet, wenn die zuverlässig wären.

Zumal ich privat gerade für 2022 eine Rückzahlung (Gas) von fast 800€ für ein größeres Einfamilienhaus bekommen habe.

Der Preis dafür war aber mehrmals wöchentlich vor irgend welchen Heizkörpern zu knien und viel Zeit mit immer wieder neu konfigurieren verbracht zu haben.

Das wäre eine nette 5-stellige Summe gewesen.

Aber so tue ich mir diesen Stress nicht an!!!

Zitat von Devil

und das soll dann was genau bringen?

Na ja, es soll ja Leute geben, die vor dem Kauf recherchieren. Hätte ich auch intensiver machen sollen

Zitat von Devil

Ja dann frag doch mit diesen Werten mal genau das den Support. Ist ja bei der ganzen Sache auch das was ich merkwürdig finde. Dann muss doch der TRV, das irgendwie erkennen und wenigstens einfach mal neustarten.

Habe ich gemacht -> Standardantwort erhalten

@ThomasKA

Evtl. macht es beim Hersteller mehr Druck, wenn, falls möglich, der Thread in:

Keine Kaufempfehlung für TRV

umbenannt wird,

Also, bei mir treten die Fehler in folgenden Werten auf:

"thermostats", "target_t","value" : ��.�

"thermostats","target_t","value_op" : �.�

"thermostats","target_t","tmp","value" : ��.�

"bat","voltage" : �.���

Ich sehe da keinen Zusammenhang mit der Wlan-Verbindung, sondern eher ein Problem beim internen Schreiben in den Speicher.

Z.B. ist der Wert "value_op" (Zieltemperatur bei Verwendung eines Shelly-DW Sensors bei geöffnetem Fenster ) gar nicht änderbar. Wieso sollte dieser Wert durch eine schlechte/nicht vorhandene Wlan-Verbindung falsch gesetzt werden, wenn es ein read-only Wert ist? Analog gilt das auch für "bat","voltage" und "target_t","tmp","value.

"thermostats", "target_t","value" wird von mir auch nicht extern verändert, sondern ergibt sich aus dem shedule profile.

Für mich stellt sich das so dar, dass es einen Bug in der Firmware gibt, der diese Werte falsch schreibt. Und ja, eventuell tritt dieser Fehler im Zusammenhang mit Wlan-Problemen auf, aber das Wlan ist hier nicht ursächlich!!!

Hallo,

Ich habe hier 11 TRV in einem ganzem Haus verteilt. Natürlich mit einem Mesh (Fritz AVM). Der Fehler tritt immer wieder bei verschiedenen TRV auf. Das einzige, was hilft, ist ein Reset und neu einrichten.

Den Support habe ich angeschrieben. Nur das Übliche:

Yes, we have similar raised issue with the developers.

Please, set a fixed 2.4Ghz channel on the network and have the devices connected to it.

Disable the 5Ghz network if it's not used.

Disable the band-steering feature.

Set static IP on the client and on the user side.

Disable the CoIoT feature of the device if it's not being used

Nach weiterer Beschwerde kam das Angebot die TRV auszutauschen.

Ist ja Quatsch. Die Wahrscheinlichkeit, dass alle 11 TRV einen Hardwaredefekt haben, ist gleich 0!!!!

Ich habe also die Wahl, entweder ein performantes Wlan, oder heizen mit TRV.

Da ich 1000€ für die TRV ausgegeben habe, finde ich es unverschämt, dass dieser offensichtliche Firmwarefehler nicht zeitnah gefixt wird!!!

Zumal "Yes, we have similar raised issue with the developers" ja sagt, dass denen der Fehler bekannt ist.

ICH BIN SAUER!!!

Schade. Danke für die schnelle Antwort.