Problem

You found a good deal on an Intermatic InTouch CA5100 Accessory Switch, you installed it and consulted the manual to set it up only to be pointed at another manual -- not included in the package -- for pairing instructions. Hopefully, you also noticed that this is a switch that doesn't actually control anything; it simply sends Z-Wave commands and reports its status (for people like me that have a regular outlet where it would have been really convenient to have a light switch).

You've searched the internet and you have no doubt discovered that Intermatic appears to have decided to pretend they never created this product. There's no reference to it on their web site and several URLs that once pointed to manuals on a different site run by Intermatic now just redirect to their homepage. Awesome.

How to Pair

Making it work

You're not quite there, yet. Though the device is recognized, SmartThings doesn't know what it does, yet. Visit this helpful forum post for a groovy script that can be added using the IDE. After you've published the script, you can visit the My Devices tab, select the switch and change its type to Intermatic CA5100.

I'm writing this post mostly for myself because I know at some point I'm going to have to do this again and after having spent about an hour trying to find some hint as to how to pair this thing, I can only imagine it'll get harder in the future. In fact, the only reason I discovered this at all was because I went to the Amazon product reviews and found someone who had mentioned the pairing procedure in passing during his review. Once that product is gone, I don't expect that information to be there any longer. As far as the device, itself -- it was inexpensive compared to others and fit my needs perfectly. Now that it's working, I have no complaints, but failing to include a manual with three simple steps to pair the thing is a pretty big omission and likely caused endless support calls.

Background

The HubPiWi Blue is an add-on for the Raspberry Pi Zero that gives you three USB ports, and a combined WiFi/Bluetooth adapter (RealTek chipset). If you poked around after install, you likely noticed that there's a module for a Realtek device already detected and running. We're part of the way there, unfortunately, it's only the "Bluetooth" part and I'm not even sure that it truly works. Thankfully, RealTek provides module sources for a Linux driver and they were great with Raspbian (with a few Makefile tweaks). Unfortunately, this means we'll not be able to update the kernel after this without repeating a lot of these steps again.

Initial Setup

I’ll skip the basics except for this: Get an SD card, load the latest Raspbian image onto it and pop that into the Pi Zero’s available card.  You’ll want a monitor/keyboard handy or an FTDI adapter.  And you’ll need some time – my recommendation: line up some chores to do during each of the major steps and you’ll get a bit done while you’re waiting.

What you’ll need

If you want to follow this post exactly, here’s what you’ll need.  I’ve included notes about alternatives where I can, but I’m doing this as I write, so I’m providing what I used to make it work.

• A Raspberry Pi Zero
• A HubPiWi Blue
• USB power and Micro USB cable
• An HDMI display and Keyboard or an FTDI Adapter
• A Wireless network you intend to attach to.

Before We Build the Driver

As always, run the following commands:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo reboot

It’s a Pi Zero, so it’s going to take a while.  To its credit, it performed faster than my original Raspberry Pi.  And for $5 (or if you were one of the lucky ones that grabbed one at Microcenter for a buck), you can’t really complain.

I used the non-LITE version of Raspbian and ended up with 122 packages that needed updating, which took around 35 minutes.

Building and Installing the WiFi Kernel Module

The HubPiWi uses the Realtek 8723BU Chipset and the same Bluetooth module found in the 8723AU. Luckily, there are kernel modules for these. I've created a fork of the WiFi driver repository and modified the Makefile to allow for an easy build on Raspbian, so we'll clone my forked repository and use that to build the module.

cd ~/
git clone https://github.com/Diagonactic/rtl8723bu.git

The driver is kernel version specific, so we need to get the correct linux headers.

sudo apt-get install raspberrypi-kernel-headers

Time for some more chores.  This clocked in at about 10 minutes.

cd ~/rtl8723bu
make 

This will run about 30-40 minutes.  When you’re done, you’ll have a compiled driver and be ready to install:

sudo make install 

At this point you can either reboot with the “reboot” command or type the following:

sudo insmod 8723bu.ko
ifconfig

You should see your wlan0 device ready to go! Of course, you still need to configure it to attach to your network. There's a variety of ways to do that so simply search away and set that up and you'll be connected.  That’s fairly easy and there’s several articles on how to do that.  This device also comes with Bluetooth support, so follow the remaining instructions to get that working if that’s something you’re interested in.

Building and Installing the Bluetooth Kernel Module (Optional)

