Netzteil für ESP, Arduino & Co

Damit ich nicht immer ein passendes Netzteil suchen muss, wenn ich mal wieder einer meiner Bastelein auch ohne USB Anschluss auf meinem Schreibtisch ausprobieren will, habe ich mir ein kleines Netzteil gebastelt.

Basierend auf einem DP20V2A* und zwei LM2596* hab ich nun ein Netzteil, welches mir 3,3V, 5V, 12V direkt ausgibt. Dazu noch einen variablen Ausgang vom DP20V2A. So bekomme ich fast alles, was ich zwischen nix und 12V, 2A benötigen könnte.

Noch nicht eingebaut, da noch nicht geliefert: USB Anschlüsse für 3,3V und 5V.

Man nehme die besagten Teile und packe noch 5 Stück 5.5×2.1 Buchsen* für die Anschlüsse drauf, dazu noch 4 x M3 Schrauben um den Deckel fest mit dem Gehäuse zu verschrauben, ein paar Kabel und den Lötkolben und schon kann man das ausgedruckte Gehäuse mit den Komponenten versorgen.  Natürlich benötigt man noch eine Stromversorgung – Ein Netzteil für das Netzteil ;-) Ich verwende ein ausgedientes 12V, 2A Steckernetzteil mit entsprechendem 5.5×2.1 Anschluss.

Wie fast überall bei meinen Gehäusen können die LM2596 einfach „eingeklickt“ werden, Schrauben benötigt man wirklich nur für den Deckel, denn auch wenn der gut sitzt – durch das An- und Abstecken der Anschlusskabel hab ich es dann doch lieber wirklich fest.

Man könnte sich noch überlegen einen Stein reinzukleben, damit es etwas schwerer wird. Die Bedienung würde damit sicherlich noch etwas einfacher werden, da es dann nicht so schnell verrutscht. Ich werde mal gucken ob/wie sich das realisieren lässt.

Die Druckdatein findet ihr auf thingiverse.com: https://www.thingiverse.com/thing:2809082

Für die Anschlusskabel benutze ich die erwähnten 5.5×2.1 Anschlüssen auf der Seite des Netzteils und auf der anderen Seite, was ich eben benötige. Bei mir sind dies meisst Pins für ein Breadboard. Durch die verwendeten Anschlüsse am Netzteil kann hier alles angeschossen werden, was man benötigt, man muss sich halt nur ein paar Anschlusskabel basteln.

*) Die Links entsprechen KEINER Kaufempfehlung, sie dienen nur der Erklärung was ich verwendet habe.

UPDATE 02/03:
Ein paar Tage später nun auch mit USB Anschlüssen. Meine Löcher waren einen Ticken zu groß, Heisskleber half hier – Ich denke man sollte die eh ankleben um sie nicht irgendwann in der Hand zu haben:

Gehäuse für den Forumslader

Zum Ende der letzte Saison gönnte ich mir endlich den Forumslader inkl IQ-X Scheinwerfer fürs Fahrrad. Eine Ladeelektronik inkl Akku, die an den Dynamo angeschlossen wird und über zwei USB Schnittstellen entsprechend Strom zur Vefügung stellt. Das Ding hat sich bei den Touren als hervorragend herausgestellt und ich wollte endlich mein Gehäuse-Workaround loswerden: Da nichts anderes da war, war es die Zeit über in einem alten Plastikgehäuse eines Auto-Cockpit-Pflegetuches – gesichert mit Socken ;-)

Das neue Gehäuse inkl zwei Deckelversuchen ;)

Nun ist ja aber der 3D Drucker da und sowas wird nu konstruiert. 3D Modelierer würden mich wahrscheinlich für meine Modelle erschlagen, aber was solls – das geringe Wissen über Blender führte zum Ziel. Der Forumslader wurde ausgemessen, ein kleines Teststück ausgedruckt, angepasst und über Nacht komplett gedruckt. Beim Deckel (an der Unterseite) brauchte ich drei Ausdrucke bis es passte – weniger war es die Passgenauigkeit, die stimmte auf Anhieb – es waren die „Nüpsel“, die den Deckel über Kopf sicher am Gehäuse halten sollen. Ich musste etwas rumprobieren, bis ich die richtige Form und Ausdrucksweise (Füllung 100%) gefunden hatte damit sie hart & flexibel genug sind um zu halten und auch wieder lösbar zu sein.

Passt. Ohne weiteres Zutun sitzt der Forumslader perfekt im Gehäuse.

Die entsprechenden STL Datein zum Druck findet ihr auf thingiverse.com:

https://www.thingiverse.com/thing:2803283

Am Rad. Die Möglichkeit für Kabelbinder erweist sich als sehr flexibel.

 

 

 

Ich bin sehr zufrieden mit dem Gehäuse und werde vom Alltagstest berichten, der die nächsten Tage wieder starten wird. Zwar hab ich mit meinen Winterbastelein noch genug auf dem Zettel, doch muss ich langsam auch wieder raus aufs Rad und ab zum Boot!

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.