I have two of the LTE Beacons in the dev kit, and have been having trouble getting them to connect. They are currently reporting that they are connected to Orange and TMobile.pt respectively, and I have been unable to have them connect to any cell network in this area. (I know and have verified full coverage here, in the US.)
I connected via the Estimote app and it shows general details about them, and says that they are supposed to update (one daily, one monthly… despite the fact that I toggled the light on it to daily…) but nothing seems to happen.
I’m not really sure my next course of action. In the cloud I would be able to see any events they publish, but of course without a cellular connection not much is going to happen.
Any debugging tricks or tips, resets for it, or other thoughts?
As another note, I tried using the IDE in the cloud to use the Web Bluetooth to publish directly to the beacon locally, and no matter what computer I try, it doesn’t show me the option. I know I have bluetooth enabled in the browser and tested it with other test devices… but the IDE doesn’t give the publish option.
Updated: hmm, I checked both of your LTE Beacons, and it seems they’re connecting fine. I can see last activity for both SIM cards 11 hours ago, on the AT&T network. Can you try uploading a micro-app to the beacon and see if that works?
So according to the Estimote app on iOS and Android, the last carrier was still Orange and Tmobile.pl, and the cloud console shows the last heartbeat as 27 December, even though at least one of them is set to a daily heartbeat. (For one, I keep setting it to daily using the button, and the app doesn’t show the change, so I’m not sure how to force that…)
Now this is strange… I just did a Draft IoT app (the GPS Tracker) and it now shows me the beacon connection, even though my other one was the draft one deployed to production. Odd? Anyway, the draft gives me the option to scan and it shows different information than the Estimote app does. This one shows battery at 4% (the app shows 99%) and the last carrier as AT&T, though the app is still convinced its Orange. I’m not really sure which to believe, but it’s a pretty big difference.
(The other one shows a battery of 3% on the web and 99% on the App, and also shows AT&T as last carrier, which is different than the app.)
According to the IDE, the sample micro app has been deployed, although it shows the assigned IoT app as None. I took the draft and did a deploy and selected both LTE Beacons, and now they do show the assigned IoT app again on the web.
At this point, I don’t see any reports on the web and the mobile app seems confused… web maybe less so, though I don’t see any heartbeats or events on the web side.
If the web is accurate (and not the app) I would hope to get a heartbeat and event on position change, though aside from that live event log I don’t see how I can monitor that. Is there a way to trigger an event, whether through JavaScript deployed on the beacon or a button press or something? Or to force the heartbeat to see if the connectivity is actually in place?
One other note on heartbeats… when I connect via the Draft IoT app, the beacon (presumably) reports that the last heartbeat was today… and the web console reports it as December. I don’t know if it attempted a heartbeat and it failed, or if there is some other reason those are skewed. Obviously the beacon’s view of the world may be different than the cloud console.
So I think things are working better than they might otherwise be portrayed, and that the console / app are a bit misleading. Working with a draft app I was able to deploy a simple app onto the beacon, and added a simple button handler to send an event. I can see that received on the event console for the app… so that’s promising.
Whether in draft or deployed, I can’t get the app on the server to respond to the event. I tried stripping it down to a simple post, using the request promise library used in the example:
indent preformatted text by 4 spaces
This seems like it should fit the execution requirements, as the request.post returns a promise… but I can’t see any result on my server. I’m not sure of a good debugging process here, but trial and error hasn’t been too successful so far. Is there a way to log information on the server code, or to see why the outbound request might be failing?
All right, so we went to the database, and we can see the heartbeats from your beacons just fine. We suspect the Cloud dashboard doesn’t refresh its caches correctly, we’ll look into this.
The Estimote app takes some of the data directly from the beacon, but some from Estimote Cloud, which is why some things you see in the app are okay (e.g., battery level), and some are not (e.g., last carriers). This should also get fixed once we fix the cache. [EDIT: actually, turns out Estimote app doesn’t actually fetch any data from the LTE Beacon directly, only from Estimote Cloud “device details” APIs. So if working correctly, the app should always show the same things as Estimote Cloud does.]
You can force a heartbeat via sync.now() in your micro-app.
So something being cached makes sense to me. I don’t know if that same cache is driving the Estimote app itself, but it seems to have a similar characteristic.
A few API questions…
setSyncPeriod has a parameter for unit, but it’s not clear what the possible values are for that?
The device can receive a message from the cloud, but I’m not sure how to send one to it. Is there an API endpoint for that? The LTE API seems to only focus on reading events.
In location using startUpdates, there is minInterval (s) and minDistance (m), so with this, if I have minInterval set to 300 and minDistance to 10, when would it report? After 10m of movement… after 300s has passed, or in the event that either has passed? Basically are those parameters And’ed together or Or’ed?
And then a follow up, so I had both LTE beacons running the same application doing the button press handling and location reporting… and one stopped responding, without any more events being published. The last report showed good battery, and I have it plugged in via USB-C just to be sure.
Now, when I scan from either the Estimote app or the Web Bluetooth, it only shows one of the two beacons, and the other seems to be unresponsive. I don’t know of any way to reset it, and with it not showing on any bluetooth scan, I’m not really sure how to bring it back into action.
The device can receive a message from the cloud, but I’m not sure how to send one to it.
At this time, there’s no way to send messages from Cloud to the beacon. It’s on our radar, but we still have to put more research into if/how this would be possible, especially when running on battery power (in which case, the beacon has its LTE radio off most of the time).
minInterval (s) and minDistance (m) (…) are those parameters And’ed together or Or’ed?
Good question! I’ll need to get back to you on that (;
So I still have one of the LTE beacons that’s gone radio silent. It’s been plugged in and was showing a reasonable battery level before it stopped answering… is there a way to reset this thing? It’s not responding to Bluetooth and not reporting anything to the cloud services.
Beyond that… yet another question… I have been unable to get the LTE beacons to report their location at all. Perhaps I’m configuring the device wrong, but I’ve had it with a clear line of sight with no blockage, and it simply won’t trigger any location activity. Any insight?
You can see a snippet of code below, with a spot of debugging.
var lastPosition = { };
location.startUpdates((position) => {
lastPosition = position;
print("Handling Position Update.. " + new Date());
cloud.enqueue('position-change', {
lat: position.lat,
long: position.long,
battery: sensors.battery.getPerc(),
temp : sensors.temp.get()
});
sync.now();
print("Completed Cloud Enqueue for Position Change and Sync request..");
}, { minInterval: 300, minDistance: 10, timeout: 0 });
LTE Beacons sometimes getting stuck is a firmware problem. We’re working on an update to address that. The beacon should “unstuck” itself after a while, or you can “restart” it by unplugging the battery and plugging it back in. The latter would require getting the beacon out of the enclosure though, which isn’t an easy thing to do without a risk of damaging the GPS antenna, so I probably wouldn’t recommend it at this time.
minInterval (s) and minDistance (m) (…) are those parameters And’ed together or Or’ed?
The minDistance actually turns out to be not implemented yet.
Beyond that… yet another question… I have been unable to get the LTE beacons to report their location at all.
Note that it may take up to 12.5 minutes to get the first fix, assuming clear line-of-sight to the satellites. Let us know if you’ve had your beacon running out in the open for more than that, and still didn’t get a location update.
Ok that’s good to know that it’s a known problem. I had both beacons freeze up like that for some hours, and eventually both seemed to return to service. I don’t really want to open the enclosure and risk damaging things, so I’ll just plan for the intermittent operation for right now during testing.
With the location monitoring, is minInterval implemented? I’m still having trouble getting any location fix from the beacon… I don’t know if that code could be tried on another one, or if somebody can tell me what I’m doing wrong with it. I’ve left the beacon in the open for quite a while and never get a position reading. I’ve also tried putting it on the dashboard of my car while driving around for a while, and it never got a fix there either.
By the way, the web bluetooth integration in the IDE works great, now that I understand to use the draft project for that. I really like that quick iteration and ease of writing out the updates to the beacons. Kudos to people for that.
So, uhm … I’ve just learned that the 0.0.2 firmware version that you have doesn’t properly support GPS yet ^_^ That’s bad news, good news is, we already have that fixed and it’ll go out in this next firmware update that we’re preparing, that’ll also fix the freezes. One update, two bug-fixes!
On a more serious note, we’re sorry about that, and thanks for bearing with us as one of the first users of the LTE Beacon!
Ah well… that would explain a few things, and that means I can go bring them back inside. It’s a bit cold here, and they look chilly.
I’ll set them aside for the moment then, and wait for the firmware update. Is that process something that would be executed through the mobile app? And I hate to ask, but is there a timeframe on the release? I totally understand the early adopter thing, so it’s not a problem…
We have the majority of the firmware ready, and we treat this as a pretty high priority, as it affects many of the LTE Beacons from the first batch. It’s almost the end of the week now, but I hope we’ll start rolling it out next week.
The updates happen automatically during a sync/heartbeat. (In the future these automatic-updates will be configurable.)
Hope every thing ok in this new year for you. We used estimote technology in our app since the beginning and its totally integrated to the core of our system. We will be honnored to beta test and report LTE beacon behavoiur. On one hand because our customer want to make many uses cases with them. So we have 3 weeks for that with my team, i can order them now and if you have some tests to perform just let me know.
Are you sure lte.getStatus() returns empty object instead of Promise? Or do you mean that object returned by promise is empty? Because when you call JSON.stringify on promise it will return empty object JSON: {}.
Calling:
So I see… when I did a print message with the result of the promise it didn’t show anything, but when I added it to an event I sent back through the cloud, I was able to see the status object details. Great!