Since it’s always a good idea to only enable the features you’re actually going to use, if you have nothing to pair the device with or no use for Bluetooth at this time, you can skip this.  These steps are Bluetooth specific and doing them will not improve or affect your ability to get going with WiFi, which is more-than-likely what you wanted to get working, anyway.

The modules above do not include the Bluetooth part, so for that we need to grab and compile a new module.

cd ~/
git clone https://github.com/lwfinger/rtl8723au_bt.git –b kernel
cd rtl8723au_bt.git
make
sudo make install

Note the “-b kernel” on the git clone command.  If you fail to include this the make command will not work (and will instruct you to grab the kernel branch, which is why we’re including the –b kernel above).  This will take about 15-20 minutes on the Pi Zero, so kick back and drink some more coffee.

Now all we need to do is insmod a few modules and we’re in business

sudo insmod btrtl.ko
sudo insmod btintel.ko
sudo insmod btbcm.ko
sudo insmod btusb.ko

Assume you received no error messages, we can now verify that Bluetooth is working:

sudo bluetoothctl

You should see something along the lines of “[New] Controller xx:xx:xx:xx:xx:xx yourhostname [default]”

That’s it!  Pairing devices with this controller is done the same way it would be done with a Raspberry Pi 3.  If you need instructions on that, I’ll leave you to google away since that may change as time progresses (but should always be the same process for this device as it is with others).

Bluetooth Device Compatibility

If you chose to install the Bluetooth Kernel module there’s a small but important disclaimer.  Bluetooth implementations can be hit and miss.  Despite having a “certification” component that’s supposed to mean that a Bluetooth device will operate with anything else that’s certified (indicated by the Bluetooth logo being present on your device), this is often not the case in the real world.  I expect you’ll have no problems with any Android or iOS device, however, if you’re trying to pair with something a little more exotic, like an older Microsoft Windows Mobile phone, Microsoft Branded “Sync” stereo, or other stereo/TV, you may have problems (I’m not picking on Microsoft, directly, here, these are just devices that I have owned that I’ve had Bluetooth pairing problems with in the past).  Bluetooth keyboards, for instance, are notoriously painful to get to pair properly (you may want to use the GUI tools to do this, though it will be very slow on the Pi Zero)

Ongoing Maintenance Note - IMPORTANT!

If you've been messing with Raspberry Pi hardware for a while, you'll recognize those first few steps as common steps for updating the Pi.

Nearly every bit of "help" will point you at these steps as a "do this first" (keeping software up-to-date is always a good idea). The issue, though, is that this will sometimes install a new kernel version. When that happens, the new kernel will not have a module for your WiFi adapter. Not to worry: simply repeat the process from Building and Installing the WiFi Module after a new kernel comes down and you'll be back up and running.

Several months ago I purchased a Maker Select 2.  I believe my quote, most recently, was “It’s been a few months and the 3D printer is still the coolest thing I’ve ever owned.”  It’s also, sometimes, one of the most frustrating.

My current project is printing a multi-extruder printer (aiming for 4, but starting with 2) using a mash-up of a few different designs and I’m working on a Bowden extruder.  Since I had the need to print some very strong parts for another project, I picked up some PC-Plus after a bit of research.

This stuff is stronger than I’d imagined

Since I’ve had, now, four failed prints with this material, I’ve had an opportunity to test the physical properties.  My tests indicate the most optimistic of the marketing materials is spot on.  My PLA+ extruder body was able to be cracked pretty easily with a rubber mallet on my cement basement floor.  The ABS and Nylon parts were pretty solid but one of the components was designed in such a way that the flexibility of those filaments was going to be a problem. 

This stuff was hard to break with a full-on metal hammer.  It’s far less flexible than ABS or Nylon and the point it which it will flex is (in my unscientific estimation) about twice the pressure it takes to completely snap a PLA print.  I’ll admit, it was kind of fun hammering the crap out of the part seeing how hard I’d have to hit it to get it to crack.  About the only bad thing I can say is that it did dent pretty well but it dented at well beyond the point other parts would have broken.

This material is the stuff that profanity is made out of

I’ve yet to run into a filament that is more difficult to print properly with.  I’ve printed with PETT, PETG, T-Glase, ABS, PLA, PLA+.  It’s safe to say that it takes all of the difficulties of each of these and combines them into one magnificent package.  It’s very temperamental with regard to moisture as evidenced by the fact that it shipped in a vacuum sealed pack with a zip-lock seal for easy re-packing.  Luckily we run the air conditioner here like it’s the arctic.

