This blog explains the setup of a Particle Photon (or Core) connected to HCP – IoT, as an extension to Rui Nogueira blog about RaspberryPi on SAP HCP – IoT (–iot-blog-series-part-61-getting-productive-with-iot-services). You can use Rui’s HCP IoT setup from the link above and move over to the work instruction below to start posting your sensor data from the particle to HCP IoT.

My experience with the RPI which Rui has been using was that you needed to do a lot to get the RPi going (Install OS, Dev Tools, connectivity setup, etc). And all of those things together got me seeking for an easier solution (from my point of view). At the end I had created a similar scenario, but with the Particle Core and Photon instead of using the RPi.

The fun thing about the Particle Core and Photon is that they are very small and they’ve got WiFi onboard. The connection setup to a wifi access point can be established by an app on your phone or tablet.

Spark rebranded to Particle
When I started exploring IoT with HCP I bought a Spark Core (kickstarter project). A couple of months ago Spark has been rebranded to Particle ( Particle has also launched a new device in the meantime, the Particle Photon. I’ll be using the Photon for this blog. And they’ve started another kickstarter project for 2G and 3G connectivity.

Particle Photon Kit
For this blog I’ve used the Particle Photon Kit which contains a couple of standard components.

  • The Photon
  • USB cable for power supply
  • Breadboard
  • Resistors
  • LED’s
  • Photo resistor


Particle Tools
The Particle Core and Photon are delivered with some “free” tools. “Free” because you’ve already payed them when you bought the device. One of the nice tools is the Web IDE. You write your code in the particle cloud and publish it to your device once you’re done.

Currently you have to put the webhook (file) onto the particle cloud with a CLI (commandline interface). Particle is working on an easier solution to create the webhooks.

More info on the webhooks :

More info on installing the CLI:

Let’s get started (Work Instruction)
So now we have all the ingredients to get us going.

  • HCP IoT from Rui’s blogs.
  • The Particle Photon Kit
  • The Particle tools

Task Screenshot / Code
Setup the hardware /wp-content/uploads/2015/11/photon_setup_823538.png

Connect the photon

The RGB LED between the two buttons should be breathing cyan. That way you can confirm that the device is connected to the internet.

When the LED is Flashing green, it’s looking for the internet connection.


Create a file (using notepad or some other texteditor) with the following code.

Change the “<<<YOUR HCP URL HERE >>>” with your HCP IoT url. For example: https://iotmmss***********

Change the “<<<YOUR HCP DEVICE TOKEN HERE >>>”  with the token you received while creating your device on HCP.

save the file and name it “HCP_webhook.json”


“event”: “post_to_hcp”,

“url”: “<<<YOUR HCP URL HERE >>>”,

“requestType”: “POST”,

“headers” : {

“Authorization”: “Bearer <<<YOUR HCP DEVICE TOKEN HERE >>>”,

    “Content-Type” : “application/json”


“json” : {





“mydevices” : true


Logon to the particle cloud through the CLI withthe command prompt or terminal command: particle login

Create the webhook with your json file

Command: particle webhook create hcp_webhook.json
Response from particle should look something like this.

Using settings from the file hcp_webhook.json

Sending webhook request  { uri: ‘‘,

  method: ‘POST’,


   { event: ‘post_to_hcp’,

     url: ‘*********’,

     requestType: ‘POST’,


      { Authorization: ‘Bearer *********,

        ‘Content-Type’: ‘application/json’ },


      { mode: ‘sync’,

        messageType: ‘{{HCP_MTYPE}}’,

        messages: [Object] },

     mydevices: true,

     deviceid: undefined },

  headers: { Authorization: ‘Bearer ********* }


  Successfully created webhook with ID **********

login at the Particle Web IDE.

Go to:


Create a new application by clicking on the “Create new app” button and enter a name for your application.

Enter the following code to your application and replace the “<<< YOUR HCP MESSAGE TYPE ID HERE >>> ” with the message type ID from HCP.

int photoresistor = A0; // This is where your photoresistor is plugged in. The other side goes to the “power” pin (below).

int power = A5; // This is the other end of your photoresistor. The other side is plugged into the “photoresistor” pin (above).

// The reason we have plugged one side into an analog pin instead of to “power” is because we want a very steady voltage to be sent to the photoresistor.

// That way, when we read the value from the other side of the photoresistor, we can accurately calculate a voltage drop.

char resultStr[250]; // Here we are declaring the String, which we will use later to store variables that are being used within the webhook towards HCP.

void setup() {

pinMode(photoresistor,INPUT);  // Our photoresistor pin is input (reading the photoresistor)

pinMode(power,OUTPUT); // The pin powering the photoresistor is output (sending out consistent power)

digitalWrite(power,HIGH); // Write the power of the photoresistor to be the maximum possible, so that we can use this for power.


void loop() {

    float tempLight =  analogRead(photoresistor); // This variable will be used to store the value of the photoresistor.

    char *hcp_messageType = “<<< YOUR HCP MESSAGE TYPE ID HERE >>>”; //This variable contains the HCP message type ID

    //Next we will fill the resultStr with all the variable data thats needed for the webhook towards HCP and use the publish command to send the data towards HCP.

sprintf(resultStr, “{\”HCP_MTYPE\”: \”%s\”, \”HCP_SENSOR\”: \”Light\”, \”HCP_VAL\”: %f}”, hcp_messageType, tempLight);

Spark.publish(“post_to_hcp”, resultStr, 60, PRIVATE);

memset(resultStr, 0, 255);

    // delay to send the measurements every 30 seconds.



Verify your code. /wp-content/uploads/2015/11/particle_verify_823542.png
When your code is successfully verified, you’ll get the following response at the bottom of the screen. /wp-content/uploads/2015/11/particle_verified_823543.png
Publish your code to your Photon as soon as it is successfully verified. Use the Flash button on the top left of the web ide. /wp-content/uploads/2015/11/particle_flash_823544.png
During the flashing the RGB LED on your photon will flash magenta. As soon as it is ready, it will reboot the device and connect the wifi again. /wp-content/uploads/2015/11/photon_flashing_823545.png

As soon as your code is flashed and the Photon is connected again, your code is active and being executed.

Go to the Particle Dashboard to verify that your Photon is pushing the sensor data to HCP:

Return to your HCP Message Management Service Cockpit and select the tile “Display stored messages”. HCP_MMS_cockpit.png

When all the code and settings are correct, there should be a table named “T_IOT_[your message type id]”.

Select the table and have a look at the values that are being stored from you Photon.



As visible in the blogs of Craig Cmehil and also by Gregor Wolf there are quite some blogs on the topic of IoT solutions connecting to HCP. Combining the blogs gets your IoT scenario up and running in no-time. The more sensors, the more interresting it gets. Within this example I used the photo resistor as it was included in the Kit. In the next blog I’ll describe how to add the DHT11, basic temperature and humidity sensor, on the Particle while using the available libraries from the Web IDE. Pretty straight forward, but even easier once you have an example 🙂

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Raphael Vogel

    Did I get this right? You need to upload your HCP authorization token to the Particle Cloud?

    I think there are better ways.

    ESP8266 is cheaper, OpenSource with NodeMCU and you don’t need to rely on other Cloud  provider tooling like WebIDE

    1. Arnaut Kamhoot Post author


      The Bearer token (oAuth) which you receive on HCP while creating the device needs to be stored. If there are better ways then please share them.

      Thanks for the tip on the NodeMCU. I’ll keep this one in mind! Btw, you´re not being forced to use the Web IDE for the particle. There are other devtools as well which you can use:

      1. Marcus Conrad Behrens

        Yes, I’d rather publish the Bearer token to the Particle cloud then to write it directly to the firmware of a “hackable” on-premise hardware. This way I rely on the security provided by Particle from device to cloud and not on one I have designed.

        Raphael, if you have ideas of how to deal with the token differently please share with us. one of the caveats of putting the token on device is the need to update it from time to time. This makes it necessary to allow for OTA firmware updates which in turn makes it another door for entry for intruders that is much wider.

        I would like to use ESP8266 next for another project and will also hook it up to HCP. My goal is to offer each SAP employee a 10$ entry package to hook up a sensor of their choice to HCP and do analysis on the data. It’s very differetn if they choose the sensor themselves and if they keep the hardware and the data (i believe).

        1. Jan Penninkhof

          I really like your last paragraph. I think it totally makes sense to not only focus on Raspbery PI’s and Tessels, which currently seems to be the case at SAP. It would actually be very good for folks at SAP to work with devices that have a much smaller memory footprint and CPU power, to experience how that pairs up with the current IoT services on HCP. They may find that it’s quite challenging to e.g.:

          1. Build the relatively long JSON string, required to communicate with HCP
          2. Turn on SSL on HTTP requests (this takes quite some memory)
          3. Use the device ID provided by HCP instead of the chip-ID that’s already on the MCU.


          1. Marcus Conrad Behrens

            I’m also a big fan of single purpose devices that only do sensor and network communication – no more.

            On the long json string – I achieved streaming 12k data from SD card (bypassing the 4k main memory of an arduino) into an http post via an adafruit fona gsm module. So if you have a good network library it should allow bigger posts – even posts bigger then the main memory of the microcontroller.

      2. Jan Penninkhof

        It’s not necessary to make the token part of the firmware. Instead, you could have some sort of config file on the ESP8266/NodeMCU (using SPIFFS), e.g. configurable using a web-interface.

        I think having the bearer token in the cloud or on the thing is in some cases quite acceptable, and in other’s it’s not. I think it may help to know that there’s also a lot of these tokens currently in the browser cache of your computer. Acceptable?

        > Risk = Chance * Impact.

        I’d say in most cases, the chances of a token being taken from the cloud or an MCU is quite low. It’s quite difficult to hack the cloud or thing to pull these data out of them. Encryption could even increase difficulty.

        The impact is also quite low. Image you got Arnout’s token, what do you want to do with it? In case of Arnoud’s example, the worst you could do is mess up his light intensity stats. Ah hell, we’ll get over that, right? As the impact is so low, the chance of someone putting in considerable effort to pull the token from the thing will also lower.

        Anyhow, this is not a rule-of-thumb for all things (especially not if you consider e.g. a Tesla-car a thing). There are many things that you don’t really need to worry about, but high-risk things should be treated as such, and should be secured properly.

        On another note: I’m pretty sure that Arnout’s thing still has some sort of session/security vector on-board when it contacts, so there’s still something “interesting” on the thing that would give you the opportunity to mess with his light intensity stats.

  2. Jan Penninkhof

    I really like your blog Arnaout! I’ve been thinking of getting the Proton/Particle myself as well when it was announced on Kickstarter. Eventually I was turned of by the delivery times though. Programming it through the cloud really seems to be a breeze. Thanks for the write-up!

    1. Arnaut Kamhoot Post author

      Thanks Jan!

      The Particle Photons are more accessible and cheaper now then the Spark Core with which I started. Particle is currently working on a board which connects through 3G. Even more possibilities although I had created a same sort of solution during a trafficjam 🙂 .


    1. Arnaut Kamhoot Post author

      Sorry for the (extreme) slow response. As you might have noticed, we have organised a mini CodeJam during the SIT Brussels. During the session, we had the same issue but also found a solution. We used a hotspot router to solve this. First user gets the login, the rest (the Photons) could follow.




Leave a Reply