Teslausb / Raspberry Pi für die Dashcam WLAN

anon35000762 · 24. Juli 2022 um 07:54

Yup, heute Morgen deswegen die „mach mich stromfrei“ auf dem Datenkabel“ ausprobiert: Pi0 sackt beim booten ab. Baue den Sumpf gleich nochmal auf mit einem Pi-Netzteil mit 3A… kann das sein dass Laden + Booten >500mA ist??? Das wäre ja fatal.

anon35000762 · 24. Juli 2022 um 11:15

Kein Erfolg.… es liegt nicht am Netzteil oder an der Power…

Werde jetzt nochmal ein image etchen, wo ich nur die Funktion des PiSugar2 teste.

Hab’ beim Googeln herausgefunden (Link), dass der Nachfolger PiSugar3 genau deswegen gebaut wurde: eigene „MCU“, um alle Stati power on/off, Zustand Akku, Zustand Pi0, unabhängig vom Zustand des Pi zu „verarbeiten“.

Jetzt ist mir auch klar, warum kein Batterie-HAT vernünftig USV-Funktion kann: wie soll das gehen ohne Strom am Pi0 und ohne dass dann Code laufen kann… Puh… der PiSugar3 wird leider nur in Frankreich verkauft. Das wird jetzt leider ne Woche dauern… bestellt isser.
Also ich bin quasi „Opfer der Werbung - und mangelnder Recherche“ - also selbst schuld.
Ein Klassiker halt.

Ah und der PiSugar3 hat ne USB-C-Buchse. Das wäre doch mal „zukunftssicherer“ und kein Adapter-Gefummel…

anon35000762 · 24. Juli 2022 um 11:54

So. Es ist definitiv so, dass der PiSugar2 zwei Dinge nicht gleichzeitig kann:

per Befehl beim Akkustand x herunterfahren
sobald externe Power wegfällt und wieder vorhanden ist, booten

Damit das funktioniert, muss man einmal mit dem mechanischen Schalter den PiSugar2 vom Akku trennen (Reset des PiSugar, der auf dem Befehl „herunterfahren“ kleben geblieben ist) und
wieder anschalten.

