Es artet aus – wie immer ;-)

Tja, kaum ist das Wochenende da rumpelt es wieder in der Kiste. An zwöf Ecken wird gleichzeitig geschraubt und ich hoffe jedes mal nicht den Überblick zu verlieren. Nachdem die ersten Sensoren in mein Dashboar intergriert waren (ich erwähnte: Grafana) ging es daran auch die anderen Infrastrukturkomponenten dort sichtbar zu machen – zumindest das „sinnvolle“ ;-)

Der Überblick: Temperaturen. „Sinnvoll“ tatsächlich für das Fleisch in den Gefriertruhen und für die Überwachung des Keramik-Brennofens der Froo.

Als erstes wollte ich meinen DSL Leitungszustand sehen – letzte Woche waren wir tatsächlich ein paar Tage mit geringerer Bandbreite angebunden als bezahlt und ich merkte das erst subjektiv. Drum gesucht und nicht wirklich gefunden: Aus diesem Grund aus Codeschnippseln im Netz mal ein kleines Komandozeilentool gebastelt um verschiedene Dinge der Fritzbox abzufragen (ja, kommt online – doch Schritt für Schritt ;-). und ein Zweites um diese Infos dann zum MQTT Server zu geben.

Nebenbei kam ich beim python-phao-mqtt weiter und ich hab meinen ersten rudimentären Überwachungsclient für Linux & macOS der auf den Servern laufen kann. Dieser sendet nicht nur den Onlinestatus – und eben Offline per MQTT Last-Will, sondern auch die laufenden Services ganz einfach per aktueller Prozessliste minus meiner Ausschlussliste, was ich nicht sehen will = dynamische Prozessliste die ich übermittelt bekomme.

Der mehr technische Blick: Was läuft, was lief wann nicht und Personenerkennung über WLAN Signalstärke der Sensoren ;-)

Läuft alles noch nicht so rund, wie ich möchte. Insbesondere die Sensoren melden sich für meinen geschmack noch zu häufig beim MQTT Broker ab und an – ggf liegt das am WLAN, welches ich nebenbei ja auch umgebaut habe. Nicht nur für die Froo, sondern auch für die Sensoren ;) gibt es jetzt ein ziemlich flächendeckendes Mesh aus drei Asus Routern – willkommen in der neuen Welt ;)

Ich mag WLAN ja nicht so, kennt ihr ja – aber was solls – wenns Daten bringt ‚;-) Schon echt faszinierend, was ich aus meinen Popeldaten für Rückschlüsse bez Anwesenheit von Personen und ähnlich schliessen kann. Bringt mich nicht auf die glücklichere Seite des Lebens – rein Welt-Gesamtbetrachtungstechnisch, aber wenigstens weiss ich nun ob es dem Fleisch in der Truhe auch gut geht, das ist wichtig!

PS: Wer in Bremerhaven / Cuxhaven und Umzu irgendein Kleinteil bez. Arduino, ESP8266 und Zubehör, wie Sensoren, Kabel, Ersatzteile für den Creality CR10-S benötigt, der gebe Bescheid: Ich mach den Arduino Späti.

Ich kann zwar für keine Verfügbarkeit garantieren – aber der Postboote meint: Chinas Lager müssten nun leer sein und er wundert sich jeden Tag, das er noch was bringen kann … es ist ja echt fein: Wenn man vor monaten mal angefangen hat was in China zu bestellen, dann trudelt das ja zeitlich sehr variant ein und jeder Tag ist eine Überraschung. Was kommt heute,? „Brauche“ ich das vor anderem Zeug oder leg ich das nur noch auf Halde, weil ich auf Grund der langen Lieferzeit schon vergessen habe, was das überhaupt ist?! ;) Haben ist ja bekanntlich besser als brauchen – und irgendwie nervt es halt, wenn man ne Idee hat und mn dann auf ein Teil wochenlang warten muss – die Wahrscheinlichkeit der Teileverfügbarkeit muss steigen ;) … manchmal klappt es schon sehr gut: Idee & einfach dafür in die Kisten greifen. Sehr fein. Ist halt Lego für „Erwachsende“ … und schon da half nur Quanti- & Diversität ;-)

 

