This week, it was how many services can I bounce a notification through?
But I didn’t get to it.
I did however do a lot of research into various artworks I was curious about.
So we’ll call it a trade off for now.
Week 6: Playing with Alexa and Google Home
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.
Week 4: ServoVane
Resources:
Overview: This week, I wanted to do a project that focused on parsing data out of an API and doing something with it. I decided weather would be the Path Of Least Resistance due to the fact that everyone has a weather project out there somewhere, and the documentation for weather APIs is pretty solid. I also wanted to explore some of Adafruit’s Feather Wings.
System: For this project I wanted to stay away from BaaS providers. You can do a version of this mashing up IFFTT and Adafruit/IO or the like, but I wanted to instead combine all my parsing / data grabbing / behaviour into one board. The Feather is just an ESP2866 on a breakout. Which means it has the ability to do TCP calls, UDP, act as a wee little web server, or just be a gateway. You can drill down into the functionality using various libraries that are compatible with Arduino. For this set up I decided to parse some JSON directly from the Weather Underground API. The servos themselves run on a repeating timer, for a set amount of time. So they are not on constantly. After which they stop, the feather hits a delay mode for a while until grabbing the next weather conditions and triggering the routine all over again.
Components: Adafruit Feather Huzzah, PWM Servo FeatherWing, 5v 2a Power Supply, 5V power supply (USB port, but could be a plug in), 7 micro servos
Things I Experimented With: Parsing, Libraries, Mapping, Timing, APIs
Things I learned: There’s some library conflicts with the ESP8266WiFi and Wire.h, in so far that you need to declare the PWM before you start doing any pin setting logic. It could be a timer issue (but the PWM board apparently has its own timer), or it could be a bit of a pin mash. I should have been using a 5v 10a power supply, but I didn’t, so that might have also contributed to some funny behaviour. I also need some extra barrel jack adaptors in various sizes.
Of Note: You need little delays for the ESP2866 to be able to process JSON. If you don’t have them, it can sometimes just not grab things.
Future Iterations: The sounds servos make is pretty nice/annoying. I think working more with the timing and figuring out how to make something like this more of an audio piece might be fun. Working more on system timing and run time.
Week 3: Nihilistic Internet
The intent of this week was to take a deauth attack and roll it into having a trigger. Except I took on helping to organize a conference that happened this week, and so this project was sidelined. I did manage to get a successful deauth attack running on a generic ESP2866 via a tutorial and a few github repos, but didn’t really get to dig into why it was working and modding it. That said, I did start looking up books and lessons that I could read /do that would help me understand the wireless stack a bit better. Some of them were:
The TCP/IP Guide
Introduction to the ESP8266 and the IoT
A collection of Raspberry Pi IoT projects
Next week I’m going to be working with the feather, an API, and some servos, so I’m going to bundle one or two of these resources into that project.