services:
polestar2: # sollte zum Auto 1 passen
image: consulitas/polestar_2_mqtt_docker:latest
container_name: "polestar2" # sollte zum Auto 1 passen
restart: always
environment:
TZ: "Europe/Berlin"
POLESTAR_EMAIL: "xx@xxx"
POLESTAR_PASSWORD: "XXX"
POLESTAR_VIN: "LPSVSEDEEMLxxxxx1" # sollte zum Auto 1 passen
POLESTAR_CYCLE: 270 # seconds
MQTT_BROKER: "192.168.1.100" # IP or DNS name
MQTT_PORT: "1883"
MQTT_USER: "" # has to be empty ("") if broker has no password
MQTT_PASSWORD: "" # has to be empty ("") if broker has no password
MQTT_BASE_TOPIC: "polestar2" # sollte zum Auto 1 passen
polestar4: # sollte zum Auto 2 passen
image: consulitas/polestar_2_mqtt_docker:latest
container_name: "polestar4" # sollte zum Auto 1 passen
restart: always
environment:
TZ: "Europe/Berlin"
POLESTAR_EMAIL: "xx@xxx"
POLESTAR_PASSWORD: "XXX"
POLESTAR_VIN: "LPSVSEDEEMLxxxxx2"
POLESTAR_CYCLE: 270 # seconds
MQTT_BROKER: "192.168.1.100" # IP or DNS name
MQTT_PORT: "1883"
MQTT_USER: "" # has to be empty ("") if broker has no password
MQTT_PASSWORD: "" # has to be empty ("") if broker has no password
MQTT_BASE_TOPIC: "polestar4"
Einfach
2 Services (Container) definieren - auf Einrückung achten!
Ich habe mich aus der App mal ausgeloggt. Jetzt komme ich nicht mal mehr auf den Login Screen. Der „Weiter“ Button tut erst mal gar nichts.
Abwarten und Hanftee trinken.
Auch in der Schweiz im Moment keine Verbindung möglich…ist ärgerlich, aber wenigstens gibt es untenstehende Info und dauert in der Regel nicht allzu lange…
Wenn hier in der Reccurence (270s) und einem Toleranzofset (30s) keine neuer Wert kommt, sendet mir der IObroker eine Pushnachricht auf mein Handy (…und wenn es wieder im Zeitrahmen ist eine Entwarnung). Deswegen habe ich heute morgen direkt gesehen, dass 'mal wieder etwas schiefläuft. Insgesamt steckt da die Überwachung der Zielladung hinten dran - ohne SoC-Info funktioniert das ja nur halbgar über einen geschätzten Ladezustand.
heute Nacht hatte mein System wieder die Verbindung zum Polestar-Server verloren. Aber es war „komisch“.
Der Wert container/connected blieb auf „online“, hingegen hing container/last_update auf einem Zeitstempel von 04:33 fest. Ich habe dann in Portainer den Status gecheckt. Es gab zwar keine Fehlermeldung, jedoch auch keine neuen Werte. Ich habe dann den Container neu gestartet und das Problem war gelöst -und leider versäumt die Meldungen zu dokumentieren.
Mag sein, dass ich als 100% Laie jetzt kompletten Blödsinn vermute, aber für mich sah das so aus, als ob lokal das System prima läuft aber keine Verbindung zum I-Net bzw. Polestar-Server mehr hat.
Der Zeitpunkt der Störung bringt mich zu einer Vermutung, denn gegen 04:30 geschieht (bei mir) die DSL-Zwangstrennung.
Normalerweise (gestern) sieht das Protokoll dann so aus:
Der IoT-Adapter verliert mal kurz die Verbindung und ggf. nachfolgend beschwert sich manche Device-Steuerung (hier Chromecast) und dann ist es wieder gut.
Heute hat, ausnahmsweise, das Script, dass den PS2-Containers überwacht, diese Beschwerde-Rolle übernommen:
Das zeitliche Zusammentreffen der Ereignisse bringt mich zur Vermutung, dass die Containerabfrage ins Leere gelaufen ist (weil zu diesem Zeitpunkt keine I-Net-Verbindung) und der Container sich von diesem Schock nicht wieder erholt hat.
Anscheinend muss aber sehr genau eine zeitliche Abfolge getroffen werden. In der 270Sek-Taktung hatte ich, in der gleichen Situation, auch schon die Script Meldung „Container offline“ und im nächsten Zyklus dann „Container ist wieder online“ .
Kann das sein? Kann(st du) man das irgendwie abfangen? Ich habe erstmal keine Möglichkeit gefunden den Container-Neustart „von außen“ automatisch zu triggern…
mitlerweile auch
nicht wieder erholt hat.
