Umbau AquaGrow Mini Platine
- Ersteller shooter
- Erstellt am
shooter
Member
Hi Rene,
sorry grad viel um die Ohren...
Ich habe inzwischen Display An/Aus auf Taste * implementiert....auch nur weil mir das Display nachts einfach zu hell war und es ohnehin nicht immer an sein muss..
Wenn das für Dich interessant ist schick ich Dir den code.
Ansonsten nix neues, aktuell ist der Wunsch da auf Sommerzeit umzubauen....mal sehen welche Taste dafür noch übrig ist
Gruß,
Flo
sorry grad viel um die Ohren...
Ich habe inzwischen Display An/Aus auf Taste * implementiert....auch nur weil mir das Display nachts einfach zu hell war und es ohnehin nicht immer an sein muss..
Wenn das für Dich interessant ist schick ich Dir den code.
Ansonsten nix neues, aktuell ist der Wunsch da auf Sommerzeit umzubauen....mal sehen welche Taste dafür noch übrig ist
Gruß,
Flo
omega
Well-Known Member
Hallo Flo,
Grüße, Markus
dafür nutze ich den Timer, den ich für die Softwareuhr, das Dimmen und die Tasterentprellung eh brauche. Das Display wird 30s nach dem letzten Tastendruck ausgeschaltet. Bei einem Tastendruck wird es wieder eingeschaltet, wobei dieser eine Tastendruck geschluckt wird (keine Funktion auslöst), da ich ja i.d.R. nicht mehr weiß, in welchem Zustand sich das Menü etc. vorher befand.shooter":3r1t7vjf schrieb:
Grüße, Markus
MajorMadness
Active Member
Ja du musst nur minus des LCD an einen npn transistor hängen und im loop prüfen ob bestimmte Zeit verstrichen ist. Dafür muss man nicht extra mit Interrupts ect experimentieren oder timer missbrauchen.
Uint32 lastpress; vor setup und dann beim auslesen der buttons
Lastpress =millis();
Bisschen weiter unten
If (lastpress+30000<millis(){ digitalWrite(LCD, LOW);}
Also so ungefähr. Ist nur Pseudocode da ich am Handy bin.
Achja und wichtig: beim abschalten des LCD sollte das Menü auf oberste ebene zurück gesetzt werden. Sinnvoller als das man aus versehen was umstellt.
Uint32 lastpress; vor setup und dann beim auslesen der buttons
Lastpress =millis();
Bisschen weiter unten
If (lastpress+30000<millis(){ digitalWrite(LCD, LOW);}
Also so ungefähr. Ist nur Pseudocode da ich am Handy bin.
Achja und wichtig: beim abschalten des LCD sollte das Menü auf oberste ebene zurück gesetzt werden. Sinnvoller als das man aus versehen was umstellt.
omega
Well-Known Member
Hallo Moritz,
Und wieso missbrauchen? Wozu ist ein Timer denn sonst da? Wenn Du Deine Anwendung aber lieber pollen und sie so unsinnig CPU-Zeit verbraten lassen willst, statt vorhandene Resourcen sinnvoll zu nutzen, bitte.
Grüße, Markus
wieso experimentieren? Interrupts gehören zu einem µC wie seine Adressleitungen.MajorMadness":3v6s9eyq schrieb:
Und wieso missbrauchen? Wozu ist ein Timer denn sonst da? Wenn Du Deine Anwendung aber lieber pollen und sie so unsinnig CPU-Zeit verbraten lassen willst, statt vorhandene Resourcen sinnvoll zu nutzen, bitte.
Da ist es ja, das Gepolle.
Grüße, Markus
MajorMadness
Active Member
Poste doch endlich mal deinen kompletten Quelltext. Dann sieht man wie du es gelöst hast, wovon du redest und andere können sich das rauskopieren wovon du sprichst.
Ich habe dich ja schonmal drum gebeten dein Projekt vor zu stellen. Damit meinte ich nicht du sollst irgendwas pseudohaftes in das Thema eines anderen schreiben sondern dir wirklich mal die Mühe machen und ein Thema eröffnen wo du deinen Code postest, was warum geschied und wie man damit ne dimmung/steuerung/whatever baut. Mir geht es nicht darum deinen Code zu zerreissen aber wenn du immer meinst meiner ist so schlecht: Zeig doch einfach wie man es richtig macht. :bier:
Ich habe dich ja schonmal drum gebeten dein Projekt vor zu stellen. Damit meinte ich nicht du sollst irgendwas pseudohaftes in das Thema eines anderen schreiben sondern dir wirklich mal die Mühe machen und ein Thema eröffnen wo du deinen Code postest, was warum geschied und wie man damit ne dimmung/steuerung/whatever baut. Mir geht es nicht darum deinen Code zu zerreissen aber wenn du immer meinst meiner ist so schlecht: Zeig doch einfach wie man es richtig macht. :bier:
omega
Well-Known Member
Hallo Moritz,
Das entscheidende ist das Konzept selbst und nicht, wie es umgesetzt wurde. Für eine Umsetzung gäbe es zig Möglichkeiten, meine ist nur eine davon. Die jeweilige Umsetzung ist ja nur noch Detailkram, in dem man sich verlieren wird, wenn man versucht, daran das Konzept zu durchschauen.
Hier ist ein schöner Artikel bzgl. Superloop vs. Event-Driven.
Kern des ganzen bei mir ist die EventQueue. Die hat die Methoden
- void addListener( EventListener *listener, int mask)
- void addEvent( Event *event)
- void dispatch()
Von der EventQueue (eine Template Class) gibt es eine einzige globale Instanz.
Der Timer erzeugt in seiner ISR TimerEvents und stellt sie per addEvent in die EventQueue.
Der Tastaturtreiber ist einer der EventListener, der sich für TimerEvents interessiert und erzeugt selbst auch Events: KeyEvents.
Anderer Klassen interessieren sich für KeyEvents, leiten also auch von EventListener ab. Und erzeugen u.U. auch wieder Events, z.B. einen LightSettingsEvent aufgrund der Änderung der Lichtzeiten/parameter über das Menü.
Für einen LightSettingsEvent gibt es natürlich auch einen EventListener.
Initialisisert/instantiiert/registriert wird das ganze Klasse für Klasse wie die Abhängigeiten jeweils sind:
- setup() instantiiert die GUI-Klasse
- die instantiiert das LCD, das Menü, den Timer, den LightTimerStorage, den DimmerStorage, das Light, die RTC, den Tastaturtreiber
- die wiederum andere Klassen, die sie benötigen, das Light z.B. den Dimmer, der Dimmer die Dimm-Effekte
- LightTimerStorage und DimmerStorage registrieren Speicherbereiche im globalen Objekt EEProm
- manche von ihnen registrieren sich bei der EventQueue als EventListener
usw.
Die main-Loop macht nichts anderes, als dispatch der EventQueue aufzurufen. Bis auf die Timer-ISR passiert alles andere in den EventListenern.
Die Verarbeitung eines Events wird vollständig abgeschlossen, bevor der nächste Event verarbeitet wird. Das schont den Stack und sorgt für Status- und Datenkonsistenz.
Im Groben funktioniert jede Anwendung so, die dem Event Driven Design folgt. Nur heißen dort die Klassen anders und interagieren anders miteinander weil es eine andere Anwendung ist und/oder der Entwickler ein anderer ist.
Vielleicht beschäftigst Du Dich etwas mehr mit solchen Konzepten. Dann brauchst Du den Code anderer nicht mehr sondern kannst sie selbst umsetzen.
Grüße, Markus
was soll denn der Quelltext bringen, wenn man das dahinterliegende Konzept nicht kennt bzw. dessen Beschreibung nicht verstanden hat? Man könnte ja auch mal nachfragen.MajorMadness":2jiun8i5 schrieb:
Das entscheidende ist das Konzept selbst und nicht, wie es umgesetzt wurde. Für eine Umsetzung gäbe es zig Möglichkeiten, meine ist nur eine davon. Die jeweilige Umsetzung ist ja nur noch Detailkram, in dem man sich verlieren wird, wenn man versucht, daran das Konzept zu durchschauen.
Hier ist ein schöner Artikel bzgl. Superloop vs. Event-Driven.
Kern des ganzen bei mir ist die EventQueue. Die hat die Methoden
- void addListener( EventListener *listener, int mask)
- void addEvent( Event *event)
- void dispatch()
Von der EventQueue (eine Template Class) gibt es eine einzige globale Instanz.
Der Timer erzeugt in seiner ISR TimerEvents und stellt sie per addEvent in die EventQueue.
Der Tastaturtreiber ist einer der EventListener, der sich für TimerEvents interessiert und erzeugt selbst auch Events: KeyEvents.
Anderer Klassen interessieren sich für KeyEvents, leiten also auch von EventListener ab. Und erzeugen u.U. auch wieder Events, z.B. einen LightSettingsEvent aufgrund der Änderung der Lichtzeiten/parameter über das Menü.
Für einen LightSettingsEvent gibt es natürlich auch einen EventListener.
Initialisisert/instantiiert/registriert wird das ganze Klasse für Klasse wie die Abhängigeiten jeweils sind:
- setup() instantiiert die GUI-Klasse
- die instantiiert das LCD, das Menü, den Timer, den LightTimerStorage, den DimmerStorage, das Light, die RTC, den Tastaturtreiber
- die wiederum andere Klassen, die sie benötigen, das Light z.B. den Dimmer, der Dimmer die Dimm-Effekte
- LightTimerStorage und DimmerStorage registrieren Speicherbereiche im globalen Objekt EEProm
- manche von ihnen registrieren sich bei der EventQueue als EventListener
usw.
Die main-Loop macht nichts anderes, als dispatch der EventQueue aufzurufen. Bis auf die Timer-ISR passiert alles andere in den EventListenern.
Die Verarbeitung eines Events wird vollständig abgeschlossen, bevor der nächste Event verarbeitet wird. Das schont den Stack und sorgt für Status- und Datenkonsistenz.
Im Groben funktioniert jede Anwendung so, die dem Event Driven Design folgt. Nur heißen dort die Klassen anders und interagieren anders miteinander weil es eine andere Anwendung ist und/oder der Entwickler ein anderer ist.
Vielleicht beschäftigst Du Dich etwas mehr mit solchen Konzepten. Dann brauchst Du den Code anderer nicht mehr sondern kannst sie selbst umsetzen.
Ich komme nicht dazu, was vernünftiges auf meine Homepage zu stellen. Und den Quelltext allein werde ich nicht weitergeben.
Grüße, Markus
shooter
Member
Sooo...weiter im Text:
Ich habe heute mal ein paar Minuten Zeit gefunden und mich der Sommerzeit gewidmet.
Zunächst dachte ich daran die Zeitumstellung Sommer = MEZ (UTC+1) +1 mit einem Tastendruck zu realisieren...
Nach dem ich mal ein wenig gestöbert habe entschied ich mich aber dagegen.
Ich verwende nun die neue DS1307new Bibliothek um die Sommerzeit zu ermitteln, das geht recht einfach und auf die Sekunde genau!
Die Zeitumstellung wird ab sofort also automatisch bewerkstelligt.
Dazu mal ein paar Gedanken:
Ich stelle die interne Uhr bei der Konfiguration also nicht zwingend auf die Aktuelle (Sommer-) Zeit ein sondern auf die MEZ. Die Berechnung der Sommerzeit erfolgt dann automatisch.
Um nicht andauern (gut...zweimal im Jahr) die RTC umstellen zu müssen arbeite ich Systemweit mit meiner eigenen Zeit, welche natürlich auf der RTC basiert (wird am Anfang eines jeden loops geholt) aber dann noch an Sommer- bzw. Winterzeit angepasst wird.
So muss ich also nur noch einmal die Uhrzeit in der RTC setzen und habe ein (Batterie-) Leben lang Ruhe!
Die Umstellung auf die neue DS1307new Bibliothek war ein wenig tricky, aber hat ja alles geklappt.
Wer den aktuellen Code haben möchte bitte wieder per PN an mich
Gruß,
Flo
Ich habe heute mal ein paar Minuten Zeit gefunden und mich der Sommerzeit gewidmet.
Zunächst dachte ich daran die Zeitumstellung Sommer = MEZ (UTC+1) +1 mit einem Tastendruck zu realisieren...
Nach dem ich mal ein wenig gestöbert habe entschied ich mich aber dagegen.
Ich verwende nun die neue DS1307new Bibliothek um die Sommerzeit zu ermitteln, das geht recht einfach und auf die Sekunde genau!
Die Zeitumstellung wird ab sofort also automatisch bewerkstelligt.
Dazu mal ein paar Gedanken:
Ich stelle die interne Uhr bei der Konfiguration also nicht zwingend auf die Aktuelle (Sommer-) Zeit ein sondern auf die MEZ. Die Berechnung der Sommerzeit erfolgt dann automatisch.
Um nicht andauern (gut...zweimal im Jahr) die RTC umstellen zu müssen arbeite ich Systemweit mit meiner eigenen Zeit, welche natürlich auf der RTC basiert (wird am Anfang eines jeden loops geholt) aber dann noch an Sommer- bzw. Winterzeit angepasst wird.
So muss ich also nur noch einmal die Uhrzeit in der RTC setzen und habe ein (Batterie-) Leben lang Ruhe!
Die Umstellung auf die neue DS1307new Bibliothek war ein wenig tricky, aber hat ja alles geklappt.
Wer den aktuellen Code haben möchte bitte wieder per PN an mich
Gruß,
Flo
MajorMadness
Active Member
Hehe kann mir vorstellen das es tricky war. Ich hab einiges in der RTC geändert gehabt. Das hat mir aber paar bytes an Speicher gespart. Die ds1307 hat leider nen guten overload den ich nicht brauchte. Ich Frage mich aber warum umstellen? Ich hab mein Aquarium absichtlich immer gleich an, aus. Halt Richtung Natur. Gut, im Sommer oder Winter sehe ich ne Stunde mehr oder weniger nix wenn ich im Wohnzimmer bin da es schon aus ist aber das stört mich jetzt nicht so sehr... Eher noch das es immer 8stunden Beleuchtung hat und nicht einen Jahresverlauf gibt...
shooter
Member
Hallo Moritz!!!
tricky hielt sich in Grenzen...ich musste mir nur ein neuen TimeStamp basteln.
Ansonsten bleibt zu sagen das die ganze Geschichte prozentual gesehen keinen zusätzlichen Speicher verbraucht! Vor und nach dem Umbau bleibe ich bei 92%...inzwischen ist es mehr, dazu aber gleich.
Warum also das ganze?
Nun ich stelle meine Beleuchtungszeit so ein das ich die Lichtphase für mich zum "schauen" maximal ausnutzen kann, also dann wenn ich zu hause bin! Dazu kommt dann noch das mein Küchenaquarium zusätzlich als Raumbeleuchtung dient...
Darum möchte ich das der Aquarienzeitablauf mit meinem Zeitablauf synchron ist und nicht durch Sommer- und Winterzeit beeinflusst wird.
Nun kommen wir zum nächsten, es gibt wieder ein UPDATE
Diesmal eins was man auch sehen kann. Ich habe die Displayausgabe angepasst:
- Ausgabe Temperatur Sollwert
- Ausgabe ob Sommer- oder Winterzeit (MEZ) oder (MEZ+1)
- Ausgabe der Steckdosenbelegung
Dazu habe ich nochmal Fotos von meinem Aufbau gemacht (allerdings ohne angeschlossene Peripherie...)
Für die Anschlüsse habe ich 6P6C Kabel gewählt, ähnlich Netzwerkkabel bzw. ISDN aber die Dosen dazu sind auch mit 6 Kabelabnehmern belegt!
Hat sich als recht praktisch erwiesen...
Auf den Fotos sollte auch gut zu sehen sein wie was wo am Arduino angeschlossen ist.
Moritz, ist es eigentlich möglich mehr als nur einen Temp-Sensor (da ja eigentlich BUS System) zu betreiben, wenn ja wie?
Gruß,
Flo
tricky hielt sich in Grenzen...ich musste mir nur ein neuen TimeStamp basteln.
Ansonsten bleibt zu sagen das die ganze Geschichte prozentual gesehen keinen zusätzlichen Speicher verbraucht! Vor und nach dem Umbau bleibe ich bei 92%...inzwischen ist es mehr, dazu aber gleich.
Warum also das ganze?
Nun ich stelle meine Beleuchtungszeit so ein das ich die Lichtphase für mich zum "schauen" maximal ausnutzen kann, also dann wenn ich zu hause bin! Dazu kommt dann noch das mein Küchenaquarium zusätzlich als Raumbeleuchtung dient...
Darum möchte ich das der Aquarienzeitablauf mit meinem Zeitablauf synchron ist und nicht durch Sommer- und Winterzeit beeinflusst wird.
Nun kommen wir zum nächsten, es gibt wieder ein UPDATE
Diesmal eins was man auch sehen kann. Ich habe die Displayausgabe angepasst:
- Ausgabe Temperatur Sollwert
- Ausgabe ob Sommer- oder Winterzeit (MEZ) oder (MEZ+1)
- Ausgabe der Steckdosenbelegung
Dazu habe ich nochmal Fotos von meinem Aufbau gemacht (allerdings ohne angeschlossene Peripherie...)
Für die Anschlüsse habe ich 6P6C Kabel gewählt, ähnlich Netzwerkkabel bzw. ISDN aber die Dosen dazu sind auch mit 6 Kabelabnehmern belegt!
Hat sich als recht praktisch erwiesen...
Auf den Fotos sollte auch gut zu sehen sein wie was wo am Arduino angeschlossen ist.
Moritz, ist es eigentlich möglich mehr als nur einen Temp-Sensor (da ja eigentlich BUS System) zu betreiben, wenn ja wie?
Gruß,
Flo
Anhänge
MajorMadness
Active Member
Klar, ist (eigentlich) Relative einfach: die DS18B20 arbeiten im OneWire Bus, d.h. sie haben alle eigene ID's und über die können viele parllel angesprochen werden. Problem: Ich wollte nicht das der User die ID des Sensors suchen muss und keine Aufwendige Lib verwenden, deswegen greife ich mir einfach den ersten den ich finde, verwende diese Temperatur und ignoriere alles andere. Was du machen müsstest ist meine function get_temp() so umbauen das er auf mehrere ID's und sensoren functioniert. Beispiel dazu findest du u.a. in der Dallas Temperatur Libarie ect http://milesburton.com/Dallas_Temperature_Control_Library
Methode 2 wäre einen 2ten Sensor einfach an 2ten digitalen Pin setzen mit 4,7k Resistor und dann eine 2te instance von onewire und diese verwenden um mit get_temp aus zu lesen.
Methode 2 wäre einen 2ten Sensor einfach an 2ten digitalen Pin setzen mit 4,7k Resistor und dann eine 2te instance von onewire und diese verwenden um mit get_temp aus zu lesen.
