The way I understand this, it should take readings and publish then wait 2 seconds and then sleep for 10 seconds (I was trying for longer periods but wanted to see it come back up first). However, it just sleeps and never comes back.
Actually System.sleep(10); does nothing else than WiFi.off();(for WiFi devices - the behaviour on Electron is not decumented yet tho’) and will still run your code, causing to call Particle.publish() without cloud connection which currently has a bug and can cause your device to stall.
Try this to wrap your publishes in an if (Particle.connected()) { ... }, but also make sure that you give the sytem the time to get connected before going to sleep again - otherwise it just looks as if it was permanently sleeping while you just keep knocking it out before it’s even ready to do anything.
Also your 2sec delay might be a bit too short for the asynchronous publishing tasks to finish.
So give this a shot
if (Particle.connected())
{
Particle.publish("voltage", String(voltage));
Particle.publish("soc", String(soc));
delay(3000);
System.sleep(10);
}
Actually does nothing else than go to sleep and wake up just for testing on how the sleep has to behave, but the device go to sleep (I’m using an electron), the leds turns off, but after 60 secs the device doesn’t wake up.
I’m pretty sure it wakes up but since it will immediately go back to sleep you won’t even see it happen.
Try adding a delay(5000) before the sleep call
You are also using a wake-pin but I assume you haven’t got anything connected to that pin.
Try adding a pull-up or pull-down resistor to prevent it from floating and consequently increasing the risk of the wake interrupt being active while going into sleep mode.
If the interrupt line happens to be active on sleep, all following interrupts - including the RTC interrupt for timed wake - will be inhibited.
Just for my own knowledge, does the Device (Post #5) have time to complete the Serial.print when it’s going to sleep immediately after? I assume that’s not an issue, or ScruffR would have mentioned it.
Would adding for (uint32_t ms = millis(); millis() - ms < 200; Particle.process()); after the Serial.print eliminate that as a possibility?
Due to SEMI_AUTOMATIC mode (otherwise wifi/cloud house keeping would allow 1ms for at least some bytes to be tramsmitted) I'd assume the serial print statement actually wouldn't render any result on the serial output, but I didn't care too much about mentioning that because of ...
... which for me implied that there is still no RGB LED action which there should be, even if nothing is happening on the serial monitor.
Yes, it would.
But just swapping round the print and the delay line should do the same.