Sharing: Write and Read data to Exosite Cloud using Tiva Connected Launchpad + CC3100 BP + Sensor Hub BP

May I agree w/Amit re: "interesting" and (selectively) applaud your effort and sharing.

However two (significant) issues "bubble up" from your application:

• Has not the "Exosite <-> this vendor combination" - long had (well known) & frustrating disconnect issues?   Have these (now) been solved?
• Three decimal points (accuracy) from such an inexpensive temperature sensor is unlikely - is it not?  (better to "over-deliver" than "over-promise") don't you agree?

Have you determined how long your connection will "remain up" - and how to "gracefully recover" when so many have reported connection disruptions?

Is "brief connection & signaling success" sufficient?   Should not the "whole story" (warts & all) be revealed when you present such an example?

cb1- said:

Has not the "Exosite <-> this vendor combination" - long had (well known) & frustrating disconnect issues?   Have these (now) been solved?

I know that. There is a very long post at TM4C forum regarding that. From what I understand that is caused by something at lwip library.There is also a mention that was because the lwip library was not updated for coping with the much faster Tiva MCU. But, I am using SimpleLink and connecting my device through "WiFi" to Exosite Cloud.

I do not know yet if my connections to Exosite Cloud will last for a long time. The longest testing I made was about 1 hour. The problem with my free account at Exosite, is that it does not have a clock widget to show how long my device connects to Exosite. I will ask at Exosite, if I can get a clock widget, so I can test how long my device connects to Exosite.

I agree with you, regarding the "three decimal points" from TMP006 sensor. I just copied the code from Tivaware, and have not made any effort to improve it.

- kel

Markel Robregado said:

...long had (well known) & frustrating disconnect issues?   Have these (now) been solved?

I know that. There is a very long post at TM4C forum regarding that.

Indeed - we know that you knew that - and that's the point!   Should you NOT have alerted post readers to this issue?

In the interest of "Full Disclosure" (thus far, absent) here is the link which greatly details, "Multiple User's experience (often unpleasant) w/this poster's "shared" example:

You may note that the earlier thread ran from July 2014 - August 2015 - yet serious issues remained.   (and remain!)

Those seeking to (properly) "share" should advise their readers of possible (here likely) difficulties which are almost guaranteed to arise - thru such "sharing."

BP101 said:

If you create a dash board at Exosite then you can add a chronograph widget for accumulated time. Anyhow the data ports on time stat shows the total connection time.

I will learn how to do that.

I will test how long my device connects to Exosite if I am able to. The problem is, if my mother see me sleeping already at night, she will turn off the power to my WiFi router to conserve electricity. 

- kel

Yes Markel - such would have been wise. The dictate, "Surgeon - Do no harm!" overlaps to those "sharing," too...

The 4+ months of thread (silence) - after over a year's worth of frustration (reflected w/in that earlier thread) - all signal that such troubled, "sharing" may not have been a wise choice...   Especially so when NO Warning is sounded...

This project is still in progress. I will do long hours testing and provide results here. Maybe not soon, because of the holidays.

See, blog post link here. blog post includes link to github with the program for this project.

If there are any problems setting up the CCS project, inform me and I will help you out. Either through here or PM.

- kel

Markel Robregado said:

This project is still in progress.

Indeed - and that (progress - or lack of same) as noted in the long referenced thread - should have (somehow) found its way into your subject line or first post.

We assume that "long hours of testing" - by any individual - is unlikely to succeed where the (combined) efforts of two tech firms - thus far - have failed. Badly!

Might a better, "subject line/title" be, "Write & Read Data (maybe & sometimes) to xyz Cloud using abc LPad?"

Choosing to "coat-tail" upon so troubled an implementation is not (especially) compelling & may not be suitable for, "sharing."

No one cares about me - I make few assumptions - and no one's asked for (any) proof!  Your remark is difficult to understand.

My (and many others) concern is (properly) with those who may succumb to your "sharing."  And then forum users may needlessly (suffer) - just as ALL those did who reported, "Grave difficulty w/Exosite & TM4C thread" - which (conveniently) received NO mention w/in your, "sharing!"

Haven't you a responsibility to forum users - perhaps it is (you) who assumed too much...   (i.e. that a presently "failed" (seemingly abandoned) project could be fixed!)

There was an issue before connecting Tiva Connected Launchpad to Exosite using qs_iot. The issue is related to lwip library and  was fixed as mentioned by Stellaris Sai in the thread. 

My project uses SimpleLink and not lwip. I have not yet performed long hours test to prove that my device will connect to Exosite for a long time, due to that I have other things to do and is Holidays. I will update this post with the results of long hours test when I am done with it.

