The Documentation For s2-pi has been updated and can be found here:

https://mryslab.github.io/s2-pi/

To install the demo code either type:

sudo pip3 install s2-pi

Or

Download From Github.

pymata_aio

Version 2.3 Has Been Released

NOTE: pymata_aio now requires Python 3.5

If you wish to use Python 3.4.3 use pip or github to retrieve version 1.9.

Version 2.3 Features

• TCP/IP support was added for running the SparkFun RedBot robot with a WiFly module.
• Improved Control-C handling.
• FirmataPlus and FirmataPlusRB now reset the Arduino when a "send_reset" or "shutdown"  API command is executed.

NOTE

Any applications developed using earlier versions of pymata_aio should be fully compatible with version 2.3 and should not require any modifications.

pymata_aio

Version 2.1 Has Been Released

The latest version retains all of the features of version 1.9, and is the new baseline for all future enhancements.  It Implements PEP 492 (async/await).

Any applications developed using version 1.x should be fully compatible with version 2.1 and should not require any modifications.

Asyncio is Coming to PyMata!

The next version of PyMata, scheduled for release later this summer, incorporates the Python 3 asyncio library. "Why?", you might. ask. Let's compare results of running two similar projects that control a servo motor

Both tests were run using Python 3.4.3 on Linux. The CPU used in the tests is an Intel® Core™ i5-2500K CPU running at 3.30GHz.

First, here is the PyMata 2.08 project code:

And now the system monitor results:

Application code for the new release:

Its system monitor results:

CPU utilization went down from 28% to 6% !

Comparing the code, you might be wondering why there is no import of the asyncio library. There are 3 APIs  included with the new release.

• pymata_core
• This is a pure asyncio API for those that wish to code directly in asyncio. It is a method based API.
• pymata3
• This is a "pymata plug-in api" that acts as a proxy for pymata_core. It shields the user from having to deal with asyncio. This is the API used for the sample code above. It is method based.
• pymata_iot
• This API provides an Autobahn based Websocket interface. It too is a "pymata plug-in" API that uses JSON messaging between client and server.
• Here is a screen shot of a web application taking advantage of this API:

• This rather busy screen shot shows a page that allows control of the digital inputs and the PyMata data latching feature. Pin 12 and 13 are enabled for reporting. Pin 12 is currently low and pin 13 is high. A latch was set for pin 12 that was triggered on 27 June 2015 at 13:27:24. Pin 13 also has a pending latch to fire when it goes low and then high again.
• Here is a sample of the JavaScript code used in this screen shot for setting pin mode:

• This code uses the browser's built-in Websocket client and therefore JavaScript was used. You can easily communicate using a Python Websocket client as well. First here is the JSON message template

• And the Python code to set the pin mode via Websocket:

Here is a summary of the features of the new release, its current status and a "to-do" list.

Major Release Features

• Utilizes the Python asyncio library for concurrency implementation.
• Full implementation of the StandardFirmata version 2.4.3 protocol.
• Continued support for FirmataPlus protocol(Sonar, Stepper Motor, Tone, and Encoder support).
• 3 APIs provided for application flexibility.
• Auto-detection of the Arduino COM port.
• Built-in Control-C detection.

Current Status

• pymata_core API is code complete and tested.
• pymata3 API is code complete and tested.
• pymata_iot is 70% complete and tested.

To Be Done

• Finish pymata_iot.
• Code cleanup.
• Documentation.

Futures and Coroutines and Loops! Oh my!

I have just published an updated version of esp4s, the project that uses Scratch to interface to an Arduino Esplora microcontroller board. This latest version uses Python 3.4.3 and its associated asyncio library. The new program is called esp4s-aio and is available on Github.

Going from proof of concept to a finished project was not as simple as I had originally thought. The Python documentation for asyncio is really great for reference once you understand how to use the library, but at least for me, was not very instructive for a first time user.

But once I figured out how to convert Pyserial's readline() and write() to "futures", and was able to instantiate and communicate with an aiohttp HTTP server, I was well on my way to finishing the task at hand.

But those weren't my only educational challenges. I also needed to learn how to unit test the code and came upon pytest-asyncio. After asking the package authors several rookie questions, and receiving quick and accurate answers (without any snark I might add) the last pieces of the educational puzzle were in place.

Now on to the code. I started with the same architectural design I used for the original esp4s. However, working through the code, I quickly realized that I could take a simpler, more sequential code flow approach than I used for the original multi-threaded esp4s project. This not only simplified the design, but the testing and debugging, as well.

One very major design departure from the original project, was to go from having the Esplora pushing out all sensor data every 25 ms. to a polled approach.I was concerned that performance would suffer but that turned out not to be the case. 

Now on to the results. I used a common Scratch script called test.sb2, ( which is provided in the esp4s-aio distribution) to compare esp4s and esp4s-aio. The Scratch script toggles an LED on the Esplora while concurrently displaying status for all 16 Esplora sensors. Scratch polls for status data at a rate of approximately 30 times per second.

It was interesting to find that the esp4s-aio version shows no display lag as sensor data varies, but the original version does (which means that the design of the original was sub-optimal). 

However, more dramatic was the difference in CPU utilization. First, here is  CPU utilization for the original:

And now the CPU utilization for esp4s-aio:

In this graph, the first 20 seconds are before Scratch was started and esp4s-aio is running idle. The increase begins when the Scratch script starts polling for data.

So overall, I am very pleased with the results, and plan to use asyncio coroutines for several future projects.  Since my projects tend to be more I/O intensive than CPU intensive, asyncio and coroutines are definitely in my future.