ESP8266 + UNO with

Thanks, @alvarolb.
Now I can better debug the communication.
From the wifi client debugging it seems to me that the server doesn’t act as you described. I will do more testing (dumping of incoming messages) and let you know.

Really really thanks to both! In particular to @JiriBilek for these recent great news!
I will test it a lot for sure.
I like o lot this platform, I´m very happy with this improvments!

The file “WifiEsp.ino” is for upload to the ATMEGA and file “EspDrv.cpp” is to replace the other with the same name, obvious.
For now I don´t have any question!

@Andrei_Sousa: Please don’t forget the EspDrv is in very very early stage of modification. I will refine it once I get it working with thinger without problems.

Really thanks @JiriBilek!

This is a great open source solution in my opinion (this platform with ESP8266 + ATMEGA328P).
I will test this solution a lot!

I already make some tests, I understand that this is in a very early stage, I think for now is not necessary explain in detail the problems I found.
The three outputs are working very good, only when reconect it fail sometimes.
The Led is more instable, sometimes only blink turn on and off, you already see it for sure.

Having the same problems :slight_smile:


I installed the App in the Android
When I make refresh the device sometimes appear the led or one of the outputs.
But the led switch appear almost always and is working very stable.

In the App is the contrary, the Led Works better than the outputs.

after testing and discussing the results with @alvarolb I am convinced that the combination Arduino+thinger+WifiEsp+ESP AT firmware has serious problems.
I added debugging information into some thinger classes and saw incoming messages missing. This results in incorrect reaction of Arduino client on the dashboard requirements.

Sadly, I am pretty convinced of bad behaviour of the device as I changed my ESP12 firmware to the Arduino ESP, compiled and uploaded the same sketch I had tested (some headers changed) and it is now running smoothly without a single problem for dozens of minutes. Something I really could not achieve with the old setup.

Maybe it is a bad idea to use Arduino as master and ESP as working device. The ESP is much more powerful. The key of the problems may be in ESP AT firmware which debugging and/or updating is probably out of my capabilities.

I am not giving up yet but I am not sure we can get it running.

Ok! I understand the basic concept you explain.
Of course I don´t have no idea about all the complexity, with thingspeak I can send AT commands with the Arduino to the ESP01 (by serial), is a very interesting solution, is not so heavy to the Arduino but is not so user fliendly like… I don´t really understand why the solutions are so diferent! :slight_smile: I agree with you, with AT comands working good with in my opinion is a better solution. I send data to thingspeak with a few AT comands, is not very dificult!! I created this channel:
If I could help some how!
Really thanks for your interest!

I will try this library, that seems to support the ESP8266 with AT, and seems to work fine with other GSM modules… Maybe it is possible!

If it worked it would save me a lot of work. I don’t have too much time to test anything now unfortunately, but I am waiting for your results.

I have published a new library version (2.6.0), but not pushed as a new release (it will not update with library manager) that should provide support (finally!) to the ESP8266 board by using AT commands. It relies on the commented TinyGSM library that can be installed with the library manager.

Can you please manually install the library and test that? I have done some test with success!! It is not quite optimized yet, but it should work fine :slight_smile:

I am looking forward to a new library. I will test it in the evening.

Great! Let me know if it works :slight_smile:

my testing didn’t end with a success, unfortunately.

When I used the default sketch (led + millis), all went great.

Then I added another led to the sketch. After navigating to the dashboard with just the first (default) led it was ok. I added second control for the new led and it worked! But when I left the dashboard for another page and returned, the library failed ([THINGER] Writing bytes: 8 [FAIL]).
The TinyGSM library tried to recover without success and eventually ended in state
[NETWORK] Starting connection…
[NETWORK] Cannot connect!

After that I am not able to use the dashboard page with the two controls any more. The problem is deterministic, after deleting the second led from the dashboard arduino somewhat stabilizes. And adding the control back it crashes again.

My observations so far:
a) there may be the same problem with transmitting data while reading
b) the TinyGSM library has big problems with recovering after failure

The whole tested sequence was:

…In devices tab
[THINGER] Authenticated
…Switched to dashboard with 2 on/off controls
[THINGER] Available bytes: 17
[THINGER] Writing bytes: 7 [FAIL]
[SOCKET] Timeout!
[SOCKET] Is now closed!
[THINGER] Writing bytes: 14 [OK]
[THINGER] Available bytes: 19
[THINGER] Writing bytes: 8 [OK]
[THINGER] Writing bytes: 15 [OK]
[NETWORK] Starting connection…
[NETWORK] Cannot connect!
…etc etc