It curls.  No, I mean, like 80s perm psychotic curls.  They used to ship it with a square of BuildTak.  The manual and nearly everywhere you read says it is *required*.  Thankfully, it’s not if you’re creative.

To get that strength, you need to run your hot end at 260 degrees or higher (that’s as high as the Maker Select 2 goes, so that’s what I’m stuck with) and you need to print slowly (details below).

The BuildTak Option

The Maker Select v2 shipped with a BuildTak clone of some kind attached to the metal heated bed.  I say “Of Some Kind” because this was one of the first things I removed from the printer since the PLA and Nylon I was printing with seemed to just bounce off of the surface of whatever this 3M product was.  After trying a few things that worked well for me in the past, I gave up and purchased 3 sheets of BuildTak.

Let me just say: I hate this stuff.  Perhaps that’s strong sentiment borne out of hours of frustration with this filament more than it is a scathing rebuke of BuildTak, but I’ll never buy it again. 

The first problem is that it works a little too well.  PC-Plus sticks to it like super glue and removing the part rips the surface off of the BuildTak.  It’s difficult enough getting the bed leveled perfectly to the factory recommendations but now you have to figure out just how higher you need to level it in order to get the part to stick properly, but not too well.  That’s assuming the BuildTak doesn’t just pull itself right off of the glass due to the heated bed weakening the adhesive.  Since I purchased the 127mm by 127mm sheets, I was printing the part right on the edge of the BuildTak and that’s exactly what happened to my second print. 

Second, and this might be a matter of me improperly cleaning the surface, but I was only able to use a non-ripped sheet twice.  After that, it simply stopped sticking no matter how close I printed. 

Third, geez this stuff is expensive!  Three of those tiny sheets was almost $10.00.  The idea that I’d get about 6 prints for that price didn’t sit well with me.

Lastly, I prefer to print directly on the glass because it makes the part look nice.  BuildTak has a rough surface and it shows up in the finished product.  That wasn’t so important for these parts (just looking at my printer with gray, green, clear, pink (!) and black parts indicates I don’t care what it looks like, I just want it to be durable and functional).

(Mostly) Ignoring the Manual

I’ll be the first to say that much of the manual’s recommendations worked fine except for the 0.33mm gap between the raft and the part (which resulted in a “3D printed turd” stuck to the hot end since it wouldn’t adhere to the part below).  I’d imagine part of that had to do with the fact that I can’t get it up to a higher temperature with this printer.

I really hate printing rafts.  Watching the filament burn down as it drops a surface on top of a surface that should be sticking already only to throw that part in the trash (or if it’s ABS, store it to make more glue) is wasteful.  Then there’s separating the part from the raft, which, since I rarely print rafts, I haven’t quite gotten right yet.  It’s either sticking so hard that I have to risk breaking the part to remove it or it fails to stick at all.

I was able to get it to stick perfectly, though by throwing out most of the recommendations and using a few settings that I had used with T-Glase and other finicky materials.

First, clean the hell out of your bed (91% alcohol does the trick).  Level your bed to the factory recommendations and make sure it’s absolutely perfect.

Heat up the extruder to 260 and clean any filament from the last seven failed prints off of the hot end so they don’t become a magnet for the stuff it’s already laid down.  This stuff sticks well to virtually nothing except for itself and while printing, if you get any strings, they’ll gob up and start removing portions you’ve already printed.

Heat up the bed to 90 degrees and apply a nice layer of Elmer’s Glue Stick.  Follow that up with a reasonable amount of ABS Glue (google it, it’s easy to make).  Let everything dry.

I used a 0.1mm gap on the raft when I printed with a raft (I’ve not had to since I cracked the formula for getting this to print properly).  Slow your printing down.  I went to 40mm/s with 20mm/s for the bottom layer and outer layer.  I also stuck with a 40% fill, though this was more because the part required it.  I also used four solid layers top, bottom and sides.  It may be overkill on that, but several forum posts recommended it so I started with those settings.

