Jemand Erfahrung mit Arduino Programmierung?

Tach zusammen!

Einige kennen bestimmt diese praktischen kleinen Mikrocontroller-Boards, mit denen man viele unterschiedliche elektrische Geräte pimpen, erweitern und steuern kann. Ich selbst hatte mir vor einer Weile ein neues LED-Panel gebastelt, bei dem ich u.a. einen solchen Arduino zur Steuerung verbaut habe.
Funktioniert auch alles soweit tadellos, d.h. LEDs und Lüfter lassen sich per PWM zwischen 0-100% regulieren, kein Problem. Am Wochenende wollte ich dann aber die Software nochmal überarbeiten. Bisher fungiert der Arduino nur als eingebaute Zeitschaltuhr, d.h. zum festgelegten Zeitpunkt schaltet das Panel an oder aus, auf eine zuvor festgelegte Leistungsstufe. Nun wollte ich aber endlich mal eine automatische (exponentiale) Dimmung einbauen (Sonnenauf- bzw. untergang), aber komme damit bisher noch nicht so richtig weiter.
Daher meine Frage: Jemand Erfahrung mit sowas, bzw. Arduino- oder C(++) Programmierung allgemein, um meinen Spaghetticode etwas aufzuhübschen, bzw. mir ein paar Denkanstöße zu geben? Mit (hardwareferner) Java-Programmierung kenne ich mich jedenfalls besser aus, C(++) und dessen Zeigerarithmetik gingen mir schon immer auf den Zeiger.

Ich habe auch einen Raspi, aber der wäre für so ein Panel völliger Overkill. Viel mehr als man wirklich benötigt. Ich werde m.H. des Raspi irgendwann die Arduinos steuern, aber für eine simple Aufgabe wie das Dimmen einer LED, reicht ein Arduino vollkommen aus. Erweitern lässt der sich mindestens genauso gut wie ein Raspi, wenn nicht dank der zahllosen Shields sogar noch besser.

Ich kann später gern mal meinen bisherigen Code-Fetzen hier posten, allzu komplex ist der bisher noch nicht. Liest nur die Zeit von einem RTC-Modul aus und vergleicht sie mit der hinterlegten Sonnenauf- bzw. untergangszeit, und schaltet entsprechend an oder aus.

Ich hatte mir auch schon ein paar Sketche zu ähnlichen Themen angesehen, die mir aber alle aus unterschiedlichen Gründen nicht gefallen haben. Die einen hatten feste (große) Arrays, in denen zu jedem Zeitpunkt x während des Dimmens der Wert y für PWM Duty hinterlegt ist. Völlig umständlich und unflexibel. Andere hatten massiv mit delay() gearbeitet oder noch mehr auf Spaghetticode gesetzt als ich.

Derzeit sieht mein Programm noch so aus, dass ich die beiden Zeitpunkte für Sonnenauf- und untergang festlege, sowie eine Zeitspanne für's Dimmen (z.B. 1 Stunde), mit dem Ziel, dass der Ardu dann selbst alles Nötige berechnet, so dass ich die Dauer auch jederzeit verändern kann, ohne das halbe Programm entsprechend anpassen zu müssen.

Später mehr...

Naja, also im Grunde ist mein Programm noch sehr simpel:

#include <Wire.h>
#include "DS3231.h"   // RTC-Modul


static const byte LED_PIN = 3;
static const byte FAN_PIN = 5;


// LED settings
byte ledOff = 255;
byte ledMinDuty = 230;
byte ledMaxDuty = 0;


// fan settings
byte fanOff = 0;
byte fanMinDuty = 50;
byte fanMaxDuty = 255;


DS3231 clock;
RTCDateTime dt;


long sunrise = 25200;   // 07:00 Uhr
long sunset = 68400;    // 19:00 Uhr


unsigned long lastTime = 0;


void setup( )
{
  Serial.begin(115200);
  clock.begin();
}


// calculate how many seconds after midnight a given time is (0..86400)
unsigned long toSeconds(RTCDateTime time)
{
  unsigned long result = (time.hour*3600L)+(time.minute*60L)+time.second;
  return result;
}


