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. ToolsScreenTmuxnohupforever (specific to nodejs)cheap trickScreen 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 prefer it over Screen for many reasons. If you …

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 together …

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 codeBuild and TestConfigure the serviceMake sure that it runs on boot (if you so want) Step 1 and 2wget http://download.redis.io/redis-stable.tar.gz
tar xvzf redis-stable.tar.gz
cd redis-stable
makemake 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 above will take really long time, so kick it and go k…

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 dependenciesLose all your work as a result of SD card failureNot 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 back to where you were …

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 scripting, LRU eviction, …