If I removed client.stop(); the loop would send six texts before the Spark Core started flashing red. The core flashed red at least 3x (maybe 3x times a couple of times) which seem to indicate a connection failure based on the documentation here. I’m guessing it’s getting overloaded trying to keep hitting that URL? It’s why I put in the delay(5000); but that didn’t seem to help.
For reference here’s the code I’m trying to get to work. Each time the PIR sensor detects motion it’s supposed to turn on an LED and call a URL to trigger a text message to my phone.
Any suggestions are greatly appreciated. Thank-you
The PIR picks up the motion and calls that URL which then sends a text to my phone. It does send 3-4 texts for each time it detects motion but it’s working.
Thank you very much for all your help, greatly appreciate it. I’ll keep tweaking it from here to see if I can get it to just text once for each time it detects motion. If you’re interested you can see each time it generates a text message here: http://bstolte.com/motion_sms/
Side note: it’s pretty cool when my phone starts getting text messages when you’re working on the code
I’m getting my core all cranky cos i don’t have the PIR attached and i think when the loop keeps calling the getrequest() too often crazy stuff happens!
let me edit and see how things go.
The idea is you need to restrict sending to once every X seconds
Just a follow up. If I include client.stop(); it will run the code but not hit the URL and trigger the text message. If I remove client.stop(); it will run and send text messages.
In both cases, from what I’m seeing in the serial output , it’s cycling through the motion detected loop anywhere from 3-7 times.
“Connected” occurs in the getrequest() and “Motion detected” happens right after. It looks like it cycles back through getrequest() a few more times perhaps because the PIR sensor is still reading motion or is just slow to clear out after motion has been detected. I tried putting delays in there but didn’t really help.
I’m thinking I need to re-write so I can limit the call to getrequest() just once per motion being detected and then let it clear out.
Latest here but haven’t had much time in the past couple of days to play with it.
I think if you add small delay like delay(50); before the client.stop() you should find it will work. I think you are killing the connection before it has a chance to finish sending.
It would also be better to add rate limiting in the real application by saving the value of millis(); when you send and not sending for a certain time after than.
@bstolte, now you are successfully opening your url, please could you post either the complete solution or at least the TCP client part of the code that successfully sends :
Basically the getrequest() function does the work of opening the connection and calling the URL.
I also limited the number of times it can call the URL to once per minute. The URL it calls in my implementation will trigger a text message to my phone - I only wanted one text message per minute. Not sure if you need this part but thought I’d call it out if you were wondering why it was there.
Let me know if I can help answer any other questions.
Sorry to revive an old thread. I’m using basically identical code to @bstolte in the last post and it works – sort of. I’ve set it to call a URL every 5 minutes. It didn’t appear to be working, and I spent hours trying variations based on @bko 's code, using other hints in this thread. Suddenly it worked – once. I left it running for ~24 hours and it appears to have called the URL 7 times (out of ~288), without any apparent pattern (i.e. it is not sending every 5 hours, it seems random).
I’ve set up debug statements so I know that client.connected() returns true nearly every time. I’ve pinged my server and added delays longer than the ping time to no avail. I’ve spark.published the variable and then observed through the https://api.spark.io/v1/devices/ url, it updates continuously and without flaw, every 5 minutes.
Any ideas on why this would work intermittently? Is there any additional debug info available from client.connected() or other routines?
The key thing that lots of folks forget is that your server is sending you stuff even though it is a GET request and you may not be interested in the response. If you don’t pickup the bytes it sends and flush them, it will get backed up and the core will reboot. The general recipe is to send a request, wait for a response from the server with a time out, and then read any data that has come in until there is no more data.
I’m not certain I understand. Do you think putting a little more delay before flush, or after the GET request would help? The file I’m requesting is less than 2kB so hopefully that doesn’t take long. And the Spark isn’t rebooting itself: it keeps chugging along and publishing the current state, as far as I can tell. I will add an UpTime to the published variables just to make sure.
Wow, thank you! For whatever reason, your code worked. I then integrated it into mine, and now mine is working as well. It is late so I’m confused, but tomorrow I’ll have to investigate line-by-line to see what the differences are.
A couple observations: every once in a while the “sent and closed-bytes” (while using your Unicorn Search code directly) will return a larger byte value. About 1/8 of the time. Haven’t figured out why. Second, it does crash on occasion, with the single red blink error message. In the last hour of playing I think I’ve seen this behavior 3x. I think this is with your code directly but I may have modified it slightly, I can’t trust my memory.
I’m going to let it run overnight and check results. But THANK YOU! for all your help, very much appreciated.