Solved: TCPClient connecting but not working with Pushingbox

Troubleshooting
1

First up… here is the part of the code I’m trying to get working…

void sendToPushingBox(char *serverName, char *devid) {

    TCPClient client;    
    char line[255];
    client.stop();
    digitalWrite(LED, HIGH); // sets the LED on
    
    if(DEBUG){Serial.print("connecting... ");}
    if (client.connect(serverName, 80)) {
        if(DEBUG){
            Serial.print("connected to ");
            Serial.println(serverName);
        }
        delay(3000);
        strcpy(line, "GET /pushingbox?devid=");
        strcat(line, devid);
        strcat(line, " HTTP/1.1");
        client.println(line);
        if(DEBUG){Serial.println(line);}

        strcpy(line, "Host: ");
        strcat(line, serverName);
        client.println(line);
        if(DEBUG){Serial.println(line);}

        strcat(line, "User-Agent: Spark\r\n");
        strcat(line, "\r\n");
        client.print(line);
        delay(500);
        client.println("Connection: close");
        //delay(400);
        client.flush();
        delay(200);
        if(DEBUG){Serial.println("closing...");}
        client.stop();

        digitalWrite(LED, LOW); // sets the LED off
    }
    else{
        digitalWrite(LED, HIGH); // sets the LED on. If always on, last connexion was failed
        if(DEBUG){Serial.println("connection failed");}
    }
}

From the serial output i can see that its connecting to the pushing box server and each string appears ok when printed in the terminal

I have a similar bit of code to send a GET to my XBMC computer that works fine, although it did take a while to set the delays to make it work.

The core is working normally and always breathing cyan during the connection…

Any idea’s?? is there any way to get more info of whats happening??

SSID: Removed
Core IP: 192.168.1.9
Gateway: 192.168.1.1
Mask: 255.255.255.0
WiFi RSSI: -44
connecting... connected to removed.com
GET /jsonrpc?request={%22jsonrpc%22:%222.0%22,%22method%22:%22Addons.ExecuteAddon%22,%22params%22:{%22addonid%22:%22script.securitycam%22},%22id%22:%221%22}} HTTP/1.1
Host: removed.com
Authorization: Basic removed

closing...
connecting... connected to api.pushingbox.com
GET /pushingbox?devid=removed HTTP/1.1
Host: api.pushingbox.com
closing...

So this is the result in the terminal… with some bits removed just for security, but they look perfect. the first connection works perfect and also includes authorization… i just cant figure the pushing box bit out.

tried the code from this post… cant get that to work either https://community.spark.io/t/official-source-code-for-pushingbox/4109

2

HI @Hootie81

Something has changed for me too–I have test code that pushes out to gmail every 30 seconds via pushingbox and it works once and then the core goes to flashing cyan and reboots. I am not sure why but will try to look into it.

I also tried curl and Chrome for the pushing box to see if something in the return looked different and I didn’t see anything I thought was going to be a problem.

I don’t think that TCPClient is the problem because when I run my Yahoo weather web scraping firmware, it works great.

3

I tried to debug this some more tonight but I don’t have any good results to report.

I have my core on a separate router where I can see the tx/rx LEDs and there is a lot of traffic when I do the GET request to Pushingbox. I have tried flushing the TCP buffer in several ways but I am not seeing what is causing the poblem. I get a flashing cyan, then a brief red LED flash (but not an SOS panic code) and the it reboots.

I also ran my Yahoo web page scraper for a couple hours this afternoon and it never failed, so I updated the title to refer to Pushingbox. Maybe we can get @clem from Pushingbox to help debug this problem since you say his code doesn’t work either. My feeling is that the problem is specific to that site.

4

What i meant by the first one works and the other doesnt, is the first client connect is to my home theater PC to display the camera on the screen. the second one (pushing box) isnt working.

Some times they both dont connect but running them a second time they both connect but only the XBMC one works.

The core stays breathing Cyan the whole time, sometimes it looks like it gets a little bit cut off but then fades back in and out as per normal.

I have tried an online get request thing which works no worries and triggers the scenario… so im sure its something from the core side of things, probably just a timing issue.

Another little bug i noticed with the spark IDE is if i comment out the line

runXbmcScript(xbmcServer, xbmcPort, xbmcScript, xbmcLogon); 

then it will compile ok and appear to flash ok… but the core will still be running the last firmware. i need to comment out the whole Void bit it calls to get it working if that makes sense?

Here is the whole code for reference… As soon as it connects to the cloud (when the D7 led comes on) i terminal in and push enter to start it talking :slight_smile:

#include "application.h"

int doorbell = D0; // Doorbell button connects to D0 on the core
unsigned long Lockout; // used to stop flooding servers
boolean DEBUG = true; // enable Debug
int LED = D7; // Built in LED

// XBMC Setup
char xbmcServer[] = "MyXBMCserver.com";
int xbmcPort = 80;
char xbmcScript[] = "/jsonrpc?request={%22jsonrpc%22:%222.0%22,%22method%22:%22Addons.ExecuteAddon%22,%22params%22:{%22addonid%22:%22script.securitycam%22},%22id%22:%221%22}}";
char xbmcLogon[] = "USERNAME:PASSWORD"; //Base64 encode Username:Password as one thing


