Fingers elektrische Welt

Diagonal verzerrt

Sieht das so aus wie auf der Deppenlampe ohne Zeilensynchronisation?
Dann tippe ich auf falsche Anzahl Pixel in X-Richtung. Das kann durchaus zu leeren Bildern führen, es ist aber nicht auszuschließen daß die Y-Größe dann auch nicht stimmt.

Ich hab mal eines meiner Testbilder angehängt.
Die Pixelmaße sind 296x146
Mit dem alten Script gehts, mit dem neuen nicht.
Auch eine abschneiden von jeweils 10 Pixel in Länge und Breite bringt leider keine Besserung.

Nachtrag:

wenn ich in den /tmp Ordner schaue, stelle ich fest, das die Bilder nicht korrekt konvertiert werden. TempConvert.bmp lässt sich meist noch mit einem Bildbetrachter anzeigen. Die anderen erzeugten Bilder die "000002838CCA3B12_7176246181206894028.bmp" oder ähnlich heißen lassen sich nicht öffnen. Die mit der alten Station.py erzeugten Bilder "7176216331184172200.bmp" hingegen schon.

Mal eine grundlegende Frage... ich überlege grade wie ich das Ding möglichst einfach & energiesparend dauerhaft betreibe.
Ich habe hier keinen extra Router, Pi o.ä. der "ohnehin immer läuft" und den ich als Server nutzen könnte. Alle meine Geräte (Desktop, Laptop) schalte ich bei Nichtgebrauch aus oder in den Ruhemodus.
Ich würde gerne vermeiden, extra einen Pi o.ä. hinzustellen, der dann 24/7 die nächsten Jahre nur dafür durchläuft und rund um die Uhr 3-5 Watt schlürft.
Also, was nimmt man als minimalistische Plattform? "alles selber entwerfen und bauen" scheidet aus.
Idealerweise sollte das Ding Zigbee (natürlich) können, und Ethernet und/oder Wifi (vermutlich ersteres stromsparender), und man sollte selber einfache eigene Programme drauf starten können (Programmiersprache egal. Meinetwegen auch nur Shell und compiliertes C.).

Die bilder werden in 296x128 erwartet und müssen auch so vorliegen

T5000 hat geschrieben: ↑Mo 12. Dez 2022, 13:58 Die Pixelmaße sind 296x146

Und zum nachtrag, durch das ROT in den Bildern werden sie in ein altes BMP format konvertiert was so gut wie keine software mehr unterstützt, die firmware im display aber schon.

@berferd

Du könntest eine Station auch nur für ca. 20 Minuten starten um die Displays upzudaten und den rest des Tages aus. Die Displays suchen alle 15 Minuten nach der Station.

Es gibt auch eine ESP32 Station, dadurch läuft alles auf diesem.

Als Zigbee transceiver wird eine Display Platine genommen und mit einer eigenen firmware als Access Point genutzt, diese flasht der ESP32 selber

Die software funktioniert ist aber noch im beta status.

Das Repo ist hier:
https://github.com/jjwbruijn/ESP32-epaper-station

An dem Energieverbrauch denk ich auch grad rum. Muss grad primär eine Wohnung neu beleuchten und da wird wohl zigbee zum Einsatz kommen. Esp32 kann das auch, wenn man sich also als gateway nen esp hernimmt, passt das da vllt grad auch noch drauf.

Wenn man die Informationsbeschaffung der Displays irgendwie extern takten könnte, kann der Esp in der Zwischenzeit auch aus sein. Alle gleichzeitig anschalten führt nach längerer Betriebszeit bestimmt zu Phasenverschiebungen und damit Ausfällen.

Fritzboxen können ja nebenher teils auch schon smart Kram, leider nur sehr eingeschränkt und selber sachen dazupatchen ist eher nicht, oder gibts Freetz noch? Router mit OpenWRT?

Mein Plan ist, ein 2x3 Displaymatrix auf dem ich meine Daten darstelle.
Die Display kann man parallel an einen Akku klemmen und über eine ttl- Daisychain hintereinander schalten und mit einem nem ESP32 mit Daten füttern.
Die Funkdaten laufen dann nur über den ESP.
Wlan halt dann.

