The InqPortal IoT / App / Web server version 5.2.0 is now available in the Arduino IDE Library Manager. Here are the new features and what you can expect from them.
Way-High WebSocket Throughput
Testing – We do extensive (shall we say abusive) testing. These edge cases, these Fringe events are to push Inqportal beyond its and the ESP8266’s capabilities. In the best case, we handle and report these error conditions so you can optimize your application. We recover and log these issues for you to evaluate and keep on chugging along. In the worst case, we want to eliminate surprise exceptions and Watch Dog reboots. We give you the conditions and reasons for failure. But in either case, these are way beyond what any sane person should expect out of a $1 web server (hardware and software included)!
Many web socket libraries have trouble when they start reaching their maximum throughput. If you’re lucky, they just start throwing away your messages. If you’re not – they just reboot leaving you with a dumb look on your face – What just happened? InqPortal will report lost data so you’ll know you need to reduce your output.
Real World Theoretical – Web Socket performance is very sensitive to WiFi connection strength and WiFi traffic. So let us define a perfect world for a Web Socket connection. You might recognize this as an unrealistic number. We like to think its a better number than a theoretical performance number – Like a gigabit network card. When have you ever seen Windows report a 1Gbit file transfer? Ah… never! At least these web socket numbers were seen – once.
Test Conditions
- In this case we are using the Built-In Access Point (SoftAP) so we have just one connection. A LAN connection (StationAP) has two… one between the ESP8266 and the router and another from the router to the computer with the browser client. We eliminate this unknown variable – the router, repeating the TCP messages going back and forth.
- The desktop WiFi antenna is a mere two feet away from ESP8266, ESP-01.
- We set up four browser clients so the server has to send out four messages for each message your application wants to send.
- We use small messages ~50 bytes long. This is the most common for a server to sending out data for clients. It also is the most abusive. For each message TCP has many transactions to send and acknowledge.
- We let it rip and try to maximize the output.
Old Results of Version 5.0 – In version 5.0 we were able to continuously send 32 KB/sec. At higher rates, we started to see data loss and at an extreme of 130 KB/sec we would randomly experience an exception after hours and gigabytes of data transferred. A non-desirable problem.
Version 5.2 Results – We are very proud to report on our new web socket optimizations. Over a 15 hour non-stop period (no rest for the wicked) the InqPortal server delivered over 11 GB of data at a rate over 200 KB/sec! This was achieved with a data send frequency of 1000 Hz – Yes, 1 message sent every 1 millisecond. This was done with no lost data.
Future – At the moment, we believe there is no more performance to be had. We note in our version 5.0 test, our ESP8266 metric: loop frequency was barely dropping from our idle rate of 130 kHz. We knew we were leaving available performance on the table. In version 5.2 our loop frequency is hovering around 400 Hz. This is a staggeringly low value and can say it is certainly the same as your computer running 15 hours at 100% CPU utilization.
Client Triggered Server-Side Events
We listened between the lines of a post on the ESP8266.com forum. Older versions had ways of creating an event on the server that could be triggered by the clients. It involved having a variable and other non-intuitive details. In Version 5.2, the event can be created with just one line of code. We also added an example ButtonClickEvent to the examples you’ll find when you add the InqPortal library from your Arduino IDE Library Manager.
UI Connection Experience
It is very difficult to create a bullet-proof UI when it comes to configuring the LAN Access Points. You must realize that first and foremost that you are configuring the connections via a connection between your browser client Admin and your ESP8266. When the ESP8266 scans for available access points, it must disconnect from the Admin and sequentially go through all WiFi channels and see what access points are on those channels. After it completes the scan, it must reconnect your browser and Admin so it can display the result to you. But it doesn’t stop there. The ESP8266 can only run one channel. If you are say… configuring LAN Access Points through a connection on the Built-In Access Point (SoftAP) and the LAN AP you are configuring is on another channel, the connection you are using must sever and be reconnect to your browser on another channel. All transparently to you. And the worse case is when you kill your computer’s connection to your ESP8266 server via selecting a new SSID in devices WiFi settings. Say… your reconnecting your computer back to your local area network router. Both the ESP8266 and your Admin client are left dangling in the wind. Without you putting the new address in the browser, it can’t get there. To give a transparent user experience hiding all these lost and recovered connections is certainly non-trivial. We feel there is still room for improvement, but in this version 5.2 there are fewer “what’s the ______ is going on?” moments.
Serial Monitor Default Baud Rate
The most trivial change, we changed the default baud rate of the built-in handling of the Serial Monitor from 115200 to 74880. This was pointed out to be the best rate to reduce garbage data on the screen and to improve hook-up rate between your application and the Serial Monitor.
For further information and to get started…