If your printer goes higher than 260 degrees, try going higher.  I had layer adhesion issues under 260 but still occasionally ran into small sections that didn’t adhere properly at that temperature.  That bit about making sure the head is clean is very important.  Every one of my layer adhesion issues occurred because the head picked up a string, which picked up small bits of printed material as it went along until it got large enough to get snagged somewhere in the printed body and was deposited, causing the bed to sink slightly as the head passed over.  This resulted in a small gap in a spot on the print.  Those small gaps are enough to make a very strong part pathetically vulnerable to snapping.  I resolved most of these issues over a few prints by slowing them down to the point where the head was adequately melting any smallish gobs as it passed over them and increasing the retraction by a factor of two.  Many forum posts recommended going as high as 290 degrees, which I’d imagine would allow print faster and let gravity resolve some of the issues when gobs appear but the printer I was using only allows me to get to 260 degrees.

For tall parts, consider taking a few of those Amazon boxes apart and making an enclosure.  This will keep the temperature consistently higher while printing and reduce curling.

Using these settings, and the ABS Glue plus Glue Stick, though, made the part stuck so hard to the glass I had to use a razor blade to separate it.  There was zero curling on a part that had several little finger-like points on it (and failed to print properly on anything else with this stuff) so I’m fairly convinced this is the way to go for me from now on.  YMMV

Things that didn’t work

3D printing is often about experimentation to get the easiest process to produce consistent prints with a material.  The only thing these attempts did was consistently produce curled parts or 3D printed turds.  All of these were attempted directly on glass.

Hairspray

As is common with ABS, hairspray seems to make the curling worse.  It will stick initially, but after several layers, it’ll start to curl upwards.  If you’re lucky, the print will stick somewhere and you might have a salvageable part if you don’t care about the looks and the curling occurs on part of it that doesn’t affect its performance.  I was printing an extruder so there’s very little of it that can be off.

Glue Stick (alone)

Initially it stuck and didn’t curl as much as the hairspray did.  This might have worked were the part much smaller but on the extruder body it failed after about the 20th layer, pulling completely off of the bed.  I tried this twice and I’m fairly certain it’s not a good solution.

Elmers and Water

Performed similarly but worse than the glue stick

BuildTak after Two Prints

The surface might as well have been covered in olive oil.

That 3M BuildTak like thing that Maker Select ships with

They gave me an extra one which I put in a box since the one that it came with performed so poorly but I thought I’d give it a shot.  It worked as well as it ever has which is to say, not at all.

ABS Glue (alone)

I’ve read some forum posts from people claiming they simply applied ABS glue to the glass and were printing successfully with other materials.  Perhaps mine is too diluted or I’ve done something wrong, but it’s never worked for me even with ABS filament.  This was no exception.

I also tried mixing a few variants of these, especially the hairspray since even though it seems to encourage more curling, if it gets a good stick initially, it won’t budge with other filaments I’ve tried.  The only mix that worked was Glue Stick and ABS Glue, though to be fair, I didn’t try Elmers+Water and ABS Glue and I have a feeling this would have worked.  It’s just less convenient waiting on the Elmers to get tacky enough to begin printing.

I’d love to know what anyone else has tried or if there’s a better method/something I’m missing but it’s a relatively new filament, has lots of pain points and isn’t experimented with enough to find great information from the forums so I’ve been at a loss for any solid help (which was one of the motivations for getting off my butt and writing this).  If you’ve had success with this material using other tricks, please comment!

Many thanks!

Adventures in Bed Bugs

Sheraton Lake Beuna Vista Hotel, Orlando, Florida

Working with the hotel

Lesson 1: FedEx doesn't mean fast, anymore

Lesson 2: Expect others to treat your stuff with little respect

Customer Service in an Age Without Humans

Supervisors In Name Only

Twitter

Contrast with Another Property

Problem

What's happening

The Fix

Problem

Why It Doesn't Work

The Fix

net localgroup administrators YOURDOMAIN\youraccount /ADD

Overview

I’m giving a talk remotely today to the DFW Unified Communications Users Group on Skype for Business development and will be showing some of the code related to my simple Raspberry Pi LED Status tool.  The code behind the project was thrown together in under an hour and really isn’t a great example of best practices, however, it’s a good place to get an idea about how to do some basic development with the Skype for Business Client.

In this post, I’ll go through some of the code used for that project.  This post is based on the initial commit, so make sure you’re referencing that in case I’ve got the bug and decided to update it.

The Lync Client SDK

Yes, Lync.  Unfortunately, it wasn’t updated for the Skype for Business release, however, it works fine with the latest client.  You’ll need to be running the latest Lync 2013 client or Skype for Business client in order to use solutions developed with Lync Client SDK, however, you require no other components to actually run the program—it’s all included with the client.