void loop( )
{
  dt = clock.getDateTime();
  unsigned long now = dt.unixtime;


  // every second...
  if(now > lastTime)
  {
    lastTime = now;
    now = toSeconds(dt);


    byte ledDuty = ledMinDuty;
    byte fanDuty = fanMinDuty;


    //sunrise & sunset must have been set and be different from each other
    if( sunrise>0 && sunset>0 && sunrise!=sunset)
    {
      if(sunrise<sunset)
      {
        //before sunrise or after sunset...
        if(now<sunrise || now>sunset)
        {
          ledDuty = ledOff;
          fanDuty = fanOff;
        }
        else
        {
          //else turn lights on
          ledDuty = ledMaxDuty;
          fanDuty = fanMaxDuty;
        }
      }
      else
      {
         // todo: Sonnenuntergang vor Sonnenaufgang (=Nachtbetrieb)
      }
    }
    analogWrite(LED_PIN, ledDuty);
    analogWrite(FAN_PIN, fanDuty);


    // print date
    Serial.print("[");
    if(dt.day<10)Serial.print("0");
    Serial.print(dt.day);    Serial.print(".");
    if(dt.month<10)Serial.print("0");
    Serial.print(dt.month);  Serial.print(".");
    Serial.print(dt.year);   Serial.print(" ");


    // print time
    if(dt.hour<10)Serial.print("0");
    Serial.print(dt.hour);   Serial.print(":");
    if(dt.minute<10)Serial.print("0");
    Serial.print(dt.minute); Serial.print(":");
    if(dt.second<10)Serial.print("0");
    Serial.print(dt.second); Serial.print("] ");


    // print led- and fan duty
    Serial.print("ledDuty: "); Serial.print(ledDuty);
    Serial.print(" fanDuty: "); Serial.print(fanDuty);


    Serial.println();
  }


  // command input
  while(Serial.available())
  {
    String command = Serial.readStringUntil('\n');
    if(command.length()>0)
    {
      command.toLowerCase();
      processCommand(command);
    }
  }
}

Ich hab das Programm noch deutlich gekürzt, um nur den relevanten Teil abzubilden. processCommand() verarbeitet dann noch Befehle wie bei einer Kommandozeile, damit ich auch jederzeit im laufenden Betrieb Variablen wie Sonnenauf- und untergang ändern kann. Soll aber hier nicht weiter stören.

Ach ja, relevant wäre noch die Definition der RTCDateTime, die in der DS3231.h wie folgt definiert ist:

struct RTCDateTime
{
    uint16_t year;
    uint8_t month;
    uint8_t day;
    uint8_t hour;
    uint8_t minute;
    uint8_t second;
    uint8_t dayOfWeek;
    uint32_t unixtime;
};

In den Schleifenteil, den ich mit "//else turn lights on" kommentiert habe, müsste jedenfalls die Berechnung für's Dimmen rein. Ich will jedoch im Idealfall nicht einfach linear dimmen, sondern exponenziell (wenig Steigung am Anfang, immer stärker zum Ende hin).

P.S.: Und ja, ich weiss, dass das sehr murksig geschrieben ist. Wenn ich mal wieder paar Tage Ruhe hab, überarbeite ich v.a. diese hässlichen geschachtelten Schleifen nochmal.

--------------- 13. November 2019, 09:24 ---------------
Okay, ich glaube, jetzt hab ich's.
Ich habe einfach erstmal noch ein paar if-Schleifen eingebaut (juhu! ^^), um herauszufinden, ob ich gerade im Sonnenauf- bzw. untergang bin (sunrise <= now <= sunrise+dimduration), berechne dann, seit wie vielen Minuten schon, setze das in Relation zur dimduration, und erhalte ein float zwischen 0.0 und 1.0, welches den relativen Zeitpunkt während des Auf- oder untergangs darstellt.
Diesen Wert kann man nun in eine beliebige Funktion einsetzen, von der man der Meinung ist, dass sie den Sonnenauf- bzw. untergang am günstigsten abbildet. Ich habe mich zum Testen zunächst für f(x)=x^4 entschieden (siehe Graph). Der daraus resultierende y-Wert ist mein (relativer) PWM-Pegel.
Mein absoluter PWM-Pegel lässt sich damit dann also wie folgt berechnen:

