Die Fackel

Blinkender Kram hat es mir angetan. Für diejenigen, die mich kennen ist das nichts Neues.
Auf dem 31c3 hat eine herumstehende LED-Fackel meine Begeisterung und den haben-wollen-Drang entfacht. Ich habe mich gleich durchgefragt und konnte den Verantwortlichen für diese optische Illumination höherer Vergnügungsordnung ausfindig machen. Er hat mich innerhalb weniger Minuten technisch auf den Stand der Dinge gebracht und mir die Funktionsweise erklärt. Klug wie ich bin konnte ich von all dem gerade mal die Internetadresse verstehen, aber darüber bin ich heute sehr froh, denn sie legte den Grundstein für die Fackel Version 2.0.

Die Fackel besteht aus einem LED-Strip vom Typ WS2812B, den man schlicht auf eine (optimalerweise leergefutterte) zylinderförmige Chipsverpackung spiralförmig aufrollt.

Man kann die Chips auch in der Packung lassen, das hat keine Auswirkungen auf die Lichtintensität, aber erhöht unnötig das Gewicht. Der „mrks“ aus Regensburg schreibt davon, ein Abflussrohr genommen zu haben. Ich habe davon abgesehen, ich finde die Fackel kommt im Bad nicht so zur Geltung. Zumal ich dafür die Fliesen von der Wand hätte klopfen müssen.

In der ursprünglichen Version von „mrks“ wird die Ansteuerung der LED’s durch einen Arduino Micro vorgenommen. D.h. der Feuereffekt wird auf einem ATmega32u4 Prozessor berechnet, der speichertechnisch mit 2.5 kb RAM schon am Limit ist.

Der ESP8266 als NodeMCU

Da ich allerdings ein Freund von über-wlan-fernsteuerbaren Dingen bin (Thema iot), war mein definiertes Ziel, die Fackel auf einem ESP8266 zum Laufen zu kriegen.

Es gab zwar Vorbehalte, dass die Berechnung auf der CPU bei eingehenden WLAN-Pakete ins Stocken geraten würde, aber diese Befürchtungen haben sich aufgrund der viel höheren Performance (und gefühlt unbegrenztem RAM) als unbegründet erwiesen.

Es hat etwas länger gedauert bis ich den Programmcode ausreichend verstanden habe um ihn entsprechend abzuändern, letztendlich ist es mir jedoch gelungen, den Algorithmus auf den ESP8266 zu portieren.

Die erste Version nach der Portierung lief also genau wie auf dem Arduino, d.h. einfach programmatisch ohne irgendwelche Features, aber durch die neuen Hardware standen ganz neue Freiheitsgrade zur Verfügung.

Das erstmal genialste an der Angelegenheit ist, dass ich nun zur Ausgabe an den LED-Strip die FastLED-Bibliothek nutzen konnte. Sie hält jede Menge Funktionen vor, um den Strip bzw. die Ausgabe anderweitig zu beeinflussen. Ich schätze beispielsweise sehr die Fähigkeit, die Stromstärke der LED’s begrenzen zu können. D.h. ich kann im Code festlegen (mittlerweile auch live), dass beim Beleuchten z.B. maximal 1 Ampère verbraucht werden darf und kann somit als Stromversorgung auch einen USB-Anschluss nutzen. Steht ein größer dimensioniertes Netzteil zu Verfügung, kann die Stromaufnahme und damit die Helligkeit auch erheblich erhöht werden. Bei 60mA mal 300 LED’s können bis zu 18 Ampère benötigt werden. Dann kann man allerdings eher von einer Sonne anstatt einer Fackel sprechen und man sollte in der Umgebung vorsichtshalber Schweißerbrillen verteilen, um Netzhautschäden zu vermeiden.