Klarer Fehlkauf also für den Einsatz als „USV“ (weil das genau diese Funktionalität wäre "Strom weg, laufe auf Akku bis Level x dann fahre kontrolliert herunter; wenn Strom wieder da, starte die Mühle und lade den Akku; repeat), was aber nicht geht.

Da ändert auch die Funktion „On Power Restore“ - weil dann (warum auch immer) der Pi0 in die Knie geht beim booten…

Außerdem scheint in diesem Modus das Laden nicht an der voreingestellten Schwelle beendet zu werden und bei 100% lädt er immer noch. Das ist einfach ganz übler Mist! (No Shit Arthur!)

Klappe zu, Wochenende

Faxenmacher · 24. Juli 2022 um 15:42

Don’t panic! Es kann gut sein, daß die Ladeelektronik auch bei 100% SoC weiter lädt (bulk->absorb->float).

Aber in der Tat wird keine fertige USV das gewünschte Verhalten nachbilden. Da müsstest du schon selber die passende Logik in die USV löten, welche nur dann die Reset-Leitung am Raspi zieht, wenn er runtergefahren ist, aber nicht, wenn er noch läuft. Ich zitiere mich mal selbst:

(‚ausgeschaltet‘ zum besseren Verständnis ergänzt)

Da hilft erstmal auch kein Handtuch mehr.

Gruß vom Faxenmacher!

anon35000762 · 24. Juli 2022 um 17:28

Also es ist kein PiJuice. Aber funktioniert als Version2 (PiSugar2) leider genau so: nicht als USV.

Und ja, der PiSugar2 hat eine Einstellung dafür,

TL;DR NSFW

dass er bei PowerLoss/PowerSafe Strom auf den Pi0 geben soll, den er vorher komplett runtergefahren hat. Fährt er dann wieder hoch, knickt der Pi0 weg. Der PiSugar2 taugt als nicht für den Pi02W. Leider gab es nur diesen in D zu bestellen (in F seit 2021 den Nachfolger PiSugar3, der das Problem nicht kennt, weil er komplett anders aufgebaut ist. War mir aber so nicht klar.)

APC USV

Ich habe für meine SYNOLOGY eine APC USV, die ein Kabel für die SYNOLOGY hat zum Runterfahren. Und auch bei Serverschränken triggert forget USV die Rechner zum Abschalten, bevor die Akkus alle sind.

Handtuch habe ich eh immer dabei.

anon35000762 · 10. August 2022 um 17:01

So, ich hoffe, ihr habt alle ein Handtuch!
Es wird heiß werden… :

In meinem letzen post hab ich geschrieben, dass der PiSugar2 keine USV ersetzt.

Ich hab’ aber noch nicht aufgegeben und die PiSugar3 bestellt und
TL;DR: das funzt, allerdings mit etwas Aufwand, klar.
Insgesamt geht es viel besser, als mit dem PiS2, auch „restart bei Power-On“.

USB-Stecker: die alten Probleme (Daten und Strom trennen).
Bisschen Code basteln: leider ja.
Level: High (für Bastler mit Programmierkenntnissen)
Preis: 39,99 (€€€€ = verhältnismässig teuer)

Das Thema ist mit dem PiSugar3 („PiS3“) tatsächlich gelöst worden: der PiS3 hat einen „Soft-Aus“ Taster bekommen und eine RTC samt Micro-Prozessor, der verschiedene „Zustände“ erkennt.

PiSugar3 Eckdaten

Version: PiSugar3 für Raspberry Pi Zero2W
bekanntes Design mit „Pogo-Pins“ (wie Vorgänger; geht ohne, geht mit Lötstiften)
Akku: 1200mAh (wie Vorgänger)
USB-C-Buchse on-Board für Stromzufuhr
1 LED ultralow current für „an“ (blau), 4 LED ultralow current für „Ladebalken“ (grün)
RTC Baustein mit UltraCap (läuft ca. 1 Jahr ohne ext. Spannung)
eigener µ-Controller für Ansteuerung on/off/watchdog
Lötpads für Eingang externe 5-12V („Solar-Panel“)
Anschluss an Pfostenleiste für 5V Ausgang (oder über GPIO)
soft / hard restart / power off
auto power-on bei external power-on-event
auto power-on by timer (einmalig oder 1-7 Werktage (immer gleiche Uhrzeit!)
auto power-off by battery power (0-30%)
Akku-Schon-Gang (theoretisch beworben, hab bei mir mit aktueller Software nie funktioniert)
erhältlich derzeit nur über Amazon Frankreich (oder USA) (hatte bei Amazon F bestellt)
Preis: 39,99,-€
man muss bei der Stromversorgung aufpassen: der PiS3 ist über die Pogo-Pins direkt mit dem Pi0 verbunden, also ohne Schottky-Dioden, der Strom fließt dann leider in beide Richtungen!
Somit darf man die USB-Stecker nicht an einen „Verteiler ohne Trennung bei den Spannungsführenden Drähten“ sich wundern, dass der Raspi dann vom Akku gespeißt läuft und aber der PiS3 vom Raspi über den USB-Stecker Strom bekommt auf seinem USB-C und dann den Akku… aus seinem eigenen Akku lädt (und damit nicht ein Wegfall der externen Stromversorgung erkennt…!) (Also hier Datenkabel ohne Strom oder wenigstens Pin4 (+) abkleben, sonst funktioniert weder das Abschalten noch das Wiederanschalten!

PiSugar3 Getestet mit TeslaUSB TL;DR

Außerdem kann man auf dem Raspi einen Daemon laufen lassen, der ständig in einem bestimmten (Zeit-)Abstand in ein dafür vorgesehenes Register schreibt und sollte der Schreibvorgang ausbleiben, versucht eine „Watchdog“-Schaltung erst einen Soft-Restart und wenn das nicht funktioniert (GPIO zuckt, Abfrage über I2C …), macht er einen „hard reset“ durch Power-off/Power-on cycle.
Bevor hier Menschen jubeln: das mit dem Watchdog hab ich bislang noch nicht ausprobiert, weil ich’s nicht brauche derzeit, Papier ist ja bekanntlich geduldig…

Wie sich herausstellte, sind nicht alle Features, die beworben wurden, vorhanden (RTC lief erst mal gar nicht und lies sich nicht per Software einfach stellen. Musste über I2C erstmal gefunden und „in Betrieb“ gesetzt werden… lag aber vermutlich daran, dass mein „PiS3“ wohl länger im Regal lag… aber das war keine einfach Hürde). Gut, nette Spielerei, da TeslaUSB die eigene „FakeRTC“ justiert, sobald der Internet hat und die Dateien übertragen kann, hätte ich es nicht gebraucht.

Aber Donnerwetter, das Runterfahren bei einem bestimmten Akkustand klappte prima: bei 30% Akkustand für der Pi0 geregelt runter. Das klappte eigentlich schon zu gut…
Wenn man gleichzeitig bei „On (external) Power restart“ eingeschaltet hat, ratet mal, was passiert, wenn der Akku dann immer noch 30% oder weniger hat: genau, er schaltet sofort wieder aus.
Der Mikrokontroller merkt das und sagt, „Neustart weil Power da“ und startet erneut.
Man hat also das eine Problem beseitigt und ein Neues geschafften.

Zudem zeigte sich, dass das Frontend zum Power-Manager zwar so aussah, wie beim PiS2 und leider auch genau so oft „hängen blieb“, also komplett einfror und hurra, zum Zombi-Prozess wurde!

Was tun?
Da war ja etwas Software dabei, der Power-Manager, mit dem man so sachen machen konnte, wie:

Akku-Stand abfragen
Akku Stromversorgung kappen
Power-Manager stoppen/neu starten
Prüfen ob am USB-C externe Stromversorgung hängt
Zombie-Prozesse erzeugen

Also habe ich im TeslaUSB bin/archiveloop die Stelle gesucht, wo er auf Verbindung mit WiFi wartet und dann das Archiv erreichbar ist bzw. darauf wartet, dass das Archiv (und damit die die WiFi Verbindung) wieder weg ist (das sind quasi 2 stabile „Kipppunkte“). Diese beiden Stellen sind quasi synonym mit "bin im Auto und irgendwas externe Stromversorgung an oder aus und habe Zugriff zum Archif oder auch keinen.
Wichtig ist halt:

bleibe an, solange externe Power da ist
wenn externe Power da ist, dann lade
bleibe aber an, auch wenn keine externe Power da ist und laufe auf Akku (ja, das ist der Punkt an dem wir Zugriff zum Archiv haben und die Daten übertragen…).
gehe aus, nachdem alle Daten übertragen wurden und keine externe Power mehr da ist (das ist der Punkt, an dem wir warten, dass das Archiv „weggeht“)

An den Stellen „wait_for_archive_to_be_unreachable“ und „wait_for_archive_to_be_reachable“ prüfte ich nun, ob ich noch externe Stromzufuhr habe (dank der etwas staksigen Konsolenbefehle des Power-Managers). Leider scheinen in dem Code einige Bugs zu sein, die einen stabilen Betrieb nicht ermöglichen (oder ich mache da grundlegend was verkehrt… keine Ahnung… wenn’s jemand weiß, schreibt mir!).

Das Ergebnis ist recht stabil:

der TeslaUSB bleibt so lange an, bis alle Dateien übertragen sind
(bei vollem Akku darf das dann auch mal 1-2h dauern, das geht locker!)
wenn WiFi da: schickt per Telegram „fange mit Archivierung an“
wenn Archivierung fertig: schickt per Telegram „fertig“ mit Übertragung
(regulär das Ende Archivierung)
wenn kein externe Stromversorgung anliegt: schickt per Telegram „kein externer Strom da“
kappt dann einige Sekunden später rigoros die Stromversorgung vom Akku (genau dafür ist der TeslaUSB ja ausgelegt).
sollte während der Verbindung mit dem Archiv der Tesla die USB-Stecker stromlos machen, läuft der Pi0 so lange weiter, bis er mit der Archivierung fertig ist (oder einen Akkustand von 30% erreicht hat).

Getestet im Model3 auf 10m Sichtkontakt vorm Haus mit ca. 1-2MBit Datendurchsatz (was erstaunlich ist, da der Pi0 2W in der Mittelkonsole liegt und nur im 2,4GHz Band werkelt!)

PiSugar3 Bilder

Pi0 von Stirnseite mit passivem Geekworm-Kühlkörper,
der mit längeren M2 Schrauben dann den PiS3 mit verschraubt:

So sieht das von „unten“ aus: Der Akkupack des PiS3
(man sieht schön die goldenen Pogo-Pins):

Pi0 einmal (von) oben: alles cool…

Bei 30°C Umgebungstemperatur:
36,5°C Idle (max 42°C nach 4h Laufzeit auf Akku und
Datenübertragung per WiFi ins WLAN)

Bei Fragen, fragen.

Faxenmacher · 11. August 2022 um 09:57

sehr schön ausgearbeitet!

Du kannst die den Pi0 also an dieser Stelle gezielt runterfahren? Dann brauchst du ja gar nicht warten, bis du nur noch 30% Power hast.

Bekommst du den Event ‚nur noch 30%, ich schalte ab‘ mit? Oder kannst du den SoC pollen? Dann könntest du die notwendig Hysterese selbst schaffen, indem du den Zuckerwürfel dann auf ‚schalte bei 25% ab‘ stellst und dann per Kommando runterfährst. Dann kommt er bei ‚external power‘ mit 29 oder 30% wieder zurück und bleibt eingeschaltet. Dann pollst du den SoC bis er wieder deutlich über 30% ist und stellst dann auf 30% zurück.
Eigentlich könntest du komplett auf das automatische Abschalten bei 30% verzichten und dann nur noch selber den SoC pollen und bei 30% selbst abschalten.
Am besten wäre es, wenn der Zuckerwürfel nur im Zustand ‚no external power‘ bei 30% abschaltet.

Ich sag ja, USVen lösen Probleme, die wir ohne sie gar nicht hätten

Gruß vom Faxenmacher!

anon35000762 · 11. August 2022 um 11:48

Guude wie!

Genau das ist die Aussage und genau das war das Ziel, was es umzusetzen galt.
Ich schalte ab, wenn ich fertig bin mit Archiv syncen, oder, wenn das Archiv nicht erreichbar ist, einige sec nachdem power auf dem USB-C (Fahrzeug) abgeschaltet wurde.

Aktuell ist der Akkustand uninteressant für mich. Erreicht der Akku 30% (oder weniger…), aus welchem Grund auch immer, fährt der Pi0 runter. 30% sollte im Winter genug Reserve sein, damit der LiPo keinen Schaden nimmt.

Ich kann den PiS3 Akku-SoC in % über command line pollen, ja, das geht.

Disclaimer...*

Das Event kann ich statt des Shutdown durch ein beliebiges Kommando auf der command-line ersetzen z.B. eine „Semaphore“ schreiben: „batt_low_event“.
Das könnte ich auswerten und als Erweiterung der Modifikation noch dazu-coden, so dass (nur bei Akkubetrieb) die 30% nicht unterschritten werden.

Das ist dann etwas „durch die Brust ins Auge“, aber ließe mir die Kontrolle noch „Diess und Dass“ zu tun, bevor ich denn geregelt den Shutdown vornehme.

Aber ja, ich sollte generell shutdown in einen halt-modus machen und dann erst den Akku abklemmen! Dadurch erspare ich mir den fsck beim booten und der Pi0 ist schneller oben.
Da geht noch was!

Gute Idee!

Mich hat das halt extrem gewurmt, dass da „nix Gescheites nicht“ auf dem Markt ist an USV und die Versprechen bei den verkauften Produkten nicht eingehalten werden.
Jetzt hab’ ich ne Lösung die funktioniert, ohne mir groß einen Kopf machen zu müssen.

Kurze Kabel und Gehäuse für die „Gesamtlösung“ kommt die Tage per Post bzw. „frisch aus dem Drucker“, dann bemühe ich mich mal schöne Bilder zu machen und auch aus dem Auto ein paar Aufnahmen zu posten.

Stay tuned!**

*= Don’t Panic!
**= und vergesst Euer Handtuch nicht!

anon35000762 · 13. August 2022 um 13:49

Nachschlag:
Die neuen, kurzen Kabel sind da (je 15cm, einmal USB-C - USB-A und einmal USB-micro - USB-A), das ist Grund genug mal ausgiebig zu testen und letzten Schliff an der Software zu machen.

Bilder - eigentlich nur die neuen Kabel und warum ein Blick durch die FLiR-Kamera manchmal Sinn macht

Schick! Neue kurze Kabel

Von unten: PiSugar Akku:
Das „Bügeleisen-Kabel“ ist am Pi0 in der Daten-Micro-USB-Buchse:

Von oben: Geekworm passiv-Kühler:
Irgendwie ist das USB-C Kabel wärmer, als ich es erwarten würde…

viel Strom und viel Hitze an der falschen Stelle
Aha, das ist der Grund: Stecker wird heiß, bei einem Kabel für 4,95€ sollte das nicht passieren
So nicht, das Kabel geht zurück!

Der Stecker ließ sich mit meinem „Schätzeisen“ nicht richtig messen, da zu klein (diese „Pistole“ misst in diesem Abstand einen Ausschnitt mit ca. 2cm Größe und mittelt darüber die Temperatur; deswegen war es sinnvoller, den Kühlkörper zu messen und dann in Korrelation dazu über die Skala zu schätzen, um wieviel heißer der Stecker sein könnte… irgendwas um 47°C )

Warum ich von kritischen Teile meistens 2 Stück bestelle
Warum nicht gleich so:

(Raumtemperatur: 28.2°C; Pi0 den ganzen Tag durchgelaufen, Akku wird jetzt geladen;
Kühlkörper-Temperatur: 43,1°C
CPU-Core: 46,394°C (cat /sys/class/thermal/thermal_zone0/temp)

TL;DR - PiSugar-Software Mist; bash Test kann nur integer; Telegram-Bot; Ich will aber das Datum vorne!; mein Gott, der Akku! Disclaimer: Der Text ist lang und sehr Code-lastig..., ich hatte gewarnt!

Direkt der Hammer am Anfang: die PiSugar-Server Software ist extrem großer Mist!
Ich werde nochmals beim Hersteller nachhaken, aber ich erhoffe mir da keine großen Erknenntnissse oder Verbesserungsaktionen. Das erklärt auch das „Bastel-Gefühl“, was mich die ganze Zeit begleitet. Entweder mache ich extrem was falsch beim Aufruf der Anwendung über nc (ich lausche und send mit netcat auf einem lokalen Socket, der eigents dafür „hingestellt“ wird vom PiSugar-Server und der eigentlich stabil laufen sollte, wenn man commandos über netcat schickt).
So hab ich eigentlich mehr aus jux und Dollerei ein Logging in den TeslaUSB eingebaut, wie oft mir diese Schnittstelle zum Pi-Sugar-Server abschmiert.

Was red’ ich: seht selbst: Während der TeslaUSB wirklich nur idled und ich in der Zeit auch nichts am Rechner gemacht habe oder gar per SSH eingeloggt gewesen wäre: der chrashed spätestens alle 5 Minuten ab, manchmal sogar mehr als 3 mal pro Minute…

Also war das schon sinnvoll, ein function zu schreiben, die darauf achtet, dass die Schnittstelle zum PiSugar oben ist. (Warum der chrashed: Weiß ich ned. Dazu muss ich erst lernen, wie man debuggen kann. Und dann ist der Quellcode auch noch in Rust, kann ich auch ned…).

Als „Beifang“ kann ich dadurch zuverlässig nachlesen, mit welchem Akkustand der PiSugar gestartet ist:

Ach ja, ich sprach davon, ich könne mir den Filesystem-Check (fsck) beim Booten sparen: nein, kann ich mir nicht… ich hatte „Shutdowns“, die verunglückt sind. Weil der Archive-Loop grade mit irgendwas länger beschäftigt war und dann der PiSugar in den Shutdown über den Akku-Stand reinlief… passiert eher selten, wenn der Akku vom PiSugar halt nicht wirklich geladen war, aber das kann im Winter mal schnell passieren…
Außerdem weiß ich jetzt, dass der Pi0 mit dem PiSugar3 etwa 5h45min läuft, wenn der Akku zu 100% geladen war und der Pi0 er größtenteils idled.

**Telegram-Bot: **
Neuland. Ich fasse mich kurz:

Bot kann an EINE Chat-ID was schicken, also entweder an mich, oder meine Freundin. Nicht gleichzeitig an beide. Uff. Dazu muss man mit einem (anderen) Bot die Chat-ID ermitteln
Ah, private Chatgruppe einrichten, Chat-ID von dieser Gruppe ermitteln, das so konfigurieren.
Apropos konfigurieren: nein, dazu braucht man den TeslaUSB nicht neu installieren. Es richt, wenn man sich mit sudo -i unter /root/ mit „bin/remountfs_rw“ das Dateisystem beschreibbar macht und dann für Telegram z.B. die gewünschten Parameter einträgt. (Es gibt aber Vorgänge, dafür müsste man in /boot/teslausb_setup_variables.conf Änderungen machen, die dann mit setup-teslausb in andere config-Dateien geschrieben werden.

Das hier mehrfach erwähnte „setup-teslausb -selfupdate“ updated, wie man vermuten könnte, übrigens nur den updater selbst. (Zumindest wenn ich nach dem Code dazu gehe… ):

function cmd_selfupdate {
  setup_progress "WARNING: $BRANCHNAME contains a different version of $0. It is recommended to run '$0 selfupdate' to update to that version"

So, die Nachrichten, die ins Archiveloop-Log geschrieben werden, lassen sich auch auf Telegram schreiben. Allerdings hab ich momentant zurückgeschraubt und nur 2 zusätliche Messages aktiv, nämlich Grund des Abschaltens: batt_low oder no_ext_power…

Aber bis ich bei folgendem Bild angelangte, hat’s mir ganz schön ge-„bash“-ed…
Gegeben: nur zsh oder ksh können im test-command mit decimal rechnen.
alles kein Problem, solange ich am Testen war und der Akkustand immer 100% war.
Irgendwann war er dann mal 66.35312… und Archiveloop schmierte dann ab…

if [ ${batt_level} -gt 0 ] && [ ${batt_level} -lt ${batt_level_low_limit} ]

grafik

Spoiler: ja, ich habe die Ausgabe nochmal korrigiert, denn wie im Telegram-Message Screenshot gezeigt ist ein „bat_low“ eine niedrig fliegende Fledermaus… und dabei auch noch einmal die Darstellung mit Akkustand bei beiden Texten ans Ende gestellt.
</Dad_Jokes>

Ich hab’ bei den Bildern mit dem glühenden Stecker festgestellt, dass der PiSugar auch mit 3A lädt. Naiv wie ich bin hatte ich den leeren Akku mit Pi0 an ein Netzteil für den Pi4 gehängt („Das hat bestimmt genügend Saft…“) und mir war nicht klar, dass man da seitens der „Frickelbude“ für den PiSugar da nicht den Strom limitierte (Da meinte wohl jemand „USB-A kann doch nur 500mA…“) hm ja. Wenn der Ladestand pro Sekunde dann 2% hochgeht, spätestens DANN hat man Fragen…

Das ist übrigens auch u.A. der Grund, warum das Ganze noch nicht ins Auto verbaut ist.
Gehäuse fehlt und das mit dem Laden muss ich nochmal mit Messgerät dazwischen messen, wie hoch der Strom in den Akku tatsächlich ist. Auch ist mir sehr suspekt, dass das Frontend dauern „Charging“ anzeigt, obwohl der Akku laut Anzeige bei 100% ist.
Was mich halt auch fuchst: die Akku-Schon-Funktion, die, je nach Nutzung, nur bis 60-80% lädt (hä, warum weiß man das nicht genau? Ok, kein Culomb-Meter, klar, dann kann man halt nur schätzen.)

Also nach Alledem hab’ ich ca. 150,-€ mit allen Fehlschlägen und Pi0 inklusive ausgegeben, bin nicht sicher, ob das „sicher genug“ ist (wird wohl ne zeitlang gut gehen… und was ist, wenn der Akku des PiSugar anfängt zu brennen in der Mittelkonsole… ) und dann die etlichen Stunden…
Warum gibt es nach so langer Zeit anscheinend noch immer keine vernünftige USV-Lösung für den Raspi???

Edit: Schreibfehler, die mir aufgefallen sind, noch korrigiert.
Bin nicht so fit heute.

Gebt mir Feedback, ob das zu viel Einzelheiten oder zuviel Geschwätz war.
So, Wochenende!
Euch ebenfalls ein Schönes! *

*= Wochenende natürlich. Weil Handtuch habt ihr doch eh alle schon…

Faxenmacher · 15. August 2022 um 10:00

Da hast du aber mal 'n Meisterstück hingelegt & danke für den Bericht.
Kohle? Egal.
Zeit? Egal.
Lernfaktor? 100%!
Love & peace & happiness? 100%!!

Gruß vom Faxenmacher!

anon35000762 · 15. August 2022 um 11:23

Ich muss mal dem @Faxenmacher speziell danken, dass er das alles durchliest:
Danke für’s Feedback!

Naja, ich bekomme hoffentlich jetzt bald endlich eine Wallbox und WiFi in die Garage und da möchte ich schon wissen, ob die Lösung jetzt geht oder nicht… (nach 4x Umziehen und hier jetzt mehr als 2 Jahre warten…)

Noch 2 Korrekturen muss ich allerdings machen, ich war am Wochenende zu ungeduldig:

der PiSugar-Server ist doch besser, als ich ihn dargestellt hab: er stürzt nämlich nicht so oft ab, wie ich es dargestellt hab… es passiert halt, dass der Pi0 etwas ausgelastet ist, wenn der Archiveloop parallel mehrere Aktionen im Hintergrund laufen hat
durch unsauberes Testen habe ich immer nur die Situation getestet, wenn WiFi und damit Internet vorhanden ist. Wenn man dann an Telegram eine Nachricht schicken will, wenn KEIN WiFi da ist (eigentlich zu 99% der Fall, wenn das Fahrzeug bewegt wird), stürzen die „selbstgebackenen Aufrufe von Telegram“ ab und der Archiveloop läuft gar nicht mehr…

Edit: Ach, es gab auch was Schönes!
Ganz vergessen: Durch den USB-Port-Replikator laufen 2 separate Stromquellen (die 2 USB-Buchsen sind 2 separate Stromquellen im Model3 pre-FL (keine Ahnung, aber ich nehme stark an, beim FL ist es das Gleiche).
Dadurch kann ich die 2 benötigten Stecker „unverklebt“ lassen (das Datenkabel, was an den Pi0 geht hätte ich den +Pol sonst abkleben müssen, da es sonst die in einem weiter oben liegen Post abeschriebenen Fehler gibt).

Lernkurve grad bei:

Gadget Mode über USB unter Windows 11 hinbekommen
Wo muss nochmal die config für den Raspi hin ( /etc/network/interfaces )
Gah, wieso wird das modul g_ether entladen? (im archiveloop… weil es sonst knallt mit den virtuellen Laufwerken für Music und TeslaCam)
→ (fast) alles zu Gadget-Mode hier… lick (macht ihr eh nicht… )

Klar, dass unter Windows 10/11 der RNDIS-Treiber fehlt (gibt es hier → Acer USB Ethernet/RNDIS Gadget für Windows7 usw. 21kb; taugt für Windows10 und Windows 11 genauso).

So, diesse Woche dann wohl am Laptop testen, wie das Ganze läuft, wenn KEIN WiFi Empfang möglich ist…

Teufel, Eichhörnchen, Handtuch
Hurz! *

*= guten Start in die Woche!

Mittelhesse · 15. August 2022 um 14:16

und wenn alles läuft machst du dann die Änderungen direkt für die Marcone release?

anon35000762 · 15. August 2022 um 16:07

Du wirst lachen, PiSugar hat auch ein repository auf GitHub.

Dann brauche ich aber Eure Hilfe… ich bin kein Profi in Sachen Linux / dev / Raspi, hab’ selbst damit for 12 Wochen erst angefangen und frage mich die Ganze Zeit, „Himmel, warum gibt es denn weder für TL noch TUSB eine bullseye mit 64-bit OS?“).

80% von meinen „Verbesserungen“ wird wohl wegfallen, aber auf die 20%, die dann übrig bleiben, bin ich gespannt.

Es gibt übrigens auch eine PiSugar3 Plus, der mit 5000mAh Akku ausgestattet ist und dem Pi4B laufen soll. Aber erst einmal muss es auch auf dem Pi0 laufen…

Bilder vom Einbau im Auto komen dann, wenn das Gehäuse drum ist. Das ist am WE fertig geworden, ich muss es nur noch abholen…

anon35000762 · 25. August 2022 um 10:53

So, ganz kurz mal die Foddos loswerden mit dem Gehäuse und wie die finale Lösung aussieht…

Heute hätte ja die Wallbox montiert werden sollen, aber nach 16 Monaten seit Beantragung war in den letzten 14 Tage trotz Anwalt erst mal keine Entscheidung des Eigentümers der in 2020 fertiggestellten Wohnanlage zu bekommen, was montieren zu dürfen, dann also hier erst einmal Bilder ohne „Meßdaten“ zur Übertragung…

Gehäuse stammt von der Pisugar Seite auf GitHub und wurde in der Höhe (+2mm und +3m) verlängert für zusätzliche Haltemagnete und mehr „Headroom“ auf der Pi0 Seite, wegen des Kühlkörpers, damit Konvektion entstehen kann)

Vorsicht! Kritische Infrastruktur! Nicht Hacken!

.

TeslaUSB mit PiSugar3 1200mAh im Gehäuse:

Hier die Seite mit dem PiSuger3 noch offen (Deckel komt gleich drauf):
Die drei „Rundstücke“ sind Neodym-Magnete, die es mal bei Penny zu 20 Stück gab, im Akku des PiSugar3 ist ein Stück Blech, da halten die prima und werden beim Aufsetzen des Deckels press an jenen gedrückt (ohne dass er aufpoppt; musste dazu das 3D-Druckmodel um 2mm „verlängern“ lassen)

.

Hier die Seite mit dem Pi0 noch offen (Deckel komt gleich drauf):
Auch hier wurde das Gehäuse um 3mm verlängert, damit der KüKö de Pi0 eine Konvektion zur besseren Wärmeabgabe nutzen kann

.

So sieht das dann mit Deckel aus von der Seite gesehen, die später „unten“ liegt:

.

… einmal Kabel bitte (1x Strom über USB-C auf PiSugar, einmal Daten über Micro-USB am Pi0:

.
Es sind die kurzen Kabel von neulich:
Man sieht hier noch Tesafilm, den ich rundum geklebt habe, damit die Deckel nicht aufpoppen. Ist etwas, was ich mir anders vorgestellt hätte. Verschraubungen mit versenkten Schrauben wäre halt nett gewesen…

.

Man kann im Hellen das Blinken der LED nur durch die Öffnung für den Micro-USB-Port sehen:

.

Im „Dunkel“ der vorderen Mittelkonsole kann man aber schön die LEDs vo Pi0 und vom PiSugar3 sehen. Der USB-Hub trennt übrigens die beiden „Eingänge“, die vom Fahrzeug kommen (2x USB-A (oben, links) laufen „links“ vom Auto, 1x USB-A (oben, mitte), 1x USB-A (unten, rechts im SSD-Schacht) und 2x USB-C (oben, rechts) laufen „rechts“).

Man sollte die Kabel so stecken, dass die Stromquellen sich nicht über den Hub (oder den angeschlossenen Geräten) „sehen“ können (Strom „fließt quer“ vom Pi0 zum Eingang des PiSugar). Damit spart man sich das Abkleben von den Stromkontakt(en) im USB-A-Stecker an der Datenleitung des Pi0.
Somit zieht der PiSugar3 oben links Power über USB-A und der Pi0 hängt an Daten und Strom über USB-A unten und schickt dort auch seinen Daten. Mein QI-Charger-Pad muss ferner so gesteckt sein, dass es nur die Buchsen des zum „rechten Fahrzeug-Port“ gehörigen Hub nutzt. Wenn nicht, wenn also QI einmal linken, einmal rechten Hub-Strang nutzt, steht am PiSugar Spannung über das QI-Pad an vom Pi0 stammend. Dann schaltet der PiSugar nicht ab, weil er nicht erkennt, dass am Hub selbst keine Spannung mehr ist (da er an seinem eigenen Eingang die Spannung seines eigenen Akkus sieht).

.

Damit kann ich erstmal leben!
Achso, das Gehäuse ist mit den Magneten, die innliegend sitzen am „Blech“ des Hubs (und einem Magneten im Inneren des Hubs) gehalten.

Slatfatf! *

*= Die Delfine bedanken sich!

Mane123 · 16. September 2022 um 09:34

Mal eine kurze Frage: Wenn ich einen Raspi einfach direkt anstecke, ohne Akku dazwischen, kann ich aus der Software irgendwie (am besten per REST API) auslesen, ob alles fertig übertragen ist? Damit ich das Auto so lange wach halten kann, wie strom nötig ist.

anon35000762 · 16. September 2022 um 10:54

Das war ursprünglich mal so implementiert, ist aber wirkungslos, seit Tesla die API umgestellt hat.
Ein Update hat es m.W. seither nicht gegeben.
Spuren davon findest du noch im config file

Mane123 · 16. September 2022 um 10:55

Ich könnte das auch selbst bei mir lokal laufen, also muss nicht automatisiert sein, ich möchte eigtl nur den Zustand sehen, ob er fertig ist, oder nicht.

anon35000762 · 16. September 2022 um 11:03

Unter /root/bin/ liegt archiveloop. Da schau mal rein.
Das script sourced auch log-Routinen und schreib Stati weg.

Tipp: schau mal unter archive_Clips und copy_music_files…

Ich wüsste aber nicht, wie du den Wagen zwingen möchtest, online zu bleiben ohne Zugriff über die (Tesla) API. Wen du DAS lösen würdest und Forken könntest in eine neue Version, alle wären dir dankbar!

anon35000762 · 16. September 2022 um 11:07

Ach Moment… benutzt du keinen Bot zum versenden von messages? Das kann man doch für verschiedene Plattformen wie Telegram, discord, IFTTT, web_hook konfigurieren …

Und klar, dann kann man einstellen, dass er bei Beginn und bei Ende Archivierung ein Ei legt.

Mane123 · 16. September 2022 um 11:18

Ich hab mich grundsätzlich noch nicht all zu sehr mit dem Thema hier auseinander gesetzt. Ich würde es bei mir aber über TeslaMate lösen, das habe ich daheim als Logger laufen und auch eine Software zum PV geführten Laden dafür geschrieben. Würde es dann eigentlich entweder da, oder in einem separaten Dienst (in Docker laufend) implementieren. Aber dazu muss ich halt eben wissen, ob Teslausb grad was überträgt oder nicht