// Pushing Box Setup
char serverName[] = "api.pushingbox.com";
char deviceID[] = "DeviceID";

void setup() {


    pinMode(doorbell, INPUT_PULLUP); // other side of doorbell will connect to ground to pull low
    Lockout = millis();
    pinMode(LED, OUTPUT); // sets LED as output
    if(DEBUG){
        digitalWrite(LED,HIGH); // Light the onboard LED so you know it's time to open your Serial Terminal
        Serial.begin(9600);
        while(!Serial.available()); // wait here for user to press ENTER in Serial Terminal
        digitalWrite(LED,LOW);

        Serial.print("SSID: ");
        Serial.println(Network.SSID());
        Serial.print("Core IP: ");
        Serial.println(Network.localIP());
        Serial.print("Gateway: ");
        Serial.println(Network.gatewayIP());
        Serial.print("Mask: ");
        Serial.println(Network.subnetMask());
        Serial.print("WiFi RSSI: ");
        Serial.println(Network.RSSI());
    }
    

}

void loop() {

    if (millis() >= Lockout){  // check how long its been since last pushed
        if(digitalRead(doorbell) == LOW) {  //read the doorbell button
            delay(50);
            if(digitalRead(doorbell) == LOW) {  // debounce check again to make sure 
                Lockout = millis() + 15000; // set up the lockout period 15 seconds before it will run again
                runXbmcScript(xbmcServer, xbmcPort, xbmcScript, xbmcLogon);  // opens up a script in xbmc that displays an ip camera 
                sendToPushingBox(serverName, deviceID); // sends push notification to mobile phone or sends email using pushingbox
            }
        }
    }

}


void runXbmcScript(char *hostname, int port, char *url, char *xbmclogon) {
    
    TCPClient client;
    char line[255];
    client.stop();
    digitalWrite(LED, HIGH); // sets the LED on
    
    if(DEBUG){Serial.print("connecting... ");}
    if (client.connect(hostname, port)) {
        if(DEBUG){
            Serial.print("connected to ");
            Serial.println(hostname);
        }
        delay(200);
        
        strcpy(line, "GET ");
        strcat(line, url);
        strcat(line, " HTTP/1.1\r\n");
        client.print(line);
        if(DEBUG){Serial.print(line);}
        
        strcpy(line, "Host: ");
        strcat(line, hostname);
        strcat(line, "\r\n");
        client.print(line);
        if(DEBUG){Serial.print(line);}
        
        strcpy(line, "Authorization: Basic ");
        strcat(line, xbmclogon);
        strcat(line, "\r\n");
        strcat(line, "\r\n");
        client.print(line);
        if(DEBUG){Serial.print(line);}
        delay(500);
        client.flush();
        client.println("Connection: close");

        client.flush();
        delay(200);
        if(DEBUG){Serial.println("closing...");}
        client.stop();
        digitalWrite(LED, LOW); // sets the LED off
        delay(1000);
    }
    else{
        digitalWrite(LED, HIGH); // sets the LED on. If always on, last connexion was failed
        if(DEBUG){Serial.println("connection failed");}
    }
}

void sendToPushingBox(char *serverName, char *devid) {

    TCPClient client;    
    char line[255];
    client.stop();
    digitalWrite(LED, HIGH); // sets the LED on
    
    if(DEBUG){Serial.print("connecting... ");}
    if (client.connect(serverName, 80)) {
        if(DEBUG){
            Serial.print("connected to ");
            Serial.println(serverName);
        }
        delay(500);
        strcpy(line, "GET /pushingbox?devid=");
        strcat(line, devid);
        strcat(line, " HTTP/1.0\r\n");
        client.print(line);
        if(DEBUG){Serial.print(line);}

        strcpy(line, "Host: ");
        strcat(line, serverName);
        strcat(line, "\r\n");
        client.print(line);
        if(DEBUG){Serial.print(line);}

        strcpy(line, "User-Agent: Spark\r\n");
        strcat(line, "Content-length: 0\r\n\r\n");
        client.print(line);
        if(DEBUG){Serial.print(line);}
        delay(500);
        //client.println("Connection: close");
        //delay(400);
        client.flush();
        delay(200);
        if(DEBUG){Serial.println("closing...");}
        client.stop();

        digitalWrite(LED, LOW); // sets the LED off
    }
    else{
        digitalWrite(LED, HIGH); // sets the LED on. If always on, last connexion was failed
        if(DEBUG){Serial.println("connection failed");}
    }
}
5

Something very strange going on :frowning: If i use runscope and send the request through them it works no worries at all…

@clem might have to help us

6

Hi @Hootie81

Here is what I have found–I beefed up my pushingbox debugging program to do serial prints all over and added timeouts to all loops etc.

This improved things a bit in that I send 7-10 GET requests in row every 10 seconds and they work OK. Then pushingbox does not respond to a GET request connection attempt and I just don’t connect from that point forward.

