Internet of Things

Q1: How to scan for all nearby wireless access point (AP) on Linux, in particular, Ubuntu or Debian?

A: Here is one solution

sudo iwlist wlan0 scanning | egrep 'Cell |Encryption|Quality|Last beacon|ESSID' should help.

It’s the combination of sudo (run as root, do privileged operations), iwlist wlan0 scanning (produce some output on STDOUT), the pipe symbol “|” (connecting STDOUT of the command(s) to the left to the STDIN of the process on the right), and an egrep command with a “single quoted” (to prevent the shell from interpreting the “|” characters) Regular Expression to filter STDIN. See man bash, man sudo, man iwlist, man egrep, and man re_format for details.

ALWAYS do man whatever (as above) BEFORE you execute a command string from someone else. Self-education is much safer than blind trust.

Q2: How to assign a .local domain to your Raspberry Pi so you don’t need to look up its IP?

Most likely your home network uses DHCP IP assignments, which means that each time a device leaves the network and returns a new IP address is assigned to it. Even if you set a static IP for a frequently used device (e.g. you set your Raspberry Pi box to always be assigned to number 192.168.1.99), you still have to commit that entirely unintuitive number to memory. Further, if you ever need to change the number for any reason you would have to remember a brand new one in its place.

Doing so isn’t the end of the world, but it is inconvenient. Why bother with memorizing IP strings when you can give you local devices easy to remember names like raspberrypi.local or mediaserver.local?

Now, some of you (especially those of you with a more intimate knowledge of DNS, domain naming, and other network address structures) might be wondering what the catch is. Isn’t there an inherent risk or problem in just slapping a domain name onto your existing network? It’s important here to make note of the big distinction between Fully Qualified Domain Names (FQDNs), which are officialy recognized suffixes for top-level domains (e.g. the .com portion of http://www.howtogeek.com that signifies How-To Geek is a commercial web site) and domain names that are either not recognized by the global naming/DNS system or are outright reserved for private network usage.

For example, .internal is, as of this writing, not a FQDN; there are no registered domains anywhere in the world that end with .internal and thus if you were to configure your private network to use .internal for local addresses, there would be no chance of a DNS conflict. That could, however, change (though the chance is remote) in the future if .internal became an official FQDN and addresses ending in .internal were externally resolvable through public DNS servers.

Conversely, the .local domain, has been officially reserved as a Special-Use Domain Name (SUDN) specifically for the purpose of internal network usage. It will never be configured as a FQDN and as such your custom local names will never conflict with existing external addresses.

What Do I Need?

The secret sauce that makes the entire local DNS resolution system work is known as Multicast Domain Name Service (mDNS). Confusingly, there are actually two implementations of mDNS floating around, one by Apple and one by Microsoft. The mDNS implementation created by Apple is what undergirds their popular Bonjour local network discovery service. The implementation by Microsoft is known as Link-local Multicast Name Resolution (LLMNR). The Microsoft implementation was never widely adopted thanks to its failure to adhere to various standards and a security risk related to which domains could be captured for local use.

Because Apple’s mDNS implementation Bonjour enjoys a much wider adoption rate, has better support, and a huge number of applications for platforms big and small, we’ve opted to use it for this tutorial.

If you have computers running Apple’s OS X on your network, there’s nothing you need to do beyond following along with the tutorial to set things up on the Raspberry Pi (or other Linux device) side of things.  You’re set to go as your computers already support it.

If you’re running a Windows machine that does not have iTunes installed (which would have installed a companion Bonjour client for mDNS resolution), you can resolve the lack of native mDNS support by downloading Apple’s Bonjour Printer Service helper app here. Although the download page makes it sound like it’s a printer-only tool, it effectively adds mDNS/Bonjour support across the board to Windows.

Installing Bonjour Support on Your Raspberry Pi

The first order of business is to either pull up the terminal on your Pi or connect into the remote terminal (if you have a headless machine) via SSH. Once at the terminal, take a moment to update and upgrade apt-get. (Note: if you’ve just recently done this as part of another one of our Raspberry Pi tutorials, feel free to skip this step.)

sudo apt-get update

sudo apt-get upgrade

After the update/upgrade process is complete, it’s time to install Avahi–a fantastic little open source mDNS implementation. Enter the following command at the prompt:

sudo apt-get install avahi-daemon

Once the installation process is complete, you don’t even have to reboot the device. Your Raspberry Pi will begin immediately recognizing local network queries for its hostname (by default “raspberrypi“) at raspberrypi.local.

The particular machine we used for this test is the same Raspberry Pi we turned into an ambient weather indicator, and then later changed the local hostname, so when we go to look for the newly minted .local address, we’ll be looking for weatherstation.local instead of raspberrypi.local.

Again, for emphasis, the portion that precedes the .local suffix is always the hostname of the device. If you want your Raspberry Pi music streamer to have the local name jukebox.local, for example, you’ll need to change the Pi’s hostname.

Go ahead and ping the new .local address on the machine you wish to access the device from now:

Success! weatherstation.local resolves to 192.168.1.100, which is the actual IP address of the device on the local network. From now on, any application or service which previously required the IP address of the Raspberry Pi can now use the .local address instead.

Q3: A cloudless voice recognition shield for Arduino

Check out MOVI (http://www.audeme.com/movi.html)

MOVI™ is an easy to use speech recognizer and voice synthesizer.  It is used with an Arduino board and provides an alternative to buttons, remote controls, or cell phones by letting you use full-sentence voice commands for tasks such as turning devices on and off, entering alarm codes, and carrying on programmed conversations with projects. MOVI is programmed directly from the Arduino IDE and requires no voice samples for training, does not use an Internet connection and is speaker independent. The code on the left shows an example of how easy it is to create your own voice-based dialog with MOVI.

MOVI code example

Q4: An inexpensive WIFI shield for Arduino

esp8266

Q5: Compile and install rtl8192cu wifi chip driver on Ubuntu/Debian

https://github.com/pvaret/rtl8192cu-fixes

Installation

Ensure you have the necessary prerequisites:

sudo apt-get install linux-headers-generic build-essential dkms

Clone this repository:

git clone https://github.com/pvaret/rtl8192cu-fixes.git

Set it up as a DKMS module:

sudo dkms add ./rtl8192cu-fixes

Build and install it (this version number may change, it is .10 as of october 19 2015

sudo dkms install 8192cu/1.10

Refresh the module list:

sudo depmod -a

Ensure the native (and broken) kernel driver is blacklisted:

sudo cp ./rtl8192cu-fixes/blacklist-native-rtl8192.conf /etc/modprobe.d/

And reboot. You’re done.

Troubleshooting

There is a known issue with power management on some hardware. If your WiFi connection drops after a few minutes, install the following module setting file to disable power management in your WiFi interface:

sudo cp ./rtl8192cu-fixes/8192cu-disable-power-management.conf /etc/modprobe.d/

And then reboot.

Sometimes Network Manager also sets a device in a power-saving mode where it doesn’t use enough power to connect. You can fix it by editing /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf and setting wifi.powersave to 2. And then reboot.

Advertisements