BluzDK solid Green


#1

I left my BluzDK connected through my iOS v1.1.0 gateway last night, controlling it from the opposite end of the house (very impressive). After waking up and being reunited with my BluzDK, I noticed it was solid Green. I tried connecting with the Bluz app and it was not coming up on the scan. I’m not sure what I could have done at this point to troubleshoot, so I reset BluzDK and it immediately showed up in the iOS app. Then I had to press connect, and it was connected. I would guess this is going to be repeatable, so I can set up logging output on it to see what’s going on. Unless this is already a known issue?


#2

Not a known issue. I have gotten into similar states a few times while we were developing, but haven’t seen it in quite a while. It sounds like perhaps it was due to long-distance connections, maybe it was disconnecting/reconnecting often throughout the night?

What code was running on bluz, just normal tinker?

I will try and replicate as well.


#3

Yep just Tinker, and it could have definitely been connect/disconnecting. I’d say it was maybe 40-50 feet through walls and floors. Sorry I can’t be of more help than that :wink:


#4

Not a problem. Just to clarify, you did have the Auto Reconnect turned on in the app, correct?

I have had a setup running for nearly two weeks now where a bluz DK is connected to a gateway shield. Every once in a while, the Photon loses the TCP socket which forces the DK to disconnect/reconnect. It is happening infrequently, less than once a day, but it hasn’t hit any issues yet and is still online and controllable. I wonder if perhaps it has something to do with the iOS app, maybe it tries to reconnect in a much more aggressive manner before bluz has had a chance to clean up. Or, my rig is pretty close together, so maybe it is rapid connect/reconnect from being far away that causes it.

I will try and recreate today, if you see any further symptoms, let me know. Thanks


#5

Yep! Best new feature :grin:

Also I have Discover Only Bluz, and Cellular Data enabled.


#6

Ok, I opened an issue on this: https://github.com/bluzDK/bluzDK-firmware/issues/11

I tried a few things today, the first was to connect bluz to the iOS app and place the phone far away and then intentionally cause disconnects/reconnects (by placing my hand over the antenna) many times. This didn’t seem to reproduce it. However, I then left bluz connected and intentionally walked away and in/out of range for about 30 minutes or so (and grabbed some lunch in there :grinning:), and when I came back bluz seemed to have hung. It wasn’t green, the LED was just off, but it is possible yours simply hung when the LED happened to have been blinking.

I briefly tried the same thing with the gateway shield and didn’t immediately see the same problem, but I am still trying. I will try and turn on debug logs and get to the bottom of the issue. It must have something to do with the order of events that happen after the phone disconnects and then tries to reconnect.


#7

@BDub I was trying to fix an issue in the gateway firmware, and in doing so found a bug in the regular DK firmware that may be related to this. Essentially, there was a possibility that the socket buffer could overrun, leading the system to lockup. The symptom (total freeze of the system) is the same as you reported, and while I have no direct evidence that long range connections would cause it, I could see instances where it could happen.

Anyway, I checked in the fix to the develop branch. If you happen to have any time, would you be able to build locally form that branch and try again? If this does fix the issue, that may expedite getting 1.1 sent out as this is a particularly nasty issue and could be caused other ways.

Let me know. Thanks


#8

My first day with Bluz went OK. The next day I tried to use it again and I get the solid green. Pressing reset does not restore it to original state.


#9

@paul_tanner Had you updated the DK to 1.1.47? That should clear up any issue of the DK getting stuck in the solid green state.

If you power cycle the board, can you get it back to blinking green and re-connect it to the cloud? If so, you can update the firmware as described here: DK firmware v1.1.47 is Available


#10

Thx @eric
Unfortunately power cycling does not fix it. Is there a special method for factory resetting?


#11

So when you power cycle the board, the LED comes on and stays solid green? It never blinks?

Could I ask what user code you are running?

There is a way to factory reset the device, you can follow these instructions: http://docs.bluz.io/tutorials/bootloader/#performing-a-factory-reset


#12

My user code had a publish call which I think is wrong if a connection is not in place. I will fix that.

Meanwhile I was able to factory reset. Thx. I will look at updating the firmware.


#13

