Welcome to the tenth instalment of Dive Into JeeNodes. Let’s show real-time data!
With HouseMon running on the Raspberry Pi, we can start to think how to show incoming data on a web page. The following approach is the most basic one possible: get the received packets into Node.js, i.e. the RPi server, “publish” each through a WebSocket connection to any attached client, and figure out how to get the received value onto the web page.
Let’s start from the back. This is the web page we’ll be setting up:
Note that I’m running the server on my Mac in these screen shots, hence the “localhost” in the URL, but this will work in exactly the same way with HouseMon running on the RPi. Note also that the following three files are already included in HouseMon – they are just shown to explain what is going on.
That page is produced by a file called client/templates/demo.jade, with this contents:
.row
.twelve.columns
h1 Demo
h3 {{value}}
Lots of stuff going on behind the scenes, clearly, but this is what Jade looks like with Foundation CSS, and how AngularJS ties a dynamic “value” variable into a web page. It’s sort of like a template (but not quite, due to the two-way binding nature of all this).
The second piece of the puzzle is a file called client/code/modules/demo.coffee:
module.exports = (ng) -> ng.controller 'DemoCtrl', [ '$scope', ($scope) -> $scope.$on 'ss-demo', (event, value) -> $scope.value = value ]
This one is a bit dense: it defines an AngularJS “controller” which will listen to incoming “ss-demo” events, and set the “value” variable we referred to in that Jade file above.
The last code we need, is in a file called briqs/demo.coffee. It defines this “Briq”:
exports.info = name: 'demo' description: 'This demo briq is used by the "Dive Into JeeNodes" series' menus: [ title: 'Demo' controller: 'DemoCtrl' ] state = require '../server/state' ss = require 'socketstream' exports.factory = class constructor: -> state.on 'rf12.packet', packetListener destroy: -> state.off 'rf12.packet', packetListener packetListener = (packet, ainfo) -> if packet.id is 1 and packet.group is 100 value = packet.buffer[1] ss.api.publish.all 'ss-demo', value
A “Briq” is something which can be installed at run time in HouseMon. Once installed, that file above will run on the server side. Briqs are a new mechanism I came up with (it’s no rocket science, but at least the name is new), and it’s still very early days. Once I figure out how, briqs will be turned into self-contained directories with the above three source files all in one place. For now, each of those files needs to be placed in a very specific location, for SocketStream to be able to find and use these files.
So how do we “install” the above demo in HouseMon, you may ask…
Easy. Go to the “Admin” page in HouseMon, via the Admin tab in the upper right corner:
No installed briqs yet, but you can see some briqs which are currently included in HouseMon in the second list. We need to install two briqs: one to set up that demo page, and one to connect to the JeeLink.
Click on the “demo” entry in the list to get this (whoops, I already installed everything):
Once you’ve clicked on install, you’ll see a new “Demo” tab appear in the upper right. It won’t do much, though, because we’re not receiving any data yet!
Click on the “rf12demo” entry, and fill in the serial port of your JeeLink. On the RPi, it’ll most probably be “/dev/ttyUSB0”, so just enter “ttyUSB0”. Then click install.
Go to the “Demo” page, and if your JeeNode is powered up, you’ll see an updating value.
Bingo – you’re looking at data coming from your Wireless Sensor Network in real-time.
(This series of posts is also available from the Dive Into JeeNodes page on the Café wiki.)
Wow! I actually got some values to display, the problem is that I’ve not got a Jeelink, yet, so I’m using a Jeenode and serial/USB converter and picking up packets from a couple of devices transmitting temp and battery data.
I couldn’t see any data on the web page but I could see the data in the Putty window, so I looked at the briqs/coffe.demo file and changed the group to match mine (212) and the buffer to match some changing data in my packet and it worked.
Brilliant. thanks for starting this tutorial, still a lot to try and take in but, baby steps!
One thing I’ve noticed is that whilst the Housemon is running the mouse in the RPi desktop is really unresponsive, is there a conflict?
I’ve seen slow mouse response on several occasions, not just HouseMon – it’s a single-core processor, and I suspect that SD card I/O completely blocks the system at times. You might want to try a different brand SD card, but we may in fact be pushing some limits here – for HouseMon, I consider the RPi more as an embedded server – maybe with an attached touch LCD one day. Definitely not for simultaneous web browsing etc.
I usually use it without a monitor, using putty but I wanted to edit the demo.coffe and it was easier done in the desktop environment.
I’m not sure its loading though because even when I’ve stopped housemon I have to remove and reinsert the wireless mouse receiver to get the mouse working properly again, anyway not a big problem.
Maybe it’s FTDI funniness, see https://git.jeelabs.org/housemon/issues/7