MukTi/one: In freier Wildbahn.

Watt cool: Ich entdeckte den MukTi/one auf der Schiffsbrücke in freier Wildbahn. Er wird täglich benutzt und macht der Froo spass!

Zwar sind schon zwei Themen aufgefallen, die demnächst mal einen Servicetermin rechtfertigen, aber die trüben den MukTi/one Spass keinesfalls.

Soweit ich das beurteilen kann mehr Mukke für die Froo als Tide für den Kuddel, denn eines der Themen ist: Ich hab vergessen das die Tidenanzeige direkt nach dem anschalten aktiviert wird. Bisher landet man im Menü … und das kennen wir alle: Ein Tastendruck ist zu viel, da hätte ich auch nicht jeden Tag bock auf (meine ich ernst).

KleinDing Produktion läuft.

Da die Sensorprodution läuft gab es schon jetzt am Wochenede mit dem Herrn D aus M zusammen eine etwas längliche Config-Session um Grafana, InfluxDB und Homie produktiv zu nehmen. Ich hab nämlich keine Lust irgendwann hunderte von Sensoren umstellen zu müssen ;-) – Mal endlich wurde Verschlüsselung & Co aktiviert und dazu noch eine etwas allgemeinere Erreichbarkeit sichergestellt. Vom nachfolgenden WLAN Umbau ,damit die Sensoren auch an jeder Ecke Netz haben, reden wir mal nicht. Und wie gesagt: Immer wenn Zeit war wurde weiter an meiner Unkenntnis des Lötens & der Elektronik gefeilt ;-) Irgendwie ist das löten ja für mich zur Winter-Meditation geworden…

Nach dem Waschmaschinensensor war ein Sensor für unsere Gefriertruhen auf dem Plan – wie schon im vorherigen Beitrag geschrieben sollen die Nachricht geben, wenn sie mal zu warm werden. Dafür musste ein neuer Sensor her, ein wasserdichter Temperatursensor DS18B20 der über I2C Protokoll angeschlossen wird – wieder viel falsch gemacht, ausprobiert, berichtigt & gelernt. Dazu noch ein Gehäuse nach meinem neuen „KleinDinger“-Standard gefertig und fein. Insgesamt ging das relativ fix für mein zweiten Versuch nen Prototypboard zu löten gar nicht mal so unzufriedenstellend. Dieses mal schon mit Silberdraht, anstatt 100% fliegende Leitungen.

Gleich hinterher gabs das etwas schwierigere Modell: Gas Sensor für die Schiffsbrücke. Die Froo heizt da im Winter mit Gas, und auch wenn die Heizung selbst schon nen Sensor haben soll: Trau, schau, wem. Außerdem kann das eingebaute Teil ja keine SMS senden ;)

Wenn ich beim zweiten Sensor basteln schon manches Mal gedacht hab: Jetzt hab ichs verstanden, so war es hier wieder wie so häufig: Immer einen Schritt vor, zwei zurück, sich Ruhe einreden, Aha-Erlebnis sofort wieder zunichte machen und trotzdem irgendwie vorwärts kommen und Spass haben. Das sind einfach wahnsinnig viele Komponeten, dazu an jeder Ecke neue Themen und dadurch andauern Unsicherheit bezüglich der Ursache, wenn etwas nicht klappt.

Hier mal eben neu: Gas Sensor MQ5 und Shift-Level Converter von 5 auf 3.3v und oben druff noch ein Buzzer zum Piepen. Ewas komplexer als Sensor zwei und zusätzlich auch mit Bauteilmodifikation – SMD LED auf dem Board des Gassensors raus und eine externe LED ran, damit die Kontrolleuchte vernünftig ins Gehäuse integriert werden kann.

