Direct Bluetooth connection from App(No Particle Cloud)


Do you have 1.1.47 selected as the version in the Web IDE? This was added in that version, so if you are using 1.0.47 you would see issues like that.


I have 1.1.47 selected in the web IDE but am also using the CLI.


Could you perhaps post the code (or a subset of the issue if it is long)?

I just tried this and it seems to compile just fine:

void dataCallbackHandler(uint8_t *data, uint16_t length) {
  //do something with the data
void setup() {
void loop() { }

EDIT: Changed the code as I had accidentally copied the wrong callback on the first try. With this code I was able to show the error you mentioned only if I changed the version to 1.0.47. With 1.1.47, it compiled fine.


thx @eric. Today it compiled for me on the web IDE but still not on CLI
I guess this could be a caring glitch with the web IDE (I did try it multiple times).
is there a way to tell the IDE what version to use?


In the Web IDE, you can select it via the Devices button on the bottom left side, then select the device and choose the version:

In the particle cli, you can specify the target to build:

particle compile bluz --target 1.1.47 my_project


great thanks that works with one minor change

particle compile bluz --target release-1.1.47 my_project

it will remain a mystery why the web IDE approach did not work but never mind - I find the CLI a lot more convenient.


Well, it did work in July and I can still run that binary. But trying the build again (same code) now now I get:

region `APP_FLASH' overflowed by 440 bytes

I guess I’m stuck now until something happens to release some space. I will go back to this issue Available firmware space on Bluz

P.S. I do have this working when the amount of code (especially use of floats) is minimal. However, when I start adding libraries to support various sensors I get one of two problems:

  • overflowing of APP_FLASH which the compiler picks up
  • overflowing of RAM which causes the kind of mess only resolved by a factory reset.

To reproduce the latter issue you can build with BMP280 (temperature/ pressure) sensor and leave nothing out.


I have a wireless weather project that I want to use the Bluz for that would require it to talk directly to an custom App on a smartphone (made via App Inventor). It’s a project that will ultimately be used on a sailboat where there is no cell signal or wifi. I’m guessing that this thread is where I should be looking for info. I’m admittedly new at this but I have no problem putting in the time and do what needs to be done to figure it out. All I’m asking for right now is a push in the right direction and where to start…and dumbing it down a little can’t hurt. Thanks!


Hey @EvelOtto

Yes, this is definitely possible(direct connection from app to bluz module). I believe @eric has some sample code for iOS and Android which will get you pushed in the right direction. I admittedly do not know anything about App Inventor though.


I guess what I’m looking for right now is a code example of how to get the Bluz connected to an app. I’ve found a few tutorials out there on how to do it with an arduino w/BT shield and wanted to know if it works any different with the Bluz?


The best place to start is our open source apps, here is the iOS one:

The method of BLE connection is similar, but the way to send data down is a little specific to bluz.

Windows Phone Support

Hi everyone,
I am working over bluzDK-firmware and when I am running make command, I’m getting these type of error-

make -C …/modules/bluz/user-part all
The system cannot find the path specified.
The system cannot find the path specified.
make[1]: Entering directory E:/Electronics/Particle/Bluz/bluzDK-firmware/modules/bluz/user-part' make -C ../../../user The system cannot find the path specified. The system cannot find the path specified. make[2]: Entering directoryE:/Electronics/Particle/Bluz/bluzDK-firmware/user’
‘Building file: src/blank.cpp’
'Invoking: ARM GCC CPP Compiler’
mkdir -p …/build/target/user/platform-103-m/src/src/
The syntax of the command is incorrect.
make[2]: *** […/build/target/user/platform-103-m/src/src/blank.o] Error 1
make[2]: Leaving directory E:/Electronics/Particle/Bluz/bluzDK-firmware/user' make[1]: *** [user] Error 2 make[1]: Leaving directoryE:/Electronics/Particle/Bluz/bluzDK-firmware/modules/bluz/user-part’
make: *** [modules/bluz/user-part] Error 2

Please help me in resolving the issue…


I am also having the same issue. Please guide us in resolving the issue.

Locally connect the nrf BLE to Bluz gateway

To make a user app, you should be in the firmware modules/ folder, then use this command:

make PARTICLE_DEVELOP=1 platform=bluz APP={folder name under the user/applications/ folder with your code}

So for example, if your code is in user/applications/myapp it would be:

make PARTICLE_DEVELOP=1 platform=bluz APP=myapp

You also need to have the ARM gcc toolset installed and in the path, we recommend using version 4.9.3.

What command are you trying to run?


Hi, I am flashing my code into bluz using STLinkV2, it first wipes my all the available firmware on bluz and then flashes the new one. Is it correct process to flash the code ?

Thanks in advance :slight_smile:


You only need to use the STLink if you are altering system level firmware. If that is the case, then yes, the STLink is the easiest way. It will erase the flash each time so you need to flash all parts every time


Hi @eric !
Thank you both @IOTrav and @eric you guys saved me a lot of time here.
@eric I’m using the code you created on custom_data_service app. After I flash the code OTA, it seems like Particle Cloud is not accessible anymore.
Since you’ve already integrated the service within the system, all I had to do is flash the user-part. It works great but the cloud part. Am I doing something wrong? Or missed something here?


The app in the GitHub repo for custom_data_service calls the SYSTEM_MODE(MANUAL) command. This puts bluz into manual mode, meaning it will not connect to the Particle cloud.

In that same code, there is this:

    pinMode(D6, INPUT_PULLDOWN);
    if (digitalRead(D6) == HIGH) {

So if you hold the D6 pin HIGH on bootup (just jumper it to the 3V3 pin) then it will enter AUTOMATIC mode and operate normally. You can remove the SYSTEM_MODE(MANUAL) call at the top of the code if you don’t want to operate in manual mode.


@eric thanks. Now it works the way I need it to.