Timealarms.h ab und zu keine aktion

Hallo,

habe hier ein Problem mit timealarms.

er schaltet z.B.
startLichtPanel_1_und_2();
stopLichtPanel_1_und_2();
startNachtLicht();

jedoch bei stopNachtLicht(); kommt es ab und an zu Problemen. Nicht ständig aber ab und zu.

was kann das sein?
kann ich das irgendwo loggen.

Ich kann den Fehler nicht finden. Habe auch überall meine Alarm.delay(xxxx); zumindest im Loop.

da ich einige Sensoren habe die ich ständig abfrage, würde ich auch gerne bei Antwortproblemen das Programm weiter laufen lassen.

Bei den DS18B20 Sensoren habe ich bezüglich Antwortzeiten keine Probleme bemerkt. Nach x anfragen erhalte ich mal bei einem Sensor einen Error. Das lkiegt aber bei mir an der Busverkabelung, die ist an ein zwei Stellen etwas zu lang und ich musste mit Pull-Ups arbeiten.

Bei den BME680 Sensoren die ich habe, (die sind jetzt nicht aktiv da ich nicht sicher war) bekomme ich ab und an einen Hänger im seriellen Monitor wenn er z.B. einen Gas-Wert nicht liefern kann.
da müsste ich noch eine Routine einbauen die sowas abfängt.

aber das wäre auch das einzigste mit den DS18B20 Sensoren was mir dazu einfällt denn die BME680’er sind nicht in Betrieb.

Grüße sepp


code.txt (21.8 KB)

Hi

Was denkst Du werden wir jetzt mit Deinem Sketch machen?
Nicht nur, daß Er mit >20kB doch schon Einer der etwas ausgefresseneren Listings ist.
'Kommt Es zu Problemen' kann ja nun doch auch etwas ausgefeilter umschrieben werden.

MfG

postmaster-ino:
Was denkst Du werden wir jetzt mit Deinem Sketch machen?

Was schon, analysieren, optimieren, am besten richtig aufpimpen und neuschreiben.

Nach 68 Posts und ein Jahr im Forum sollte man doch wissen, wie es geht, ein Problem zu posten.

postmaster-ino:
Hi

Was denkst Du werden wir jetzt mit Deinem Sketch machen?
Nicht nur, daß Er mit >20kB doch schon Einer der etwas ausgefresseneren Listings ist.
'Kommt Es zu Problemen' kann ja nun doch auch etwas ausgefeilter umschrieben werden.

MfG

kann ich nicht nachvollziehen.
Um einen Fehler finden zu können braucht man den Code...
soll ich den Code um 80% kürzen und nur mit timealarm bestücken. ?
super dann stelle ich hier die sample-datei der Lib ein

Hi

Na super - also bist Du echt der Meinung, daß wir hier, wie ElEspanol Das schrieb (allerdings würde ich darin Ironie sehen), Deine Arbeit machen sollen?

WENIGSTENS den besch.... Fehler solltest Du doch beschreiben können - Du bist Der, Den Dieser stört - mir gefällt der Sketch so - ok, habe Ihn mir nicht angeschaut, aber dafür sieht Der doch ganz gut aus, oder?

Soll heißen: Unter den gebotenen Arbeitsbedingungen musst Du auf einen anderen Clown warten - und ich auf einen anderen Zirkus - oder eigene Probleme angehen, wäre definitiv eine bessere Idee, als hier ohne Mitarbeit des Fragesteller Jagd auf unbekannte Probleme machen zu wollen.

MfG

Neee....dein Sketch ist schon ok.
Nur könntest du ein paar mehr Fehlerbeschreibungen geben, als nur "kommt ab und zu zu Problemen".
Z.B. wann und wo treten Probleme auf ?
Hast du ein debugging mit dem Seriellen Monitor vorgenommen ?
Was hast du da festgestellt ?

Oder möchtest du, das wir das für dich machen ?