ledDuty = ledMinDuty + y * (ledMaxDuty - ledMinDuty)

Hab das dann gestern mal laufen lassen und sieht bis jetzt auch schon sehr gut aus. Ich werde den PWM-Pegel mal bei nächster Gelegenheit 24h loggen (dafür, und zum Programmieren für den Ardu ist der Raspi z.B. wirklich hervorragend geeignet), und das dann plotten, um zu schauen, ob's auch wirklich das tut, was es soll...

--------------- 13. November 2019, 11:47 ---------------
Kleine Korrektur:

Die obige Formel ist zutreffend für die PWM der Lüfter (fanDuty), statt wie geschrieben "ledDuty".
Der Grund ist, dass die Leistung der Lüfter (rpm) proportional zur angelegten PWM Duty steigt. Bei den LEDs verhält es sich genau anders herum, jedenfalls bei der Verwendung von Meanwell-NTs (Typ AB und Typ B). Dort verhalten sich PWM Duty und tatsächliche Leistung der LEDs (in Watt) genau umgekehrt proportional: LED Duty 0 = P_max und LED Duty 255 = P_min (=aus).

MinDuty musste ich übrigens einfügen, weil sowohl Lüfter, wie auch LEDs ein minimales PWM Level brauchen, um zuverlässig zu laufen. Bei den Lüftern ist dieser minDuty Wert 50, weil darunter die Lüfter z.T. nicht mehr gleichmäßig schnell laufen, uns dann gegen null hin nacheinander ganz stehen bleiben. Bei den LEDs hat sich 230 als optimal herausgestellt, weil darüber die LEDs erst vereinzelt anfangen zu flackern, uns dann ebenfalls bis 255 nacheinander unkontrolliert ausgehen.

Im Fall des Sonnenaufgangs sieht das also aktuell konkret so aus:

//within sunrise
if(now>=sunrise && now<=sunrise+dimDuration)
{
   //how many seconds since sunrise?
   unsigned int sunriseSeconds = now-sunrise;

   //relative progress within sunrise cycle [0.0...1.0]
   float sunriseProgress = (float) sunriseSeconds/dimDuration;

   //rel. duty = sunriseProgress^4
   float relDuty = sunriseProgress * sunriseProgress * sunriseProgress * sunriseProgress;

   ledDuty = ledMinDuty - relDuty*(ledMinDuty-ledMaxDuty);
   fanDuty = fanMinDuty + relDuty*(fanMaxDuty-fanMinDuty);
}

Ich freue mich grundsätzlich über jeden Gleichgesinnten, der im Idealfall auch praktische Erfahrung, notfalls aber auch nur Neugier und Interesse dieser Thematik entgegen bringt.
Wohin genau bei meinem Projekt dabei die Reise geht, darüber habe ich zwar eine grobe Vorstellung, allerdings lasse ich mich da immer auch spontan und in Abhängigkeit meiner (viel zu spärlichen) Freizeit (bei 40+Wochenstunden im Dreischichtdienst) und meinem Gusto leiten. Langfristig gesehen soll aber alles irgendwie primär dem Zweck diesen, die Zahl der benötigten Eingriffe in mein Kämmerlein zu minimieren, und statt dessen (unter best. Prämissen) soweit wie möglich zu automatisieren. Und diese MC-Platinen (ob nun Arduino, ESP32, o.ä.) sind dafür einfach ideal.

Zum eigentlichen Thema:

Elektronisch sieht das bei den Meanwell Typ B+AB NTs folgendermaßen aus: An Dim+ und Dim- (dem Steuerkontakten) liegen 10V an, maximal fließen dabei 100µA (wenn ich mich recht entsinne). Die Bordspannung der MC-Platinen laufen jedoch i.d.R. mit 3,3V oder 5V. Soweit ich mich diesbezüglich belesen hatte, ist die Verwendung eines Optokopplers dabei best practice, weil man damit die 10V des Meanwell Treibers potenzialtechnisch sicher von der jeweiligen Bordspannung des verwendeten MC trennen kann. Kostet auch nur (je nach Bezugsquelle) Centbeträge bis wenige Euro. Ich hatte damals einfach Diese bestellt, aber grundsätzlich funktioniert das mit vielen anderen genauso gut. Die eine Seite des OC hängst Du dabei am Arduino zwischen einen der PWM-Pins deiner Wahl und Ground (mit 560 Ohm Widerstand zwischen dem PWM Pin und dem OC), auf der anderen Seite kannst Du direkt Dim+ und Dim- des Meanwell hängen.

