Hi,
stimmt nur bedingt, nach 28 Stunden hat die CO2-Ampel nicht mehr reagiert.
Sascha
Hallo,
kannst Du mir dein Blockly Script schicken? Ich habe die Ampel mit WiFi-Bee und bekommes es nicht hin, das Bee zu aktivieren.
Hallu zusammen,
bei mir läuft die Ampel seit zwei Wochen ohne einfrieren.
und nun gehen wir in die nächste Runde mit dem Test — 5,2 VDC Spannungsversorgung - unveränderter Standard-Aufbau, unverändertes Script - 10cm Usb-Kabel ---- lets go ! (Y) (Startzeit: 18:45 Uhr)
Hi @franki — ich arbeite nicht mit dem Wifi-Bee (also WLAN Anbindung) – ich habe den Lora-Bee (LoRaWAN Netzwerk — thethingsnetwork) … irgendwo gibts im www einen fertigen Blockly-XML mit WLAN – ich such´ Dir den nochmal raus …
@frankl
Das hatte ich ja schon einmal hier: co2-Ampel + WiFi-Bee gepostet.
Und hier: https://sensebox.de/projects/de/2020-11-12-co2-ampel_osem gibts noch einmal mehr Infos dazu 
Hallo,
ich habe den Befehl
Wire.setClock(50000);
gestern Abend eingefügt, aber meine Ampel ist über Nacht leider trotzdem wieder eingefroren.
und auch bei mir gibt es neue Erkenntnisse: der Sensor hat sich trotz der höheren Spannungsversorgung wieder aufgehängt. Er lief mal etwas länger (bis heute früh 8:30 Uhr hat er geschafft … ) … nu bin ich echt ratlos …
Meine Einfrierzeiten schwanken stark. Manchmal nach 4 Minuten, manchmal erst nach mehreren Stunden.
Ich habe mit meiner ersten Programmierung den Sensor ohne delay kontinuierlich abgefragt. Da hat sich das Programm eher schneller aufgehangen als jetzt, wo ich längere delay-Zeiten eingebaut habe.
Vielleicht ist es kein Problem mit der Stromversorgung, sondern ein ganz anderes:
Vielleicht findet in einer Methode der Sensor-Bibliothek eine falsche Typumwandlung statt. Dadurch würde dann Müll in den Speicher geschrieben bzw. aus ihm gelesen. Anfangs mag das noch egal sein, weil der Speicher kaum genutzt wurde. Aber je länger das Programm läuft, desto größer ist die Wahrscheinlichkeit, dass es dadurch zu einem Fehler kommt.
Ohne delay habe ich viel mehr Speicherzugriffe und dadurch eine höhere Wahrscheinlichkeit zum Absturz.
In die Richtung habe ich auch schon mal gedacht. Anfangs habe ich den Sensor auch mehrmals pro Schleifendurchlauf abgefragt, wollte meinem Sohn nicht gleich mit Variablen kommen. Da kam es dann auch nach ein paar Minuten mal zum Absturz. Nach der Umstellung auf 1x pro Scheife und längerer Messdauer lief es dann gefühlt länger.
Um die das-Display-führt-zum-Einfrieren-Theorie zu überprüfen, habe ich mein Display von der MCU abgesteckt und jeglichen mit dem Display in Zusammenhang stehenden Code aus dem Programm entfernt. Leider ist die Ampel nach ein paar Stunden trotzdem eingefroren.
Die CO2-Werte habe ich mir über einen 24-LED-Ring anzeigen lassen (ohne externe Stromversorgung). Um die Aktivität schnell erkennen zu können habe ich zwei LEDs im Wechsel blinken lassen. Neben dem CO2-Sensor waren noch der Beleuchtungssensor, der Umweltsensor BME680 und die SD-Bee verbaut und auf alle wurde auch zugegriffen.
Die Zugriffsfrequenz auf die I2C-Schnittstelle war auf 50 kHz gesetzt.
Gestern Abend habe ich was ähnliches ausprobiert - Display und LED entfernt (physisch), Code unverändert – hier das Ergebniss: — um kurz nach 0 Uhr heut Nacht war Schluß … – Frage an die Technik, Jungs, was gibbet neues ausm Labor !!!
Moin zusammen, ich freu mich sehr dass ihr so aktiv seid und mit beim Aufdecken des Fehler helft!
Ich hab hier noch nichts Neues zu melden bislang außer, dass die Ampel die @swenp mir zur Verfügung gestellt hat, das Wochenende durchgelaufen ist ohne einzufrieren…bin außerdem im Kontakt mit unseren Hardwaredesignern.
1 Like
@Jan: Das habe ich immer gehasst, wenn die Probleme des Kunden bei mir auf dem Tisch nicht nachvollziehbar waren. Du hast aber einen neuen Sketch geladen, oder? Der, der drauf war lief bei mir ja auch.
@jensileinchen, @Philipp2p: Vielleicht mal statt des CO2 Wertes die Temperatur auslesen?
viellecht können wir uns ja auf einen Sketch einigen, den wir alle laufen lassen ? Glaube ja jeder hat sich seinen eigenen gebastelt … Klar, die Übertrage ich ja eh mitm Lora Chip – also Temp, Luftfeuchte und CO2 - ich kann mal „nur“ Temperatur auslesen und übertragen lassen, klar ! – Mache ich heute nachmittag.
ja genau @swenp, ich habe deinen Sketch drauf gelassen. Wenn ihr etwas einheitlich testen wollt, dann benutzt am besten einen von diesen Sketches: https://github.com/sensebox/sensebox-examples/tree/main/co2-traffic-light
Ich lade da gleich noch die .bin Dateien zu hoch, damit wir Fehler mit dem Kompiler ausschließen können!
@Jan: Der Sketch der drauf war hat bei mir ja auch funktioniert, hatte ich dir noch geschrieben. War glaub ich nur Sensor ohne RGB-LED, „from scratch“. Irgendwo auf eurer Homepage hatte ich die „sensebox_co2_ampel_v1.bin“ heruntergeladen, die ist definitiv eingefroren.
@Jan — 17:15 Uhr – Test mit „Deinem“ Sketch vom *.bin aus github läuft ab sofort – da nun keine Lora-Daten mehr gesendet werden kann ich später nicht den genauen Zeitpunkt sagen, wann sich die Ampel aufhängt, wir werden sehen … (ich verwende den RAW, nicht den AVG)
// Nachtrag: 06:13 Uhr — bin nun im Büro, aber um 05:10 lief der Sensor noch !
Bei mir läuft seit heute Morgen ein anderer Test. Ich habe die Datenabfrage durch zwei delay(100) isoliert, um „Wechselwirkungen“ mit anderen Sensoren bzw. Vorgängen zeitlich auszuschließen.
delay(100);
if (airSensor.dataAvailable()) {scd30_co2 = airSensor.getCO2();}
delay(100);
Ob 100 Millisekunden reichen, dass sich die Elektronen von zwei verschiedenen Sensoren nicht begegnen? 
Jedenfalls läuft es seit 14 Stunden 
Mal schauen, wie lange noch. 14 Stunden hatte ich vorher auch schon mal … Ich halte euch auf dem Laufenden.
1 Like
Hätte ich noch meine Sensebox würde ich da mal versuchen, über die eingebauten LEDs eine Art logging einzubauen (sorry für den PseudoCode):
LED1 an
If Sensor.dataavailable()
LED2 an
Sensor.getCO2()
LED2 aus
LED1 aus.
Vielleicht bleibt die Kiste ja immer im gleichen Call stecken, das wär doch was…