2.0.50-beta.2 Pre-Release Available


We are happy to announce the availability of v2.0.50 beta release.

This release includes the following enhancements and fixes:

  • Utilize buildpacks for releases, allowing the use of gcc 4.9.3 on the Web IDE
  • Addition of the Timer interface to setup software timers
  • Addition of the Time interface to get accurate time information from the cloud
  • Addition of the EEPROM interface to allow persistent storage
  • Addition of BLE functions to set transmit power and advertising name
  • Allow the gateway to connect only to certain advertised names
  • Allow the gateway to specify connection interval
  • Stability to the gateway code that could result in hangs if DK’s are publishing
  • Fixes to issues #26, #10, #5, #4, #1

Docs for the newest features are on the staging server: http://staging-docs.bluz.io/
You can update your gateway to the latest firmware on the staging console server: http://staging-console.bluz.io/

This release is still in beta and is not considered ready for production. We are interested in any users feedback from using these features, good or bad, or you can open issues directly onto our issues page: https://github.com/bluzDK/bluzDK-firmware/issues

Updating to a new version means that system firmware must be updated the first time. We strongly recommend using the bluz iOS or Android app for this first process, instead of hardware gateways, to speed up the update.

Details: https://github.com/bluzDK/bluzDK-firmware/releases/tag/v2.0.50-beta.2




Now that 4.9.3 is working, does this mean that there will be more user space for programs?


That will be coming up very soon.

The ability to use 4.9.3 opens this up, and we indeed shrunk the system firmware space for this release. But what we need to do is a two-step process. So the first release shrinks the system firmware but leaves the user firmware size as-is, basically creating a hole in the flash. Then, next release, we will increase the user space.

This is necessary, a device must have the smaller size system firmware before it can accept the larger sized user part (or it would overrun the system part). Since the Web IDE always updates the user part first, we needed to do it in two stages.

So this puts on on the path and the next update will increase the user size.


Are the SLEEP_MODE_DEEP changes available in this release? I didn’t see it documented in the staging docs.


Yes, it is. Thanks for the note, I will update the docs to show that.


I’m perhaps being a bit dense, but I don’t see how to update the system firmware with the bluz iOS app. When I launch the app, I can see all my bluetooth devices, but don’t seem to have any ability to do anything with them


That happens from the Web IDE. So once the device is online, you can select the new version from the Devices tab in the IDE. Flash an app, the device will enter safe mode. Bring it online again and the cloud will automatically update the system firmware version.


So…I’m not at home so I can’t yet confirm what I’m seeing, but I believe my digital inputs are not working properly with the system firmware upgrade. They worked fine in 1.1.47, but now are reporting being “off” when they are actually “on”. Nothing was changed except recompiling and flashing the existing code with 2.0.50-beta.2.

Can I recompile with selecting 1.1.47 to go back to that flavor of the system FW? I tried, but it didn’t seem to take.


What pins are you using?

There is a bug reported on v2.0.50 where D0 and D1 don’t seem to be behaving properly. I can confirm this is true, so if you are using those pins there may be an issue. Issue is here: https://github.com/bluzDK/bluzDK-firmware/issues/35

There isn’t a way to downgrade from the Web IDE. I should be able to get a new beta version out later this week with the fixes, if you can wait. If not, you can download the system binary file for v1.1.47 here: https://github.com/bluzDK/bluzDK-firmware/releases/tag/1.1.47

Then you can flash that over to the DK and it will revert your system version back to the old version. You can use the Particle CLI to do it like this:

particle flash [device name] system-part1.bin

NOTE: You probably want to upload the system part when using the app, not the gateway, or it can take a long time.


I’m using D1 on both devices. So…that’s the issue. I did not see the bug reference or I wouldn’t have upgraded. Darn! I assume you’ll post a note when the update is ready. Thanks for the quick reply!

I’m sorry, but I still don’t understand your NOTE. I guess I’m just dense. How do I upload the “system part when using the app, not the gateway…”?


Sorry about that, we didn’t discover the bug until after we released. I will try and get this resolved quickly. All great feedback though, good thing we catch these in Beta!

For the NOTE section, I just meant that it will be much faster to upload if you connect the DK to the cloud using the app, not the gateway. So the way to do that is to disconnect them from the gateway (unplug the gateway is the easiest) and then use the iOS or Android app to reconnect them. Then perform the update.

You can do a system firmware update with the gateway, it will just take longer (~7-10 minutes). Unfortunately, the Particle cloud has a hard limit of 10 minutes to timeout an OTA update, so it is possible the process could timeout. This is just due to the fact that the system firmware binaries are much larger and the throughput through the gateway is slower than through the app.


@ctmorrison: I just thought of something, there may be a simple workaround for this.

Can you add these two lines of code to the top of your setup() function, before you configure the digital pins? So like this:

void setup() {
  // rest of your code…

That may force the I2C driver off which would allow you to control the pins again. I am not home at the moment, but I can also try this soon to see if it works. If it does, then this can be a simple workaround until I can get the fix pushed to the Web IDE.



This “fix” did not seem to work.

But…Ahhhhh…I now (finally) understand what you mean by using the app. I couldn’t understand how I was to do an update without the gateway. FWIW, it might be helpful to note this in the docs if it’s not already noted.


@ctmorrison: I did try this fix and it seemed to work. The TWI driver is being activated for some reason, still trying to discover the root cause, but calling Wire.end() should solve the problem. You can also try calling SPI.end() instead, though this would have the same effect. This would need to come before any configuration of any of the pins in the setup() function.

Let me know if that works. I hope to get a new version with the permanent fix soon.


Simply inserting Wire.end(); before pinMode works perfectly to restore D1 as a functioning interrupt pin for me. Thanks!


@bpr and @ctmorrison: This issue is now fixed. I will get a v2.0.50.beta3 pushed out to the Web IDE soon (as soon as I finish the servo library) and that will fix it for you permanently.

In the meantime, you should be able to just put Wire.end() or SPI.end() at the beginning of your setup() function as a work-around.

The issue had to do with the fact that we swapped which peripheral the user had access to with v2.0, however your bootloaders still use the old way. You can see more here: https://github.com/bluzDK/bluzDK-firmware/issues/35


@eric, I’ve tried both SPI.end() and Wire.end() as my first statement in setup() and neither works for me. The statement immediately either of these is: pinMode(sensor, INPUT_PULLDOWN) where sensor is an integer variable initialized to D1.

So…I don’t know if I should introduce a delay before configuring D1 or if it’s something else, but my code continues to report the digital input as being off when it should be reported as on.

BTW, I’m using D2 as a digital output to provide the power for the external switch that’s being sensed via D1. I turn on D2 just prior to reading D1. I’m using this approach to save battery.


This is one of the few instances in which I used the internal pulldown resistors in lieu of external ones. I’m wondering if that’s contributing to the issue. @bpr, do you use internal or external pull ups/downs?


I used internal . It’s a puzzle why you’re still having troubles. I’ve also tested d1 only as an interrupt so far.
Addendum: I checked D1 using simple digitalRead and it also worked also. So my only suggestions would be to try it without any breadboard (if your’re using one - some people report some breadboards are faulty) and to also make doubly sure you flashed the new version firmware and built you’re application using it.