References

Download the Lync Client SDK (search, I won’t provide a link due to Link Rot regularly wiping them out) and install it.

You’ll need to reference Microsoft.Lync.Model.dll and Microsoft.Lync.Utilities.dll.  They’ll be located in the Office15 folder…somewhere.

A Note about Multi-threaded Code

The Lync Client SDK provides a set of APIs for interacting with the client using multi-threaded code.  This means that you’re going to have to be cautious with certain operations.  Many things you’ll want to work with are fired on events in a background thread and all of the perils of multi-threaded programming will apply.  You’ll see a few things I’ve done to combat this, but the code in the initial commit is by no means fully audited to ensure thread-safety and a lot can go wrong in this area!

Interacting With the Lync Client

In the constructor for the Monitor class, you’ll see everything you need in order to connect to and interact with the Lync client.

// Connect to the current Lync Client
m_client = LyncClient.GetClient();
var contact = m_client.Self.Contact;
if (contact == null) // There's better ways to do this, but this works in a dirty implementation
{
 SimpleLogger.Log("Client is not logged in - Setting Offline", m_gpioController.AllOff());
 throw new InvalidOperationException("Client must be logged in before starting the monitor");
}
// Create a subscription and subscribe to our own contact object
contact.ContactInformationChanged += ContactOnContactInformationChanged;
var contactSubscription = m_client.ContactManager.CreateSubscription();
contactSubscription.Contacts.Add(contact);

The connection occurs at LyncClient.GetClient().  This method will throw if the client is not launched.  I chose not to catch that exception since it effectively renders the application dead.

From there, I subscribe to the ContactInformationChanged event and add a subscription to my local contact (m_client.Self.Contact).  This ensures that when any property of my contact changes, the method “ContactOnContactInformationChanged” will fire (on a background thread).

When Contact Information Changes

I have a pretty simple event handler defined for that:

private void ContactOnContactInformationChanged(object sender, ContactInformationChangedEventArgs e)
{
            if (e.ChangedContactInformation.Contains(ContactInformationType.Availability))
                SetLedState();
}

var contact = m_client.Self.Contact;
if (contact == null)
 return;
object availabilityId = contact.GetContactInformation(ContactInformationType.Availability);
var availability = (ContactAvailability) availabilityId;                

What’s up With All The Interlocked Stuff in GpioController

Remember all of that multi-threaded nonsense I mentioned earlier?  I implemented Blinking using a Timer, which is a class that lets you fire off a method on a background thread at a given interval.  Because of this, and because our status changes come on an event handler that fires on a background thread, there’s a few members of our GpioController that could be modified by more than one thread.

Normally I’d use a lock, and that would be fine here, as well, but the requirements for this application were simply to ensure that the variable being read is the latest copy in memory.  Lighter weight patterns work fine in this scenario and I use them enough that I simply go there when the kind of variable fits well.

In addition, the GpioController is disposable because that timer needs to be cleaned up.  The Dispose pattern that’s commonly used is not thread-safe.  I’ve included a class in the Patterns class that handles it in a thread-safe manner.  There’s not going to be a case in the application, as it’s currently written, where the GpioController will be disposed on anything but the main UI thread, however, I anticipate that future changes will introduce this and I’d rather not fix that later.  For the most part, you can ignore that class.  If you’ve not done a lot with the Interlocked static methods, you’ll find it to be confusing.

The GpioController keeps a “current LED state” in a flags enum.  Enums are effectively syntactical sugar over ints with constant fields.  I developed a NuGet package that contains a number of helpers for flags enums and includes a wrapper to provide “safe” access to an enum from multiple threads, providing guarantees that when the “Value” member is set, any getters on another thread will always receive the latest value instead of what happens to be in the cache for the core your code is executing on.

The only other place that needed protection was around the blinking feature.  To protect that, I used an int variable in place of a bool and Interlocked to ensure it’s updated and read properly.  Let’s look at that more closely:

// Check that the light is actually blinking and set it to NOT blinking in a threadsafe manner
if (Interlocked.CompareExchange(ref m_isBlinking, 0, 1) == 1)
{
 m_timer.Change(Timeout.Infinite, -1);
 Thread.Sleep(m_currentBlinkInterval.Milliseconds * 2);
}

