Philips Hue Library


#1

Hi folks,

I recently tried my hand at writing/porting a library to interact with the Philips Hue bridge and connected lights. The library is posted here - https://github.com/nolandubeau/philips-hue

I have studied several example libraries and read through the Particle library docs. There are so many great examples out there to learn from.

When I include this library in a project and flash it to an argon for example, it compiles and flashes the first time without error, however the application doesn’t appear to work as there is no output in the serial monitor. When I then try to flash it again, there is a DFU error in the workbench terminal and the board goes into an unresponsive state from therein. In order to get the board working I then need to re-flash the firmware to get it to respond.

As I’m new to developing on the Particle platform I’m at a loss as to why the board becomes unresponsive with the DFU error. The code appears to “blow it up”, but at the same time it compiles without error.

Note: With the exception of one function in the firmware, I have commented out the majority of REST calls and just returned strings for testing purposes. Also, you will need to provide the IP to your PhilipsHue hub as well as the API user which you can generate with a rest call to the hub.

Hoping someone more experienced on the list can shed some light (pun intended) to help me get past the error.

Thanks.

Nolan


#2

One note on the use of HttpClient in your library.
You should state that dependency in the library.properites file so that this library will automatically be pulled in when your lib is imported.

Also your (as any other) header file should guard itself against repeated inclusion (eight via #pragma once or a #ifndef .. #define .. #endif construct).

And - if you have been following this forum a while might have read before :wink: - trying to avoid using String wherever possible may contribute to long term stability of a project using your library.

You may also want to replace the Serial.print() statements with Log.info() to allow the user of your library to turn on/off logging from “outside”.

Next, you need to avoid while(true){}; or at least call Particle.process() inside that loop to allow the device OS to attend to its background duties.


#3

Thanks @ScruffR.

Noted regarding the dependencies and logging. The serial prints were just placeholders that intended to replace with logger.

I’m fairly new to the forum so will need to catch up on the discussions regarding strings. I’ll have to dig into the HTTPClient code as I’m pretty sure response.body is returned as a string from the HTTP requests. Would you recommend that an implantation like this return JSon objects instead? Thanks for the tip re Strings

Could you elaborate a bit more on #pragma once? I’ve seen this in a few libraries but have yet to look into how it prevents libraries from being included more than once.

Finally, do you think that some of these errors on my end would be contributing to the DFU error?

Thanks for the great feedback.


#4

If you had multiple files in your project where each of them would feature a #include <yourLib.h> statement, then you would end up with a multiple definitions error message and that’s where the guard kicks in and only “allows” the first statement in a module to actually include the file and all subsequent ones will be ignored.