HotSystems:
Neee....dein Sketch ist schon ok.
Nur könntest du ein paar mehr Fehlerbeschreibungen geben, als nur "kommt ab und zu zu Problemen".
Z.B. wann und wo treten Probleme auf ?
Hast du ein debugging mit dem Seriellen Monitor vorgenommen ?
Was hast du da festgestellt ?

Oder möchtest du, das wir das für dich machen ?

Hallo,
erstmal Danke für die Tipps, was mir zeigt das man doch Interesse hat einen Newbie zu helfen.
bin zwar hier schon einige Zeit aber beruflich bedingt kam ich nur sporadisch dazu an dem Programm und somit meinen Arduino-Kenntnissen zu arbeiten.
Sorry!

Nein, ein debugging habe ich nicht gemacht.
Werde ich gleich mal machen.
Ich glaube aber fast dass es nicht an meinem code ansich liegt sondern eher daran das viele wichtige Infos zu timealarms nicht in der Doku sondern mehr in den Posts bei der Lib-seite unter github zu suchen sind.

Ich glaube es liegt an meinen Wartezeiten.
Ich habe gerade was gelesen das wohl bei Alaram.delay(groesser_als_500) es zu einem softreset kommt und dann geht da nix mehr
ich werde mal im Netz suchen wie ich das mit dem Debug machen muss und dann hier wieder berichten

Bis jetzt habe ich nur festgestellt

  • die Alarme funktionieren mal.... und funktionieren mal nicht. Es kann sein das ich jetzt teste und es geht alles und morgen nicht.
    Wie z.B. heute... da wurde nicht nur der eine Alarm sondern auch ein zweiter nicht ausgelöst. Es gab Tage da wurde nur 1 Alarm nicht ausgelöst. Man kann es also nicht genau orten.

Nein ich möchte nicht das ihr das für mich macht, aber ich hoffe darauf das man mich in die richtige Richtung schiebt wo ich den Fehler auch zu suchen habe. Das würde mir schon helfen.

postmaster-ino:
Hi

Na super - also bist Du echt der Meinung, daß wir hier, wie ElEspanol Das schrieb (allerdings würde ich darin Ironie sehen), Deine Arbeit machen sollen?

WENIGSTENS den besch.... Fehler solltest Du doch beschreiben können - Du bist Der, Den Dieser stört - mir gefällt der Sketch so - ok, habe Ihn mir nicht angeschaut, aber dafür sieht Der doch ganz gut aus, oder?

Soll heißen: Unter den gebotenen Arbeitsbedingungen musst Du auf einen anderen Clown warten - und ich auf einen anderen Zirkus - oder eigene Probleme angehen, wäre definitiv eine bessere Idee, als hier ohne Mitarbeit des Fragesteller Jagd auf unbekannte Probleme machen zu wollen.

MfG

ich sagte doch oben schon das man den Fehler nicht genau lokalisieren kann.
Mal funktioniert der Alarm bzw. die Alarme mal nicht.

um es zu testen habe ich die Zeiten verkürzt.
Da geht es einwandfrei.
Lass ich die Zeiten so dass mehrere Std Abstände zw. den alaramen liegen dann geht mal der eine Alarm und der andere nicht oder es gehen mal beide nicht.

Ich glaube es liegt an den Alaram.delay(sind_groesser_als_500_millis).
das liest man aber leider nicht in der Doku. Un dein debugging habe ich leider nicht gemacht.
Das muss ich jetzt über den Feiertag nachholen

Bei Fehlern die nur sporadisch in so langen Zeiträumen auftreten, ist debuggung langwierig und lustraubend. Da ist es oft einfacher, eine andere Lib zu suchen oder selbst was zu schreiben.

Hi

Verdacht: Wenn bei längeren Zeiten der Fehler auftaucht, hat vll. der Typ einer Variable damit was zu tun - ggf. ist darin nicht genug Platz.
millis()-Vergleiche mit z.B. uint16_t klappen nur 65535ms lang, danach läuft Das über.
Sinnvoll ist hier, Alles, was mit millis() zu tun hat, im gleichen Datentyp, wie millis(), abzuhandeln - wenn's bei kurzen Wartezeiten auch zwei Byte kostet (uint32_t statt uint16_t).
Vll. ist's was in der Richtung.