Im weiteren Verlauf konnte ich die WLAN-Fähigkeit einbinden. Das Ziel sollte sein, die Fackel um weitere Lichteffekte zu ergänzen und diese selbstverständlich per WLAN steuerbar zu machen. Dazu habe ich den Code anderer Projekte (z.B. Tweaking4all oder StefanPetrick) mit dem der Fackel ergänzt und hatte nun eine erste Möglichkeit, zwischen unterschiedlichen Effekten auszuwählen. Leider kam es in dieser Phase zu einer Unannehmlichkeit, bei der ich fast das Handtuch geworfen hätte. Es war nicht möglich, aus gewissen Effektprogrammen in Andere zu wechseln. Wieder mal nicht trivial. Gewisse Effekte, einmal gestartet, hingen fest. Das war so genannte nested loops zuzuschreiben, d.h. der Prozessor hatte sich in „Unterschleifen“ derart mit dem Licht beschäftigt, dass er nicht mehr dazu kam, nach neuen WLAN-Befehlen Ausschau zu halten. Dies ist dem Design des ESP8266 geschuldet, der üblicherweise immer wiederholend eine Grundschleife (Loop) durchläuft. In dieser Grundschleife kann er auch nach Netzverkehr schauen, aber wenn die Grundschleife nicht mehr erreicht wird, dann ist eben Essig.

Nach Lektüre diverser Seiten besteht die einzige Chance darin, den Code so umzuschreiben, dass man ein gewisses Zeitmanagement implementiert. Es führt zu einem rudimentären Multitasking. D.h. jede Unterroutine wird nur nach Verstreichen einer gewissen Laufzeit (millis) aktiviert und auch nur einmal und nicht unendlich durchlaufen. Das setzt auch wieder voraus, dass alle benutzen Variablen global weitergenutzt werden müssen. Lange Rede, kurzer Sinn, das gesamte Konzept musste umgeschrieben werden, um zukünftigen Erweiterungen durch Effekte stand zu halten. Es sind noch lange nicht alle Routinen komplett angepasst, aber es funktioniert bereits ausreichend, d.h. der Loop wird häufig genug durchlaufen, um z.B. den Netzwerkverkehr ausreichend abzuholen und auszuwerten.

Im weiteren Verlauf habe ich noch MQTT-Funktionalität implementiert. Die Effekte können also auch durch eine schicke Oberfläche wie z.B. Node-Red bedient werden. Dem Einsatz im Wohnzimmer in einem sowieso schon hochautomatisieren Heimnetz steht also nichts im Wege.

In einer der letzten Schritte habe ich eine Wifi-Manager Bibliothek eingebunden. Mit ihrer Hilfe ist es möglich, den (wlan-) unkonfigurierten ESP8266 in einer ihm unbekannten Umgebung „auszusetzen“ und dann erst das WLAN einzurichten. Dazu spannt der Chip seinen eigenen WLAN-Accesspoint auf, mit dem man sich verbinden und dann die Credentials für das lokal vorhandene WLAN eingeben kann. Befindet man sich auf „freiem Feld“, d.h. nicht in der Nähe eines nutzbaren Accesspoints, so schaltet die Fackel in den Standalone-Betrieb um und man kann die Fackel über den nun aktivieren internen Accesspoint steuern. Das macht schon Laune.

Des Weiteren ist es möglich, die Effekte auch per Button durchzuschalten. Ich habe hierfür GPIO 14 (Wemos auf D5) konfiguriert. Wird der PIN mit Ground (GND) verbunden, wird ein Interrupt ausgelöst und der Zähler um (mindestens) Eins hochgezählt. Es steht noch auf der Verbesserungsliste, den Button zu entprellen, denn ohne Kondensator können leider auch mehrere Trigger gezählt werden, und bisher bekomme ich das programmtechnisch nicht zuverlässig abgefangen. D.h. wenn man den Button drückt, kann auch mehrere Effekt vorgesprungen werden, was eher einem Effekt-Lotto gleicht. Mittlerweile ist der Taster auch entprellt, was für mich nicht trivial war, da speziell bei der Nutzung des Interrupts Einiges zu beachten ist.

Wenn man GPIO 5 (D1) auf Ground zieht, werden die WLAN-Daten gelöscht und man kann es neu konfigurieren.

Die Software

Wer sich nun durch den Text gequält hat, entweder Fragezeichen, Ausrufezeichen oder Sternchen im Hirn hat, der darf endlich zum Herzstück des Ganzen übergehen, dem Code:

https://github.com/cruisinger/FireTorchESP

Der Code ist in Github abgelegt und ich bitte um Weiterentwicklung (z.B. per Pull-Requests) durch Erweiterung oder auch gerne durch Korrektur.

Die Hardware

