The code that polls the device is logically part of your WCF service, not the host project. Whether the code physically resides in the WCF service project or a class library referenced by the WCF service project is personal preference.
Here's how I've done it.
I have a WCF CollectionService that is hosted in a Windows service. The CollectionService project obviously has a CollectionService class that implements the WCF-enabled ICollectionService interface, which is how clients interact with the CollectionService.
In this same project, I have a Collector class that has a private constructor, preventing instances of the class from being created outside the scope of the class. The class has a private static list of Collectors that it maintains. The class also has two static functions - Start() and Stop().
When a client wants to start a Collector, it invokes the Start() operation of the CollectionService. This CollectionService, in turn, calls the static Collector.Start() function which creates a Collector instance and stores it in the static list of Collectors. When a client wishes to stop the Collector, it invokes the Stop() operation of the CollectionService, which translates into a call to the static Collector.Stop() function, stopping the Collector and removing it from the list.
When a Collector is instantiated, it starts a new thread that begins collecting data and making it available to interested parties. The new thread is the key. Otherwise, the Collector instance would simply sit in the list of Collectors and not do anything.
Because I'm dealing with threads, obviously I have to deal with synchronization issues, like synchronizing access to the static list of Collectors. I don't want a client trying to start a Collector while someone else is trying to shut it down.
That's it in a nutshell.
If you have not created the Windows service yet, here are two SO posts that I've written giving step-by-step instructions for how to do it.
The first link basically gets you to the service; the second shows how to install/uninstall it without requiring InstallUtil.
I hope this helps.
EDIT
If only one Controller can be running, then subsequent calls to start a Controller could simply be ignored, possibly with a return message indicating it is already running.
If you want multiple clients to access the data from the Controller, this is pretty straightforward. You simply need to maintain a list of subscribers. The Controller simply sends the data to any subscribers in the list.
Such a Publish-Subscribe framework in WCF already exists. You can read the details here:
What You Need To Know About One-Way Calls, Callbacks, And Events
You can download this framework for free from Juval Lowy's website, IDesign.net. I am using this concept to signal CollectionService events to interested parties. I expect you can use the same concept to provide data to multiple clients.