MfG

postmaster-ino:
Hi

Verdacht: Wenn bei längeren Zeiten der Fehler auftaucht, hat vll. der Typ einer Variable damit was zu tun - ggf. ist darin nicht genug Platz.
millis()-Vergleiche mit z.B. uint16_t klappen nur 65535ms lang, danach läuft Das über.
Sinnvoll ist hier, Alles, was mit millis() zu tun hat, im gleichen Datentyp, wie millis(), abzuhandeln - wenn's bei kurzen Wartezeiten auch zwei Byte kostet (uint32_t statt uint16_t).
Vll. ist's was in der Richtung.

MfG

ja, ich glaube fast bzw. bin sicher das es nicht an timealarms liegt sondern an meinem Programm.
Hatte nun das Problem mit Sensoren (BME680) sowie mit oled-displays.
Ich lies mir jetzt über Nacht mal alles auf den Seriellen Monitor ausgeben.
Siehe da. Bei den OLED-Displays ist wohl irgend ein Buffer übergelaufen oder es war eine Variable schuld, dann stoppte die Ausgabe und somit wohl das Programm.

Als Timealarms in Kombi mit Sensoren lief hatte ich ab und an einen Hänger als die GAS-Werte abgefragt wurden, dann funktionierte timealarms auch nicht.

Wie findet man solche Fehler?

du bist auf einem MEGA oder?

sepp01:
Wie findet man solche Fehler?

mehr serielle Ausgaben und beobachten wo der Fehler auftritt.

Was mir so generall am Sketch auffällt:

Variablen: such mal jedes int und überlege dir, ob es wirklich ein int sein muss, brauchst du den negativen Wertebereich, müsen es wirklich zwei Byte sein? oder reicht ein uint8_t oder int8_t vieleicht auch.

Auch auf deine mehrdimensionale Arrays achten!

Meiner Meinung fehlen auch viele const.

Such dir mal ein Beispiel mit den DS Sensoren, wo man die Adressen auch in Array packen kann, damit du von den vielen Codeduplikaten wegkommst und nur in entsprechenden schleifen über alle Sensoren iterieren kannst.

Und überarbeite deine Seriellen Ausgaben und verschiebe Fix-Texte mit dem F-Macro in den Programmspeicher. --> google f-macro arduino

noiasca:
Variablen: such mal jedes int und überlege dir, ob es wirklich ein int sein muss, brauchst du den negativen Wertebereich, müsen es wirklich zwei Byte sein? oder reicht ein uint8_t oder int8_t vieleicht auch.

Bei Gefahr eines Überlaufens würde ich eher zunächst alles auf 32bit Wertebereich umstellen.
Und den Index von Arrays explizit seriell nach jeder Änderung des Indexwertes ausgeben, evtl. Noch mit dem entsprechenden Arrayinhalt.

Immer vorausgesetzt, es ist genug Speicherplatz da. Den freien Speicherplatz ausgeben lassen, kann auch helfen.

wenn er jedes int wie angesprochen kontrolliert, kann er ja feststellen, ob das int richtig ist, oder ob er weniger oder mehr benötigt. Im überwiegenden Fall wird es weniger also ein 8bit sein. Und dieses augenscheinliche habe ich angeraten.

"Alles auf 32bit" umstellen finde ich sinnarm.

ElEspanol:
Bei Gefahr eines Überlaufens würde ich eher zunächst alles auf 32bit Wertebereich umstellen.

Was ist an diesem Tipp sinnarm?
Versetze dich in die Lage von jemand, der weniger weiss als du, u.U. nicht mal überblicken kann, was für ein Wertebereich notwendig ist. Oder durch Fehler in der Berechnung der Wertebereich überschritten wird. Dann habe ich lieber 32bit und sehe klar, dass der Wert nicht sein kann als ein falscher Wert in 8bit, dem man nicht gleich seine Unplausibilität ansieht.