I tried also dashboard with output variables but with similar behaviour.

My testing sketch is now identical to the example one with following changes:

  • Serial1 is running on pins 6 and 7
  • LED5 added:

pinMode(LED_D5, OUTPUT);
thing[“led”] << digitalPin(ARDUINO_LED);
thing[“led5”] << digitalPin(LED_D5);

It’s early to make conclusions but I suspect the AT-command interface is error-prone. The major issue is that Arduino is not able to stop the ESP’s transmitter.


Can you try with pins 8, 9, 10, 11, or 12? I think that software serial does not work quite well with rx pins that does not support interruptions. I will try to add more resources tomorrow.

I quickly rewired it and the result is the same. As far as I know Arduino Uno and clones running on 326 (my device for this sketch is Arduino Pro Mini 5V 16MHz) can interrupt on any digital pin.
The SoftwareSerial won’t work without being able to set ISR on Rx pin - see SoftwareSerial.cpp line 318 and following:

  // Only setup rx when we have a valid PCINT for this pin
  if (digitalPinToPCICR(_receivePin)) {
    ... the setup ...

I’ll try it on hardware serial on arduino mega later on but using mega is not a general solution.

Edit: on Arduino Mega the test is failing on hardware serial as well. The same behaviour:

[THINGER] Writing bytes: 7 [FAIL]
[_SOCKET] Timeout!
[_SOCKET] Is now closed!

Thanks for the reports! Will take a look on that now!

I have updated the library again (2.6.1). I have disabled a feature that was introduced in the latest version to recover more rapidly from disconnections. Seems that the ESP8266 AT is failing to write sometimes, so the library was thinking the device was disconnected from the socket. This is not true for this kind of devices (or library), as the connection is still ok even if it fails to write to socket . So, the new version is more tolerant to such errors.

Now the ESP8266 with AT commands seems to be much more stable in the connection (even with more resources), and the possible write errors are often retried automatically from the console. However, this is a temporary patch until the AT client library behaves as expected. Seems to be quite complex to build an AT based reliable interface!

I am testing also a retry write mechanism that seems to work by now, but not sure if it is something generalizable with other boards. Maybe it can be activated with a preprocessor definition just for some devices, and it should be compatible with the connection check I removed in the latest version.

[THINGER] Writing bytes: 60 [OK]
[THINGER] Available bytes: 18
[THINGER] Writing bytes: 14 [FAIL]
[THINGER] Expected: 14
[THINGER] Wrote: 65535
[THINGER] Retrying write...
[THINGER] Writing bytes: 14 [OK]
[THINGER] Available bytes: 42
[THINGER] Writing bytes: 15 [OK]

The 65535 means an underflow for the size_t (as the library is returning -1 also as a size_t). Seems to be unsigned int.

This is the testing write method on ThingerClient.h

    // TODO Allow removing this Nagle's algorithm implementation if the underlying device already implements it
    virtual bool write(const char* buffer, size_t size, bool flush=false){
            temp_data_ = (uint8_t*) realloc(temp_data_, out_size_ + size);
            memcpy(&temp_data_[out_size_], buffer, size);
            out_size_ += size;
        if(flush && out_size_>0){
            bool success = false;
            unsigned short tried = 0;

#ifdef _DEBUG_
                Serial.print(F("[THINGER] Writing bytes: "));

                size_t written = client_.write(temp_data_, out_size_);
                success = written == out_size_;

#ifdef _DEBUG_
                Serial.print(F(" ["));
                Serial.print(success ? F("OK") : F("FAIL"));
                    THINGER_DEBUG_VALUE("THINGER", "Expected: ", out_size_);
                    THINGER_DEBUG_VALUE("THINGER", "Wrote: ", written);
                    THINGER_DEBUG("THINGER", "Retrying write...");
            }while(!success && tried<10);

            temp_data_ = NULL;
            out_size_ = 0;

            //FIXME Without this small delay or activating the debug (which takes time), the CC3200 does not work well. Why?
            #ifdef __CC3200R1M1RGC__

            return success;
        return true;

Hi, @alvarolb.
I created a library that connects Arduino (master) to ESP8266 (slave) using SPI protocol. I have just tested it on and it is running for 30 minutes without a single problem.
After fixing remaining issues and trying with more devices I will post the library here.

The connection is not as easy as with the AT firmware. The ESP has to be flashed with custom firmware, SPI pins are available only on “big” modules (i.e. ESP-12), hardware SPI on Arduino uses LED Pin for the communication and voltage convertor between 5V Arduino and 3.3V ESP is needed.