Eine richtige Uhr hat der Arduino leider nicht. Nur einen Zähler, den man auch als Uhr verwenden könnte (soll wohl 2-3 Monate laufen, bevor er überläuft und neu startet. Notfalls ließe sich damit zwar auch eine Uhr improvisieren, denn nach 3 Monaten sollte die Blüte eigentlich durch sein, aber das Wahre wär's nicht, weil auch ein simpler Stromausfall genügen würde, so dass die Uhr mitten drin bei 0 neu starten würde. Dafür gibt's aber RTC-Module, wie z.B. DS3231, die i.d.R. nicht nur mit einer separaten Stützbatterie gegen Stromausfälle abgesichert sind, sondern darüber hinaus auch noch mit integriertem Kalender und Alarmfunktion per Interupt ausgestattet sind (auch wenn ich sie nicht nutze).

Die sekundengenaue Auflösung ist übrigens schon seeeehr großzügig gewählt. Der Arduino läuft mit 16MHz, man könnte also auch mühelos millisekundengenau auflösen.

--------------- 14. November 2019, 16:12 ---------------
Noch sauberer wäre es, wenn man die internen Zählregister des Arduino dazu nutzen würde, einfach in einem fest definierten Intervall (z.B. sekundenweise) einen Interrupt auszulösen, der den Quellcode wieder anschiebt, so dass nicht pausenlos die RTC-Uhr abgefragt wird.
Aber das sind zunächst erstmal nur Kleinigkeiten, der Code funktioniert in der Hinsicht auch auch so erstmal problemlos.
Ansonsten ist das kein Schönheitsfehler, Diese MCs funktionieren nun einmal grundsätzlich so. Es gibt eine Initialisierungsfunktion setup(), die nur einmalig bei Start und Reset aufgerufen wird, uns eine Hauptschleife loop(), die endlos aufgerufen wird, und in der man auf künstliche Verzögerungen wie delay() o.ä. verzichten sollte, sondern lieber mit Interrupts arbeiten sollte.

Was den Quellcode angeht:
Grundsätzlich hast Du z.B. bei den Konstanten Recht. So ganz konstant möchte ich aber nicht alle haben. maxLedDuty (und analog dazu maxFanDuty) z.B. passe ich aktuell lieber noch anhand der jeweiligen Temperaturverhältnisse manuell an. Wenn es zu warm ist/wird, setze ich diese Obergrenze einfach herab. Später*) wird das auf Grundlage von Sensordaten auch automatisch erfolgen.
Was die Funktionsbenennung und -kapselung angeht, hast Du natürlich auch Recht.
Bezüglich der if-Abfrage: die kann eigentlich sogar ganz raus. Die Schleifen-Kaskade in ihrer jetzigen Form muss eh logisch nachvollziehbarer überarbeitet werden. Hat aber im Moment gerade erstmal keine allzu hohe Prio, denn zum Glück läuft das ganze jetzt soweit erstmal recht zufriedenstellend und stabil.