noiasca:
du bist auf einem MEGA oder?

mehr serielle Ausgaben und beobachten wo der Fehler auftritt.

Was mir so generall am Sketch auffällt:

Variablen: such mal jedes int und überlege dir, ob es wirklich ein int sein muss, brauchst du den negativen Wertebereich, müsen es wirklich zwei Byte sein? oder reicht ein uint8_t oder int8_t vieleicht auch.

Auch auf deine mehrdimensionale Arrays achten!

Meiner Meinung fehlen auch viele const.

Such dir mal ein Beispiel mit den DS Sensoren, wo man die Adressen auch in Array packen kann, damit du von den vielen Codeduplikaten wegkommst und nur in entsprechenden schleifen über alle Sensoren iterieren kannst.

Und überarbeite deine Seriellen Ausgaben und verschiebe Fix-Texte mit dem F-Macro in den Programmspeicher. --> google f-macro arduino

ok, vielen Dank , das ist schonmal ein echter Tipp
und Ja, ich verwende einen Mega und ja meine variablen sind rein gar nicht groß auf Sinnigkeit angelegt, somndern nur erstmal hauptsache eine variable wo das ergebnis rein passt .
gebe zu das dies schlampig ist.

jetzt aber die Fragen:

Ich muss mit Zeiten rechnen und verwende hier die timelib.h
und bekomme beim kompilieren diese Warnmedlung
xxxxxxxxx: warning: large integer implicitly truncated to unsigned type [-Woverflow]

T3.Year = 2019;
verstehe ich nicht wieso er meckert
ich habe hier keine negative Zahl also ohne Vorzeichen , sollte doch passen oder?

gibt es einen Link wie man so ein Programm richtig aufbaut.
Die Beispiele die ich im Netz gefunden habe beschreiben nur "3 zeilen"-Programme, das hilft mir recht wenig.

Ps.
wie meinst du das mit den mehrdimensionalen arrays?

diese dienen nur dazu die Pins des Arduinos zu halten damit ich einen Stufentrafo schalten kann.
Was habe ich da falsch gemacht? bzw. wie macht man es besser?

zu
F-Macro in den Programmspeicher. --> google f-macro arduino

ich habe hier "nur" den Beispielcode von Adafruit für Oled's genommen

ok, ich betreibe 8 davon, vielleicht geht das noch bei einem.
Deswegen ist mir wahrscheinlich nun auch mein Programm ausgestiegen...

in so einem Fall schau ich mir die lib halt an.
wenn ich richtig an bin:

time-master\TimeLib.h

und ich weiters annehme, dass dein T3 zu diesem Struct gehört:

typedef struct  { 
  uint8_t Second; 
  uint8_t Minute; 
  uint8_t Hour; 
  uint8_t Wday;   // day of week, sunday is day 1
  uint8_t Day;
  uint8_t Month; 
  uint8_t Year;   // offset from 1970; 
} 	tmElements_t, TimeElements, *tmElementsPtr_t;

//convenience macros to convert to and from tm years 
#define  tmYearToCalendar(Y) ((Y) + 1970)  // full four digit year 
#define  CalendarYrToTm(Y)   ((Y) - 1970)
#define  tmYearToY2k(Y)      ((Y) - 30)    // offset is from 2000
#define  y2kYearToTm(Y)      ((Y) + 30)

dann ist mir klar warum der Kompiler mit 2019 meckert.

ungeprüft:

 T3.Year                   = CalendarYrToTm(2019);

wäre zum testen.

Ps.
wie meinst du das mit den mehrdimensionalen arrays?

das fand ich böse