Noch zackig ein Gehäuse (es wird tatsächlich langsam fein beim Deseign ;) nach Sveni Standard – auch, wenn es etwas höher muss, kein Problem: mein Workflow in Blender läuft langsam.

Ganz nebenbei hab ich meine Sourcecodes zusammengeführt und vereinheitlicht. Ich möchte nur eine Firmware auf allen Sensoren haben, jedoch möchte ich jeweils nur den benötigten Code kompiliert haben, der für die eingebauten Sensoren notwendig ist. Also eine Datei, für die Sensoren ein paar Variablen setzen, kompilieren und gut. Das läuft soweit für die bisher verwendeten Bauteile und auch wieder ne Ecke gelernt ;)

In der Praxis hat sich das zusammen mit den steckbaren, größeren Bauteilen wie Wemos & Tempsensor schon als sehr fein herausgestellt. Hatte ich hier erst den BMP280 verbaut (Temperatursensor ohne Luftfeuchtigkeit, dafür mit Luftdruck) stellte ich dann fest, dass mich auf der Brücke ja doch die Luftfeuchtigkeit interessiert. Also schnell nen BME280 aus dem Fach, Pins drangelötet, aufgesteckt und Variable im Sourcecode angepasst. Läuft.

Im weiteren Verlauf meiner Tüddelagen werde ich meine Datein hier dann veröffentlichen. Kann dann jeder selbst etwas drauss machen, wenn er will – oder drüber schmunzeln, mir wurscht ;)

 

Die Waschmaschine ist fertig. (2/2)

Wie in Teil 1 Berichtet funktionierte meine Lösung ganz fein – dennoch ergaben sich beim Basteln des Produktionsversion des KleinDigs ein paar Probleme. Der DHT22 Sensor wollte nicht mehr so, wie ich will. Lange Zeit dachte ich an einen Fehler bei mir, denn die gelötete Kleinplatine sah schon etwas komplexer aus, als mein Aussensensor. Ich Teste dort, lötete hier um, nahm einen anderen DHT22 Sensor, einen anderen Wemos D1 Mini – bis ich davon Drei durch hatte und keine Verbesserung feststellte: Der Sensor funktionierte und versagte seinen Dienst, wie es ihm passte. Ich fand einfach keine Möglichkeit das sicher zu reproduzieren oder zu entfernen.

Alles etwas klein für mich, aber was solls.

Das der Sensor nicht der Genauste war wusste ich, aber das tat nichts zur Sache. Ich lass im Netz auch über ähnliche Probleme und irgendwie nirgens eine feine Lösung. Naja, dachte ich – dann nehm ich doch mal nen neuen Sensor von Bosch, den ich immer vermieden hatte da der auch noch den Luftdruck messen kann – was ich ja gar nicht brauche. Der Kostet auch noch ganze 70 Cent mehr (2,80 zu 3,50 ungefähr) also würde es ja „eigentlich“ auch der DHT tun, – aber der will nun am Wemos einfach nicht.

BME280 (links) und Wemos D1 Mini (rechts) mit Debugverlötung.

 

Und der Tuts. Der BME280 von Bosch misst was das Zeug haelt und doch ist die Freude nur von kurzer Dauer – denn auch da erscheinen auch nach vielem Umlöten, Hardwaretesten und mich selbst mit meinen Lötkenntnissen immer wieder in Frage stellen, einfach nicht alle Werte auf meinem MQTT Broker.

Passt mit etwas nachhelfen ins erstellte Gehäuse. Ganz ohne Schrauben.

Bis ich darauf komme mal im Log zu gucken ob  die Daten auch tatsächlich nicht vom Sensor gemessen werden können (wovon ich die Ganze Zeit ausging als Werte fehlten) dauerte es etwas. Und faszinierend – alle Werte wurden einwandfrei gemessen. An meinen miesen Lötfertigkeiten liegt es also nicht und irgendwie waren die letzten zwei Stunden Verwirrung ganz umsonst. Es muss was am Sourcecode sein. Komischweise hatte ich bis auf die Änderung des Sensors und eben das Hinzufügen eines weiteren Messwertes (Luftdruck) nichts gemacht.

