This paper is referring to the Zeta 1 version of NuPIC, which is not the version implemented in HTM.Java. Please read H is for Hierarchy for background.
If you have 8 sensors, I believe you’ll need to have at least 8 HTM models. In our current architecture, you can only choose one predicted field to make predictions for per model. So if you are attempting to create live predictions for each sensor on the device, you would need 8 models, one for each sensor stream. You might end up passing all 8 streams into each model, but only predicting on sensor stream for each model. Or you might end up sending only on sensor stream to each model (it depends on if sending all 8 streams to each model helps the prediction, you’ll have to experiment with that).
Also, some general notes about signal processing with HTM. You are not the first one to try this. 
Sample the data if the velocity is too fast
What rate does the device produce data? It may be too fast, in which case sampling is your friend. For example. we learned from a neurologist at the Fall 2014 hackathon that humans can identify an “pre-ictal” state in an EEG signal (a seizure is imminent) at a sampling rate of 100 Hz, but the EEG data stream itself is a massive amount of data, so very heavy sampling or aggregation of some kind is necessary to get a stream into the HTM.
A good rule of thumb for this is, if you (as a human) can identify different classifications in the data at the current sampling rate, the HTM will have better chance as well. I’ve found that it is generally better to sample or aggregate the data aggressively until the resulting signal is simple enough for you to see the pattern, but no simpler.
You might need to FFT
For extremely high-velocity data like EEG and sometimes EMG, you might want to apply an FFT to the data. This will expand your model space significantly, but it is one way to extract features that only exist in certain frequencies of the data. For a heavy metal example of this, you can see this video and my nupic.critic project:
Figure out how to use “Anomaly Likelihood”
In the NuPIC (python) codebase, we have an Anomaly Likelihood algorithm that we use to massage the raw “anomaly score” coming out of our HTM systems. This algorithm exists in HTM.Java, but I don’t think it is integrated in any way with the Network API. We’ve found that using this post-process increases the value of the anomalies reported dramatically. Here’s some more details:
