I am building out my fleet of Particle Boron devices which send data to Ubidots using a Particle Integration based on a webhook. Here is why I went this way back when I made this decision:
Less code - less libraries and less code for me to maintain
Consistent Particle.publish() format for sending status data to the console or data to Ubidots
Response templates - Automatically strip the response from Ubidots down to a single integer (201 success / 400 or other failure) which made it easier for my code to determine if the data was delivered and could be deleted from the device.
Security - Webhook data is encrypted from my device to Ubidots
However, this approach does have its downsides:
Not clear how to implement a mesh to cellular gateway model
troubleshooting Webhooks is a real pain in the butt
Particle is very sensitive about the response time - Ubidots only has 6 seconds to acknowledge a response and this has caused issues periodically
Hi there @chipmc, we released the Particle library a lot of months ago and was our first approach to support the new mesh devices from Particle. The main focus of our library is to provide to our users a faster way to create POCs and MVPs to test their product ideas. The library exposes 4 ways to send data: TPC and HTTP using the native TCP client, UDP using the native one and Particle Webhooks, and basically we implement in the background routines to create properly Ubidots accepted payloads and send them to the cloud using these protocols.
Said this, there is a big advantage of using Particle Webhooks: Security. Particle has developed its own secure protocol based on pre-shared keys between the device and their cloud while our library (unless that you use Webhooks) uses the native plain TCP or UDP clients that sends plain data text that would be sniffed. Unfortunately, Particle does not actually offer a native TCP client with TLS (I am not sure why, as Espressif already does this) that we can add to the library. In the past, we tried with some TLS libraries that we found in the forums with poor results so we decided to not add them.
I will have a word with our PM, as I think that we may contact to Particle to extend the timeout wait for cloud-to-cloud connections, if this is possible I will notify you.
Now, about pros / cons of the library:
Pros:
Easy way to add to your actual routines
You can test all the available IoT protocols accepted by Ubidots just changing the instance builder settings
Already implemented methods to update variables with context data, to use device types and other ubidots features.
Cons:
Limited to update 10 variables per request
Plain text data, unless that you use Particle Webhooks
If you use Particle Mesh + HTTP/TCP, there is a throttling that limits data send to 20 seconds per node.
Let me know if you need any additional information
Thank you! This is exactly the information I was looking for. As my clients value secure delivery of data, it seems that I need to stick with the Webhooks approach.
I will also, inquire about the TLS security with my contacts at Particle. I am sure they would appreciate the feedback and may have some suggestions to enable secure delivery using your library.
Hi there @jotathebest, thanks for the update!! It definitely should help with the webhooks coming from Particle. Did you get any update about the TLS client? I would really like if we can explore this option to be included in our actual library.
Anyone can implement TLS/SSL on top of TCPClient. The implementation from community member HiroTakaster works. The main issue is that TLS is huge. It wouldn’t fit in Device OS itself, and if in user firmware, it uses most of the available flash. It is theoretically possible on the Argon to run TLS on the ESP32, and on the Boron, E Series E310, and LTE devices to run it on the u-blox modem. But this would preclude the Photon, P1, Electron G350/U260/U270 and Xenon, and it would behave differently across devices.
Thanks @chipmc for the update, in the past I tried with both Photon and Electron the HiroTakaster TLS library, but I experienced different issues and just decided to not include it. IF the library may work properly in Argon and Boron, I may include it in our actually library. I will be testing it in the incoming weeks, thanks!