Oak not staying online

[AUAJ]

I am running into an issue where my oaks won't stay online.

I have gone through the initial setup and was able to upload the first sketch blinking the LED.  My issue occurred after I connected the weather shield to the oak.

Now the dashboard page shows that the oak goes offline about a minute after i supply power to it. 

I tried another Oak and the same thing happened.

Could it be due to a faulty weather shield?  If so, can I fix the Oak or have i bricked it?

Thanks.

[exeng]

What sketch are you running for the weather shield? Are you running the one that @who posted? If so it does a deep sleep after 150 seconds to conserve battery power. Any code that uses sleep to conserve power will need pin 10 [WAKE] connected to the reset pin [RST] to facilitate wakeup. 

[AUAJ]

What sketch are you running for the weather shield? Are you running the one that @who posted? If so it does a deep sleep after 150 seconds to conserve battery power. Any code that uses sleep to conserve power will need pin 10 [WAKE] connected to the reset pin [RST] to facilitate wakeup.

Yes, the sketch posted by @who.  I have tried using a jumper to connect the WAKE pin to RST but with no luck.

I can't upload a different sketch as the Oak disconnects before the Oak can be flashed.

Do you have any ideas?

[exeng]

If you are trying to load a new sketch it's difficult to do when the currently running sketch is in a deep sleep and very hard to catch it when awake.

You should be able to get into safe mode by connecting pin 1 to ground and cycling power. Wait 3-4 seconds after power up and remove the pin 1 to ground connection. This should get you into safe mode as indicated by the onboard LED flashing in bursts of 3. Once in this state, you should be able to upload a new sketch. I have a number of Oaks in service that sleep and as such have to get them into safe mode to upload new sketches.

I assume your weather station is working and you just want to be able to upload a new sketch. I'm running a modified version of @who's code on a weather shield sleeping for 10 minutes between readings. It reports to a Thingspeak channel (and Particle). A second Oak with a TFT LCD shield retrieves the data from the Thingspeak channel and displays the last read values for me. Another Oak is running a pool temp monitor and also reporting to Thingspeak. This data is also retrieved and displayed on the TFT LCD.

[driffster]

