Our Chrome browser thinks it’s a Chromecast dongle. Here’s a screenshot of it playing a YouTube video. Note the tile banner and onscreen controls which are just like the ones you’d see on the actual hardware. Give it a try yourself by downloading the Leapcast Python package which [dz0ny] programmed.
After cloning the GitHub repo we had a few problems compiling the package. Turns out we needed to install python-dev and that took care of it. Starting the daemon is a simple command, we specified our Chrome binary path as well as added a few flags
leapcast --name HAD --chrome /usr/bin/google-chrome --fullscreen
Once that was running the Android YouTube app automatically detected Leapcast as a Chromecast device. It gave us a tutorial overlay mentioning the new share icon on the interface. Pressing that icon during playback launched an Incognito window which played the video. [dz0ny] links to a device config JSON file in the README. If you check it out you’ll notice that Netflix is listed as “external” while the others are not. This is because the Chromecast protocol uses a binary for Netflix. The others do it with local websockets or a cloud proxy so they work just fine with this setup.
A while back, [Blaise] tried his hand at getting the WebSocket protocol working with PIC microcontrollers, WiFi adapters, and a few pots, knobs, and switches. It was an excellent project for its time, but now [Blaise] has a Raspberry Pi, and the associated GPIO pins and Ethernet connection. He decided it was time to upgrade his build to the Pi, this time with a project he calls PiIO.
The basic idea of [Blaise]’s project requires a Pi, a server, and a computer running a browser for the end user. On the Pi side of the build, [Blaise] connected a Microchip MCP3008 eight input, 10-bit ADC via the SPI bus. The Pi takes the ADC sensor values from pots, buttons, or any other analog source and sends them to a server with the WebSocket protocol.
The server hosts a web site written with Django, Autobahn, and Python to communicate with the Pi and host the web page for the data received from the Pi. There’s support for multiple Pis in [Blaise]’s build, making complicated projects we can’t even conceive very possible.
[Blaise] put up an awesome demo video of PiIO up; you can check that out after the break.
Continue reading “WebSockets, Raspis, and GPIO”
Using animated GIF images as a crude WebSocket is an idea we’ve never come across before, but it actually makes a lot of sense. Not in terms of it’s overall usefulness, but just for the fact that the animated files work in a similar way. The nature of these animated containers is what makes it work. A GIF doesn’t tell the browser how many frames to expect, so the connection is kept open until the “hey this is the last frame” command is received. This can be used to stream data to anything that can play the animations.
The demonstration after the break shows this in action. Hello World and a couple of other test messages are pushed to the browser without refreshing the page. In our mind that’s what’s useful — real time updates without a refresh or any underlying client-side code structure. But we haven’t looked into the particulars like does this eat bandwidth even when nothing new is being sent?
When [Hans] wrote into us about this gif hack he referenced this discussion panel on WebSockets. We didn’t watch the whole thing yet, but apparently someone calls the gif trick the WebSocket of the ’90s.
Continue reading “gifsockets: WebSockets using animated GIF files”
[Blaise Jarrett] has been grinding away to get the WebSocket protocol to play nicely with PIC microcontrollers. Here he’s using the PIC 18F4620 along with a Roving Networks RN-XV WiFi module to get the device on the network. He had started with a smaller processor but ran into some RAM restrictions so keep that in mind when choosing your hardware.
This project was spawned after seeing the mBed feature a few days back which combined that board along with a WebSocket library and HTML5 to pull off some pretty amazing stuff. [Blaise] doesn’t have quite as much polish on the web client yet, but he has recreated the data transfer method and improved on that project by moving to the newer version 13 of WebSockets. The protocol is kind of a moving target as it is still in the process of standardization.
The backend is a server called AutoBahn which is written in python. It comes along with client-side web server examples which gave him a chance to get up and running quickly. From there he got down to work with the WebSocket communications. They’re a set of strings that look very much like HTML headers. He outlines each command and some of the hangups one might run into with implementation. After reading what it takes to get this going it seems less complicated than we thought, but it’s obvious why you’ll need a healthy chunk of RAM to pull it off.
This project shows you one possible way to use HTML5 to fully integrate sensor data from a microcontroller into our technological lives. Now, when we saw this tip come through our inbox we thought it would be an interesting example to learn from but we weren’t ready for how truly cool the setup is. Take a look at the video after the break and you’ll see that scanning the QR code on the project box will immediately start a 10ms resolution live stream of the accelerometer data. Furthermore, the browser page that the phone loads allows you to send what you’re currently viewing to the main frame of a browser running on a different computer with the touch of a button. In this way you can build a dashboard of streaming sensor data. Talk about the future of home automation. Imagine a QR code on your thermostat that allows you gain access to your home’s heating, air conditioning, humidifier, and water heater performance and controls just by snapping a pic? The sky’s the limit on this one so let us know what you’d use it for by leaving a comment.
Continue reading “Wicked use of HTML5 to display sensor data”