Week12: Allstar Interruption

Code Repo

Resources:

Overview: This week I wanted to make a juke box that someone could interrupt with a particular song (in this case Smash Mouth’s Allstar). I set it up to run locally, and made a basic site out of Flask, with a button, that then changed the values on a API. I re-used some of my code from the Alexa Blender to to grab that changing API value. The issues I ran into were mostly w/ the feather’s music maker wing. It seems to be having issues maintaining its power when you use an interrupt based play back. I”m guessing there was something wrong w/ the interrupt calls as the blocking calls to the music still worked well. After doing a bunch of troubleshooting I couldn’t get the wing to be stable. I tried different iterations, and tutorials based on using Adafruit IO / doing streaming radio, changing pins and resistors, a different SD card, re-solder, etc. But the board would peter out after a bit. I even tried to follow something to re-flash the nodeMCU, thinking it might be a corrupted memory thing, but for some reason couldn’t make a proper connection. At least I found a lot of resources on music boxes / IoT music things.

Components: Feather Huzzah, Music Maker Featherwing, Flask-Restful

Things I Experimented With: Timers, playlists, SD card.

Things I learned: Plug and play doesn’t really mean that.

Future Iterations: I’d probably set this up via a BaSS, and maybe use a different board. I’d like to still figure out what happened. As the user guide for the huzzah is pretty surface, but if you try and trouble shoot the NodeMCU there’s a rabbit hole of forums. I think as well, I need to find more robust ways of using a homebrew API.

Week8: Maps

Code Repo: Week 8

Resources

This week I just wanted to play around with google maps. Once again I found that there is a FLASK extension to do this, but instead I just decided to mess around and find some resources for using just command line python. I found that the maps API is more like 6 APIs you have to turn on, which seems weird, but hey! Internet!

Anyways, I found a few good resources, and just put together a little program that looks for nearby places and sets them as waypoints. In this way you could potentially always route someone through every pizza joint in town before getting to their destination. Which I wouldn’t mind, because who doesn’t like pizza? I’m pretty sure within a year someone will make an app called Pizza Quest that does just this (hmmm…).

The places api is pretty big too. It spits out reviews, images, locations, hours, lat/long, different kinds of address formatting. Its impressive how much is packed in there.

Other neat things I found, did you know there is a google maps longest route challenge? It takes place every year!

Components: Just Python

Things I experimented With: APIs, aggregation, parsing

Things I learned: It takes a lot of APIs going to run google maps.

Future Iterations: Plugging this into a GPS device would be pretty fun.

Week 6: Playing with Alexa and Google Home

Code Repo

Resources:

Overview: This week I decided to play with Amazon Alexa and Google Home. Mostly just looking at tools and possible frameworks that you can use it with. There’s a good site called echosim.io that is a web version of Alexa, and which allows you to test out some of your skills. Google Home allows you to test right in its api console api.ai.

Comparisons: In Alexa’s case tho I wanted to try some bot to bot chatting. So I made a small app for Alexa that can ask Siri some questions, which works surprisingly well, as long as your phone is next to the speaker. You can, indeed get a bot chat going if you so desire.

My hope with Alexa was to get it responding to wild card utterences. But to do this you really need to be able to set a default response, which oddly, you can not do in Alexa. There’s a lot of chatter on the forums about wanting a default response, but also wanting Amazon to expose Alexa’s confidence rating which can influence which response Alexa gives. Whether the devs will do it, remains to be seen. Amazon does want Alexa to be able to chat, but its pretty early, and the limitations are noticable.

Google Home, meanwhile feels more setup to do random conversations. Not only does it have some built in items for small talk, but I found the work flow using Flask-Assistant better than Flask-Ask, even though they are very similar in their use of decorators. The big thing: Flask-Assistant has an auto-scehma generator for making JSON, which is great. Because for small things its fine to manually make JSON, but when you start getting into larger things, having something auto-gen and format your stuff is very helpful. I also seemed to be able to jump into templates faster with Flask-Assistant. Google’s web sim isn’t as good as Amazon’s. But it does have the option of being able to just type things in, which is nice if you’re working in public and don’t want to be talking to your computer.

It is good to note, that both these bots are effective in their own ways, depending on the access they have to your various accounts. Which is pretty deep. So the worries around surveillance are quite legitimate. I don’t know if I would keep one active in my home if I weren’t specifically using it for a project. But then again, we did get used to phones pretty quickly.

Conclusions: Its too early to tell who’s going to come out on top of the bot race. I think that if you’re into doing weird stuff, or want to play around with strange contexts right now, Google Home is your best bet. But that could change depending on what Alexa comes out with over the next year. I would also suggest picking up the physical speaker, as it does add to the “experience”. Seeing as we’re so used to phones, extending that behaviour to a speaker isn’t that far fetched.

Of Note: The decorator setup in Python was interesting. Its the same setup that my friend Jon came up with when we were developing txtr in 2014. Which allows you to do choose your own adventure via SMS.

Future Iterations: I’d really like to get a Siri / Home thing going. Or make something that only chatters errors. I think having a bot that only tells you things in cryptic error speech would be pretty funny.

Also! I helped troubleshoot something w/ Flask-Assistant and Virtualenv.

Week 5: Tiny Oracle

Resources

Overview: Tiny Oracle was an idea I had a few months ago. Its based around aggregating new / traffic / weather / tweets etc into one place, and then generating how a city “feels” based on that data. I didn’t get to the data part this week, but I did make some good progress with the hardware, and even started writing my own restAPI to handle requests. The results, despite it just being a tech test were whimsical.

System: This took a bit of a twisty road. Basically I started thinking I would make a Python based bot that just aggregated all my feed data, parse it, then toss some commands over to a BaaS provider like PubNub or AdafruitIO. But I once again ran into the issue w/ the Feather and its MQTT library, that there’s something buried in it, that prevents it from being totally non-blocking. I knew the particle library didn’t have this issue, so I started digging around in it, and seeing if I could re-mod the mod to re-use for the Feather. But it looked like the particle library was just doing GET requests. So I started looking around for some info on REST APIs, and decided I didn’t need a Pub/Sub setup. I found some tutorials, downloaded Flask (which I like and am familiar with), and starting making a basic API to pass on some JSON. The Feather makes a request on a timer, grabs the JSON the server serves up, and then prints out a message and does a little display based on it. I found it pretty straight forward to build this little Server / Client system. It doesn’t have any security, so its only for local testing, but I would like to make a version that does. But I would like to keep rolling my own solutions going forward.

Components: Adafruit Feather Huzzah, Nano Thermal Printer, FLASK, Python, Adafruit Neopixel Featherwing.

Things I Experimented With: FLASK rest-ful, requests, protocols.

Things I Learned: A lot about basic rest apis! And that you really don’t have to send things to “my butt” if it doesn’t have to go to there. Most of the MQTT libraries for the various BaaS providers seem to have some kind of blocking issue (pubnub / adafruit) in the subscribe function. Also that a lot of data can still just be grabbed with just GET requests.

Future Iterations: I really want to get this to a point where its parsing different data feeds to build its feelings. I also want to keep building a little restAPI for more of my personal projects.