Ich hatte leichte Anlaufschwierigkeiten mit der Bridge Pro und dem iobroker Adapter.

Anfangs bekam ich die gleichen Fehlermeldungen wie die im github issue aufgeführten. Ich versuchte zu dem Zeitpunkt noch die alte und neue Bridge gleichzeitig gestartet zu halten und die Migration war noch nicht durchgeführt. Ich wollte einfach vor der Migration sicherstellen, dass die neue Bridge mit iobroker erreichbar ist und Wert liefert.

Trotz Fehlermeldungen und keiner Verbindung zur neuen Bridge in iobroker, habe ich dann die Migration durchgeführt und anschliessend die alte Bridge auf den Werkzustand zurückgesetzt.

Danach habe ich die alte Instanz im iobroker gestoppt und eine neue Instanz angelegt, um die neue Bridge Pro zu verbinden.
Die Automatik dabei hat nicht geklappt - ich musste gezielt die IP-Adresse der neuen Bridge manuell angeben.
Auch bei der Anlage des Benutzers gab es dann leichte Schwierigkeiten: Knopf an der Bridge gedrückt, anschliessend in der Konfiguration und ich bekam eine Bestätigung mit "Ok". Allerdings wurde das Eingabefeld für den Benutzer dabei nicht mit einem Wert gefüllt. Daher konnte sich die Instanz auch nicht mit der Bridge erfolgreich verbinden.
Im log von iobroker konnte ich jedoch den Wert für den neuen Benutzer zum Glück finden, da die Anlage dort protokolliert wurde. Ich trug dann manuell den Benutzer in die Konfiguration ein. Nach dem folgenden Restart hat alles geklappt und die Objekte wurden wieder in der neuen Instanz angelegt und alles funktioniert wie zuvor.

@timowald Was genau hast du denn vor bzw. was meinst du mit "Export deiner Seite"?