Danke für den Tipp mit der richtigen Auflösung, ich weis auch nicht mehr wo ich meine falschen Werte her hatte.
Display1 : altes station.py Script - Bild in Graustufen ohne rot im PNG
Display2 : neues station.py Script - gleiches Bild wie Display1 -> die Graustufen fehlen, Mario hat keine Hände usw
Display3 : neues station.py Script - Bild mit rot im PNG

Die Graustufen fehlen halt im neuen Script. Wird sicherlich an dem ungewöhnlichen BMP Format liegen.
Ideal wäre natürlich, wenn das Script erkennt, das es ein Graustufen PNG ist und es dann in das modernere BMP wandelt.

Ich bin erstmal froh, das ich überhaupt soweit gekommen bin, inkl. C2531 Flashen usw.

Diese Ständer kann man für die Displays wunderbar zweckentfremden: https://www.thingiverse.com/thing:5422488

Mhhhhahprprhrhprrr

Was genau möchtest du uns denn mit diesem Post sagen?
Bitte schreibe doch einen vollständigen Satz in einer Sprache, welche wir lesen können.

Es wird eindeutig die Änderungsrate der eingespeisten Leistung in Kilowatt pro Stunde angezeigt...

Kontext Mädels!
Es geht um die ausgefransten Buchstaben durch Subpixelrendering umgemappt auf 1bit Graustufen Epaper und die immernoch fehlende Lösung dazu.

Aber gab es nicht früher (tm) Schriften extra für den Bildschirm? Da war doch das gleiche Problem, bis die grafischen OS die Druckerschriften entsprechend rendern konnten.

Evtl wäre das ein Ansatzpunkt?

Die Adafruit Grafikbibliotheken haben soweit mir dünkt auch spezielle Schriften für die kleinen Grafik Panels.

Ich hab was in Python gebastelt mit Skalierung und min/Max.
Klappt leider noch nicht 100 bei negativen Zahlen kackts ab

Ich bin ja in meinem Gesamten System auf der Variante ESP32-gateway-Station. Die Sendezeit ist ja durchaus begrenzt, wenn man den Äther nicht verstopft haben will.
Mich stört es etwas, immer die pixelgrafik zu übertragen, auch wenn komprimiert, hat man da doch erheblich mehr daten, als wenn man Schrift und grafik auf dem Display rechnet. Selbst mit 1MHz kerntakt dürfte das fixer gehen als das rüberschieben der grafik.


Ich denke erstmal effizienzverliebt an Protobuf-codierte Zeichenbefehle. 1 byte Typ und Farbe, 2 Byte Position und Größe, dann ggf für Text oder Kurven noch ein Datenstring Fällt da jemandem noch etwas ein, was besser für differentielle screen-updates geht?

So, nun
Hier 6 Display uarts in Reihe an einem ESP32

Der holt sich die Daten direkt aus der InfluxDB und geht dann schlafen, nachdem er den Strom für die Displays aus gemacht hat.

