image

I finally got time to hack together the prototype for the class project for my class this weekend. We’re going to be using the RaspberryPi to connect to Plivo and make phone calls, nominally to our Mom’s. I thought one button was boring so our call Mom Button class will actually have 4 buttons suggested as:

* Call Mom
* Call Dad
* Text Mom “I love you”
* Mother’s day special

For more details or to sign up see Meetup.

Cross posted on MakerBar Blog.

Advertisements

Next Saturday I’ll be teaching another class at my hackerspace, the MakerBar in Hoboken.  This will be my third Raspberry Python class.  Following up on the initial class, and the train class.  Like the others, this workshop will cover the basic use of a Raspberry Pi, but it’s coming together really well, I’ve got a Pi sitting on my desk chattering inane things from my twitter feed at me and actually, it’s proving more useful than I expected.  Just in developing the project I’m finding more out about my friends than I had before–mostly some corporate feeds to unfriend and some friends to check up on.

The class will run about 2-3 hours so we’ll have time to get our Pis setup, on the latest version of Raspbian, which already includes NTP, and really dive into the programming and improvement.  Since most of our time and effort will be software, the hardware is perhaps not so impressive, no loop of train track here, but this is a picture, of the prototype

If you’re interested in coming, please rsvp at meetup here.  And if you need a Pi or SD card, leave a comment there, a few are on order so we should have some.

PythonAnywhere

August 26, 2012

There is a missing middle in our approaches to sharing servers.  On one end we have static web hosting where all users are doing the same thing so we can install and run one copy of Apache for all users, that works up to the point of cgi scripts and php. The other end of the spectrum is to buy a server and that extends down to virtualized servers. Between there is a gap where there is some commonality to the user’s needs, but little support. Engine Yard has their RailsEngine platform for Ruby and there are a few Python offerings of which PythonAnywhere is one.

PythonAnywhere starts from the assumption that you will be running Python. They also assume that you’ll want to use Python interactively at least sometimes, probably a lot. The operation of PythonAnywhere is to login and select a console. You can choose from your existing consoles or start a new one in your choice of:

* Python: 2.7 / 2.6 / 3.2
* IPython (0.12): 2.7 / 2.6 / 3.2
* PyPy (1.6): 2.7
* Bash
* MySQL

Once you select a console it will open directly in your browser through a combination of JavaScript and Flash. It tries a few different connection mechanisms so it does work even without Flash and through some but not all firewalls. It also works on Android 4 and supposedly iOS, though you should get a keyboard without auto-complete or an external keyboard . This kind of quick access to different runtimes is great for testing, but the consoles are also persistent, so you can start working on one device and switch to another.  You can prepare a session on your desktop and then connect to it from your laptop for a presentation, or rely on iPython’s history feature to recover even if it gets restarted. The other payoff is sharing, any console can be shared–no account needed for the recipient. Sharing is real time and persistent a class can share the teacher’s console passing control from student to student to answer or ask questions.

Surrounding the console features PythonAnywhere provides file hosting with a basic JavaScript IDE which will let you run scripts or launch them to a console. If you use Dropbox you can set it to sync folders or use your choice of version control to check out projects.

For non-interactive hosting you can go simple with scheduled tasks or hook in a wsgi application.  Because the servers are virtualized via Amazon’s ec2 you cannot run a server directly.  Free users can have username.pythonanywhere.com addresses, and paying customers can point their own domains at the service.  That’s pretty much the way of things when it comes to paying, PythonAnywhere is on a freemium model, most of what you need is in the free tier, unless you’re doing something that you’ll have to admit is on the heavy side.  The only real hassle to the free tier is that they’ve had to restrict http access to a whitelist of sites to prevent misuse.

To get started with PythonAnywhere just sign up at https://www.pythonanywhere.com/ with the free account you can get two consoles, a database, and everything you need.  Sign up is faster than installing python locally.  Even from the basic account you can share a console, so this makes a great tool for learning and exploration.  Give it a try next time you’re experimenting or collaborating, try it on a desktop or laptop before trying to use it on a mobile device where it can be a bit more finicky.

Disclaimer, I have been involved in the PythonAnywhere Beta test and they have thanked me with account upgrades and free gifts.  No one from PythonAnywhere nor Resolver Systems was contacted to prepare this review.

There are three main interfaces that can bridge the gap between SecondLife and real life:

* e-mail – E-mail is the simplest of Second Life’s external interfaces and the one that can be used without an external server. On the downside, it also has the greatest lag and highest latency. Outbound the Lindens add 20 seconds of script lag to each call, inbound there’s no scripted lag but your messages are subject to normal E-mail delays. E-mail is designed to be slow but reliable, for example, the spec requires that clients retry failed messages and suggests a 30 minute retry interval. I’m sure you’ve seen much delays up even to several days.