I had an issue with bad code (or faulty upload) that made one oak Connect/disconnect rapidly to the wireless router, I was able to flash with new code but the problem persisted with any code I would send after that (the code actually worked, but the Oak was not staying connected on Particle. I fixed the problem with a complete factory reset and reinstall the latest firmware.

If nothing else a factory reset will allow to upload new code to it.

[defragster]

I was doing OTA updates on a generic ESP8266 and to prevent having to serial wire for an update I started checking an open pin I called ESTOP on power up.  When I found this set, I would make sure to run only tested code that provided for the Arduino OTA update to work.

This is similar to the SAFE MODE pin - except you can control it in your code.  If you have a free pin - that is (or can be made) normally high or low when all is well - then in setup() or before going into sleep check that pin for the Emergency Stop signal and don't sleep or run 'new or risky code' that you see fit to put an "if (ESTOP)" around.  Then just make sure to cycle normally as needed to allow the Particle update to proceed.

[AUAJ]

I was doing OTA updates on a generic ESP8266 and to prevent having to serial wire for an update I started checking an open pin I called ESTOP on power up.  When I found this set, I would make sure to run only tested code that provided for the Arduino OTA update to work.

This is similar to the SAFE MODE pin - except you can control it in your code.  If you have a free pin - that is (or can be made) normally high or low when all is well - then in setup() or before going into sleep check that pin for the Emergency Stop signal and don't sleep or run 'new or risky code' that you see fit to put an "if (ESTOP)" around.  Then just make sure to cycle normally as needed to allow the Particle update to proceed.

Great idea.  Thanks.

[AUAJ]

Thanks for the help everyone.  The safe mode helped.

I am trying to read the data from the command line and am also having issues with that.  I'm assuming it is something that i'm doing wrong but i don't know.  I removed the sleep from the code for testing.  I can check and confirm that the Oak is live (particle list) but when I try to subscribe to the Oak I don't see anything. 

I receive the message:
"Subscribing to "Oak2" from the firehose (all devices)
Listening to: /v1/events/Oak2"

but nothing after that. 

Any suggestions?

Also, if I run the subscribe command without defining the Oak name then I receive output from other Oaks that aren't mine or connected to my WiFi.  They don't seem to even be near my location (based on some of the names).  Is this normal?

[PeterF]

Can I just check what command line tool you are referring to? Is it the particle-cli? And what parameters are you giving it?

As far as subscribing without defining your device name and getting other messages, yes, this is normal. Particle publishes are public unless you specifically declare them to be private, and if you don't specify that you want to subscribe to either just one of your devices, or a specific one, you will most likely end up subscribing to a public feed.

[AUAJ]

Can I just check what command line tool you are referring to? Is it the particle-cli? And what parameters are you giving it?

As far as subscribing without defining your device name and getting other messages, yes, this is normal. Particle publishes are public unless you specifically declare them to be private, and if you don't specify that you want to subscribe to either just one of your devices, or a specific one, you will most likely end up subscribing to a public feed.

I am using the command line.  Yes, i'm using the commands described in the particle cli.

I was using the command: 

Code: [Select]

particle subscribe Oak2
and only receive the following message:

"Subscribing to "Oak2" from the firehose (all devices)
Listening to: /v1/events/Oak2"

[PeterF]

Lovely... thanks for that.

Now, what I said before about the default being for particle publish events to be public still stands. In this instance, by giving the command particle subscribe Oak2, you have said that you want to hear events named Oak2, not that you want to subscribe to events from Oak2. From the particle-cli documention: particle subscribe eventName

What you want is either:
particle subscribe eventName deviceName
particle subscribe eventName 0123456789abcdef01234567

The best would be the latter, as it subscribes to your exact device, not any device with the same name (ie. I also have an Oak named Oak2, so I bet you would be getting temperature updates from it every ten minutes!!) To get that device number, you can either get it from the dashboard or running particle list, which will list all the devices you have attached to your particle account.

[AUAJ]

i tried the "particle subscribe weatherstation 012234567abc123" (replacing the last string with the device ID), however I still receive the same message.  I also tried adding the "--private" after the device ID.

Below is the code, only change from @who is triggering the sleep with a LOW pulse.  I also didn't connect the WAKE-RST solder pad.

Any suggestions for where i'm still going wrong?

Code: [Select]

#include <Wire.h>
#include "SparkFunHTU21D.h"
#include "SFE_BMP180.h"
//#include "Particle.h"

HTU21D htu;
SFE_BMP180 bmp;

#define ALTITUDE 509 // Alt in meters
#define PCF8591 (0x90 >> 1) // I2C bus address
#define ADC0 0x00 // ADC0

int Sleep_pin = 5;  // Config as INPUT_PULLUP to default HIGH
int OakLEDpin = 1; // Oak onboard LED pin 1
int sleepTimes = 150; // 150 seconds

float temperature, humidity, pressure, ambient;

void fetchTemperature(){
  temperature = htu.readTemperature();
}

void fetchHumidity(){
  humidity = htu.readHumidity();
}

void fetchPressure(){
  char status = bmp.startTemperature();
  char buffer[10];
  double T,P,p0;
  if(status != 0){
    delay(status);
    status = bmp.getTemperature(T);
    if(status != 0){
      status = bmp.startPressure(3);
      if(status != 0){
        delay(status);
        status = bmp.getPressure(P,T);
        if(status != 0){
          pressure = bmp.sealevel(P,ALTITUDE);
        } else Particle.publish("error retrieving pressure measurement\n");
      } else Particle.publish("error starting pressure measurement\n");
    } else Particle.publish("error retrieving temperature measurement\n");
  } else Particle.publish("error starting temperature measurement\n");
}

void printData(){
  char tmpStr[64];
  sprintf(tmpStr, "weather;%s;%s;%s;%s", String(temperature).c_str(), String(ambient).c_str(), String(pressure).c_str(), String(humidity).c_str());
  Particle.publish("weatherstation", tmpStr, 60, PRIVATE);
}

void fetchAmbient(){
  byte value0;
  Wire.beginTransmission(PCF8591); // wake up PCF8591
  Wire.write(ADC0); // control byte - read ADC0
  Wire.endTransmission();
  Wire.requestFrom(PCF8591, 2);
  value0 = Wire.read();
  value0 = Wire.read();
  delay(200);
  ambient = value0;
}


void setup() {
  pinMode(Sleep_pin, INPUT_PULLUP); // default to HIGH

    htu.begin();
    if(!bmp.begin()){
      Particle.publish("Error, bmp not connected!");
      while(1);
    }
    fetchTemperature();
    fetchHumidity();
    fetchPressure();
    fetchAmbient();
    printData();
    if(digitalRead(Sleep_pin) == LOW){
      ESP.deepSleep(sleepTimes*1000000, WAKE_RF_DEFAULT);
    }
}

void loop() {
  // put your main code here, to run repeatedly:

}

[PeterF]

After a quick skim read, nothing is jumping out as problemactic.

If I do a Particle.publish("tempC",tmpStr,30,PRIVATE); on my Oak3, I can can use particle-cli to subscribe to it's event feed like particle subscribe tempC d95704xxxxxxxxxxxxxxd, and get

Code: [Select]

Subscribing to "tempC" from d95704xxxxxxxxxxxxxxd's stream
Listening to: /v1/devices/d95704xxxxxxxxxxxxxxd/events/tempC
{"name":"tempC","data":"25.81","ttl":"60","published_at":"2016-05-24T02:47:24.030Z","coreid":"d95704xxxxxxxxxxxxxxd"}
{"name":"tempC","data":"26.06","ttl":"60","published_at":"2016-05-24T02:48:43.227Z","coreid":"d95704xxxxxxxxxxxxxxd"}
{"name":"tempC","data":"26.00","ttl":"60","published_at":"2016-05-24T02:50:02.603Z","coreid":"d95704xxxxxxxxxxxxxxd"}
{"name":"tempC","data":"27.19","ttl":"60","published_at":"2016-05-24T02:51:21.904Z","coreid":"d95704xxxxxxxxxxxxxxd"}
{"name":"tempC","data":"27.00","ttl":"60","published_at":"2016-05-24T02:52:40.900Z","coreid":"d95704xxxxxxxxxxxxxxd"}
Might be worth making a slight change to the code to see if the deep-sleep is causing the problem.

Move

Code: [Select]

   fetchTemperature();
    fetchHumidity();
    fetchPressure();
    fetchAmbient();
    printData();
    if(digitalRead(Sleep_pin) == LOW){
      ESP.deepSleep(sleepTimes*1000000, WAKE_RF_DEFAULT);
    }
from the setup() function into the loop() function, and comment out the  if(digitalRead(Sleep_pin) == LOW) bit so the deepSleep isn't processed, and add a manual delay. So you setup and loop functions should now look like:

Code: [Select]

void setup() {
  pinMode(Sleep_pin, INPUT_PULLUP); // default to HIGH

    htu.begin();
    if(!bmp.begin()){
      Particle.publish("Error, bmp not connected!");
      while(1);
    }
   
}

void loop() {
  // put your main code here, to run repeatedly:
    fetchTemperature();
    fetchHumidity();
    fetchPressure();
    fetchAmbient();
    printData();
//    if(digitalRead(Sleep_pin) == LOW){
//      ESP.deepSleep(sleepTimes*1000000, WAKE_RF_DEFAULT);
//    }
   delay(sleepTimes*1000);
}
I've added the delay(sleepTimes * 1000) so that the code delays by the 150 seconds still, but doesn't go into deepSleep. It *should* work, and you should be able to see on the particle dashboard logs that your device goes online, and then posts a weathershield event, and then after the delay posts another update. If you don't want to wait for 150 seconds, change the delay to something like delay(10*1000); so it posts every 10 seconds. If this doesn't work, there is something wrong with it going into deep sleep, or waking up from it. Once we've isolated that, we can then look at if there is something in the code going wrong, or if there is something wrong with the shield, etc.

Pete

[AUAJ]

You sir, are a scholar and a saint.  That worked!

Could it have been because I didn't have anything in the loop() function?  If so, why didn't the same code have anything in the loop() function? 

Thanks again.

[exeng]

AUAJ, I looked at your weather station sketch and noticed what may have been your original problem. Pete's fix basically avoids your problematic code by avoiding the sleep. When you changed the logic (if statement) to determine whether to sleep or not you basically introduced the problem you were having.

Consider this:
1. the sleep pin (pin 5) [more on this later] is set to default HIGH by setting the internal pullup in your code
2. you are/were checking for LOW to enter sleep (unless you pulled the pin LOW externally the code would not sleep)
3. since you did not sleep, you entered an empty loop() and spun forever, or at least til reset by a power cycle
4. if you did enter sleep, since you did not connect WAKE to RST the sketch would not wake up.

If you fix things to sleep, you may want to add a delay in setup to allow for the Oak to reconnect to Particle, perhaps some 10's of seconds. My code actually checks for a Wifi connection in setup and doesn't proceed until connected.

Code: [Select]

void setup()
{
  pinMode(Sleep_pin, INPUT_PULLUP); // Use pullup mode to default HIGH

  while ( WiFi.status() != WL_CONNECTED) {
    status = WiFi.begin();
    // wait 10 seconds for connection:
    delay(10000);
  }
...
RE: Sleep_pin
First a comment... funny how bits of code propagate around as we pickup and use examples only to cause issues because the original intent was lost or misunderstood.

Sleep_pin is/was an artifact of trying to provide a means to software control whether a sketch entered sleep or not when it came to that point in the code. This was done so that one could externally force the code to not sleep at the next sleep opportunity and allow for uploading another sketch. It also requires something running in loop(), perhaps a simple LED flash. It's really not necessary because the safe mode method (pin 1 to GND at power up and remove after a few seconds) provides a means to reset the Oak and put it into a mode that allows new sketches to be uploaded. As Pete once said ("couldn't be bothered...") when seeing the Sleep_pin code logic for the first time, since safe mode was available as a sure thing alternative.

Hope this helps clear things up somewhat.

Finally, when using sleep one must connect WAKE to RST to facilitate wakeup.