openWB Forum

das wäre ja saublöd! Aber dann müsste man ja eine entsprechende Rückmeldung über das API bekommen. Kann man das irgendwie tracken?

Das ist nur eine Vermutung meinerseits, gestützt auf meine Erfahrung mit solchen und ähnlichen Diensten ...

Ev. fragt eines Deiner anderen Systeme immer genau kurz vor der openWB den Server ab, der dann für Sekunden oder Minuten keine andere Anfrage desselben Benutzers beantwortet.

Beim Debuging also ALLE möglichen Störquellen abschalten und das fehlerhafte System soweit wie möglich isolieren.

blueberry63 hat geschrieben: Fr Dez 11, 2020 11:31 am das wäre ja saublöd! Aber dann müsste man ja eine entsprechende Rückmeldung über das API bekommen. Kann man das irgendwie tracken?

Manche APIs sperren dann auch gerne mal komplett für 24-72 Stunden ohne Angabe von Gründen.

ich habe jetzt alle anderen Abfragen gestoppt - mal sehen, was passiert

Mich würde noch Interessieren, ob ich die Python Scripts direkt auf dem OS (Debian) aufrufen und die Ausgaben beobachten kann.

Zur Info: das Problem konnte ich zusammen mit Oliver lösen. Es hatte nichts mit OpenWB zu tun, ich hatte ein "kleines" Problem in meinem Netzwerk

Guten Morgen blueberry63

Du bist sicher nicht der Einzige, welcher aufgrund von "Netzwerk-Konfigurations-Eigenheiten" SOC-Abfrageprobleme vermutest.

Im Übrigen weiss jeder mit Supporterfahrung, dass äussert häufig ein Gerät einfach nicht eingeschaltet oder nicht am Strom angeschlossen war. Der Mensch ist halt so und ich würde auch mich nicht ausschliessen wollen. Daher muss es Dir so oder anders nicht peinlich sein.

Das Thema Netzwerk ist in diesem Forum deshalb so wichtig, weil LAN-Anschlüsse als favorisierte Anschlussart der openWB propagiert werden. Nur bei WLAN wäre Sicherheit "von Haus aus" mit an Bord. LAN-Anschlüsse, welche aus dem sicheren Bereich der Wohnung hinaus geführt werden, sollten sinnvollerweise geschützt werden; andernfalls könnten Dritte durch Missbrauch des LAN-Anschlusses recht einfach an persönliche Daten von Geräten kommen, welche sich ebenso im LAN befinden.

Nebst "Abschottung" durch VLAN, WLAN, Firewall oder der eher schwache Schutz durch MAC-Filterung oder Ausschalten von DHCP wäre die Implementierung von IEEE 802.1X eine saubere Lösung. Da Elektriker aber nur selten ebenso über hinreichend IT-Sicherheitskompetenzen verfügen und die Inbetriebnahme einer Wallbox hoch komplex bzw. interdisziplinär würde, verzichten leider viele Wallbox-Lieferanten auf IEEE 802.1X.

Steht die Ursache Deiner Verbindungsprobleme im Zusammenhang mit der Implementierung der Sicherheit auf dem LAN? Oder in welchem Zusammenhang?

Grüsse

Zimberg4

Mein Problem war selbst verursacht: ich hatte Anfang der Woche meine eigenen DNS+DHCP Dienste (liefen auf einem Cubietrack) abgeschaltet und arbeite jetzt nur noch mit der Fritzbox. Beim Abschalten/Stoppen der alten Dienste hatte ich einen Fehler gemacht. Alles gut

Ich bin mir nicht sicher, aber kann es sein, dass sich mal wieder etwas an der API von Renault geändert hat? Im Goingelectric Forum schreiben sie, dass sich der KAMEREON_API_KEY geändert hat...

Jep, die neue lautet:
$kamereon_api = 'Ae9FDWugRxZQAGm3Sxgk7uJn6Q4CGEA2';

gesucht mit dem alten Key: Ich habe die in meinem Fall in /var/www/html/openWB/ramdisk/zoereply1lp1 gefunden.
in geändert.

Das klappt aber nicht. Der API-Key scheint aber richtig zu sein, denn damit kann ich wieder via Webserver auf den Zoe zugreifen.