* xmlrpc – xmlrpc is the only option that allows an external program to trigger an in-world event, in fact xmlrpc can only be triggered externally triggered though the script can send data out in a reply. Xmlrpc is low lag and low latency, the Lindens add 5 seconds of script lag and only when your script sends a reply. Sending a reply is optional from the standpoint of lsl, but not replying will likely raise an error in your external code. Xmlrpc communication is based on channels which are assigned by Second Life’s servers. Any program using xmlrpc must include a mechanism to get the channel identifier out of SL. The other two SL/RL interfaces are prime candidates though you could ask users to copy and paste. You should also make provisions to open a new channel when the old one idles out, the scripted object rerezzes or changes region, or the channel is closed by a grid reset. This is rare, but something you need to plan for.

* http request – while xmlrpc uses http internally you’re not supposed to think about that. If you wanted to think about it you would use http request. Http request effectively turns Second Life into a web browser. Http has no lag and low latency, the Lindens limit it to 100 requests per 100 seconds, you’ll have to add your own lag if needed to stay within that limit. You can use three of the http methods; GET, POST, and PUT. GET and POST are commonly used in web sites, with a little bit of effort you can interface them to any web framework you’re familiar with, either to retrieve data or send it to a form. You’ll need to format your data and run it through llEscapeURL yourself, but your framework will handle it from there just fine. PUT is a little less common in web applications and may turn up somewhere odd in your framework, but it can be used to send unformatted data very nicely. All http requests are initiated from within Second Life, but they can retrieve up to 2k from your web service. With the low lag you could easily poll to allow an external service to trigger events in SL.

I’ll write more about each of these in later entries or take questions by comment or e-mail.

After we posted the control panel In Kenzo left us a note inviting us to enter into the NMC Connect art show. While Bill and I had defiantely talked about the possibilities of building some sort of art piece using the technology, hopefully a large installation and likely working with a more established artist, we certainly weren’t expecting to do one just a couple weeks later. But, we didn’t want to pass up the opportunity either. So, Bill, Sandhya2 Patel, and I sat down to brainstorm how to run our skills into art. Sandhya2 was a great help since unlike Bill and I she is an incredibly skilled artist. Bill chipped in with the comment that we could do light and temperature easy, so, of course we came up with a plan that required a barometer. Sandhya2 built a wonderful little german weather house, Bill got a barometer, and I wired the whole thing through so that the sensor is entangled with both the actual Weather House and an in world replica of the controller.

Here’s the finished in-world build:

Weather Wisdom Build

And the finished real world controller:

Controller in place in the windowClose up of the controller

You can see the build up until the 13th at http://slurl.com/secondlife/NMC%20Campus%205/225/124/20. We’ll probably put it up again somewhere else after the show, but we can’t be sure just where yet. Also, after the show we definitely want to hook up the LEDs that we have in the world build. Hooking up 3 devices to one serial port takes a little doing and we had to cut it out of the RL controller.

NB:  Pingbacks are disabled because I keep getting pingback spam on just this entry.

One of the things that have fascinated me since I joined Second Life has been mixed reality events. Just as I joined, my friend Hiro Pendragon was working on The Happening. I thought that was pretty neat and have watched the new events since, even built a few gadgets of my own. I just finished another one, a real life control panel linked through into Second Life. My friend Bill Ward built a small control box, just like this:

which I then hooked to my computer just like this:

Connected to computer

and built a representation of in Second Life like this:

Second Life Controller

The two are now entangled together through a Python web server so that turning the knob on the real world one, or pushing a button, changes the same on the one in Second Life.

What for? Well, the same techniques can connect other real world objects to other SL objects. We’ll probably be connecting the panel to trains and fireworks, maybe a few other things soon, and then working on other panels and in-world applications.

You can see the RL and SL panels at my display gallery in Pi. Or as best as can be shown in the larger picture below:

Both controllers in SL

That’s Bill(Williem Leandros) on the left, myself on the right, and Rhiannon Chatnoir looking on in the middle.

Flood My Basement

November 30, 2006

For the last couple weeks I’ve been telling friends that one of my current projects is “flooding my basement.” Those who are not Second Life residents look at me real funny, those that are look at me virtually funny. Perhaps it would have sounded better if I said I was developing and http request/xmlrpc based webservice to allow anyone on the internet to flood my basement, ah hindsight.

Well it’s done now, if you go to my shop in Second Life you too can now flood, and dry my basement, the controls on the web connect live via xmlrpc to my shop and control positioning and visibility of the water around my shop. From here I’m going to expand a few things and then get really tricky.

Update: I’ve had some trouble with the tricky slurl above, the control panel is here and my shop is at Areumdeulli (175,102,97)