Markel Robregado said:

The issue is related to lwip library and  was fixed as mentioned by Stellaris Sai in the thread. 

Markel - have you made the effort to read the (many) posts which arrived (after) Sai's post?   Do not those (all) reveal that the problems & frustrations continue?

And one of the last posts was made by the thread's originator - and he requests his money back - even with - and especially with - Sai's "fix."

If you are leading forum readers, "Off a high cliff" - is it not your responsibility to (announce) that fact?   And to (really) verify that the "fix" worked?  Some 250 views/visits have resulted from your thread - anyone "caring" for those here is duty bound to (properly & fully) report such "well known" Connection Difficulties!

Forum readers should note that the thread in question - which presents substantial, "pain & suffering by Exosite <-> TM4C users" has sat, "dead silent" since August 2015.   Can that silence serve to comfort the many posters who complained - and have not reported success?

Markel's claim that a "fix" was made appears unsupported by any (reasonable) read of the facts...  "Sharing" should be confined to designs which have some reasonable chance of success - it appears that this particular "sharing" breaks from that long held policy - and is unlikely to be (really) "fixed" anytime soon!

It is just now that I have read the thread from beginning to end and it is a very very bad issue. 

From Stellaris Sai, these are the main issues with qs_iot and Tiva Connected Launchpad.

• buffer corruption issue" that resulted in incomplete packets being sent out to the Exosite Server. Due to these incomplete packets, the Exosite Server sends out a HTTP 401 response. The "qs_iot" app then thinks that the CIK is no longer active and tries to acquire a new CIK.

• issue that resulted in the "qs_iot" application getting stuck after reacquiring an IP address.

I can say with good confidence, that these issues will not happen with my simple project. I can say that with higher confidence though after I have done long hours testing.

The files at Tivaware that have caused those issues, I am not using in my program. The exosite C library for qs_iot, is different from the exosite C library that I am using. The exosite C library I am using internally calls SimpleLink API's. SimpleLink library is not part of Tivaware.

Regarding the issue of qs_iot that acquires new CIK(Client Interface Key) to exosite. That implementation is not used in my application. At qs_iot implementation to exosite is client model. With Exosite Client Model the device supplies Exosite with vendor id and unique id. Exosite will then provide the device a CIK. That process is called "Provisioning".

With my application, it is not possible to do this. Because my account at Exosite is free. That is the limitation. My Exosite account is for evaluation purposes.

A CIK(Client Interface Key) is your private key to Exosite. Exosite Identifies your device with CIK.

How do I get a CIK with my Exosite Free Account? When I create a device at Exosite website, a CIK is provided.

To write temperature data to Exosite I use exosite_write(), this below is what it generally does.

creates a socket to Exosite -> Send http request for writing to Exosite that has a CIK -> Closes Socket to Exosite

Sample http request to exosite to write value "77" to Exosite Dataport with alias sensortemp.

m2.exosite.com/.../alias -H "X-Exosite-CIK: YOUR_CIK_HERE" -H "Accept: application/x-www-form-urlencoded; charset=utf-8" -d sensortemp=77"

Similar process for retrieving data from Exosite.

If there is a 401 error return with my application, LED D1 will blink. That's it and no special error checking and recovery implementation. The program will check if device is connected to AP. If true do the same process again. Very basic implementation. The flowchart regarding this can be seen at my blog post.

The 401 return error that is mentioned in that thread using qs_iot, will not happen with my application, because I have the CIK and is hard-coded to my HTTP Request. 

Regarding the IP the "qs_iot" application getting stuck after reacquiring an IP address, will not happen with my application. From what I know my device IP is stored at CC3100 BP Non-volatile memory. I would need to reconfirm this.

Anyway, I have already shared the blog post and source code for this project. So to other readers here, feel free to evaluate it. Maybe do long hours testing which I have not done yet.

- kel

Markel Robregado said:

It is just now that I have read the thread from beginning to end and it is a very very bad issue. 

True that, Markel - true that - very BAD indeed!   Surely not an implementation one would (normally) choose to "share!"

In your (recent) reading you may have noted that I joined that highly discouraging, "Connection LOST" thread multiple times - first in defense of the two vendors - later with the request that both vendors (regularly) report their latest findings.  Responding sporadically - (seemingly "only" when either vendor chose to) may not qualify as an especially sound means of demonstrating client care & concern.  The recent 4+ months of (silence/avoidance) by both vendors - is unacceptable.   

