In the past posts, I shared a lot of nodejs code to run mostly your code unattended. A few commenters pointed out that the data stops getting recorded when they kill their remote session. There are multiple ways to skin this type of cat. Here’s what you do in practical terms. Tools Screen Tmux nohup forever (specific to nodejs) cheap trick Screen  it has been long on the Linux scene, it allows you to interact with your remote session, resume from where it is, or you have left it. It’s not a piece of cake to use if you have not educated yourself about it. This quick (2 min) tutorial gives you a quick jumpstart about it. However, if you do want to use, take a look at this  quick reference . It doesn’t come installed with Jesse on Rasbian use the following to install it sudo apt-get install screen to execute your code screen -d -m node --mycodefile.js Screen has been around for a long time, less seasoned but with many more other advantages is  Tmux . I prefe

What leads me to write this post is the principle of using my own life as a human lab for social experiments and the fact that humans by definition are quite bad in choosing randomly when they need to. The level of bias is always very high, no matter how fair you believe your thoughts are on the matter. Below you find a bit of history about my social experiments and some software that I put together to reduce that bias in my walk the talk social experiments. History As in most families that raise their children with wisdom and common sense, mine brought me up with principles of respecting others and kick in the ass with no mercy to whom takes advantage of you beyond a particular bounding line. Many years have gone under the bridge since that pillar was instilled in me and these days I feel that new technologies challenge those principles trading-in convenience aka mental laziness. For instance, I used to meet my friends on a regular basis during the week, physically getting to

iamsensoria.com Raspberry Pi and Sensor Tag - Part IV - Update This post is part of what is becoming a very well rounded project about the leverage of Raspberry Pi and Sensor Tag by TI to collect sensor data. In part III I mentioned that a much better approach to... A reader of this blog pointed out through the ask away button that on my linked post I didn’t show the steps for installing Redis on the RPi but shown only the steps for OS X. Mantis91 is right and below you find the missing piece. From the command line you will be doing the following: Download Redis, last stable known version, source code Build and Test Configure the service Make sure that it runs on boot (if you so want) Step 1 and 2 wget  http://download.redis.io/redis-stable.tar.gz tar xvzf redis-stable.tar.gz cd redis-stable make make test   (sanity check!) cd src sudo cp redis-server /usr/local/bin sudo cp redis-cli /usr/local/bin cd .. cd .. rm redis-stable.tar.gz The operations abov

After all the work that you have done to bring to life your Raspberry Pi project you don’t want the following things to happen: Update your system if everything works  and  you have hardware dependencies Lose all your work as a result of  SD card failure Not keep your RPi system up to date if  security  and  server  services are vital to your project. Not automate some processes that keep your system pristine and in check.  Everything Works The old say goes “if it works don’t touch it!” - That piece of wisdom is as real as popular. Especially when you have DYI hardware involved in the mix. The open-source community is ultra awesome but also evolves very quickly occasionally/often (your call here) careless about dependencies and reliability on backward compatibility. Therefore, if your project works, and you are happy with the service that it provides to you, refrain from touching it or update anything on the software end or your weekends are going to be booked just to go bac

This post is part of what is becoming a very well rounded project about the leverage of  Raspberry Pi and Sensor Tag by TI  to collect sensor data.  In part III  I mentioned that a much better approach to store data besides redirecting the console output to file was to leverage a database. Storing  time-series data  can be pretty tricky and mostly unreliable if not well architected.  You might want to take a look at carbon and whisper, part of the graphite project. Carbon can handle vast amounts of time series data. To give you an idea of how well it scales, when graphite was first put into production at Orbitz, it was  handling 160,000 metrics per minute . In this case, I picked  Redis .  It’s an in-memory data structure store, used as database, cache and message broker. It supports data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Regis has built-in replication, Lua script