I am trying to get the google location service to work on a particle boron, but so far no luck.
The first thing I notice is that I have modified the google-maps-device-locator example to print the coordinates in the callback, but it’s not getting called.
I’ve followed the instructions in geolocation basics and gotten to the point where I can click the test button of the intergrations>google maps page and I get “Success! Your integration is behaving as expected.” But when I check the events tab, it’s blank with a floating message saying “Waiting for Events”
When I try to display events using the curl command in the terminal, it responds with :ok and then prints a blank line every 30s (which is the location reporting period).
Anyone have an idea what is going on?
BTW: Here’s my code:
#include <google-maps-device-locator.h>
GoogleMapsDeviceLocator locator;
SerialLogHandler logHandler;
void locationCallback(float lat, float lon, float accuracy)
{
// Handle the returned location data for the device. This method is passed three arguments:
// - Latitude
// - Longitude
// - Accuracy of estimated location (in meters)
Serial.print( lat );
Serial.print( ', ' );
Serial.print( lon );
Serial.print( ', ±' );
Serial.println( accuracy );
}
void setup()
{
Serial.begin(9600);
// Scan for visible networks and publish to the cloud every 30 seconds
// Pass the returned location to be handled by the locationCallback() method
locator.withSubscribe(locationCallback).withLocatePeriodic(30);
}
void loop()
{
locator.loop();
uint32_t t = millis();
static uint32_t last;
if( t - last > 1000 )
{
last = t;
Serial.print( '*' ); // show that the program is alive
}
}
Thank you for this post! I have been meaning to get around to playing with location services for some time and your post prompted me to give it a try.
First, I was able to follow the link above and use your code without modification - and it worked. So, the issue is likely with the API integration.
so, now that you know where I am… let’s try to figure out what went wrong. The first place to check is on the integrations page in the console. If you open the Google Maps integration and scroll to the bottom, you will see a record of the number of times this integration was called and information on the result.
Blanking out the sensitive bits, can you post what you see here?
This is a nit, your serial print statements use ’ which is for a single character. If you use " you will get better output.
When you set up your API key at Google, the tutorial stops when you get the key itself. However Google goes on to encourage you to restrict the API key in order to protect it. This is a very good idea - any it can break your application if you don’t set it correctly. I restricted who could call the API to(particle.io/*). I tried to restrict the API to Gelocation but that made the API stop working. I have had some intermittent issues with restrictions, try turning them off if you are getting failed web hooks.
Using Serial print, you only get 2 digits to the right of the decimal point. If you want you can get more accuracy by changing your return handler to this:
Thanks so much for your help!
I only have two requests in the event log of the google maps integration. They both appear to be test events from pressing the test button at the top of the intergration page. See below.
I did not change the integration name. It’s “deviceLocator” and is set to accept events from “any device”.
As for organization, everything is in the sandbox. I have not created any products yet.
The thing that seems like a red flag is how the tutorial talks about seeing events in the console, but all I ever see is “waiting for events”. I feel like I must have missed something really basic but have no idea what it is.
Are you sure you are looking at the console for the right device? You should be able to reset your device and determine if it is the same one by when it shows up in your device list on the console. Otherwise, you can install the Particle CLI (if you have not already) and use Particle Identify to get the deviceID which should match the one in the console view. Command Line | Tutorials | Particle
Can you confirm the version of deviceOS you are running?
Yes, it’s my only device. I can signal it, ping it, and flash it.
Device OS is 1.4.4
I think my screen shot was misleading. I do get all the boot up events, but I had already booted my Boron before I opened the console. But I don’t receive any location events, even though I can see my program is running. Of course, there is no scanData, so maybe that’s normal. The question then is why isn’t there any scanData? I know it can see towers because I can signal it and flash it.
Interesting… something must be up with the firmware on the device. Might be worth trying just a simple Particle.Publish() with dummy data every minute to see if that at least makes it to the cloud.
You may also consider some Serial Debugging: USB Serial Debugging | Tutorials | Particle
More particular if you set your log level to LOG_LEVEL_ALL you’ll receive additional debug information. Logging
I personally have not use the geolocation myself… just trying to provide some troubleshooting tips that might help.
Are you getting any type of error when monitoring serial over USB. There should be lots of data being written to a serial monitor on your PC using USB Serial monitor.
What about just a basic Particle.Publish() such as this:
// EXAMPLE USAGE
bool success;
success = Particle.publish("motion-detected");
if (!success) {
// get here if event publish did not work
}
I agree with Tom that there is nothing obvious that I can see as he code worked without any changes when I followed the tutorial steps. Couple more thoughts:
I am not sure this is apples to apples but there is at least one other post with a similar theme that might be worth looking at. In they case it was the issue around product vs sandbox.
You can replace all Serial.print statements with Log.info - that way it should all be in the same stream.
Just for fun, why not call the Geolocation service explicitly using:
/**
* You can use this to manually publish your location. It finds the Wi-Fi or cellular location
* using scan() and then publishes it as an event
*/
void publishLocation();
Not sure it will make any difference but perhaps eliminate some things.
Jeff – I tried your “motion-detected” event code. It worked fine. However, the geolocation example doesn’t use the Particle.publish() call, so I’m not sure this tells me anything.
Chip – I read through the post you linked. At first it sounded promising, but I think it’s a different problem. Sounds like their webhook replies were going to the wrong place.
I tried updating the OS to 2.1.0 and I definitely get a lot more log message–a screen full after boot before my application even starts up. Once my geolocation app is running, the debug messages seem to point to some issue with the cellular radio. It looks like the micro tries to send some commands to the cellular modem but gets errors back.
That explains why the scan data is empty; it didn’t get performed. Definitely going to need help from particle on this one. What’s weird is this is the second Boron I’ve tried, so I doubt it’s a hardware problem.
@tomgherron or @particle7888 if you guys feel like, when the issue gets sorted, I invite any of you to tell us where the issue was, for future reference and the benefit of the community.
Thanks!
Checked with Rick and he replied that Web IDE might be using an old version of either the Google Maps Device Locator library or CellularHelper. The Boron uses cellular global identity, which should work with AT+CGED at all, resulting in the error. Old versions of the library did not use cellular global identity.
I am deploying my counters to all the North Carolina State Parks (there are 53) over this summer. The state sends them to the parks from a central warehouse and the parks scan a QR code to register the counter. This has worked very well over all but, one counter came on-line and was not registered to a park. I watched it over the past two weeks sending counts but the solar panel was not connected so the battery was getting very low. I did not have the registration information so I did not know who to reach out to to get this sorted.
The answer was to flash the code from this thread. The location was approximate but it was close enough to clearly see which park had the counter and reach out to the staff to get it charged and registered. Happy ending.
Though not as accurate as GPS, this service can deliver valuable information.