Was die Hardware angeht, so werden folgende paar Teile benötigt:
1 x ESP8266 , ich bevorzuge das Wemos D1 Modul.
1 x WS2812B LED Strip , hier erhältlich
1 x Pegelwandler , hier erhältlich, oder hier
1 x Protoboard , hier erhältlich
1 x JST SM Adapter (3-polig)
2-3 x Mikro Taster als Effektumschalter, etc.
1 x 220µF Elko, zur Spannungsstabilisierung am Spannungseingang
1 x 1000µF Elko, zur Spannungsstabilisierung am LED-Strip
2-3 x 0,1µF Kondensator zum Entprellen der Taster

Zusammengebaut kann das Ganze dann so aussehen:

Der Fackel-Generator
mit JST Kabel

Was die Stromversorgung anbelangt, so sollte man sich ein ausreichend dimensioniertes Netzteil besorgen. Wenn man nicht den gesamten Raum zum Lesen ausleuchten will reicht für reine Effekte durchaus ein Netzteil mit 4 bis 5 Ampère aus. Die Fackel (als der Effekt/das Programm) leuchtet z.B. auch bei 1000 mA schon sehr eindrucksvoll. Für die volle Power sollten 18A ran, das wird aber auch dann entsprechend teuer. Den Stromverbrauch kann man – wie oben beschrieben – per Software ja begrenzen. Bei Unterdimensionierung sollte man noch eine Schmelzsicherung vorschalten.

Und wenn man das Ganze über Akku betreiben möchte, dann sollte man sich neben 2-4S LiPo Akku noch einen Step-Down Wandler zulegen. Ich habe gute Erfahrung mit Folgendem:
75W/5A Wandler
Bedenken sollte man auch Anschlussstecker und Zuleitung. Ich selbst nutze Deans-Stecker. Es gibt aber auch etliche andere Adapter.

Die Schaltung

Ein Bild sagt mehr als tausend Worte. Hier ist die Verschaltung:

ESP mit WS2812B

Weitere Wünsche:
GUI mit responsive Design
Spannung der Batterie anzeigen, Unterspannungsabschaltung
Texte anzeigen
konfigurierbarer (Speech-) Timer
Debouncing der Taster
OTA – Firmware über WLAN flashbar machen
MSGEQ7 Sound Equilizer optional nutzen

Links:
A beginner’s guide to the ESP8266
http://esp8266-server.de/Tipps.html
http://werner.rothschopf.net/201809_arduino_esp8266_server_client_1.htm
https://jorgen-vikinggod.github.io/LEDMatrix/

Rhetorik braucht Übung

Rhetorik ist immer harte Arbeit:
Einer quält sich auf jeden Fall – entweder der Redner, oder der Zuhörer.
Du als Redner entscheidest darüber.

Campingplatz Hirzberg in Freiburg

Sehr freundliches Personal! Der Platzinhaber „Jonathan“ versucht es, jedem Gast recht zu machen.

Der Platz ist relativ klein, verfügt über unterschiedliche Parzellen, welche nicht alle waagerecht sind. Einige Plätze sind geneigt und stellen für manche Urlauber sicherlich eine Herausforderung dar. Wer reserviert hat oder früh am Tag anreist, ist klar im Vorteil. Für die Anreise in der Saison und am Wochenende ist eine Reservierung Pflicht – wenn man nicht wegen Überfüllung abgewiesen werden möchte.

Der Campingplatz ist relativ zentral gelegen, es sind etwa 1,5-2 km bis zum Zentrum. Direkt nebenan verläuft der malerische Bach „Dreisam“, an dem man verweilen kann.
Die sanitären Anlagen sind neu, es benötigt keine lästigen Duschmarken und auch Klopapier ist vorhanden. Leider waren die Duschen bei uns ziemlich kalt.

Das Personal ist auskunftsfreudig und zuvorkommend, was das Urlaubsgefühl erheblich steigert. Direkter Nachbar ist ein Biergarten, der zu ganz sportlichen Preisen unsere Erwartungen nicht ansatzweise erfüllen konnte. Wir werden dort nicht mehr speisen.

Es ist überwiegend ein Campingplatz für Durchreisende, d.h. der Campingplatz füllt sich ab der zweiten Tageshälfte, während er sich am nächsten Vormittags wieder stark leert. Die Abreise ist großzügig bis 12 Uhr möglich.

Für Kinder ist ein kleines Spielplatz-Gerüst vorhanden, ansonsten kommen Kinder hier eher nicht auf ihre Kosten.

Die Umgebung kann gut zu Fuß oder mit dem Fahrrad erkundet werden. Sie lädt zum Wandern ein, die Stadt zu erkunden, oder sich bei gutem Wetter an die „Dreisam“ zu pfletzen.