The Interlocked bit serves two purposes. First, it ensures that the value of m_isBlinking is both read and written to in a manner that guarantees the latest value will be retrieved. It also ensures that if two threads hit this code at nearly exactly the same time, only one will execute the statements in the if block, modifying our timer and incurring the penalty from sleep.

What the code is actually doing is saying "read what is actually stored in m_isBlinking" and if it's set to "1", set it to "0". Then, check the value that was previously stored in m_isBlinking and continue into the body of the "if" only if the previous value of m_isBlinking was "1".

Summary

The code is pretty thoroughly commented, so I’d encourage you to look at each of the methods in each of the classes for more information.  You’ll see I’ve put an event handler in for detecting power events, which is a good idea when your application is going to run on a laptop/tablet.  It’ll catch the “Suspend” event and let you do anything you need to do to clean up before suspending.  Beware that this code should be simple, since the machine can hit suspend before your code is finished executing.  I use it to turn the LEDs off and catch the Resume to ensure the application doesn’t crash when coming back up (the Lync Client API will fire events before you can actually get at the data contained within the Contact class, but it’s easy to detect and prevent while resuming).

Overview

I work from home full time and at Modality, we use Skype for Business for all of our conference calls and other communications needs.

Being a work from home employee with children, particularly one who doesn’t like to lock himself in his office, I wanted a way to let my family know when I cannot be interrupted.  And being a geek with geek kids, what better way to solve the problem than with legos and a Raspberry Pi?

Items Required

A Raspberry Pi – I used a Model B (non-Plus).  Any Raspberry Pi model should work provided you can get it on the network somehow.  These cost about USD $35.00.  This would likely work with a Banana Pro, as well (about $45.00) and using that would give you wireless out-of-the-box.

A Network Connection – I purchased a RealTek WiFi+Bluetooth Adapter.  Personally, I wouldn’t recommend this product since it required compiling a driver since the kernel didn’t have native support for it.  Refer to the compatibility list for the least effort in getting WiFi working.  If you’re using the Banana Pro, you won’t need to worry about this.

3 LEDs – Green, Yellow, Red if you want to keep with the colors that Skype for Business uses.

3 270-330 ohm resistors – one for each LED.

Wires and a Breadboard – or some other way to connect them to the GPIO pins.

Legos to build an ugly case (optional).

An SD card that works with the platform you’re using (I recommend sticking with 16GB to give you space to play around).

Setting up the Software

I won’t go into the full setup instructions for a Raspberry Pi, but you’ll want to get it up and running.  I used the DietPi operating system, but this will work with Raspbian and I’d recommend using the NOOBS tool to install if you’ve not done an RPi install before.

You’ll need WebIOPi in order to interact with the GPIO via the web.  This came preinstalled with DietPi.

Update the Raspberry Pi OS

I did the installation with the latest bits as of the writing of this post and it’s always a good idea to be up-to-date.  You’ll want to either connect via Secure Shell (PuTTY works well for this on Windows) or plug your RPi into a display and keyboard to get a shell.  Once you’ve gotten a shell up, run these commands (and grab yourself a cup of coffee).

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo rpi-update

Configure WebIOPi

The GPIO pins aren’t configured the way we need them to be, yet, so we’ll edit the WebIOPi configuration to get that going.

$ sudo nano /etc/webiopi/config

Nano is a simple console text editor.  Locate the heading labeled [GPIO] (hint: CTRL+W can be used to find text in Nano, however, GPIO should be at the top).  Anything with a “#” in front of it is ignored (a comment). The configuration under GPIO is “PIN = DIRECTION STATE”.  If you have 17, 18 and 27 already setup in some way, you’ll want to modify those lines.  If they are not configured at all, you can simply add the following lines.

17 = OUT 0
18 = OUT 0
27 = OUT 0

Locate the [HTTP] heading and make sure it is setup as follows

[HTTP]
# HTTP Server configuration
enabled = true
port = 8000

# File containing sha256(base64("user:password"))
# Use webiopi-passwd command to generate it
passwd-file = /etc/webiopi/passwd

# Change login prompt message
prompt = "WebIOPi"

Locate the [REST] heading and make sure it is setup as follows

[REST]
# By default, REST API allows to GET/POST on all GPIOs
# Use gpio-export to limit GPIO available through REST API
gpio-export = 17, 18, 27

# Uncomment to forbid changing GPIO values
#gpio-post-value = false

# Uncomment to forbid changing GPIO functions
#gpio-post-function = false

