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 
I installed the App in the Android Thinger.io.
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.
conclusion:
In the App is the contrary, the Led Works better than the outputs.
Hi,
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.
Jiri
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 thinger.io… I don´t really understand why the solutions are so diferent! I agree with you, with AT comands working good with thinger.io 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: https://thingspeak.com/channels/182070
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.
J.
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
Hi,
I am looking forward to a new library. I will test it in the evening.
Thanks.
Great! Let me know if it works
Alvaro,
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:
pinMode(ARDUINO_LED, OUTPUT);
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.
Jiri
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.
Hi,
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){
if(size>0){
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;
do{
#ifdef _DEBUG_
Serial.print(F("[THINGER] Writing bytes: "));
Serial.print(out_size_);
#endif
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"));
Serial.println(F("]"));
if(!success){
THINGER_DEBUG_VALUE("THINGER", "Expected: ", out_size_);
THINGER_DEBUG_VALUE("THINGER", "Wrote: ", written);
THINGER_DEBUG("THINGER", "Retrying write...");
delay(10);
}
#endif
tried++;
}while(!success && tried<10);
free(temp_data_);
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__
delay(1);
#endif
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 thinger.io 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.
This is great news @JiriBilek !
If you could help to reinstal the custon firmware!!? I already try several solutions.
my board is: http://www.ebay.co.uk/itm/291709890362?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
I download the “ESP8266_NONOS_SDK_V2.0.0” http://bbs.espressif.com/viewtopic.php?f=46&t=2502
And the last tool, update on 2016.11.14 http://bbs.espressif.com/viewtopic.php?f=57&t=433
I think the main problem is something I doing wrong in the flash tool. This module is 32Mbit?
I’m using the right tool?
eagle.flash.bin 0x00000
eagle.irom0text.bin 0x10000
blank.bin
Flash size 8Mbit: 0x7e000 & 0xfe000
Flash size 16Mbit: 0x7e000 & 0x1fe000
Flash size 16Mbit-C1: 0xfe000 & 0x1fe000
Flash size 32Mbit: 0x7e000 & 0x3fe000
Flash size 32Mbit-C1: 0xfe000 & 0x3fe000
esp_init_data_default.bin (optional)
Flash size 8Mbit: 0xfc000
Flash size 16Mbit: 0x1fc000
Flash size 16Mbit-C1: 0x1fc000
Flash size 32Mbit: 0x3fc000
Flash size 32Mbit-C1: 0x3fc000
Thanks a lot!
Wow @JiriBilek! This is an awesome work! Seems to be a complex setup for the mid-user, but it may provide reliable connections for advanced projects. Looking forward for reliability results!
I tried ESP8266AT example on ESP01 with Nano. All serials work on 9600 baud rates. Software serial for wifi connection works on 10 and 11 pins.
[NETWORK] Starting connection...
[NETWORK] Connected!
[_SOCKET] Connecting to iot.thinger.io:25200...
[_SOCKET] Using secure TLS/SSL connection: no
[_SOCKET] Connected!
[THINGER] Authenticating. User: *** Device: **
[THINGER] Writing bytes: 38 [OK]
[THINGER] Authenticated
[THINGER] Available bytes: 17
[THINGER] Writing bytes: 7 [FAIL]
[THINGER] Expected:7
[THINGER] Wrote:65535
... after few fails connection broke
[NETWORK] Starting connection...
[NETWORK] Cannot connect!
after that Network error continued. Led succesfuly turned on, though.
Wifi library think that connection is broken alas on wifi is shown as active and trying to reconnect.
Do you have any ideas?