Thanks Alvaro!
I get exactly the same results, it connects, but the connection is not stable enough.
Yep! I will take a deeper look at the WiFiESP library to see how it is implemented. Maybe it can be improved a bit to behave exactly as the stock WifiClient. Right now seems to have problems while reading data from socket. There also some references in GitHub that may be related to our problems:
Hi,
I confirm the WifiEsp library discards the incoming data on next transmit of AT command. There is generally no input buffer and the library reads the data directly from the SoftwareSerial buffer (on Arduino Uno). The fuction that clears the data is espEmptyBuf(), file EspDrv.cpp. You can see it is called frequently.
I am thinking of creating separate input buffer for data messages, at least for the shorter ones. The processor in Arduino doesn’t have sufficient RAM to create large buffers.
I saw exactly the same things @JiriBilek, espEmptyBuf() is called every time any command is send (i.e checking the socket state or wifi state), dropping all incoming data from server. I enabled also the DEBUG output of the library, and saw that the server sends correctly the bytes, but the library still says that there is no data available. This is not the expected behavior. Not sure what is the best approach to solve this, but the library needs a rework. I suppose that the ESP8266 maintain different input buffers, as it needs to handle different TCP connections simultaneously, so i suppose you can query per socket different states, like checking if there is pending data, read from one socket, and so on…
Alvaro,
I added an input buffer to the WifiEsp code so now the connection is quite stable but I am observing strange behaviour on the connection.
Could you please explain the thinger.io server functionality?
My setup:
a) three outputs and one output
b) two dashboards (one with all three outputs, the second one with the first output only), no buckets
My questions for approval or explanation:
- After the device connects to the server, the server requests (subscribes) only the resources that are contained in visible dashboards? So that when no dashboards are open, no requests are made, only keepalive messages are travelling.
- On every switching dashboards the server requests (subscribes) all the resources from the new dashboard?
- On timeout and following automatic reconnecting the server should act as in question 1?
I am experiencing strange subscription requests. Mostly the server requests only one resource, sometimes all three, but I cannot find deterministic behaviour in it. It is very common when I switch to a dashboard with more resources that only the first one is subscribed.
I am attaching the experimental version (needs more work definitely) of a changed file in WifiEsp with 128 byte input buffer. And my testing sketch.
Thanks,
Jiri
EspDrv.cpp (25.6 KB)
WifiEsp.ino.cpp (1.6 KB) - please rename to WifiEsp.ino
1 Like
Hi @JiriBilek! Nice you have something that works!! Great Job! I will try to test your code soon.
I will try to provide information about how the dasbhoards and resources works answering your questions:
- Yes, the resources defined in the device are not used for anything at a first instance. However, when you create and open a dashboard, the server subscribes to all the resources required to provide data to this dashboard. If you open a dashboard, the server request the resources to the device. If you close the dashboard, then the device will stop streaming the associated resources. The same happens when there are 2 or more dashboards. The subscription is only done once if both dashboards shares the same data. The same idea applies to buckets. No visible dashboards or buckets: the device should only send keepalives.
- Yes, if you close one dashboard, and the open the second one, the server will stop the resources for the first one, and then will request the resources for the second one.
- Yes, if the device is disconnected/reconnected while there is a dashboard open or data bucket associated, the server will automatically request all the resources to provide data to the dashboards or bucets.
So, if you have dash X with resources A, B, and a second one Y with A, B, and C, opening X will request A and B. Opening Y simultaneously, will request only C.
There are some other underlying optimizations, like, what happens when X request A at 2 seconds, and Y request it at 5 seconds? The server will request the resource at 1 second interval (greatest common divisor), and will provide data to each channel/dash at required interval. This use case can trigger additional subscriptions that modify the streaming interval when opening/closing the involved streams.
Not sure if it is more clear now. Let me know! 
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.
Jiri
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
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:
- Serial1 is running on pins 6 and 7
- LED5 added:
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