Hat jemand zufällig einige Adapterplatinen (so wie hier beschrieben https://www.pcbway.com/project/sharepro ... a845c.html) über?
Dann muss ich nicht extra nur für meine 5 Stück welche fertigen lassen....

Flip hat geschrieben: ↑Fr 30. Dez 2022, 21:45 Ich bin ja in meinem Gesamten System auf der Variante ESP32-gateway-Station. Die Sendezeit ist ja durchaus begrenzt, wenn man den Äther nicht verstopft haben will.
Mich stört es etwas, immer die pixelgrafik zu übertragen, auch wenn komprimiert, hat man da doch erheblich mehr daten, als wenn man Schrift und grafik auf dem Display rechnet. Selbst mit 1MHz kerntakt dürfte das fixer gehen als das rüberschieben der grafik.


Ich denke erstmal effizienzverliebt an Protobuf-codierte Zeichenbefehle. 1 byte Typ und Farbe, 2 Byte Position und Größe, dann ggf für Text oder Kurven noch ein Datenstring Fällt da jemandem noch etwas ein, was besser für differentielle screen-updates geht?

Es wäre ja schon viel gewonnen, wenn nicht dieses dusselige unkomprimierte BMP-Format benutzt würde. Das sind auch für ein komplett einfarbiges Schild aktuell 9542 Byte. Als GIF sind das meist deutlich weniger Byte, bei meinen Wetterbildern etwa 2200, als PNG noch darunter 1800 Byte. Ein einfarbiges Bild sind als PNG nur noch 159 Byte.

Eine komprimierung ist in arbeit

Bei den großen ist nun Gzip implementiert und funktioniert sehr gut. Leider haben die ZBS243 aber zu wenig RAM um das dort zu implementieren.
https://youtu.be/kPy8rIQ75NU

Ich bin jetzt nicht der Spezialist in Bilddatenformaten, aber ich war bei der Prüfung der Kinderschuhe der elektronischen Bildverarbeitung mit dabei. Viele der heute völlig unnötig mitgeschleppten Begleitdaten fressen bei so kleinen Bildern den Gewinn auf.

Da sollte man wirklch mal die Statis-Tiger dranlassen, sehr wahrscheinlich bringt eine primitivste Lauflängencodierung die höchste Ersparnis, natürlich abhängig vom Bildinhalt - ein unregelmäßiges Raster ist die Höchststrafe.
Ich hab eben geschwind mit IrfanView eine aus dem Leben gegriffene SW-Grafik (296 x 128 Pixel, bmp: 5182 Bytes) durchprobiert, da hat (tif) CCITT Fax 4 mit 1416 Bytes gegenüber allen anderen Algorithmen die Nase weit vorn. png belegt mit 2120 Bytes den zweiten Platz und huffmann kommt noch vor gif. Alle weiter oben gesehenen Musterdisplays lassen sich natürlich viel effektiver komprimieren, für Wetterbilder dürfte Fax 4 der Spitzenreiter sein.

Ein einzelner Pixel in der Bildmitte wird in (tif) CCITT Fax 4 mit ganzen 254 Bytes dargestellt, Fax3: 666, huffmann 510, gif 295, png kommt auf Platz 1 mit 144 Bytes.

Bei der Gelegenheit (habt Ihr im IrfanView schonmal die Taste [F3] benutzt?) fällt auf daß die populären Formate natürlich auch Format, teilweise Größe (dpi) und nicht zuletzt den Namen des Kompressionsbeauftragten beinhalten, das brauchen wir hier alles nicht.

Wenn RLE auch am einfachsten zu implementieren wäre macht es leider zu schnell keinen sinn mehr da die Daten zu groß werden.

CCITT T.4 ist derzeit der Favorit noch etwas vor .png um es als System umgreifende Komprimierung zu nutzen.

Hat noch Jemand das Problem, dass einzelne Displays Ihre Batterien innerhalb von 14 Tagen leersaugen? Hängen alle an der gleichen Basis mit dem gleichen Updateintervall. Manche ziehen neue Batterien innerhalb von 14 Tagen leer, manche nicht.

Ich glaube da gibt es einen Bug, das Display hängt sich auf und macht die Batterie platt.

Hab ich auch schon beobachtet.

Hightech hat geschrieben: ↑Fr 13. Jan 2023, 18:44 Ich glaube da gibt es einen Bug, das Display hängt sich auf und macht die Batterie platt.

Hab ich auch schon beobachtet.

Ein Bug in der Firmware der Schilder würde das erklären. Dann wird vermutlich der RF-Kram nicht abgeschaltet. Der RF-Kram braucht Unmengen an Strom (>30mA), der Rest nicht.

Ich habe auch beobachtet daß ein Schild oft stundenlang keine neue Anzeige schaltet, obwohl diese bereit steht. Im Log habe ich gefunden, daß diese Schilder oft bei jedem Update die Datei bekommen, inzwischen läuft das im Debug hier und ich warte aufs Auftreten. Dann kann ich sehen ob der letzte Teil des Bildes auch ausgeliefert wird.

Am Uart des Display kommen Meldungen, die mal mitschreiben und an ATC1441 schicken.
Manche Schilder stellen sich tot, nach dem Flashen tun die aber wieder.

Hightech hat geschrieben: ↑Fr 13. Jan 2023, 20:18 Am Uart des Display kommen Meldungen, die mal mitschreiben und an ATC1441 schicken.
Manche Schilder stellen sich tot, nach dem Flashen tun die aber wieder.

So arg hatte ich das noch nicht. Bisher waren die nur mal stundenweise taub. Und nach irgendwelcher Zeit leer, nach Batterietausch gingen sie wieder. Ich lese auch an den Dingern nichts mit, ich schneide nur an der "Station" das log mit.

Falls noch jemand die Displays direkt mit einem EPS o.Ä. ansteuern will sind hier die Kontakte auf der Platine. musste ich auch nur machen weil ich beim flashen der neuen firmware drei controller zerstört habe

GIbts eigentlich einen Weg, die TIMAC-FW irgendwo einfach als Binärdaten zu bekommen, um den CC2531 Anzeigen-kompatible umzuflashen?
Die Leute von TI haben da aber auch wirklich alle Register gezogen: persönliche Registrierung, Bestätigung via Email, und dann stellt sich raus: man darf eine EXE-Datei (!) runterladen. Nichmal eine selbstentpackende EXE, da käme man ja noch irgendwie damit zurecht mit Entpack-Werkzeugen, nein ein wirkliches Programm. Davon abgesehen dass ich kein passendes MS-System habe: ganz sicher werde ich hier einfach mal eben runtergeladene Binaries ausführen, um an ein tolles Gimmick zu kommen
GIbts da irgendwelche Alternativen, an das FW-File ranzukomnmen?

Teslafreak hat geschrieben: ↑Mi 25. Jan 2023, 21:28 Falls noch jemand die Displays direkt mit einem EPS o.Ä. ansteuern will sind hier die Kontakte auf der Platine.
pcb.jpg

Super... doofe Frage: Wie hast du denn den Chip weg bekommen?

Danke & Grüße, Mathias

Heißluft. Oder manchmal kann man auch nen dicken Lötkolben direkt auf den IC halten das er so warm wird das überall das Zinn schmilzt.

bastelheini hat geschrieben: ↑Sa 1. Apr 2023, 17:51Heißluft.

Danke, hat funktioniert ohne alles außenrum wegzupusten (da hatte ich etwas Sorgen). Mit der Chinesen 858D und ca 8mm Düse bei 370 °C

Einfach die Umgebung mit Kaptonband abdecken (oder Aluklebeband oder Kupferklebeband).

berferd hat geschrieben: ↑Sa 1. Apr 2023, 17:09 GIbts eigentlich einen Weg, die TIMAC-FW irgendwo einfach als Binärdaten zu bekommen, um den CC2531 Anzeigen-kompatible umzuflashen?
Die Leute von TI haben da aber auch wirklich alle Register gezogen: persönliche Registrierung, Bestätigung via Email, und dann stellt sich raus: man darf eine EXE-Datei (!) runterladen. Nichmal eine selbstentpackende EXE, da käme man ja noch irgendwie damit zurecht mit Entpack-Werkzeugen, nein ein wirkliches Programm. Davon abgesehen dass ich kein passendes MS-System habe: ganz sicher werde ich hier einfach mal eben runtergeladene Binaries ausführen, um an ein tolles Gimmick zu kommen
GIbts da irgendwelche Alternativen, an das FW-File ranzukomnmen?

Ja, auf Github gibt es eine Anleittung zum alternativen Flashen der FW.


https://github.com/atc1441/ZBS_Flasher/ ... 31_station
https://github.com/jmichault/flash_cc2531

Es geht wieder weiter, so langsam werden die Dinger richtig tauglich. Bisher habe ich das Wetter drauf aber mit diesem Paket wird vieles einfacher umzusetzen.
https://www.youtube.com/watch?v=Etonkolz9Bs

Was ich nicht verstanden habe, ich habe die bereits vorgeflashten bekommen, kann man denen OTA diese neue Firmware unterjubeln?

Hier mal zwei Anwendungen, die hier seit einigen Tagen zufriedenstellend laufen.

Einmal die aktuelle Tageslosung (https://www.losungen.de/ .. je ein zufällig gewählter Vers aus altem und neuem Testament), die ist am Badspiegel angebracht. Und dann noch die nächsten Müllabfuhrtermine, das Display dafür klebt am Spiegel neben der Eingangstür. Zigbee Server ist ein Raspberry Pi Zero W, mit TIMAC-Zigbee-Stick am USB-OTG-Anschluss des Pi. Der Pi wacht früh morgens einmal für 40 Minuten auf, gesteuert durch eine Witty-Pi-4-Mini-Platine (... zu den bemüht "lustigen" Modulnamen spare ich mir mal jeden Kommentar...), auf der eine Supercap-gepufferte RTC läuft, die dann dem Pi Zero zum richtigen Zeitpunkt die Versorgung freischaltet. So zieht das Ding tagsüber keinen Strom.
Der Pi zieht sich (falls es fürs aktuelle Jahr nicht schon im Cache liegt) via WLAN die entsprechenden File(s) vom Server, packt aus, parst die Daten, sucht den passenden Eintrag, rendert als PNG und verfüttert das an das epaperstation-Server-Script.

Die Fonts sind pil-Fonts (d.h. Bitmap), da alles andere auf dem 2-Zustände-Display (weiß, rot, schwarz) außerordentlich bescheiden aussieht.

Für die Losungstexte wird automatisch der größtmögliche Font gewählt, so dass der Text (variabel lang!) noch mit passendem automatischem Umbruch komplett aufs Display passt.
Für die "Müllvorhersage" sind die Fonts statisch, aber die Position der Icons (und des Begleittexts mit Terminen) wechselt natürlich, sortiert entsprechend der nächsten Termine. Termine innerhalb der nächsten 32 Stunden werden rot gerendert. Als Icon-Motto habe ich (passenderweise) "8 bit" gewählt, das sind diverse MacOS-, Atari- etc Icons die ich mir zusammengesammelt habe.

Als nächstes würde ich mich gerne an die tägliche Wettervorhersage wagen, kämpfe da aber noch mit der DWD-API.

Das Abholtermin-Display finde ich sehr gut. Gibt es den Quellcode dazu irgendwo?
Gruß
Kuddel

Kuddel hat geschrieben: ↑Mo 24. Jul 2023, 17:47 Das Abholtermin-Display finde ich sehr gut. Gibt es den Quellcode dazu irgendwo?

Danke!
Prinzipiell ja, allerdings muss ich mal gucken wegen der Icons, die sind natürlich ohne Rücksicht auf Copyright zusammenkopiert...
Wenn das halbwegs geklärt ist werde ichs mal auf mein gitlab setzen und hier verlinken.
Allerdings ist das auf die Müllabfuhr-Info-Dateien meines Wohnorts zugeschnitten ... ich vermute also, es sind umfangreiche Anpassungen beim Abrufen & Parsen der Daten notwendig.

Wenn du sagst, wie groß die Icons sind, kann ich mal bei Gelegenheit welche malen, hatte ich eh für die gleiche Anwendung vor.
Kannst dann für deine "öffentliche" Version auf Gitlab verwenden.
https://github.com/CanisVolans/Epaper-Icons hab auf die Schnelle mal meine Batterie und Signalstärke Icons schonmal in git gepackt,
vlt. findet die jemand nützlich.

Die Icons sind jeweils BxH 73x54 Pixel, wobei das so gerechnet ist dass 4 Icons nahtlos nebeneinander angezeigt werden, ohne dass der Renderer noch Zwischenraum hinzufügt. D.h. das Weiß (Abstand/Zentrierung) ist Teil der Icons. Jo, kann man eleganter lösen. Aber reicht für meine Zecke aus. D.h. am besten als 292x54 Grafik anlegen mit gleichmäßig angeordneten Icons, und das dann in 4 Bilder à 73x54 zerschneiden.

Es gibt Neuigkeiten:
https://youtu.be/8oQdo9bJ7Rk

Und hier der CC2531 link
https://github.com/jjwbruijn/OpenEPaper ... c2531_OEPL

Ja, hab schon vor einiger Zeit meine alle umgeflasht. Viel schnellerer Update und weniger Stromverbrauch.

Moment, das ist doch eine komplett neue Plattform (ESP32) ... ? Oder meinst Du nur die neue FW der Schilder?

Was mir noch etwas unklar ist: kann man die neue Display-FW auf unsere Schilder flashen, und sie laufen dann kompatibel zum bisherigen Protokoll weiter?
Oder "muss das alles neu"?
Geht da ein OTA (Over The Air) Update via epaper-station, oder muss ich über die Kontakte auf der Rückseite flashen? (da habe ich nämlich nicht die nötige HW...)

Dies ist ein komplett neues system.
https://openepaperlink.de/

Hauptsächlich ist es gedacht das ein ESP32 der Access Point ist, der übernimmt hierbei alles, von der Datenbank der Displays bis hin zu aktuellem wetter laden, rendern und mittels Zigbee interface( ein weiteres displa am AP ) zum display zu schicken.
Bilder und Json Templates können auch gepusht oder vom ESP geladen werden, eine Homeassitant integration ist auch vorhanden.

Hier wurde die firmware von grund auf für schnelle uploads und gute batterielaufzeit aufgebaut.
Die alte firmware war eher als Bilderrahmen, also alle 24 Stunden mal etwas hochladen gebaut.

Es gibt seit Gestern einen Port des OpenEPaperLink protokolls für den CC2531 USB Stick, dadurch kann man diesen weiter nutzen. Muss aber auch neu geflasht werden. Und die Bilder weiterhin wie in der epaper-station selbst im ordner hinterlegt werden
Besser ist da die Methode über den ESP32, der S2 Mini bietet sich da perfekt an da auch mit PSRAM verfügbar für wenig geld und PSRAM ist schon besser für viele displays. Ein einfacher ESP32 funktioniert aber auch und es kann ein AP mit fliegender verdrahtung selber gebaut werden, die richtige AP firmware flasht der ESP32 auf das angeschlossene display automatisch, da geht auch das 2.9"

Die Firmware gibt es derzeit für viele verdchiedene modelle der Displays, von 1.54" 2.9" 4.2" und 7.4"

Ein flashen der 2.9" von epaper-station zu OpenEPaperLink ist OTA möglich.
Dazu den aktuellen release von github laden
https://github.com/jjwbruijn/OpenEPaper ... FW_2.9.bin
In der datei bei 0ffset 0x8F die 0x13 durch 0x44 oder höher ersetzen (Dadurch ist die Version höher als die aktuelle im Display und es macht das udpate)
Die datei umbennnen in UPDT0008.BIN und im epaper stations ordner hinterlegen, die displays laden dann die neue version runter.
Ein zurück geht dann aber nur mit laufendem OpenEPaperLink system.

OK Danke für die Zusammenfassung, dann werde ich das mal versuchen. Werde meinen CC2531-Stick (dann geupdated auf OpenEPaperLink) mit epaper-Station dann weiter betreiben - schon alleine weil der RPi genug Flash-Speicher hat (SD-Karte), um auch größere Datenmengen zu cachen, dann muss ich die nicht jeden Tag neu ziehen (z.B. die Müllabfuhrtermine). Update ist bei mir bei allen Projekten tatsächlich nur 1x in 24 Stunden... möglicherweise würde also auch die alte FW reichen.

berferd hat geschrieben: ↑Fr 4. Aug 2023, 16:35 dann werde ich das mal versuchen. Werde meinen CC2531-Stick (dann geupdated auf OpenEPaperLink) mit epaper-Station dann weiter betreiben

Hierbei ist zu beachten das nicht die jetzige epaper-station kompatibel ist.
Es gibt derzeit 2 version die mit dem CC2531 OpenEPaperLink kompatbel snd:
https://github.com/jjwbruijn/OpenEPaper ... -PyStation
und
https://github.com/Westwoodlabs/WAMP202 ... ation-UART

Die bilder werden da wie gewohnt als .png datei in einem Ordner vom python script names "cache" erwartet

Ähm, ja das kommt davon wenn man nicht genau hinguckt auf empfohlene Links:
das verlinkte BIN-File war eine Access-Point-Firmware, kein Tag-Firmware. Damit ist das Schild wohl (mangels Programmer) wohl erstmal gebrickt. Oder gibts eine Möglichkeit das irgendwie wieder zu retten?

Argh, mein fehler, ist nun editiert, die AP firmware hat jedoch nur mit nem flasher die möglichekt geupdated zu werden.
Oder nun direkt mittels USB zu Uart converter and the UART pins als AP am PC nutzen, anstatt des CC2531 Sticks

Obacht, eben festgestellt anhand einer Renata CR2450N: es passen nur CR2450, nicht die CR2450N.
Die CR2450N verjüngt sich (stufenförmig) zum Minuspol hin, dadurch greift der seitliche Plus-Kontakt des Schilds ins Leere. Siehe auch hier, in den Fragen: https://www.photobatterie.de/Renata-CR2 ... -7806.html
Möglicherweise bekommt man das als Hack zum Laufen indem man da an einer Stelle etwas Heisskleber aufbringt mit Alufolie drüber. Die bessere Variante: gleich die richtigen Batterien kaufen.

Wo Platz ist habe ich die Versorgung über ein AAA Batteriepack hergestellt. Die Drähte bekommt man nur nicht an die vernickelten Kontakte gelötet. Muss man feströdeln. Nicht elegant.