Thus when your "sharing" arrived - we wondered (as did those who PM'ed me) - had Markel performed a (proper) investigation?   And we (today) have our answer.

You now hitch your (shared) wagon to Sai's diagnosis - in which he attempts to identify the (main) issues.  Is not the (jury) still out - as regards the correctness (and completeness) - of "Sai's fix?"   We note that the thread's originator was not impressed w/Sai's effort - and indeed asked for a refund!   Systems have - for years - failed due to (minor) issues - you must have that awareness.

You make the claim that you have, "Good confidence" that your implementation will not fail.   And in the next sentence reveal that you've NOT performed (reasonable duration) testing - thus your claim may be empty.   (to be kind) 

You have the responsibility to properly inform your forum audience when "sharing" such (plagued) implementations - which (appear) to have over-challenged TWO Tech firms - yet (somehow) have now received your (slightly) tested blessing!   

Not all forum users may wish to, "Jump off this (shared) cliff" especially when all, "DANGER - Road Out" markers have been hidden (or removed!)   Till NOW!

Hi Markel

Notice you are connecting to the Exosite server not the TI version of the same IOT server. Perhaps your using the new 128 bit encrypted links with the encrypted version launch pad and that requires a different server connection?  Not sure myself if the new encrypted TM4C1294 launch pads can even connect to original TI Exosite server. The reason to mention is that custom dash boards are available with up to two launch pads on the TI version of Exosite server. Have considered trying the wireless RF booster pack, thanks for posting your details and do keep the post updated. The best time connected for my launch pads has been around 200k seconds while semi idle connections tend to get booted after several days. 

Http 401 is a nuisance and randomly pop up when ever local network or internet delays TXD an ACK response to an RXD http 402 status. The main application loop suffers many ills and attempts to re-acquisition a new CIK after an http 401 is received anytime after an initial Sync. The problem is the SW will not write a new CIK unless the EEROM CIK is first erased and the server has also released the old CIK. That requires a manual operation on the TI Exosite server where the user must log in and acknowledge provisioning a new CIK. The only way to clear the old CIK from EEROM is via LM-Flash unlock, otherwise the SW will not write a new CIK if one already exists even during a provision cycle. Have yet to witness the SW ever provision a new CIK when the old CIK still exists in EEROM. That couldn't be made an automated process since the user has to manually change the existing CIK on the server even when the EEROM has been erased. That alone really complicates the entire schema. The catch 21 is the first IOT cloud connection of a new launch pad more often goes smoothly so a user is not even aware of how many other demons lie beneath the surface until mayhem arrives on the seen.  

The best WA is to ignore the first few http 401 and the random problem typically self corrects.

Simple && test to add in the main loop:

else if((Exosite_StatusCode() == EXO_STATUS_NOAUTH) && g_ui32LinkRetries >= 3)

BP101,

     I just want to comment about Exosite C library. I think the Exosite C libary, need to be thoroughly reviewed and improved by us users if needed. 

     I am saying need to improve Exosite C library if needed, because making the program for this project, I was advised by Exosite Engineer to modify the Exosite C library to use a hard-coded CIK. This is because I can not do "provisioning" using my Exosite Free Account.

     I am saying need to thoroughly review because the Exosite C library for SimpleLink Devices that I used, is not polished. There are some c definitions that are out of place, but is acceptable. Another issue is this below, that I ask help in solving at stackoverflow. I thought I can just use the Exosite C library, and not expect compiler errors. However, that is not the case.  

BP101 said:

I don't feel hard coding a CIK would work in any production runs given the server provides a unique CIK for each new user and an account must first establish the MAC of the new PCB.

I agree with you.

Provisioning mode that requests CIK from Exosite, is not possible with my Free Exosite Portal Account. At the Free Exosite Portal Account, when you create a new generic device there to register your device. there is no field to put your vendor id, unique id or mac address. 

At qs_iot example program, registering at Exosite Website, you input your MAC address. So, it is not the same for Free Exosite Portal Account. Maybe for Paid Exosite Portal Account I can do provisioning mode.

BP101 said:

Exosite engineers to change their free schema order to keep confusion about the CIK to a low roar. That hard coding the CIK is far from the reality of how actual CIK assignment has proven to apply.

I do not think Exosite Engineers misguided me. I have explained above about the details. I have seen projects in the internet, that uses hard-coded CIK in their program. So, I think hard-coded CIK is okay for project purposes only. Here is my conversation below with Patrick of Exosite for clarity.

Tiva Connected Launchpad + TI CC3100 Booster Pack Exosite

Regarding the long hours test, I am just merging the 2 working CCS projects below. If I don't encounter any problems doing that I will start the long hours test afterwards. I will just target 3-4 days testing.

1. Elapsed Time incremented by 1 second timer interrupt and stored at a char array in this format "days : hours : minutes : seconds".

2. Send email using Tiva Connected Launchpad + TI SimpleLink WiFi CC3100 Booster Pack.

Note: After, I merge the 2 working CCS Project above, I will merge that CCS project to the program for this project.

- kel

post edited  . . .

cb1_mobile said:

No one cares about me - I make few assumptions - and no one's asked for (any) proof!  Your remark is difficult to understand.

My (and many others) concern is (properly) with those who may succumb to your "sharing."  And then forum users may needlessly (suffer) - just as ALL those did who reported, "Grave difficulty w/Exosite & TM4C thread" - which (conveniently) received NO mention w/in your, "sharing!"

Haven't you a responsibility to forum users - perhaps it is (you) who assumed too much...   (i.e. that a presently "failed" (seemingly abandoned) project could be fixed!)

 Hi CB1, and this is same answer I ear from my colleague, everyone I meet say TI is no more reliable and also manufacturers ask NOT TO USE TI product...

 This is a worst issue and the dumbest person I meet here so called MR Blake said we have to support everyone in this forum, so I see "guru" have no idea of how to make a line of code, I seen a person said is teaching programming Atmel controller who has no idea of what

|= &= and  ~var

mean, and who helped to pinpoint compiler and Silicon issue attacked by this Mr Blake saying I was harrassing people without understanding how much worst sound there his non knowledge of electronics basic nor VERY basic programming  and how Scientist  perceive wasting her time to teach a non scholar skilled person is HARRASSING!!!!

 Here the same, a "so called "guru" show us the complete non knowledge of what is speaking about... Sorry Markel, from what I see  you are not ready to wrote a simple program, just low culture like Blk say you are a genius all other are here to learn problem maybe don't like this useless simple bare assembling ....

 Again speaking about loss: some hundred thousand euro where wasted from my worst idea to use TI processor on project, Stellaris failure was the first, now TIVA appear not so less prone to problem and I am reworking all board to fully remove TI from, this account another 3-400 thousand euros loss...

 Also MSP430 G family appear to have a silicon issue on PWM module, none seen that just focusing on 10$ board asking free support from professional....

 Energia, a very good initiative, but it is left at same policy of not updating problem are plaguing from release 12 and we are at release 17, none of old problem got removed and this sound unreliable...

 SO I also wish my money back and I promise to NEVER USE NOR RECOMMEND(!!!!)  TI product..

 May be TI don't suffer if I don't buy some 10K or a million dollar chips from them, but seems all are dismissing TI product multiply 10K 100K silicon by huge numbers.... Again as in the past seems TI has no perception of middle level industry pointing to Huge multimillon.. but also in that seems losing.
This loss continue spread over and I ear from many professional they don'ìt  wish use again a processor nor DSP and TI is not taking action, just his Blake is proud himself of so called Facebook e2e, no way if scientist or professional don't like...

 This is just a disagree of what I see/other seen and take the decision to remove processor from production.

 So my santa wish:

 have old serious good "National Semiconductor" back and not incorporated in a so worst company...

 This is for new year when I think to cancel subscription with this worst company not supporting professional using tons of their chip, this  in favour of 10$ board unskilled casual user never use more than two free sample in his professional life..

 And again thank for saying me I am harrassing people who don't know very simple basic C knowledge.

 Thank also never said thank for beta analysis to C compiler and silicon, my free work if sold professionally was not less than 100KUS$, thank so much dumb mr Blake, I don't sing if you loss your job, I am just VERY sorry for good people like Amith and other serious people involved in this crazy business...

Greetings Jens-Michael,

Your record @ this vendor's forums is without match - has proven immensely helpful - thank you.

I must (repeat) the following (pertinent) points which you may not have had time to (fully) absorb:

• application chosen for "sharing" has LONG been severely troubled
• the degree of difficulty & frustration w/this "shared application" was essentially "abandoned" by this vendor & partner firm.   (i.e. sat "quiet" for over 4 months - despite repeated, "pleas for help" by multiple, disappointed & frustrated users
• that fact was very well known - but (admittedly) not known by the "sharer."

Indeed - as you write - some sharing of applications proves beneficial.    Yet - should not those "sharing" have made minimal effort to insure that user's drawn to their project - are not being lured to a (very) high cliff?   (and one from which there is NO "clear-cut" rescue?)

That's my sense - expressed w/in the "sharer's" now "locked" post.   (other than vendor generated ones - or "demise of past M3" - I cannot recall such "locking moderation!"