Sehr empfehlenswert ist die Fahrt mit der Schauinslandbahn auf den Berg mit dem Namen Schauinsland. Die knapp 27€ fur eine Familie sind zwar nicht günstig, aber ihr Geld tatsächlich wert, wenn man die Länge der Seilbahn betrachtet. Entlohnt wird man zusätzlich mit einer tollen Aussicht auf Freiburg und Umgebung, von 1284 Meter Höhe.

Camping in Strasbourg

https://www.camping-strasbourg.com/de/

Etwa 3km von der Kathedrale entfernter Campingplatz. Ziemlich neu und schön angelegt, mit Pool, Volleyballfeld, Boule-Platz und Tischtennis-Platte. Leider in der Nähe der Autobahn, was für ein dauerhaften Rauschteppich sorgt, gerade noch erträglich. Die direkte, fußläufige Umgebung ist nicht sehr attraktiv, es bestehen kaum Einkaufsmöglichkeiten. Zur historischen Innenstadt ist der Weg zu Fuß etwa mit 40 Minuten zu veranschlagen, ansonsten mit der Tram.

Preislich befindet sich der Campingplatz im mittleren Segment. Ein Wohnwagen mit 4 Personen kommt etwa auf 40€/Übernachtung. Der optional zubuchbare Stromanschluss ist mit 6€/Tag unverschämt teuer und setzt eine bisher unerreichte Höchstmarke. Wer die Möglichkeit hat, sollte dieses Geld sparen und den Kühlschrank mit Gas betreiben. Alle Parzellen sind ebenerdig, jedoch relativ klein (ca. 50-60qm).
Positiv hervorzuheben ist, dass die Duschen keine Duschmünzen benötigen, somit Flatrate-Duschen möglich ist.
Der Campingplatz verfügt über ein flächendeckendes, freies WLAN, das einigermaßen funktioniert. Es setzt einen Login mit Passwort voraus, ist langsam und lässt nur bestimmt Ports zu. VPN-Verbindungen über z.B. OpenVPN gelingen nicht. Die Ausleuchtung über Mobilfunk wie z.B. Orange ist ausreichend, um einen besser funktionierenden Internetzugang zu nutzen.

Die Gäste bestehen größtenteils aus Durchgangsurlaubern, die den Platz für eine Übernachtung nutzen. Persönliche Kontakte sind daher leider eher selten, es wirkt sehr anonym.

Sophos Firewalls können kein DHCPv6-PD

Zugegebenermaßen, es betrifft nicht jeden. Aber es ist totzdem dramatisch, wenn eine sogenannte UTM Enterprise-Firewall eine Technik nicht beherrscht, die selbst eine kleine Fritzbox schon drauf hat. Es handelt sich um DHCPv6 prefix delegation, was die Fähigkeit bezeichnet, IPv6-Netze vom Zugangsrouter an dahinterliegende Router weiterzureichen. Mit Softwarestand 9.510-5 auf Sophos Firewalls ist diese Funktion auch im Jahr 2019 noch nicht vorhanden.

Für alle, die jetzt nur Bahnhof verstanden haben:
Das ist in etwas so, wie wenn man ein Auto kauft und stellt fest, dass es keinen Rückwärtsgang hat. Natürlich hat man im Autohaus nicht danach gefragt – ist doch selbstverständlich, dass Autos Rückwärtsgänge haben.

Am kuriosesten ist an der Angelegenheit jedoch, wie man sich als Firewall-Hersteller eine solche Blöße leisten kann. Es gibt etliche Fälle von Global-Playern, die praktisch von einem Tag auf den anderen von der Bildfläche verschwunden sind, weil sie sich auf ihren Lorbeeren einfach ausgeruht haben. Daher fällt es schwer nachzuvollziehen, wie Sophos derart am Kunden vorbei entwickeln kann. Es gibt im Forum alleine 193 Anfragen für die Funktion. Das seit über 3 Jahren!
Ich habe gelernt, dass ein Kunde, der sich beschwert, für etwa 170 andere Kunden steht, die sich an der selben Sache stören. Das macht etwa 32.000 Kunden. Denn jeder, der dort seinen Willen kund getan hat, hat schon einen weiten Weg hinter sich, mit Recherchieren, mit Ausprobieren, einloggen, Posten, etc., um dann schließlich festzustellen: Das Ding kann DHCPv6-PD tatsächlich nicht. Die ignorieren die Kunden einfach.