Gleiches "Spiel" bei mir - ich habe auch auf EVCC umgestellt und betreibe damit zwei Easee-Boxen mit zwei E-Autos (Tavascan und Smart #3). EVCC regelt das problemlos - sofern Easee nicht gerade wieder offline geht

Ich möchte mich für die Arbeit an diesem Adapter bedanken.

Seit einigen Tagen sind wir auf den Saros 10R umgestiegen, vorher war der S7 MaxV im Einsatz. Dort hatte ich noch den Xiaomi-Adapter verwendet.
Mit dem Umstieg auf das neue Modell habe ich auch bei der App den Wechsel zur Roborock-Original-App vollzogen. Somit musste auch im iobroker auf den neuen Adapter gewechselt werden.

Nach leichten Anfangsschwierigkeiten (keine lokale Verbindung), läuft die Geschichte jetzt mit der Version 0.6.19
Daher konnte ich heute auch im VIS die Anpassungen vornehmen, da die Steuerung doch in einigen Punkten vom bisherigen Xiaomi-Adapter abweicht.

Die wesentlichen Dinge lassen sich jetzt wieder steuern bzw. ablesen, so dass auch ohne Handy der Roboter seinen Dienst verrichten kann.

Anbei noch ein Screenshot von der VIS dazu.

Ich nehme jetzt den Umweg über Tronity - die scheinen einen besseren Draht zu PSA zu haben und haben daher noch/wieder Zugang zu den Daten. Das dürfte auch der bevorzugte Weg sein wie sich PSA das vorstellt: Nur noch über größere "Zwischenanbieter" und nicht mehr jeder "kleine" Besitzer der seine Daten direkt abrufen möchte. Anders kann ich mir das nicht erklären.

Für mich wird das Thema PSA ebenfalls nach dem Leasingende beendet sein. Wir haben den Peugeot 208e gekauft, weil er uns gefiel und zum damaligen Zeitpunkt die Auswahl auf dem Markt nicht allzu groß war. Aber die Software ist einfach nur ein Trauerspiel - sowohl was das Thema innerhalb vom Auto betrifft, als auch bzgl. App und API-Unterstützung. Dieser Konzern hat einfach noch nicht verstanden wie wichtig das inzwischen ist.
Allein die Tatsache, dass sie die API bereits seit einigen Jahren als "comming soon" bezeichnen ist ein Witz.

Natürlich gebe ich die Hoffnung nicht auf, dass in absehbarer Zeit wieder ein Zugriff möglich ist - aber an der grundsätzlichen Entscheidung wird das wohl auch nichts mehr ändern. Ab 2025 haben die einen Kunden weniger.

@strobelix Das mit der 6A Grenze ist wohl üblich bei den Autos. Das wußte ich jedoch bereits vorher und habe das immer als Minimalwert zum Laden genommen.
Heute ist der erste Tag mit halbwegs Sonne und bisher klappt alles wie erhofft. D.h. Umschalten der Stromstärke während dem Laden funktioniert ohne den Ladevorgang pausieren zu müssen. Das Auto scheint damit einverstanden wobei ich mich dabei trotzdem immer frage, ob die Hersteller mit sowas gerechnet haben oder wir damit irgendetwas auf Dauer "abnutzen".
Bei den Easeeboxen ist es ja schonmal wichtig darauf zu achten nur die Werte immer wieder zu ändern die den Flashspeicher nicht beeinträchtigen. Was dabei im Auto geschieht weiß ich nicht - klar ist, dass sich das Ding jedesmal beim Ändern entsprechend anpassen muss.
Ich habe das bei meinem Script so eingestellt, dass er immer mindestens 5 Minuten wartet bis wieder eine Änderung vorgenommen wird. D.h. auch wenn die Sonne in der Zwischenzeit mehr oder weniger liefert wird das frühestens nach 5 Minuten wieder angepasst. Bei halbwegs konstantem Sonnenschein führt das zu relativ wenig Änderungen, bei ständigem Wechsel durch Wolken wird halt mal zu viel oder zu wenig verbraucht.

Ich habe inzwischen meine zwei Easee-Boxen und den Peugeot ebenfalls in iobroker eingebunden.
Meine ersten Versuche mit einem passenden Ladescript führen jedoch noch zu Fehlern beim Umschalten von einphasig zu dreiphasig laden. Sobald ich den Ladevorgang pausiere, die neuen Werte einstelle und den Ladevorgang dann wieder per "resume" fortführen will, beendet sich der gesamte Vorgang - d.h. die beteiligte Wallbox geht auf den Status 4 "abgeschlossen".
Danach geht natürlich nichts mehr, egal was ich anstelle. Das Kabel muss raus und wieder neu eingesteckt werden.
Jetzt frage ich mich ob das Auto mit der Umstellung während dem Ladevorgang nicht klarkommt, oder ich mit dem pausieren und wieder fortführen einen Denkfehler mache.
Kann man die Werte auch ohne Pausieren einfach ändern?
Mit Werten sind übrigens die Felder dynamicCircuitCurrentPx gemeint. Für einphasiges Laden setze ich dabei nur Werte bei P1 - die anderen auf 0.
Bei dreiphasigem Laden entsprechend gleiche Werte auf alle drei Felder.

Ergänzung: Nach weiteren Test habe ich als "Schuldigen" mein Auto identifiziert. Den Wechsel von einphasig auf dreiphasig verkraftet der Peugeot nicht und beendet den Ladevorgang - egal wie ich den Wechsel versucht habe.
Hingegen klappt der Wechsel der Stromstärke auf der Phase P1 auch ohne vorheriges Pausieren. D.h. dem dynamischen Laden je nach verfügbarem Sonnenstrom steht nichts mehr im Weg. Leider an besonders ergiebigen Tagen dann ohne dreiphasiges Laden, was jedoch eh nur sehr selten der Fall sein wird.

@falke69 Funktioniert dein Skript eigentlich bzgl. der zweiten Laufzeit und der lief-Markierung?
Vielleicht habe ich ja etwas übersehen, aber ich interpretiere dein Skript so, dass immer gleich beide lief-Haken gesetzt werden sobald der Mäher erfolgreich zurückkehrt. D.h. sobald morgens erfolgreich gemäht wurde, stehen immer gleich beide Zeiten mit Haken drin. Aber eigentlich sollte das doch je Laufzeit getrennt markiert werden. Wenn er nachmittags nicht fährt sollte dort der Haken nicht gesetzt sein.

@moelloman Ich kann von meiner Seite inzwischen Entwarnung geben. Tiefes Stöbern hier im Forum hat mich zur Lösung gebracht. Letztendlich ist entscheidend in welcher Reihenfolge die verschiedenen Geräte online gehen.
Durch die Erklärungen des Adapter-Entwicklers erscheint mir das soweit auch alles logisch: Ich konnte letztendlich durch einen simplen Neustart des Adapters ihn jetzt auf permanent online bringen. Ich vermute das liegt daran, weil der Mäher seitdem nicht mehr durchgestartet wurde. Der Mäher ist ja für die Versorgung mit Daten zuständig. Wenn der zwischenzeitlich offline geht, verlieren wohl alle anderen Geräte/Dienste die permanente Verbindung zu den Nachrichten, auch wenn der Mäher kurze Zeit später wieder online geht.
Soweit ich das verstanden habe liegt das an der Art und Weise wie zwischen allen kommuniziert wird. Der Mäher versorgt alle, der Rest hängt sich dran und muss entsprechend sich auch wieder neu anhängen, wenn man den Mäher mal offline nimmt.
Allerdings befürchte ich, dass bei einer instabilen WLAN-Verbindung des Mähers das Problem öfters auftreten könnte.