# Uncomment to disable automatic device mapping
#device-mapping = false

The rest should be fine as is.  Hit CTRL+X and choose “Yes” to save the file.  Finally, we’ll setup a user/password that will let us authenticate.

sudo webiopi-passwd

Wiring it up

The wiring for the project is pretty simple.  Here’s a diagram that explains how to set everything up.  Make sure your resistors are wired correctly! I’m not an EE guy, but in my reading the warnings indicated that failing to install resistors or using the wrong resistors will result in damaging the Raspberry Pi.

It’s also important to note that LEDs are one-way devices.  If you install them backward you won’t break anything, but they won’t light up (which is the first thing to check if your tests don’t work).

That’s the GPIO arrangement of a B (non plus version).

That’s it, you’re ready for the code.

On Your Windows Box

The code is client-side, so it won’t work if your PC is turned off or asleep, but it’s the easiest way to do it and doesn’t require administrator privileges on the Skype for Business server as would be if we’d done this with the Unified Communications Managed API (though it can be done with a bit more work that way).

You can get the source code from the GitHub Repo.  I’ll provide a compiled version, but because the software is very hastily designed, you’ll need to build it yourself.  You can download Visual Studio 2015 Community Edition to compile the project.

Running the Application

Hit Win+R and type CMD.  Go to the folder that the application compiled to (usually ProjectName\bin\Debug) and run:

Cs-WebIoPi <IPADDRESS> <PORT> <USERID> <PASSWORD> --test

If you’ve configured it following this gude, you’ll put “8000” for the port.  When started in “Test” mode, it’ll blink all of the LEDs and cycle through each one so that you can verify your wiring.  Fix any wiring issues and when you’re all set, run it with the same command above but without the “test”.

UPDATE: The HubPiWi Blue includes this chipset and the instructions for that also work with the USB dongle. I've provided an updated set of instructions here that are a bit simpler and are targetted at Raspbian Jessie. You should use those, instead.

I recently started getting my second RPi setup, only on this one I wanted to use a dual WiFi/Bluetooth USB dongle.  I picked a device based on the Realtek RTL8723BU after reading a few posts indicating success.  Unfortunately, it doesn’t work “out-of-the-box” with Raspbian Wheezy on Kernel 4.1.13.

Before we Proceed

I’ve been tinkering with RPi’s for a little bit, but I’m by no means an expert.  If there are obvious problems with the steps I’m doing here, kick me a comment and I’ll correct them.  This worked for me.  It might not work for you.  I’m assuming you’re on 4.1.13+ installed via NOOBS and you haven’t added/changed much up to this point.  If you have, some of the steps (like removing the build/src folder) might already have things in them that you don’t want to lose, so exercise some discretion before running each command.  And, of course, this comes with NO WARRANTY expressed or implied – use at your own risk, my friend.

What You’ll Need

Besides the hardware, you’ll need a wired or working wireless connection (using a device other than the one we’re building a module for).

If you’ve done the Raspbian install from NOOBS, you should have all of the necessary packages required to build the driver.  If you haven’t, you might need to apt-get build-essential and others that I’m not entirely sure of.

Overview

We’ll update the system, clone the git repo for the driver, download the kernel source, set up the build environment, and build the driver.

I’ll also provide the steps I took to get the miserable thing to actually work!

Let’s Get To It

To get this going, you’ll need the kernel source and it’s probably a good idea to make sure you’re all up to date.

apt-get update
apt-get upgrade dist-upgrade
reboot

You can go run some errands during the dist-upgrade, it took over an hour for me.

To start, get the latest drivers

cd ~/
git clone https://github.com/lwfinger/rtl8723bu.git

If you’ve installed from NOOBS (as I did), at this point, you’re not going to be able to make the driver.  You need the kernel headers for the kernel you’re running.  Normally, apt-get install linux-headers or something along those lines would do the trick.  Not this time.

Unfortunately, when I wrote this, the linux headers for the version of the kernel used by Raspbian, 4.1.13+, were not available from aptitude.  After some searching, I found a downloadable debian package that works.

wget https://www.niksula.hut.fi/~mhiienka/Rpi/linux-headers-rpi/linux-headers-4.1.13%2B_4.1.13%2B-2_armhf.deb
sudo dpkg –i ./linux-headers-4.1.13+-2_armhf.deb

If you lack one or more of the dependencies, install them with apt-get install <dependency>, then apt-get –f install which will finish up the installation of the headers.

