Hmm, wenn ich mir den code so anschaue, dann sieht es schon so aus als ob die Master erst den eigentlichen release train an den slave shickt und dann eine Updatekommando direkt hinterher...
if [[ $lastmanagement == "1" ]]; then
if [[ "$evsecons1" == "extopenwb" ]]; then
echo "starting update on extOpenWB on LP2"
mosquitto_pub -t openWB/set/system/releaseTrain -r -h $chargep2ip -m "$releasetrain"
mosquitto_pub -t openWB/set/system/PerformUpdate -r -h $chargep2ip -m "1"
fi
fi
Da das direkt hintereinander passiert, kann es möglicherweise passieren, dass das abarbeiten des Updatekommandos das setzen eines neuen release trains überholt?
Der-Kieler hat geschrieben: ↑Do Dez 01, 2022 3:53 pm
Das findest Du ernsthaft in Ordnung?
Ja, weil es war eine bewuste Benutzerentscheidung die zweite Box auf die Beta zu setzen.
Wer das tut kann auch mit den Folgen leben.
Wer das nicht tut hat auch nichts zu befürchten.
@jpn , und ja ich denke das Timing könnte der Grund sein.
Bewusste Benutzerentscheidung? Der Kunde ist also selbst Schuld?!
Ich habe letztes Jahr ein Problem gehabt und der openWB Support hat mir gesagt, dass ich die Nightly installieren solle, da damit das Problem gelöst sei.
Wie sollte ich als Kunde wissen, was das für Konsequenzen mitbringt? Schlicht unfair, dem Kunden die Schuld in die Schuhe zu schieben, wo er keine Chance hat zu wissen was das bedeutet.
Wenn es die Programmierer nicht hinbekommen ist das kein Weltuntergang, aber es sollte als Worksround zumindest eine Meldung angezeigt werden, dass man in diesem Fall manuell das Update machen muss.
Zuletzt geändert von Der-Kieler am Do Dez 01, 2022 8:40 pm, insgesamt 1-mal geändert.
6KWp mit Solaredge StorEdge Dreiphasen-Wechselrichter SE5K mit LG Chem RESU 6.5 Speicher und 6KWp Modulleistung.
Zwei open WB Custom mit Phasenumschaltung (Mai 2021).
Tesla Model 3LR aus 2024 und Eniaq aus 04.2022.
Das problem dabei ist das die Master den Stand der Slave nicht kennnt (noch nicht)
Das einfachste wird sein den Zwangs-Abgleich zum funkionieren zu bringen.
(bis zum ersten der sich beschwert das seinen Slave "kaput geupdatet wurde" durch den Update der Master.
(z.b weil andere Handware )
Also ein einfach klicker "externe openWB mit Updaten" könnte die Lösung sein.
O.K., das verstehe ich.
Einfachste Idee: Man könnte eine Pop-Up Meldung anzeigen, wenn ein Wechsel zwischen Stable, Beta oder Nightly erfolgt.
Das wäre ein guter Workaround.
Ein eigener Button wäre sicher topp, aber was ist wenn es mehr als eine weitere Box gibt? Könnte schwierig werden, da alle Eventualitäten zu berücksichtigen.
6KWp mit Solaredge StorEdge Dreiphasen-Wechselrichter SE5K mit LG Chem RESU 6.5 Speicher und 6KWp Modulleistung.
Zwei open WB Custom mit Phasenumschaltung (Mai 2021).
Tesla Model 3LR aus 2024 und Eniaq aus 04.2022.
Seit der Umstellung auf 288 wird der RFID Tag unzuverlässig vom LP2 an den Master übertragen.
Der LP2 quittiert den Chip mit einem Beep, es ist dann aber Zufall, ob die Information beim Master ankommt.
jpn hat geschrieben: ↑Mi Nov 30, 2022 6:49 pm
...ist jetzt eher so ein periferes Problem, aber so sieht es aus, wenn bei gewähltem "Color Theme" der "Nur Ladepunkt" Modus aktiviert wird:
2022-11-30_19h44_20.png
Das müsste sich @electron als Autor des Themes ansehen.
Zum Thema "Update der externen openWBs":
Es war schon immer so vorgesehen (aber nicht sicher genug umgesetzt), dass ein Verbund aus mehreren openWB immer auf dem selben Stand gehalten wird.
Heißt im Klartext: Update am Master anstoßen und alle externen openWB bekommen die Info, auf welchen Entwicklungszweig (Stable, Beta, Nightly) jetzt aktualisiert werden soll. Wie immer gilt, dass man damit nur 50% der Anwender glücklich machen kann.
Warum es jetzt weiterhin zu einem abweichenden Verhalten kommen kann, muss noch untersucht werden. Es könnte, wie von @jpn vermutet, einfach ein Timing-Problem sein. Wir sehen uns das an.
Hier bitte keine weitere Diskussion zum Sinn oder Unsinn, dass das Update die externen openWB ebenfalls hochzieht. Dazu kann ein separater Beitrag eröffnet werden.
JHC hat geschrieben: ↑Sa Dez 03, 2022 9:19 am
Problem Nummer zwei:
Seit der Umstellung auf 288 wird der RFID Tag unzuverlässig vom LP2 an den Master übertragen.
Der LP2 quittiert den Chip mit einem Beep, es ist dann aber Zufall, ob die Information beim Master ankommt.
Gerne einen eigenen Beitrag dazu öffnen. Für die weitere Analyse benötigen wir jedoch von beiden Boxen Logauszüge.