Ich lass die betreffenden Stellen mehrfach, grübelte und Verzeweifelte fast. Irgendwann kam mir der Gedanke: Der sendet nur den den ersten Wert von der Reihe die ich ausgeben will – hmmmmm …. ob da ein Timingproblem besteht und der sich bei den darauffolgenden Ausgaben verschluckt? – Probieren wir mal einen delay dazwischen. Heureka! Es geht. Faszinierend wie dieses Thema bei den KleinDingern immer näher rückt. Andauernd ist da etwas mit – man merkt, man ist etwas Hardwarenaher unterwegs ;)

Seis drum: Bis mir jemand Anderes einen besseren Lösungsvorschlag macht bleiben die delay(100) im Code und ich erfreu mich daran, das es läuft.

Der erste Proktuktionstest wurde bestanden: Die Froo fand die erste „Waschmaschine ist fertig!“ Nachricht auf ihrem Handy. Fein.

Eben varioPerfekt. Kein Aufschrauben der Maschine & immer frische SMS.

Weiter gehts mit den Gefriertruhen im Abstellraum. Da hatten wir schon mal einen ungeplanten Ausfall. Brachte uns damals zwar ein Schlemmerwochenende, weil die guten RInderstücke alle weg mussten, dennoch wüsste ich zukünftig gern früher Bescheid, wenn so etwas passiert. Dann lassen sich besser Gäste einladen – ist für jeden genug drin ;)

Es kommen also in beide Gefriertruhen Thermometer. Hab ich wieder was zu mokeln. Ihr werdet es sicherlich lesen …

Die Waschmaschine ist fertig. (1/2)

Wie im vorherigen Beitrag erwähnt: Min Froo braucht nen Tritt, … ähh TriGGer wenn die Waschmaschine ihre Arbeit getan hat. Ja, sie piept nervig, aber das ist bis zur Schiffsbrücke kläglich verhallt.

Aufschrauben is nich – also brauchte ich eine Lösung von aussen und liess mich hier bei bitluni inspirieren.

Ein Wemos D1 mini bekommt Photoresistor, Temperatur- & Luftfeuchtigkeitsmesser (die Umgebung checken wir gleich mit ;-).

Prototyp – It works.

Die Nachrichten senden wir an den MQTT Broker mosquitto und greifen uns die über Node Red ab und lassen daraus ein kleines Dashboard basteln (welches eigentlich gar nicht wirklich gebaucht wird, aber naja – mokeln wir halt mit ;). Dazu ein Workflow um dann bei fertiger Waschmaschine eine SMS rauszusenden.

Workflow in Node-Red. Ich versuche den hier noch einzubinden.

Damit dies funktioniert benötigt die Waschmaschine eine LED, die anzeigt ob die Maschine aktiv oder fertig ist. Nach einem Testlauf habe ich schnell die jeweiligen Helligkeitswerte des Photoresistors raus und kann den entsprechen Workflow basten: Wenn Licht sich relevant Ändert und sehr gering ist, dann ist die Maschine aus und sendet eine SMS. Es wird keine Nachricht versendet, wenn die Maschine angestellt wird – da steht man ja direkt davor #;)

Ich hatte in Bisschen mit dem SMS Code zu kämpfen: Der Empfang ist natürlich sehr schlecht bei mir am Schreibisch und so gab es andauernd beim testen „kein Netz“ und auch das ansprechen der seriellen Schnittstell mit AT Kommandos unter Node Red ist etwas gewöhnungsbedürftig. Em Ende jedoch: „It works for me“ – also alles fein.