Zeit, zu wechseln, wie dieser Beitrag zeigt…

und

wie der Kunde seit 2013 (!) ignoriert wird.

Zeit

Zeit wurde erfunden, damit nicht alles gleichzeitig passiert.

Storytelling

Geschichten transportieren Nachrichten.
Das Vermitteln von „trockenen“ Fakten funktioniert i.d.R. eher „suboptimal“. Unser Gehirn ist nicht dazu geschaffen, isolierte Fakten zu speichern, da isolierte Fakten keine Verbindung zu bisher Erlerntem herstellen. Eine neuronale Vernetzung findet nicht oder nur sehr mühselig statt. Als Beispiel kann man Vokabeln pauken nennen.

Stories bzw. Geschichten hingegen transportieren neue Informationen in einem Rahmen, den das Gehirn gerne annimmt.

Auch Musik bzw. Liedtexte eignet sich hervorragend zum Transportieren und Vermitteln von Informationen. Ebenso Filme…

VMs lassen sich plötzlich nicht mehr migrieren

In einem Datacenter mit einem vmware-Cluster, bestehend aus mehreren ESXi Hosts trat die Unannehmlichkeit auf, dass sich einige virtuelle Maschinen unvermittelt nicht mehr migrieren ließen. Die Option zum Auswählen im Kontextmenu ist einfach ausgegraut, deaktiviert, nicht anklickbar. Ein Hinweis darauf, warum die Funktion nicht mehr verfügbar ist, ist nicht erkennbar. Das Hostbetriebsystem ist VMware ESXi, 6.5.0, 6765664, verwaltet von vCenter Server Appliance 6.5.0, 5973321.
Von der Beharrlichkeit, sich nicht zu anderen ESXi-Hosts migrieren zu lassen, sind Linux wie Windows Maschinen betroffen. Der Inhalt der virtuellen Container scheint somit keine Rolle zu spielen. Snapshots sind konsolidiert, bzw. es bestehen keine. Weiterhin sind keine Images in die virtuellen CD-Laufwerke der VM’s gemountet, was sonst unter vmware auch gerne mal zu informationtechnischem Schluckauf führen kann. Migrationen sind weder live, noch im ausgeschalteten Zustand der betroffenen VM’s möglich. Neustart des vCenter, der Hosts, sowie des Storge bringen keine Abhilfe. Die virtuellen Maschinen erscheinen festgenagelt an die Hardware.

Recherchen bringen Folgendes hervor:

https://kb.vmware.com/s/article/2044369

Notiz vom 09.November 2018 seitens vmware: Currently, there is no resolution

Vmware hat offensichtlich keine Ahnung, warum VM’s spontan nicht mehr korrekt in der Datenbank registriert sind, vCenter Server also an digitaler Amnesie leidet. Eine Lösung gibt es nicht, außer der harten OP an der Datenbank, oder der De- und Reregistrierung betroffener VM’s. Ich bevorzuge Letzteres.

Unangenehm an der Angelegenheit ist, dass man sich so nicht mehr auf die HA-Funktionalität verlassen kann. Die man teuer bezahlt hat. Keine Ahnung, wie sich der vmware Cluster verhält, wenn ein vmware Host wegbricht. Außerdem ist die Migration für den Fall eines Stromausfalles nicht mehr gesichert. Im Falle eines Stromausfalles meldet die USV innerhalb des Rechenzentrums, dass die VM’s in ein anderes RZ zu migrieren sind, um den reibungslosen Betrieb sicher zu stellen. Wenn VM’s jedoch an der Hardware „kleben“, crashen sie mit Ablauf der Batterielaufzeit. Wer kommt dann für den Schaden auf?

HFO Telecom bringt Ansage, dass Sprachkanäle begrenzt sind

Seit Anfang Dezember 2018 erhalte ich Beschwerden von Kunden der HFO Telecom, dass sie die Ansage hören, die maximale Anzahl von Sprachkanälen sei erreicht. Weitere Telefonate können dann nicht mehr geführt werden. Dies tritt ein, wenn zwei Leitungen belegt sind, obwohl vertraglich mehr Sprachkanäle ausgehandelt sind.

Nach Aussagen der HFO Hotline vom 10.Dezember ist dieses Verhalten auf einen Fehler zurückzuführen und sollte nun der Vergangenheit angehören.