I wonder if I am running into rate-limiting at pushingbox, but I don’t see anything on the site about that.

7

Im trying lots of different things… and learning alot in the process… its not too hard to understand

Ive added this before it stops the client

do {
        char c = client.read();
        Serial.print(c);
        } while (client.available());

its working perfect for the XBMC TCP bit, but only returns a y with dots above it for the pushingbox one.

SSID: Removed
Core IP: 192.168.1.9
Gateway: 192.168.1.1
Mask: 255.255.255.0
WiFi RSSI: -59
connecting... connected to Removed.com
GET /jsonrpc?request={%22jsonrpc%22:%222.0%22,%22method%22:%22Addons.ExecuteAddon%22,%22params%22:{%22addonid%22:%22script.securitycam%22},%22id%22:%221%22}} HTTP/1.1
Host: Removed
Authorization: Basic Removed

HTTP/1.1 200 OK
Content-Length: 40
Content-Type: application/json
Date: Mon, 26 May 2014 14:03:14 GMT

{"id":"1","jsonrpc":"2.0","result":"OK"}
closing...
connecting... connected to api.pushingbox.com
GET /pushingbox?devid=Removed HTTP/1.1
Host: api.pushingbox.com
User-Agent: Spark
   
ÿ
closing...
8

Its Working! you little rippa!

Nothing changed code wise… must have been a change with the Web IDE or at the Pushingbox end…

Project share coming up in the next day or 2 with some 3d printed parts

9

Hi guys sorry for the delay.
There was no change on PushingBox side, how did you solved the issue?
Also, in case you need to do more tests, you can use the officiel code I put on my GitHub: https://github.com/Clement87/PushingBox-for-Spark-Core
This one is working well.

10

Hi Clem,

I tried both your code and my own, neither was working. then this afternoon I noticed the Web IDE changed, so i re-flashed my core with exactly same code and it worked perfectly.

Maybe someone from Spark could fill us in?

11

Still not working for me–works 5-7 times and then it does not connect.

12

@bko, did you ever get this figured out? I’m wondering if I am seeing something similar with plot.ly. They rate limit at I believe 50ms. Maybe I’ll add a delay after initialization.

Thanks.

13

Hi @Casten

I moved on to other things and have not tested pushing box in a while, sorry. At the time, it seemed like the problem was on their end.

14

Most people seem to be having a lot of luck with delays between client print not sure why and extra println to push things through

15

Hi
I have the same symptoms with a spark sending push messages through pushingbox when it receives alarm messages. Everything was OK before the deep update. Since then I have observed that the core periodically goes through a series of various coloured flashing and eventually comes back on and connects to the cloud. It does this when several alarms are detected within a few seconds of each-other.
Another observation is that it no longer sends a confirmation notification on power-up that is in the set-up:

void setup() {
sendToPushingBox(DEVID9);//pushingbox notification "spark core 1 booted successfully"
}

My pushingbox code is exactly as per github without the debug statements.

16

does the various colour flashing include red?

is there a reason you have removed the debug statements? they can be very useful to determine whats happening, i have actually added a few more to get even more info!

How are you reading the alarms? is there an interrupt to trigger them?

What flushing method are you using for the returned data? I have found that using the code below works better to reduce the hard fault error i was getting.

while (client.available()) client.read(); // makeshift client.flush()
17

Hi
Yes, it does flash red for a short while, also blue and green. I removed the debug statements because the code was working fine and the system set up as permanent.
The alarms are digital radio signals from various sensors coming in from a receiver connected to D2 and they do set off an interrupt.The spark processes the signals and should send pushingbox messages appropriately.
I am not doing any flushing as I am not using any returned data.
I have got two spark cores working together, one handles pushingbox and the other controls the home automation and dvr. I tried to get one to do it all but it was unsatisfactory due to slow response times. Since the deep update both sparks have been unreliable and resetting.

18

There will be data returning from pushingbox and if you dont read it, it will fill up the buffer and give you the red flashing. you will need to flush after every connect before stopping the client.

how do you handle the interrupts? do they just set a flag, or do they call the pushingbox method? ie if its halfway through sending a GET request and the interrupt is triggered what happens? does it open another socket and start a new request or does it wait until the current one is finished?

1 Like
19

Sounds like that could be the problem. It would also explain why one spark could not cope with all the work. Thanks for pointing out what should have been fairly obvious, I will have to rework my code.
BTW there is a client.flush() in the pushingbox code
Regards

20

That's good you found the problem, i use interrupts to set a flag, the main loop then read the flags, if any set then it sends them. makes for a nice easy round robin code that even i can understand!

I'm guessing with the DEVID9 in the code above you have a fair few scenarios created? Have you had a look at using variables in the get request sent to Pushingbox? You can get some nicely formatted emails using it, with labels, maybe timestamps and even variables!
I wrote an example yesterday for it (but i haven't got a core to test it with) you could change the items to "alarm1" and "alarm2", the states could be High, Low, Active whatever you like. latest code is on post 8