*) Ich will's ja aufgrund meiner Zufriedenheit keinesfalls beschwören, aber sobald mein TD Silent eines Tages mal den Geist aufgeben sollte, wird ein EC-Lüfter seinen Job übernehmen, der dann natürlich ebenso einen Arduino rangebastelt bekommt. In meiner über der Blütekammer liegenden Vegi-Kammer tut aktuell noch ein Mars COB seinen Dienst. Mit dem bin ich zwar prinzipiell auch sehr zufrieden, jedoch soll das irgendwann auch noch gegen ein computergesteuertes Licht (vorauss. auch QB288) ersetzt werden.
Habe ich dann erst 2x Licht, Abluft, und noch ein paar Sensordaten (haupts. Temp. & RLF) unter Kontrolle, lässt sich auch insgesamt alles viel effizienter kontrollieren und steuern. Ich möchte z.B. (u.a.) auch noch einen Stealth Mode für meine Kammer einbauen, so dass auf externen Knopfdruck augenblicklich alle meine Gerätschaften auf Minimum gedimmt werden (ohne sie jedoch ganz auszuschalten), so dass sie geräuschtechnisch nicht mehr wahrnehmbar sind. Dann bräuchte ich nur noch mein Kämmerlein abschließen und könnte notfalls sogar bedenkenlos Handwerker unbeaufsichtigt in meiner Bude lassen.

Zitat von Razor59

Moin !
Du könntest ja hier mal wegen der Programmierung des Arduino - Boards rein schauen oder auch Fragen wie das geht . Die benutzen diese Boards ja auch mit ihren 3 D Drucker . reprap deutschsprachiges Forum

--------------- 21. November 2019, 10:37 ---------------
Noch was ,ich hatte mir ja mal einen großen Zigarren Humidor gebaut und in dem Zigarren Forum war auch ein Elektronic Spezi ,der für uns ein Board gebastelt hat. Das hat so um 90 € gekostet . Damit konnten wir die Temperatur und Luftfeuchtigkeit im Humidor steuern , überwachen . Mit Alarmfunktion und Lüftersteuerung . Wenn der noch lebt könnte ich den ja mal fragen ,ob er uns so etwas braten könnte mit seinem Lötkolben .
Da müssen wir uns aber überlegen was für Funktionen dieser Controller haben soll für den Grow und ich gebe das denn weiter .

Für den Moment funktioniert erstmal alles wie gewollt. Danke trotzdem für den Tipp.

Zitat von Wulfman77

Meine älteren Steuerungen liefen/laufen ja auch noch auf einem Arduino UNO bzw. Mega2560, aber mittlerweile
habe ich alles auf ESP8266 umgestellt
Das hat den Vorteil, dass ich meine Steuerungenüber WLAN verwalte und so jederzeit alles kontrollieren
und notfalls auch eingreifen kann, wenn nötig sogar übers Handy wo immer ich bin auf der Welt

War auch meine erste Intention. Wollte an mein Panel noch ein Bluetooth Modul stecken, später hatte ich dann auch über die ESP32 nachgedacht, am Ende dann aber alles wieder verworfen. In meine Kammer sollen noch mindestens 2-3 solcher (o.ä.) MC-Platinen verbaut werden, und mir bereitete dann irgendwann der Gedanke Bauchschmerzen, dort drin dann Funkfeuer zu haben.
Werde daher wohl doch lieber eine einfache Verkabelung (I²C oder so) für meine Kammer wählen, mit Raspberry Pi dann als Gateway mit Wifi-Option.

Zitat von Wulfman77

wenn dich die HF Strahlung, warum auch immer , wirklich stöhren sollte, kannst du den , ausserhalb der Box
installieren und nur die Steuerleitungen in die Box legen

Naja. Ich versuche einfach, solche Funkquellen grundsätzlich auf ein Minimum zu reduzieren, statt nach und nach meine ganze Bude damit im 24/7 Dauereinsatz zu bestücken. In diesem Fall halte ich das einfach für unnötig.

Charmanter fände ich da eine Lösung, bei der man die Wifi-Funktionalität optional dazu hätte, statt sie als integralen Kernbestandteil nutzen zu "müssen".

Ja, richtig. Grundsätzlich soll bei mir alles offline bleiben, und nur per Kabel untereinander kommunizieren.
Aber wenn mir mal wieder richtig langweilig werden sollte in ein paar Monaten (und die Urlaubszeit wieder losgeht), wäre ja auch ein optional zuschaltbares Webinterface interessant, über das ich dann immer die wichtigsten Werte im Blick habe. Und das wäre dann wohl per WiFi zwischen Raspi und Router am einfachsten.
Aber ist halt erstmal nur Spinnerei. Keine Ahnung, wie weit es dahin gehend je kommen wird...