There is another discussion about this topic here (after move it’s actually this very thread)
But for the “bill of goods” I can’t see any statement that the wake-on-move will always work under all thinkable circumstances, so if you bought something based on assumption I’d not call it “being sold a false bill of goods”.
And as mentioned in the other thread, some “issues” contributing to the problem are being addressed too.
What I mean, is that while in Deep Sleep for the LIS3DH I was only able to set an interrupt based on movement, but not on orientation. Mind you, I posted this topic half a year ago, but for my project I wanted to put the Asset Tracker in Deep Sleep and wake it up as soon as it moved beyond a certain angle.
Perhaps it’s possible, but I couldn’t find any clear-cut documentation or similar projects on it.
I have no intention to make enemies here, sorry if my statement ruffled feathers. The community has been very helpful. I purchased this based on the following statement:
The shield also has an on-board accelerometer, the LIS3DH. It's extremely low power so won't chew up your energy budget. The accel communicates over SPI, so it takes up A2, A3, A4, and A5 as marked on the silkscreen of the shield. A configurable interrupt from the LIS3DH is connected to the Electron's "wake" (WKP) pin, so you should be able to make a project where the Electron and GPS stay in deep sleep until it's hit hard enough to cross a threshold you set on the accelerometer.
However, based on numerous threads such as here (others are searchable) and looking at this github issue, it appears as though waking up via accelerometer doesn't work as reliably the document stated. If it doesn't work reliably, then it can't be trusted. And by not working reliably, it doesn't just ignore further accelerometer data and fails to wake on movement, but it also fails to wake based on timing or anything other than the RESET button. (Did I read the github issue wrong? I hope so, but don't think so.)
I'm going to keep trying to figure this out, but lots of smarter people before me apparently haven't been able to. So I don't have high expectations of success.
As pointed out in the other this (after move of post) thread and the initial issue description
without the timed wake you should be able to have the device wake on move.
I have not tested this, but I'd suppose the OP of the issue has since he is a Particle engineer.
BTW, have you considered any of the alternative suggestions I've made in the other this (after move of post) thread about the other sleep modes till silence is detected?
BTW²: Is "should" not also an expression that implies a degree of probability (and in this uncertainty)?
If a use-case doesn't lend itself to this kind of solution (prolonged movement not allowing for silence detection) within the inevitable limitations of the availale tools it's not the tool's fault but due to choice of tools.
I'm not saying that there is no solution to your use-case (hence the alternative approaches suggested in the other thread) but this might be a possible outcome.
At first glance something looks as if it should work, but on close examination factors may emerge that weren't anticipated at the time of choice of toolset.
As this discussion is actually leading away from the original topic of this thread, I'll split off this part and move it to your own thread where you originally raised the issue.
This does not work for the same reason as the other problems. If it sleeps w/ WKP high, it stays high until manually RESET, and no amount of jarring will cause the WKP to go low and then go high again.
System.sleep(SLEEP_MODE_SOFTPOWEROFF, 10);
Works beautifully so long as I don't bump the device while it's falling asleep. Otherwise, same issue. WKP stays HIGH and 10 seconds goes by and nothing happens. This actually might work. Obvious downside is no wake on movement. Will continue to test this.
This is the only solution you've proposed that I haven't tried. I suppose I'll try flashing the firmware later.
but if it's shaken while sleeping, the WKP pin remains high.
It doesn't.
Any recommendations on how I might implement this? I've tried
bool ready = accel.calibrateFilter(5000, 0);
if (ready & digitalRead(WKP) == 0 ) { <sleep_cmd> } else {accel.clearInterrupt(); break;}
So, here's my problem. I have a device that is going to be jostled around. Even if I want it to ignore input from the accelerometer and ONLY sleep/wake based on time, it appears that I cannot do this. If there is movement from the accelerometer as it's falling asleep, it requires a RESET to work again. You seem convinced that this is an unusual use case, but I'm starting to wonder if I have a bad unit. Any suggestions, @ScruffR or @rickkas7?
If the use-case (at least in parts) doesn’t lend itself to the original approach you may have to reframe the problem.
e.g. the way I suggested - when movement is detected when wanting to go to deep sleep with wake-on-move, an alternative sleep mode with shorter sleep cycle can be chosen, to wake a bit later for a check whether movement has stopped. If it hasn’t do the same again if it has, reset the WKP pin and go to deep sleep with timed wake.
So even if the original approach turns out to be impossible, alternative ways may still lead to (almost) the same outcome.
Unfortunately other sleep modes seem to have the same problem 
I was browsing github and saw mention of SLEEP_DISABLE_WKP_PIN as a sleep mode. Can you (or anyone) point me in the direction of which firmware I’d find this in? All I can see is it was committed to develop branch. But that means nothing to me in terms of how to get the functionality onto my Electron.
That's a new feature introduced with 0.8.0-rc.2
Particle Device OS Updates Thread - #57 by mdma
Update:
@jschwalbe, this might be interesting for your