Modifying the Makefile for Raspbian

We’ll need to tweak the Makefile for the driver to build properly.  I’m not sure that all of this needs to be added – I grabbed it from several google searches.  But, hey, it worked, so here’s what I changed.

nano Makefile

Hit CTRL+W and type “CONFIG_PLATFORM_I386_PC =” and hit Enter.  Set it to “n”. Add a line below it and type “CONFIG_RASPBIAN = y”.

Hit CTRL+W and type “ifeq ($(CONFIG_BT_COEXIST)” and hit Enter.  Insert the following text above that line.

ifeq ($(CONFIG_RASPBIAN), y)
EXTRA_CFLAGS += -DCONFIG_LITTLE_ENDIAN
EXTRA_CFLAGS += -DCONFIG_IOCTL_CFG80211
EXTRA_CFLAGS += -DRTW_USE_CFG80211_STA_EVENT # only enable when kernel >= 3.2
EXTRA_CFLAGS += -DCONFIG_P2P_IPS
ARCH := arm
CROSS_COMPILE := arm-linux-gnueabihf-
KVER := $(shell uname -r)
KSRC ?= /lib/modules/$(KVER)/build
MODULE_NAME := 8723bu
MODDESTDIR := /lib/modules/$(KVER)/kernel/drivers/net/wireless/
endif

Hit CTRL+X then “Y” to save the file.

Build It

sudo –i
cd /home/pi/rtl8723bu
make && make install

That part took almost an hour on my RPi Model B.

Making It Work

Well, at this point, you can just reboot.  But if you want to test prior to rebooting, run the following:

insmod 8723bu.ko
ifconfig

You should now see “wlan0” among the network adapters!

So you’ve upgraded your WRT1900AC router (or other similarly designed router) to DD-WRT and it’s humming along fine, or maybe you’ve done the upgrade and then followed it up with a 30-30-30 reset and suddenly you’re back to the original Linksys Firmware!  Gah, lousy downgrading $#!+!

What’s happening

Linksys routers used to be a popular choice for running DD-WRT back in the days when the vendors were far less happy with you replacing their buggy, insecure firmware with something open and customizable.  Rather than taking the approach of keeping you from replacing their firmware, lately they’ve gone the route of keeping you from breaking your device should you choose to hack around with DD-WRT.

They used to do this by providing a “failsafe” mode that provided an extremely limited, but “possible to fix” mode that would leave you carefully timing a TFTP upload during the first two seconds of boot (this still exists, I believe).  Many-a-panicked afternoons were spent in this home praying my $150 router didn’t just turn into a doorstop because of this.  They’ve gotten way better since.  Your flash memory is split into two partitions, only one of which has the currently running firmare.  The other has the last version of the firmware that you successfully installed.  When you upgrade, it replaces the unused partition and changes an NVRAM value to tell the bootloader to use the other partition for subsequent boots.

Hopefully no more TFTP adventures, but it comes at a small cost.  Should something bad enough happen, or should you do a “factory reset”, you’re likely going to end up booting the other partition – the one you were trying to get away from.

Making the install a little more Undo Proof

If you’ve followed the installation guides to the letter, you probably did what I did.  Upgraded, reboted and then did a 30-30-30 factory reset.  I’m not sure if it’s the timing of *when* you do the 30-30-30 or just doing the 30-30-30 that causes it, but the boot partition ends up flipping right back to the original firmware.

I think I ended up doing the 30-30-30 during the boot-up process into the new firmware which, I’m guessing, caused the boot to fail and reverted me back to the last version.  I’m honestly not sure, but after that happened, I simply skipped the 30-30-30 until I finished the next step.

Install DD-WRT … Twice

Yup.  Simply installing one SVN version out of date, then the latest SVN version (you might even be able to install the latest on both, but I didn’t try it), ensured that I had both partitions on DD-WRT.  After that, I did a factory reset through the web interface (which didn’t take me to the backup partition, incidentally) and I was ready to go with a fresh router that can’t fallback to the factory image.

This doesn’t solve everything, unfortunately, because there are aparently other reasons it may decide to toss you into the backup partition.  In my case, it looks like a failed boot might have caused it to revert the second and third times.  But once you have DD-WRT installed, you can drop to SSH and run nvram get bootpartition, and simply set it to the other one via nvram set bootpartition.  That’s a heck of a lot easier than redoing the upgrade during the rare times this might happen.