Nun werd ich entspannt ein kleines Gehäuse designen, modellieren & ausrucken und das Kleinding kann in Produktion gehen. Ab sofort schaffen -wir- 7 Ladungen pro Tag! ;-) … Ja, ich denke ich werde noch einen Bewegungssensor implementieren damit ich auch checken kann ob in entsprechender Zeit reagiert wurde – anonsten drossel ich einfach das Internet …

… Ich bin mir nicht ganz sicher ob die Froo drüber nachgedacht hat was passiert, wenn sie mich auf eine solche Idee bringt …

Als Optimierung werde ich versuchen die Aktivität der Waschmaschine über den Stromverbrauch zu messen – dann hat man keine sichtbaren Teile mehr vorne an der Front (Photoresistor). Dazu habe ich Teile bestellt und werde dann berichten.

Mal eben IOT – Oder: MQTT, NodeRed, Mosquitto & Homie

Bisher konnte ich mich aus den Netzangebundenen-Kleinteilein (IOT) ja gut raushalten: Es gab einfach keine Anwendungsgebiete für mich.

Nunja, hat man ne Froo, kommen auch „Anwendungsgebiete“ ;) – Insbesondere wenn einem die Froo nicht effizient genug ist. Bekommt sie doch tatsächlich nie zeitnah mit, wenn die Waschmaschine fertig ist. Meisst merkt sie es abends kurz vorm Schlafengehen und macht dann „schnell noch“ den Trockner“ an – danke, da kann der mich bei meinen Nachtgedanken noch ein paar Stunden begleiten. Ihr könnt jetzt selber Entscheiden ob nun tatsächlich die Froo Trigger war mich damit zu beschäftigen, oder einfach mein Wille abends Ruhe zu haben.

Und wie ich so bin – wieder mal was neues zum Tüddeln und tagelang geht es neben den aktuellen Projekten (insbesondere mein neues Spielzeug) auch drum mal einen Überblick über die heutigen Möglichkeiten in diesem Bereich zu bekommen. Da sind Entscheidungen für die Hardware, Hardwareprogrammierung und Automatisierungs- und Darstellungssoftware zu fällen. Und wenn man da mal mit begonnen hat sieht man den Wald vor lauter Bäumen nicht mehr. Da ist einfach wahnsinnig viel Bewegung in der Entwicklung und Entscheidungen für eine Lösung oder Produkt haben wahrscheinlich nur eine geringe Halbwertszeit, aber egal: Ich setze erstmal auf MQTT (Protokoll), daszu Mosquitto als „Koordinator für die MQTT Nachrichten“und für Darstellung als Webseite inkl Automatisierungsworkflows: Node-Red. Als Hardware kommt vorrangig der ESP8266 in Form von Wemos D1 Minis zum Einsatz, den ich über die Arduino IDE mit Homie programmiere. Natürlich hege ich gewisse Bedenken bei einer netzanbindung von solch Dingen, aus diesem Grund gibt es auch keinen Internetanschluss für die Kleinkastenwelt. Es bleibt im Haus, was ins haus gehört – und wenn es denn wirklich mal raus muss: Ein kleines SMS Gateway hab ich uns auch gebastelt.

Oben links der Raspbery mit Mosquitto & Node Red, rechts der GSM USB-Stick.

Für die zentralen Komponenten habe ich einen Raspberry Pi aufgesetzt – das Ding gefällt mir für solch Dinge sehr. Tut ja auch ohne Murren seine Arbeit beim Octopi – und wer weiss, ggf habe ich irgendwann nen Stapel von denen (ich mag Hardwareseparierung )

Neben dem Aneignen der ausgesuchten Software musste ich natürlich diverse andere Dinge ausprobieren – das bringt das Hirn schnell zum kochen als Mitvierziger. Aber seis drum, heisst ja auch nicht umsonst beim Kochen: Kurz vorm Ende noch einmal richtig Aufkochen *grins* – Da kommen dann die leckersten Sachen raus – und so natürlich auch hier ;-)