selected new firmware and “web-connected led” example
verified
tried to flash
(hopefully this is the correct way to both load a program and change the firmware)
flash unsuccessful
tried again flash successful
I have the steady magenta on device.
sent command from web form (worked yesterday)
{
“ok”: false,
“error”: “Timed out.”
}
Noticed that gateway had exited (running on android 5.1.1)
Restarted that, pressed connect and got claim button.
Error claiming device
Tried claiming and unclaiming to no avail
Unclaimed on portal
Claim still fails on app.

Not good :frowning:


#14

After a factory reset, the device is in Safe Mode, meaning it only flashes magenta. Once you got it back online and flashed down the code from the Web IDE (by selecting 1.1.47) it updated the user app, but it was still in Safe Mode and would still blink magenta. Once it comes back online yet again, the cloud will start to send down the new system firmware, which will lead to lots of blinking magenta for 1-2 minutes. You can read more about this here: http://docs.bluz.io/tutorials/updates/#firmware-parts

Looking at the logs, I see the device coming back online after a factory reset, then getting the new user part. The cloud tries to update the firmware, but it keeps going offline within about 1-2 minutes. Is the app crashing? Normally you can just get it online and leave it, eventually the LED will go to solid blue and the system will reboot into normal blinking green. You don’t need to claim the device at this stage, so you can ignore that for the moment. Just getting it online and letting the cloud finish the update is the more important part.


#15

OK. I will leave it alone for a while. gateway app is running again. Yes, it did crash before. What’s disconcerting is that there’s no indication on either app or portal to confirm that anything is happening.


#16

Latest situation: BluzDK is flashing magenta after factory reset.
Gateway app seems to connect to device and I can claim it
Device appears on the particle dashboard again.
Device still flashing magenta after 15 minutes (does not go to solid blue or blinking green)
Is something wrong with device?
Apart from the LED, is there any other way to know what’s happening?
Thx.


#17

I think this is a variation on this post BluzDK slow blinking Magenta


#18

Can you DM me the device ID? So b1e2ABCD where ABCD is really what I need. I don’t need the entire ID.

If you subscribe to events (‘particle subscribe mine’ with the CLI) or look at the Dashboard logs, you should see it come online and then should see an event indicating Safe Mode. Then you should see the update start, the event name will be spark/flash/status and it should say “Started”.

You should also see an event called module-info, if you can post the data from that event, it would be helpful (or I can look it up once you send me the device ID)


#19

Not sure how to DM you but I’m OK to give you the ID which is 43bb.
Did particle subscribe mine
Got 1 event {“name”:“spark/status”,“data”:“offline”,“ttl”:“60”,“published_at”:“2016-05-04T19:54:13.752Z”,“coreid”:…

I am missing events because the app gets disconnected or exits.

Now got this:

{“name”:“spark/status”,“data”:“online”,“ttl”:“60”,“published_at”:“2016-05-04T20:00:11.758Z”,“coreid”:“b1e243bb…
{“name”:“module-info”,“data”:”{“m”:[{“f”:“b”,“n”:“0”,“v”:"6}{“f”:“s”,“n”:“1”,“v”:“3}{“f”:“n”,“n”:“0”,“v”:“0}]}!P\u0002”,“ttl”:“60”,“published_at”:“2016-05-04T20:00:13.207Z”,“coreid”:“b1e243bb…
{“name”:“spark/status/safe-mode”,“data”:”{“f”:[],“v”:{},“p”:103,“m”:[{“s”:16384,“l”:“m”,“vc”:30,“vv”:28,“f”:“b”,“n”:“0”,“v”:6,“d”:[]},{“s”:126976,“l”:“m”,“vc”:30,“vv”:28,“f”:“s”,“n”:“1”,“v”:3,“d”:[]},{“s”:20480,“l”:“m”,“vc”:30,“vv”:0,“d”:[]},{“s”:126976,“l”:“f”,“vc”:0,“vv”:0,“d”:[]}]}”,“ttl”:“60”,“published_at”:“2016-05-04T20:00:13.208Z”,“coreid”:"b1e243bb…

Still flashing magenta.


#20

Interesting, it is coming online but it looks like the Particle safe mode healer function isn’t kicking in and updating the system firmware. From this data, it looks like the dependency isn’t there. Strange.

Can you go to the Web IDE, select the device and FW v 1.1.47. Then try flashing any app down while it is in Safe Mode? You can still load code in this state, that should hopefully restore things