Reading data using Processing

[Idahowalker]

Whiles I review your code, your ESP8266 does not have the same capability of using the pointers in the same way I do.

Just below the Arduino IDE icon located to the right side, kinda under the x, to open the Monitor and under that is another icon. Click that icon, select new tab, name the tab certs.h, OK,go to the new tab and enter your secret info there.

Example.

Code: [Select]


const char* SSID = "SomeSSID";
const char* PASSWORD = "somepassword";


Save.

On the main tab, add

Code: [Select]

#include "certs.h"

Now you can use SSID for your ssid and PASSWORD for the password, select your code, and paste it elsewhere, without having to deal with making sure your code is clean before posting it.

And, could you state the issue you are having and the possible location in code you think the issue stems from?

You are running a MQTT keepalive, client.loop(). Perhaps adding client.setKeepAlive( 90 ); could help?

[trojanhawrs]

Nice one, cheers for that. If I save it to my libraries will I be able to use that with every new sketch?

I honestly don't know if it's a code issue or not - I do receive messages sometimes but it's few and far between. I set up a little text publish node so that I can publish to "inputs" repeatedly and check the serial monitor, only 1/5 make it through. I also tried taking the serial print commands out and publishing a new packet to "outputs" when I get a callback but getting the same intermittent response. I'm fairly certain its not a broker problem, node has no problems receiving subscription messages.

I'll drop the keepalive in my setup and get back to you!

[trojanhawrs]

Re: the keepalive, didn't do anything noticeable.

I changed my callback function to the publish_in_callback examples.

Code: [Select]

// Callback function
void callback(char* topic, byte* payload, unsigned int length) {
  // In order to republish this payload, a copy must be made
  // as the orignal payload buffer will be overwritten whilst
  // constructing the PUBLISH packet.

  // Allocate the correct amount of memory for the payload copy
  byte* p = (byte*)malloc(length);
  // Copy the payload to the new buffer
  memcpy(p,payload,length);
  client.publish("outputs", p, length);
  // Free the memory
  free(p);
}

Interestingly that seems to be a little bit better, but theres still times that it won't register until the 3rd or 4th send.
Just seems like the arduino has selective hearing

[Idahowalker]

Code: [Select]

client.subscribe("interval");
  delay(1500);
  lastReconnectAttempt = 0;

I'd remove the delay, as soon as the subscribes are completed they are active but the delay puts a stop to the thing do's.

What's the Arduino Uno do?

Running the ESP8266 without software serial would be a good test. See if the softwareserial is causing issues.

[trojanhawrs]

The delay is just in the setup, only called once. I did remove it, no change.

I'm literally just using the ESP8266 for WiFi capability, I'm using the Uno's IO's to talk to sensors and actuators. I know these ESP chips are very capable and there's some boards based around them with more pins but I already had an uno so, seemed the best option at the time.

I can probably make a workaround where I loop the publish on the node side until I get a response, it doesn't seem to like getting spammed though - its dropped the connection a few times.

[Idahowalker]

It took me several weeks to work out how to best maintain a connection.

The keys I found was to run a keep alive, the MQTTclient.setKeepAlive( 90 ); setting, and to disconnect/reconnect on a periodic basis.

As posted earlier here is my disconnect code that runs once a periodic basis. 6000mS*60.

Code: [Select]

// disconnect causes the MQTT data persistence to clear. outside environmental data is updated once every 5 minutes.
void fMQTT_Disconnect( void * parameter )
{
  int i = 0;
  for (;;)
  {
    xEventGroupWaitBits (eg, evtMQTT_Disconnect, pdTRUE, pdTRUE, portMAX_DELAY );
    if( i >= 60 )
    {
    xSemaphoreTake( sema_MQTT_KeepAlive, portMAX_DELAY ); //
    MQTTclient.disconnect();
    xSemaphoreGive( sema_MQTT_KeepAlive );
    i = 0;
    } else {
      i++;
    }
  }
  vTaskDelete( NULL );
}
////

How'd running the ESP8266 do with MQTT sub/pub without softwareserial?

[Idahowalker]

I can probably make a workaround where I loop the publish on the node side until I get a response, it doesn't seem to like getting spammed though - its dropped the connection a few times.

That's why I use a slight delay between each publish.

[trojanhawrs]

It took me several weeks to work out how to best maintain a connection.

How'd running the ESP8266 do with MQTT sub/pub without softwareserial?

I would like to try that just out of interest, as I say its not really an option though as I'm using IOs on the Uno. Not terribly easy either as I've soldered the ESP to a proto shield 

I also don't know how I'd go about it, would probably have to open up a USB cable and attach to the RX/TX i suppose?

I'll probably just persevere with it as it is, as long as its sending data reliably thats the main thing. Would be nice to be able to adjust values from the PC though.

Gonna hit the sack and hopefully go at it with a clear head tomorrow, thanks for all your help!

[Idahowalker]

One of my posts contains the function void WiFiEvent(WiFiEvent_t event), if you un-comment the code in the callback, there will be some info about how the connection is doing whiles running.