Ich denke da gibt es viel guten Stoff, den man nutzen kann. Egal ob es nun die Hard- und Software íst, die ich mir nun ausgeguckt habe – findet euer Ding und nutzt es nur, wenn ihr es auch „braucht“. Die meissten Dinge kann man auch einfach „im Kopf“ erledigen … aber für manchen Dinge macht es halt Spass auch mal mit Kanonen auf Spatzen zu schiessen.

Denkt immer dran: Wenn „works for me“, dann fein.

 

MukTi/one: Klappe zu = Affe Tod …

… und hoffentlich eine Freude für die Seemannsbraut.

Just in dieser Minute hab ich den Karton zu geklebt. Der MukTi/one ist done. Und wie geht es mir dabei? Hmm … mäßig. Zu viele Dinge sind mir bewusst, die ich gerne anders gehabt hätte. Insbesondere das Bluetooth & Störgeräuschthema ist nicht zu meiner Zufriedenheit gelöst – ich weiß nun, warum Audiophile Netzteile und Co vom Tonabnehmer getrennt haben wollen – das ist sonst alles Grütze – hier mal mehr, und woanders ggf weniger. Die Grütze aber bleibt – in irgend einem Umfang: Störgeräusche. Blech bräuchte man, nicht Holz ….

Naja, muss man halt Musik hören oder ihn ausmachen ;) – Och menno, das hätte ich gern anders gehabt und wird das Erste was ich beim two Aufmerksam umgestallten werde – ich hab noch keinen Plan „wie“ – aber das wird schon. Den MukTi/one hab ich nu ja auch zusammengestöpselt bekommen.

Es fehlt nur noch die Kartonbeschriftung. https://www.muktione.de ist schon online – natürlich ohne Inhalt, denn der kommt pünktlich zum 31.1.2018. Aber wenn ihr das lest, ist das eh Februar ;)

Und auf der anderes Seite: *fettGrins* MUKTI/ONE (is done!)

Danke für irgendwas, was da in Richtung Seemannsbraut ist – Alleine hätte ich das nicht durchgezogen. Zu viel Kleinkram, der mich ohne min Froo, zum Wahnsinn getrieben hätte. – Ggf ist es das, was die Menschen Liebe nennen.

 

MukTi/one: Innerein

Auch Kuddel mag Innerein ja nur gebraten – also veredelt. So roh sind sie nicht viel Wert. Mit unseren Komponenten im MukTi/one ist es ähnlich: Einzelnd nich viel Wert doch mit der Liebe, der Mokelei und den Händen des Semmannes alias Sven wird dann etwas feines draus.

Trotzdem hier sind sie, die schnörkellosen Innerein des MukTi/one:

Bei Fragen oder irgendwelchen benötigten Bauteile, bei denen man nicht auf die Lieferung aus China warten möchte: Einfach melden, ich hab einiges an Erfahrung un Bauteilen sammeln können und rumliegen ;-)

MukTi/one: Welcome

Ja, so muss ein Gerät angehen – so wie das MukTi/two!

Äh, was? Wir sind bei Eins – bei one. Bei MukTi/one, oder nicht? Ja stimmt und -naja- das geht auch schon ganz fein an ;)

Tatsächlich gefallen mir ein paar Dinge noch nicht, denn das Ding kennt noch nicht alleine die Uhrzeit. Man muss sie tatsächlich noch manuell zu Beginn einstellen und das ist wirklich Grütze. Klar, eingestellt behält die Kiste auch die Uhrzeit (zumindest solange noch Saft in der Knopfzelle ist), doch sollte ein solches Gerät die Uhrzeit selber kennen.

