mit der Software von @swenp laufen beide Ampeln - scheinen aber zwischendrin wie oben beschrieben einen selbstständigen Neustart zu machen — die eine Ampel steht bei ~48h und die andere bei ~14 ohne das ich manuell Hand anlegen musste !!! diese Lösung von ihm finde ich prima - „muss“ nur noch WLAN /LORA eingebaut werden … .! TOP
Nachdem auch der Jahreswechsel keine Besserung des Ampel-Verhaltens gebracht hat - gibt es denn keine Aussage von „offizieller“ Seite zu diesem Problem? Tendiere dazu, das Teil zurückzusenden.
Für mich ist die Lösung von @swenp nur eine Notlösung - funktionieren sollte die Ampel schon selber.
hier nochmal eine Zwischenstand vom aktuellen Verhalten:
Bausatz 01: mit LoRa Bee: läuft Stabil OHNE LORA mit Software von @swenp
Bausatz 02: mit WLAN Bee: läuft Stabil OHNE WLAN mit Software von @swenp
Bausatz 03: mit WLAN Bee: läuft mit WLAN aber unregelmässiger freeze
Bausatz 04: mti WLAN Bee: läuft seit heute, nachdem 1 Kabel umgebaut wurde (verkehrte/verdrehte Adern) … wir haben am Stecker schwarz und rot getauscht (nun 1:1 zwischen beiden Steckern) und damit läuft der Bausatz — aktuell mit WLAN Bee aktiviert — mal schauen wann der freeze kommt …
/ Nachtrag: der freeze bei 04 kam nun zum ersten mal nach 44 Minuten … GGGGRRRRRR
Danke @mario ! — also Achtung: es sind fehlerhaft konfektionierte Kabel den Bausätzen beigelegt !
Hallo @swenp wäre es möglich deinen Teil-Code für Watchdog zur Verfügung stellen…? Und evtl. für die Uptime. Danke.
Klar, kein Problem:
Für den Watchdog:
#include <Adafruit_SleepyDog.h>
// Am Ende von Setup():
Watchdog.enable(10000);// innerhalb der loop():
Watchdog.reset();
Für die Uptime:
// Deklaration:
unsigned long myTime;
// In loop():
myTime = millis() / 1000 / 60; // in minutes
display.println(„Uptime: " + String(myTime / 60) + " h " + String(myTime % 60) + " min“);
Ein Überlauf findet erst nach 50 Tagen statt, das stört mich daher nicht.
2 Likes
ich habe jetzt mal ein ArduinoIDE Sketch gebaut mit Lora-Unterstützung, Anzeige von Temperatur und Luftfeuchte sowie die Uptime (von @swenp ) auch der Watchdog wie oben beschrieben ist integriert – die Ampel geht heute Abend in den Dauertest — mal schauen was passiert.
https://github.com/jensileinchen/senseBox-CO2-Lora-TTN-Version
unter \SRC\ liegt die INO-Datei von heute (10.01.2021)
Achtung - die Datei ist anonymisiert, Ihr müsst natürlich Eure TTN Credentials noch eintragen !
// edit zwei Stunden später: … einige Male hat er mittlerweile neu gestartet — das einzige was daran nun positiv zu sehen ist das automatisch der Loop neu gestartet wird …
@ all:
Wer hat sich von euch an den Support gewendet und eine Antwort bekommen? Bei mir herrscht Schweigen auf meine Anfrage 
Falls jemand die Ampel bereits zurückgeschickt hat - welche Erfahrungen habt ihr mit der Rückerstattung/Ersatz gemacht?
Ich gehe davon aus, das hier keine Lösung mehr gefunden wird und werde die Ampel dann zurücksenden!
Danke euch allen für die Hilfe!
Moin - tja - @Stephan – ich habe ein Ticket - also eine offizielle Support-Anfrage wurde bereits im November gestellt – ich habe ja sogar danach noch 3 weitere Ampeln gekauft, die aber alle das gleiche Problem haben – mit dem Watchdog kann man zwar die Dinger benutzen, aber leider immer mit dem unguten Gefühl, das ja nur ein Workaround geschaffen wurde, anstatt das Problem und die Ursache zu beheben … Mir macht Testen und Fehlersuche Spaß, aber nicht, wenn Produkte offenbar beim Kunden zuende entwickelt werden …
@mario @Felix @Jan und an das Team — tut sich hier noch was ?? sonst bekommt ihr meine 4 Geräte nämlich auch zurück – ( 1x LoRa und 3x Wlan Ampel …) – Herzlichen Gruß
1 Like
Moinsen, deine Nachricht ist tatsächlich bei uns im Helpdesk hängen geblieben @Stephan! Wir nehmen uns viel Zeit für den Support und sind auch selber auf Fehlersuche. Bitte nutzt für den Moment noch den Workaround von @swenp (an dieser Stelle nochmal besten dank für die Beteiligung 
). Ich verlinke die Beispiele noch bei uns in den sensebox-examples.
Moin @jensileinchen, der Fehler gibt uns nach wie vor Rätsel auf da er nur bei wenigen Bausätzen auftritt und daher schwer einzugrenzen ist. Layout von Sensor, MCU und die Stromversorgung wurden geprüft und sind in Ordnung. Software testen wir weiterhin und aktuell warte ich auf Rückmeldung von Sensirion. Umtausch der Hardware ist kein Problem, ich würd mich aber freuen wenn wir eure Fälle noch gelöst bekommen!
ganz anderer Ansatz seit heute morgen: auf dem betroffenen Board läuft nun mal eine sensebox.home Software, mit CO2Sensor, Dislay und Lora-Bee — mal schauen wie lange … !
// edit 10.02.2021
sehr spannend — das board läuft noch und sendet brav per lora messwerte ---- es liegt also eher kein hardware defekt vor sondern eher wohl ein problem mit den verrwendeten libaries ?! — testet sonst noch jemand die dinger ausser mir ?
1 Like
ich noch nicht, meine läuft als „sensebox.home“ – ist zwar damit keine Ampel mehr und zeigt auf dem Display nur alle paar Sekunden den Wert an, aber hängt sich nicht auf …
Dasselbe hier,
keine Probleme um die CO² Ampel hier laufende zu halten. Er dreht schon drie Monate ohne Fehler drausen an unserer Hochschule mit lorawan und Solarpanel.
Siehe hier.
Nächste Woche gibt es ein Festival wobei wir an die Anschauenden demonstrieren werden wie die Feinstaub und CO² Sensoren von Sensebox funktionieren. Das Zweck ist um das MINT Unterricht ein Boost in unserer Region zu geben.
Noch eine schöne Osternwoche und viel Erfolg mit dem Basteln.
Ja sicher @jensileinchen,
ganz einfache Code wobei ich auf die alte TTNv2 Platform noch mit ABP und Cayenne LPP die Feinstaub und HDC1080 Werten verschickt habe. Nicht CO² weil ich dafür MQTT und Wifi gebraucht habe um diese Werte zu visualisieren.
Die AppSkey und NwsKey is aber camoufliert herunter. Im Blockly einfach zu herstellen.
Der Grund warum ich die alte TTNv2 brauchte ist das für den Sensebox MCU v1.5 das Probleme gab. Wahrseinlich das sensebox.h im Blockly noch nicht up to date mit die neuen Libraries. Die Demo musste schnell gehen auf meiner Stelle, deswegen ABP und TTNv2 das immer stabiel funktioniert.
> #include <SPI.h>
> #include <Wire.h>
> #include <Adafruit_GFX.h>
> #include <Adafruit_SSD1306.h>
> #include "SenseBoxMCU.h"
> #include <lmic.h>
> #include <hal/hal.h>
> #include <CayenneLPP.h>
>
> float p10,p25;
>
> CayenneLPP lpp(51);
>
> #define OLED_RESET 4
> Adafruit_SSD1306 display(OLED_RESET);
>
> // LoRaWAN NwkSKey, network session key
> // This is the default Semtech key, which is used by the early prototype TTN
> // network.
> static const PROGMEM u1_t NWKSKEY[16] = { **xx** };
>
> // LoRaWAN AppSKey, application session key
> // This is the default Semtech key, which is used by the early prototype TTN
> // network.
> static const u1_t PROGMEM APPSKEY[16] = { **xx** };
>
> // LoRaWAN end-device address (DevAddr)
> static const u4_t DEVADDR = 0**xxx**;
>
> // These callbacks are only used in over-the-air activation, so they are
> // left empty here (we cannot leave them out completely unless
> // DISABLE_JOIN is set in config.h, otherwise the linker will complain).
> void os_getArtEui (u1_t* buf) { }
> void os_getDevEui (u1_t* buf) { }
> void os_getDevKey (u1_t* buf) { }
>
> static osjob_t sendjob;
>
> // Schedule TX every this many seconds (might become longer due to duty
> // cycle limitations).
> const unsigned TX_INTERVAL = 60;
>
> // Pin mapping
> const lmic_pinmap lmic_pins = {
> .nss = PIN_XB1_CS,
> .rxtx = LMIC_UNUSED_PIN,
> .rst = LMIC_UNUSED_PIN,
> .dio = {PIN_XB1_INT, PIN_XB1_INT, LMIC_UNUSED_PIN},
> };
> HDC1080 hdc;
>
>
> void initLora() {
> delay(2000);
> // LMIC init
> os_init();
> // Reset the MAC state. Session and pending data transfers will be discarded.
> LMIC_reset();
>
> // Set static session parameters. Instead of dynamically establishing a session
> // by joining the network, precomputed session parameters are be provided.
> #ifdef PROGMEM
> // On AVR, these values are stored in flash and only copied to RAM
> // once. Copy them to a temporary buffer here, LMIC_setSession will
> // copy them into a buffer of its own again.
> uint8_t appskey[sizeof(APPSKEY)];
> uint8_t nwkskey[sizeof(NWKSKEY)];
> memcpy_P(appskey, APPSKEY, sizeof(APPSKEY));
> memcpy_P(nwkskey, NWKSKEY, sizeof(NWKSKEY));
> LMIC_setSession (0x1, DEVADDR, nwkskey, appskey);
> #else
> // If not running an AVR with PROGMEM, just use the arrays directly
> LMIC_setSession (0x1, DEVADDR, NWKSKEY, APPSKEY);
> #endif
>
> #if defined(CFG_eu868)
> // Set up the channels used by the Things Network, which corresponds
> // to the defaults of most gateways. Without this, only three base
> // channels from the LoRaWAN specification are used, which certainly
> // works, so it is good for debugging, but can overload those
> // frequencies, so be sure to configure the full frequency range of
> // your network here (unless your network autoconfigures them).
> // Setting up channels should happen after LMIC_setSession, as that
> // configures the minimal channel set.
> // NA-US channels 0-71 are configured automatically
> LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI); // g-band
> LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
> LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK, DR_FSK), BAND_MILLI); // g2-band
> // TTN defines an additional channel at 869.525Mhz using SF9 for class B
> // devices' ping slots. LMIC does not have an easy way to define set this
> // frequency and support for class B is spotty and untested, so this
> // frequency is not configured here.
> #elif defined(CFG_us915)
> // NA-US channels 0-71 are configured automatically
> // but only one group of 8 should (a subband) should be active
> // TTN recommends the second sub band, 1 in a zero based count.
> // https://github.com/TheThingsNetwork/gateway-conf/blob/master/US-global_conf.json
> LMIC_selectSubBand(1);
> #endif
>
> // Disable link check validation
> LMIC_setLinkCheckMode(0);
>
> // TTN uses SF9 for its RX2 window.
> LMIC.dn2Dr = DR_SF9;
>
> // Set data rate and transmit power for uplink (note: txpow seems to be ignored by the library)
> LMIC_setDrTxpow(DR_SF7,14);
>
> // Start job
> do_send(&sendjob);
> }
>
> void onEvent (ev_t ev) {
> Serial.print(os_getTime());
> Serial.print(": ");
> switch(ev) {
> case EV_SCAN_TIMEOUT:
> Serial.println(F("EV_SCAN_TIMEOUT"));
> break;
> case EV_BEACON_FOUND:
> Serial.println(F("EV_BEACON_FOUND"));
> break;
> case EV_BEACON_MISSED:
> Serial.println(F("EV_BEACON_MISSED"));
> break;
> case EV_BEACON_TRACKED:
> Serial.println(F("EV_BEACON_TRACKED"));
> break;
> case EV_JOINING:
> Serial.println(F("EV_JOINING"));
> break;
> case EV_JOINED:
> Serial.println(F("EV_JOINED"));
> break;
> case EV_RFU1:
> Serial.println(F("EV_RFU1"));
> break;
> case EV_JOIN_FAILED:
> Serial.println(F("EV_JOIN_FAILED"));
> break;
> case EV_REJOIN_FAILED:
> Serial.println(F("EV_REJOIN_FAILED"));
> break;
> case EV_TXCOMPLETE:
> Serial.println(F("EV_TXCOMPLETE (includes waiting for RX windows)"));
> if (LMIC.txrxFlags & TXRX_ACK)
> Serial.println(F("Received ack"));
> if (LMIC.dataLen) {
> Serial.println(F("Received "));
> Serial.println(LMIC.dataLen);
> Serial.println(F(" bytes of payload"));
> }
> // Schedule next transmission
> os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);
> break;
> case EV_LOST_TSYNC:
> Serial.println(F("EV_LOST_TSYNC"));
> break;
> case EV_RESET:
> Serial.println(F("EV_RESET"));
> break;
> case EV_RXCOMPLETE:
> // data received in ping slot
> Serial.println(F("EV_RXCOMPLETE"));
> break;
> case EV_LINK_DEAD:
> Serial.println(F("EV_LINK_DEAD"));
> break;
> case EV_LINK_ALIVE:
> Serial.println(F("EV_LINK_ALIVE"));
> break;
> default:
> Serial.println(F("Unknown event"));
> break;
> }
> }
> SDS011 my_sds(Serial1);
>
> void printOnDisplay(String title1, String measurement1, String unit1, String title2, String measurement2, String unit2) {
>
> display.setCursor(0, 0);
> display.setTextSize(1);
> display.setTextColor(WHITE, BLACK);
> display.println(title1);
> display.setCursor(0, 10);
> display.setTextSize(2);
> display.print(measurement1);
> display.print(" ");
> display.setTextSize(1);
> display.println(unit1);
> display.setCursor(0, 30);
> display.setTextSize(1);
> display.println(title2);
> display.setCursor(0, 40);
> display.setTextSize(2);
> display.print(measurement2);
> display.print(" ");
> display.setTextSize(1);
> display.println(unit2);
> }
Die Blocke:
1 Like
@wdebbaut im neuen Blockly gibt es über folgenden Button: 
die Möglichkeit das Projekt direkt über einen Link zu teilen 
Moin Mario,
Die Möglichkeit zum Teilen habe ich schon mit meinem Kollegen manchmal gemacht, aber in diesem Fall nicht mit @jensileinchen , weil ich die Keys nicht sichtbar machen wollte. Danke jedoch für diesen Tip.
Gibt es schon Entscheidungen um die Beta Blockly Version endgültig zu machen?
Ich habe verschiedene Projekte auf meiner Hochschule mit diesem Uberflache gemacht mit unsere Studenten, und auf die Deklarierung der Float Variablen nach, das man keine zwei Floats zusammen schreiben kann ohne direkt im Arduino zu gehen, gelangt es uns gut um zum Beispiel mqtt zu brauchen in der neue Umgebung.
Schöne Entwickelung und Realisierung.