int LtiPower[8][2][7]={
                           {{},{31,32,33,34,35,36,37}},
                           {{31},{32,33,34,35,36,37}},
                           {{32,31},{33,34,35,36,37}},
                           {{33,32,31},{34,35,36,37}},
                           {{34,33,32,31},{35,36,37}},
                           {{35,34,33,32,31},{36,37}},
                           {{36,35,34,33,32,31},{37}},
                           {{37,36,35,34,33,32,31},{}}
                           };

da machst 8x2x7 mal 16bit wo aus meiner sicht ein uint8_t (oder von mir aus ein int8_t) auch reicht.
das sind bis zu 112 verschenkte Byte RAM.

ElEspanol:
Bei Gefahr eines Überlaufens würde ich eher zunächst alles auf 32bit Wertebereich umstellen.
Und den Index von Arrays explizit seriell nach jeder Änderung des Indexwertes ausgeben, evtl. Noch mit dem entsprechenden Arrayinhalt.

Immer vorausgesetzt, es ist genug Speicherplatz da. Den freien Speicherplatz ausgeben lassen, kann auch helfen.

ich habe genau dieses Problem in meinem Programm.
ok, jetzt sehe ich zumindest meine Grenzen.

das mit der korrekten Variablendeklaration glaube ich noch hinzubekommen..bis zum mehrdimesnionalen array da hört es dann auf...normal habe ich da konstante Werte im zweistelligen Bereich drin ... .. bis jetzt war es einfach schlampige Programmierung... ich will das nun ändern.

da ich meine Ausgaben wie Temp und schaltzeiten etc. auf OLED's machen möchte, kann ich mich hier nur an Beispielskripts halten.

da sich die werte ändern muss ich es im Loop immer und immer wieder aufrufen... und dann kommt es wohl mit F-makros zum Problem... trotz Google suche habe ich nichts gefunden wie man das löst oder wie man am besten mit OLEDS umgeht wenn man dort immer wiederkehrende Anzeigen hat und wie sich das negativ auf den speicher auswirkt

sepp01:
das mit der korrekten Variablendeklaration glaube ich noch hinzubekommen..bis zum mehrdimesnionalen array da hört es dann auf...normal habe ich da konstante Werte im zweistelligen Bereich drin ... .. bis jetzt war es einfach schlampige Programmierung... ich will das nun ändern.

na komm, statt

int LtiPower[8][2][7]={

eben

uint8_t LtiPower[8][2][7]={

hinzuschreiben

wirst a) verstehen und b) hinschreiben können ^^

noiasca:
in so einem Fall schau ich mir die lib halt an.
wenn ich richtig an bin:

ok darauf hätte ich auch kommen müssen
ich hing aber am Glauben fest das wenn ich den Wert als int deklariere das dies reichen sollte... passt natürlich nicht zum Objekt. das habe ich jetzt gesehen
danke!

noiasca:
das fand ich böse

int LtiPower[8][2][7]={

{{},{31,32,33,34,35,36,37}},
                          {{31},{32,33,34,35,36,37}},
                          {{32,31},{33,34,35,36,37}},
                          {{33,32,31},{34,35,36,37}},
                          {{34,33,32,31},{35,36,37}},
                          {{35,34,33,32,31},{36,37}},
                          {{36,35,34,33,32,31},{37}},
                          {{37,36,35,34,33,32,31},{}}
                          };



da machst 8x2x7 mal 16bit wo aus meiner sicht ein uint8_t (oder von mir aus ein int8_t) auch reicht.
das sind bis zu 112 verschenkte Byte RAM.

ok, jetzt habe ich es begriffen. Die variablendeklaration war eigentlich ein schuss ins Blaue... ich gebs zu.
Wusste nicht das bei einem array sich der Datentyp stets auf den höchsten Wert im array bezieht

wieso schreibt man hier eigentlich dann uint8_t und nicht einfach byte oder unit8?
uint8_t steht doch für unsigend char... ich habe hier aber nur Zahlenwerte stehen würde da nicht byte oder unit8 auch reichen?...
von der Speicherauslastung ist es mir bewusst das beides gleich viel benötigt aber das Char ist mir nicht bewusst