Ich probierte mit DFC77 Funkuhr rum, das war aber nix. Am Knackarsch der Welt ist dann doch weniger Empfang als man denkt. Danach kam rumprobieren mit GPS und das geht schon besser – aber auch da ein kleines Empfangsproblem bei kleinen Antennen, die das Design nicht einschränken. Der Kistenbau war einfach zu weit fortgeschritten um eine GPS Antenne vernünftig einzuplanen. Eine lose flatternde GPS Antenne kam nicht in Frage, also blieb es bei manueller Uhrzeit. Ein kleiner Wehrmutstropfen bei der Bedienung – dazu kommt nämlich auch, dass Zeitumstellungen manuell durchgeführt werden müssen : -(

Dafür ist das reine „Welcome“ ganz gut gelungen. Der MukTi/one begrüßt die Seemannsbraut – und wenn dies auch nur einmal ist – auspacken, und vom Gerät begrüßt werden, so soll es sein. Dank für die „Für mich?“ Grafik geht an @daskritzelt!

Um das ganze abzurunden überlegte ich lange, wie das „unboxing“ passieren sollte. Ist ja modern, dass Dinge teurer eingepackt sind als sie selbst wert sind. Das sollte beim MukTi/one auch so sein ;) – Obwohl das gar nicht geht: Fürs MukTi/one musste ich so viel Lehrgeld beim Material zahlen – teurer als das, kann man es nicht verpacken. Dachte ich.

So ein schoener Schaumstoffeinsatz – perfekt passend für die Kiste – schlägt Dreistellig zu buche. Nein, das ist zu viel und so landete ich am Ende nach vielen Überlegungen, schon  fast-Käufen bei der Wiederverwertung der Schaumstoffeinlage meines neuen Spielzeuges (dem 3D Druckers). Ich schnitt die Teile möglichst passend und ich finde es auch fein – ist gut geschützt und macht etwas her. Dazu noch die „Infobroschüre“, die man mait auspackt und fertig ist das feine Auspackgefühl. Ein „unboxing“ der feinen Art.

Irgendwie ja nen unboxing Video wert. Ich geb alles, das ich Eines bekomme ;)

 

MukTi/one: Das Holz

Das war schon immer eine besondere Freundschaft:  Das Holz & Sven. Man, ich bin dafür einfach nicht geschaffen. Man muss ordentlich sein und kann nicht einfach eine Zeile Code nach dem ausprobieren löschen und neu schreiben. Versaut ist versaut – da hilft nur neu Bauen. Und auf nochmal machen habe ich ja so richtig Lust, das schaffe ich noch nicht einmal, wenn geschriebene Texte verloren gehen, so grottig sie auch waren. Noch Mal machen ist die Hölle für mich. Gleich davor kommt „Unproduktiv ausprobieren“.

Wie sagte Oma mal: „Sven macht erst etwas, wenn er es kann“ – das natürlich Blödsinn, ich kann  ja fast nix (richtig), aber das Wahre ist: Ich mach es erst, wenn dahinter ein (wenigstens für mich) Zweck steht. Ich bau eine Kiste, wenn ich eine Kiste brauche. – Ich baue keine Testkiste um auszuprobieren, wie man ne Kiste baut.

Das musste sich hier nun ändern. Ich baute Teststücke und Testkanten um die Fräse und auch einen Bezug mit Polyesterharz auszubrobieren. Ich probierte zu schleifen und fluchte, baute die nächste Ecke und fluchte weiter und zwischendurch kaufte ich neues Material. Das Kantenfräsen bekam ich relativ zügig in den Griff als ich endlich konzentriert einen kleinen Frästisch baute – war ich auch schon häufiger angegangen, aber wie immer: Bisher fehlte der Endantrieb, da ich es nicht wirklich brauchte.

Das mit dem Harz funktionierte aber nicht so, dass ich es erstmal wieder verwarf. Ich baute einen Holz-Prototypen ohne weiter auf das Finish zu achten. Ich wollte endlich mal sehen ob das mit dem Display und auch dem Sound irgendwie hinhaut wie ich mir das vorstellte.

Dem war natürlich nicht so. Das mit dem Display klappte schon irgendwie, das würde was werden. Das mit dem Design und dem Sound war eher ein Totalreinfall. Also weiter nachgedacht und gemokelt bis ich mich zu einer radikalen Designänderung entschied …