But of course, there are new problems – such as our old way of getting kernel headers doesn’t seem to work. Why the foundation have rolled their own kernel and then made it so hard for people to get kernel headers is beyond me, surely they want people to hack on the thing??!! If anyone can explain this please leave a comment – it seems like an obvious gaff, and a longstanding one too. The Pi forums are full of people struggling with this, as they have been since 2012! I just don’t get why they have done this, it makes my life harder and what does it accomplish? Grrrrrr…

Anyway, I’ve been searching and experimenting and I think I’ve got a new way to get the headers, so that we can compile the drivers for various things such as the rfm12b driver. It’s as simple as adding ‘2’ to the install of linux-image-rpi-rpfv and linux-headers-rpi-rpfv to make them linux-image-rpi2-rpfv and linux-headers-rpi2-rpfv.

Also, the new device-tree may cause issues – using the raspi-config utility handles this automagically – see here for an excellent explanation of the issue.

The post Headaches whilst upgrading to Raspberry Pi 2 appeared first on layer zero labs.

Suppose you want to log users out automatically if they haven’t used your app for half an hour. You can do this with the following settings:

var idleTimeoutSeconds = 1800;

app.use(session({
resave: true,
cookie: {
maxAge: idleTimeoutSeconds * 1000,
},
rolling: true,

// … the rest of your options

}));

The rolling option is documented here but there’s a gotcha which is not mentioned: you have to set resave to true. It’s not obvious why this would be the case, since even without resave the session data is saved on change, and the rolling option appears to produce a change in the session upon every request. But without resave: true, I found that the session was expiring after the given time regardless of activity.

The post Idle Timeout in Express appeared first on layer zero labs.

The basic attributes of these modules are as follows:

Modules	Dimensions	Picture	Pinout	Antenna	GPIO	Notes
ESP-01	14.3mmx24.8mm			PCB Antenna	GPIO0/2/16	Multiple Variants Exist! Most common module. This version may be known as V090 or V091
ESP-02	14.2mmx14.7mm			U-FL connector	GPIO0/2/15	Multiple Variants Exist!
ESP-03	17.4mmx12.2mm			Ceramic Antenna	GPIO0/2/12/13/14/15/16	Most popular in esp8266.com poll
ESP-04	14.7mmx12.1mm			none	GPIO0/2/12/13/14/15/16
ESP-05	14.2mmx14.2mm			U-FL connector	NONE	Multiple Variants Exist!
ESP-06	14.2mmx14.7mm			None	GPIO0/2/12/13/14/15/16	Metal shield claims FCC
ESP-07	22mmx16mm			Ceramic Antenna & U-FL connector	GPIO0/2/4/5/12/13/14/15/16	Multiple Variants Exist! Metal shield claims FCC
ESP-08	17mmx16mm			None	GPIO0/2/12/13/14/15/16	Metal shield claims FCC
ESP-09	10mmx10mm			None	GPIO0/2/12/13/14/15	1MB Flash memory
ESP-10	14.2mmx10mm			None	None
ESP-11	19.3mmx13mm			Ceramic Antenna	GPIO0/1
ESP-12	24mmx16mm			PCB Antenna	ADC + GPIO0/2/4/5/12/13/14/15/16	Metal shield claims FCC
DWA8	17mmx27.1mm			PCB Antenna	ADC + GPIO0/2/12/13/14/15/16

ESP-01 Variants:

Tinhead of the esp8266.com community contributed info about an older variant using the ESP8266 rather than ESP8266EX (may also be referred to as v080):

ESP-02 Variants:

TuxFanGKR of the esp8266.com community reported that a pinout variant had made him let the magic smoke out! And a third variant (confusingly named ESP-02 version 2) has been spotted here. Pinout is of TuxFanGKR’s variant – photo of ‘version 2’.

ESP-05 Variants:

A fifth pin has been added to the ESP-05 module carrying reset, thanks to esp8266.com contributors gbit and Didier9 for this info:

ESP-07 Variants:

A variant of the ESP-07 has been reported with 2 extra connections (one of them ADC) by mvdlande on the esp8266.com forum:

References:
ESP8266EX Pinout
Hardware guide

Any corrections, omissions or improvements? Please leave a comment!
Thanks to comment below, pinout of module ESP-11 has been corrected.

The post ESP8266 modules hardware guide – gotta catch ’em all! appeared first on layer zero labs.

Here are the slides for the presentation we just gave. And here’s our alternative translation of the heart sutra (now on Github!)

Avalokitesvara the Origin Mistress
when debugging deeply the Undefined Paramita
perceives that all of the log files are empty
and is saved from all suffering and distress.

Oh Javascript Programmer,
objects do not differ from null,
null is merely a kind of object.
Undefined is a function,
and all functions are undefined.
The same is true of strings,
integers, arrays, truth or falsehood.

Programmer,
the features of Javascript are also its bugs;
never released and never abandoned,
neither supported or unsupported,
neither maintained nor deprecated.
Therefore, in Javascript no bugs, features,
commits, reverts, authors.

No types, no classes, no entities, no attributes,
no private, no public, no package, no friends,
no runtime context;
no state or scope
and so forth until no realm of computation.

No errors and also no catching of errors,
and so forth until no breaking or crashing
and no end of crashing and breaking.

Nothing synchronous, nor asyncronous,
no pushing no popping, no heap no stack
also no returning with nothing to return.

The Origin Mistress accepts the Undefined Paramita
and logic is no hindrance.
without any logic no programs exist.
Realising this, good code is created.
(So good, it even runs in Internet Explorer.)

In the three browsers
all Programs depend on Undefined Parameters,
on Max that is less than Min, and the Number that Not a Number.

Therefore know that the Undefined Parameter
is the great transcendent mantra,
is the great bright mantra,
is the utmost mantra,
is the supreme mantra
which is able to relieve all suffering
and is truthy, insofar as it is not falsey.

So proclaim the Undefined Paramita mantra,
proclaim the mantra which says:
Object does not support this property or method.

The post Squatconf Presentation appeared first on layer zero labs.

So after booting from the card, I ssh’d into it – as root with a password of ‘raspberry’. I change this immediately:
passwd

set the locale, timezone and keyboard:
dpkg-reconfigure locales
echo 'Europe/London'>/etc/timezone && dpkg-reconfigure -f noninteractice tzdata
dpkg-reconfigure console-data

Now some updates:
rpi-update
aptitude update
aptitude upgrade -y
aptitude install sudo

Follow the code in the first post here: http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=64843 for a recent copy of fsck.vfat to fix the errors on the boot partition.

I prefer to work as a normal user so I’ll create one
adduser pi

Answering various questions about the new user pi got me a home directory, then on to joining a few extra groups (not sure if all are needed, tbh!):
usermod -a -G pi,adm,dialout,cdrom,sudo,audio,video,plugdev,games,users,netdev pi

Finally change the hostname to ‘whateveryoucallyoursystem’ by changing the hostname and /etc/hosts files:
echo '127.0.1.1 whateveryoucallyoursystem'>>/etc/hosts
echo 'whateveryoucallyoursystem'>/etc/hostname

and reboot.

Now we can log in as normal user pi!

The post thethingbox.io image – testing and extending appeared first on layer zero labs.

Our goal is to allow others to write applications to use data from our systems for their own purposes, as well as reusing our API and apps themselves. The API is documented using the fabulous Swagger specification – we used the swagger-node-express because we like node. Swagger provides great looking documentation of the API as well as full details of the responses and error codes, but wait – there’s more. It’s not documentation in the usual sense, it’s an interface to the API itself. Thus it provides a really easy way to test the API out and get real data back, complete with headers and response codes – everything you need to develop apps against it.

Our system uses the seriously hard-core Cassandra database – even though we can’t quite justify it based on our data-needs today! In fact when we asked a support question on the Cassandra IRC channel we were told that a mere two box cluster was ‘not a typical deployment’! But it fits our requirements in terms of storing time-series data – and we have great hopes that soon we’ll be needing racks of boxes across several continents. If it’s good enough for GitHub and CERN then it’s good enough for us.

Speaking of GitHub, all our code are belong to you – this means it’s released under the GPL v2 and you’re welcome (and obligated!) to use it, abuse it, improve it and then return those improvements back to the common pot.

As well as all of this, we’ve also written an app that uses our API to present a simple web form allowing for the download of data in csv format. You can try out our download app here – again we really do appreciate your feedback (it’s the best way to get better).

Node express allowed us to get this simple web-app up and running with the minimum of fuss and maximum of effect. We’re hoping to follow this up with a graphing app very soon – watch this space.

We’ll be showcasing the system and its associated API , apps and dashboard at the very wonderful Wuthering Bytes open hardware festival in Hebden Bridge – if you can possible be there – you must! As well as our talk/workshop there are dozens of great things happening from Sophie Wilson to space rocket launches and beyond!

The post Open aquaponics API, documented with Swagger and sample app appeared first on layer zero labs.

This sensor is probably the one I’m most proud of so far, all the elements came together really well despite having to hack the MinipH circuit in the literal sense!

The enclosure maketh the project

As soon as I had finished making this sensor, and put the lid on and stepped back, I was genuinely surprised and pleased with how much better the sensor suddenly seemed. Despite the fact that I knew exactly how much sweat and tears had been expended and all the clever details, even then, I was mostly impressed when the case went together!!

At first I was a bit disconcerted by this, I am constantly trying to see the ‘real substance’ of things, ideas and people, rather than just see the ‘surface’ details. And yet, even with a project of my own that I knew intimately, I was beguiled by the case.

So anyway, the case turned out to be the perfect size, the quality of the plastic (ABS) and surface finish is very good, the sides feel strong and mate well with each other. It’s made by Evatron, model PC001 and I ordered a black and white one, both with and without a battery compartment from CPC in the UK (£4.54 with free delivery).

I prefer the look of the white one, its not trying to be Apple white (they’ve probably patented that one) but it’s not beige either – I suppose ivory is a fair description. The battery compartment option tempted me but I decided in the end that it would never be moisture or splash-proof let alone waterproof with a door.

Construction details

One of the first and easiest decisions was to remove some of the little plastic mounts intended for internal pcbs, they just get in the way. I snipped most of them off with heavy duty wire cutters and then used a sharp chisel to cut the remains of the plastic flush to the surface. Then the hole can be made in the middle of an end, it needs to be 12mm to accomodate the BNC connector of the pH pH probe circuit. I find that it’s very difficult to drill holes accurately without a pillar drill, especially in this sort of situation where the hole needs to go in the middle of where the case splits. However, it is perfectly possible to mark out pretty accurately by careful measurement and ‘eyeing’ up the marks from several angles. So I just marked out the hole as carefully as I could, then drilled it roughly in the middle at 10mm. I then used a file to remove the rest of the material and return the hole to a centred circle. I tried to retain a flat on one side of the hole, to match the mounting pattern of the connector, but it’s not vital.

Now in order to fit the pH sensor circuit we need to hack it – this time with a fine hacksaw. I spend quite a few minutes examining the board layout files (yet another reason to love open source hardware!) and a load more time examining the physical circuit, and became convinced that there weren’t any traces or components that I’d be damaging. The physical construction of this type of circuit is important, but I reassured myself that I wouldn’t be breaking any guard traces, just clipping off a bit of ground plane.

Needless to say, despite my brave words I was more than a bit apprehensive to take a hacksaw to such a perfectly formed little board. Perhaps this is what novice surgeons feel the first few times they have to cut into somebody? Anyway the operation was a success, and the patient was able to make a full recovery, minus a corner.

The MinipH circuit is from Sparky’s Widgets – aka Ryan Edwards – another hacker hero of mine! (I think I’m going to have to make a page of them soon). He has some great info on his site that really helped me understand some of the more subtle aspects of pH measurement.

I decided to use the hardware I2C port rather than the software ports provided as part of JeeLib – I figured that perhaps the processing overhead might be a bit lower, but I haven’t tested that assumption. The demo sketch provided with the hardware worked great out of the box, and Naomi then wrapped it in a class and got the data sent over the radio.

The only other fiddly detail was getting the power consumption down, as the circuit consumes a few milliamps constantly. I tried a few different ways to power the circuit and eventually settled on using a digital out to raise vcc high when I need it. The draw of the circuit is well inside the limits for the IO pins, and it seems to work fine. This way I can sleep most of the time and only switch on the sensing circuit when required.

I did some testing and found that the pH circuit needs quite a bit of time to settle, and I ended up allowing five seconds for the circuit to ‘warm up’ before reading from it. Even then the results often carry on dribbling up (or down) for quite a while. So rather than a pattern of ‘wake up, measure, sleep’ that we’re currently using, in the future we’ll be implementing a scheme where the sensor wakes up, keeps the pH circuit powered up for some time whilst taking measurements, then sleeps. Of course the mcu/radio can be sleeping during most of the measurement time, but the sensor would remain powered up.

In an ideal world I’d like to do some more clever work in software to measure the speed of change and basically predict where the results will settle. This should give a fast reading despite the pH probe actually taking ages to settle. And also, let’s face it, getting pH accurate to one decimal place is great for most situations, and the extra place may be questionable anyway as I’m not sure the accuracy is quite equal to the resolution.

And finally, the battery is from Adafruit, as detailed in the overview page. With a sleep current of 7μA against a capacity of 1200mAh, we should be good for a couple of years I reckon, even if we spend a fair fraction of one percent of the time awake.

The microcontroller sketches that configure and then run the sensor are available over at github – we are developing a system based on Node-RED to receive the data that you can also download from github. I hope that you find our work useful, and build something yourself with it, just as we’ve built on the astounding work of so many others. Happy hacking!!

The post Wireless pH sensor appeared first on layer zero labs.

You can find these rfm12b modules on sale on ebay – I paid about £10 with delivery and it arrived promptly, the seller chacal_zoom seems to have a number of interesting little circuits, specialising in minimum parts and tiny boards! (avoid the bedini circuit tho he he he!!!)

After seemingly endless weird problems getting the rfmb12 driver working and loaded automatically as well as re-installs, imaging mishaps etc. I’m now getting both more expert at configuring raspian and somewhat bored. Also I’m now convinced that we’ll always be going wireless from now on, so the rfm12b driver is a must. Plus Wiring-Pi and a couple of other nodes added into node-red for completeness, giving a ‘base-system’ setup.

So I’ve decided to go scriptomatic and as a first step I’ll list some commands that you can just paste into the terminal and go away and have a light meal while stuff installs. At the moment you will have to come back after the starter because there is a reboot early on to start using the new kernel.

So, having created an SD card with raspian on it I expand the file-system now rather than later, to make sure I leave a couple of hundred MB for SD block failures. On boot, login with the default username of pi and password raspberry. Run sudo raspi-config to enter the easy config. Change password and then in advanced – change hostname, ensure that the graphics split is 16MB, enable SPI and reboot.
Now you can log back in with your new password and then paste the commands below.

EDIT – NOT YET WORKING ON PI 2!! But you can install headers by replacing the ‘rpi’ with ‘rpi2’ if you are using a Raspberry Pi 2 – and either way don’t forget to update the version numbers in my example e.g. “3.12-1-rpi” with the ones you actually downloaded in /boot – e.g. “3.18.0-trunk-rpi2”.

1st – Kernel with headers – 8 min

echo 'Europe/London' | sudo tee /etc/timezone
sudo dpkg-reconfigure -f noninteractice tzdata
sudo aptitude update
sudo aptitude install -y linux-image-rpi-rpfv linux-headers-rpi-rpfv
echo -e "kernel=vmlinuz-3.12-1-rpi\ninitramfs initrd.img-3.12-1-rpi followkernel" | sudo tee -a /boot/config.txt
sudo reboot


The next set of commands do some config as well as installation of the radio driver, so edit them if you want a different node id by default for example.

2nd – RFM12b driver installation – 1 min

git clone https://github.com/gkaindl/rfm12b-linux.git
cd rfm12b-linux
sed -i rfm12b_config.h -e 's/#define\ RFM12B_BOARD[[:space:]]*0/#define\ RFM12B_BOARD\ 1/g'
sed -i rfm12b_config.h -e 's/#define\ RFM12B_DEFAULT_GROUP_ID[[:space:]]*211/#define\ RFM12B_DEFAULT_GROUP_ID\ 101/g'
sed -i rfm12b_config.h -e 's/#define\ RFM12B_DEFAULT_JEE_ID[[:space:]]*0/#define\ RFM12B_DEFAULT_JEE_ID\ 1/g'
make
sudo cp rfm12b.ko /lib/modules/$(uname -r)/
echo -e "rfm12b" | sudo tee -a /etc/modules
sudo depmod -a
cd examples
make
cd ~


Edit – if you have errors at the make stage then recently I found that there was a test at line 25 of the Makefile that was erroring – as we are past version 3.7 we can remove the test and just always execute the line after it. So delete line 25 from the Makefile – it starts with if [ -f /lib/….

Now to prepare for the big update/install of everything else we install Gordon’s excellent Wiring-pi library.

3rd – Installing wiring-pi – 1 min

git clone git://git.drogon.net/wiringPi
cd wiringPi
./build
cd ~


And finally, for something completely different. Some more installation stuff, this time you shouldn’t rush back …

4th – Main update & installation of packages ~ 30 min

sudo aptitude upgrade -y
sudo aptitude install bootlogd mosquitto
wget http://node-arm.herokuapp.com/node_latest_armhf.deb
sudo dpkg -i node_latest_armhf.deb
rm node_latest_armhf.deb
sudo adduser --system node-red --ingroup pi
sudo chmod 775 /home/node-red
cd /home/node-red
npm install node-red
cd node_modules/node-red
npm install serialport stately wiring-pi


And just add in the startup script from here, edit the init script to use the node-red user and you’re golden.
sudo wget -O /tmp/download https://gist.github.com/Belphemur/cf91100f81f2b37b3e94/download && sudo tar -zxf /tmp/download --strip-components 1 -C /etc/init.d && sudo chmod +x /etc/init.d/node-red && sudo update-rc.d node-red defaults

The post Node-Red on Raspberry Pi with RFM12B support appeared first on layer zero labs.

This post follows on from this one where Gareth explains how to use an RFM12b module with an RPi. To recap, the RFM12b module is a radio transciever like the Jeelink, but it is much cheaper. It is, however, slightly harder to use. The Jeelink connects via USB and is immediately exposed as a serial port. But this RFM12b module is soldered directly onto the (in this case) Raspberry Pi. It requires installing the rfm12b_linux kernel module, which creates a /dev/ entry. This is explained in the previous post.

rfm12b_linux and node-red

This section deals with using rfm12b_linux and node-red in particular. The rest of the post applies just as much to the Jeelink. Assuming you have a stream of data being received by the RFM12b module, the next question is how to make use of that data in node-red. (This example assumes node-red is running on the RPi itself). Given that the RFM12b module is exposed as a device, our first thought was to simply tail it like a file. But this did not seem to work, as was borne out by the nonsensical output of  as using cat on the command line. But luckily, when you get the kernel module from github, it comes with some example code. One of the examples, rfm12b_read, is extremely useful. It interprets the data and relays it to standard out in the form of nice human readable strings.

Using the exec node, you can simply run the rfm12b_read script directly in node-red. You just need to tell the node the location of the script, and set it to spawn() rather than exec(). This latter step tells it to give you the data in chunks as it comes it, rather than all at once in a big pile!

Add an injector to the left of the exec node, set to start automatically, and that is all there is to reading the data into node-red.

Sorting and parsing data from multiple sensors

In the RFM12b protocol (used by Jeenode and Jeelink as well as the RFM12b module), you specify a group id and a node id for each device. In this case we have a number of different sensors all broadcasting data and a central base station (the RPi) that needs to listen to them all. In the sensor-side code (which I won’t go into here), we set the group id to the same for all the sensors, but gave each one a different node ID. That way the RPi can listen to all the sensors in the group, and also be able to tell them apart.

In this example the RPi is receiving data from a RoomNode and also from this pH sensor, fresh from the Layer Zero Labs inventory…

(I’m sure Gareth will be along with a post soon to describe the hardware.)

Back to node-red … basically it is just a case of using a switch node to decide which sensor the data is coming from, and then ordinary function nodes to extract meaningful values from it. However there are a few gotchas at this stage. Also the way we have done it is probably not the best, so go carefully!

The rfm12b_read script appends the date and some other information to the beginning of each set of data. It produces something like this:

Sat Mar 29 15:52:48 2014 6 bytes read 3 4 0 88 234 0

In this case 3 is the node id (meaning that it is the roomnode), 4 means that there are four bytes to follow, and the rest is the actual raw sensor data.

However this is not a string as such but a buffer object, which node-red signifies by appending “(Buffer)” so that the actual payload is:

(Buffer) Sat Mar 29 15:52:48 2014 6 bytes read 3 4 0 88 234 0

I confess to not having researched what a buffer object is, but it is stringy enough to pass it through a switch node like this:

The switch node looks for the string “33 2”. i.e. node id 33 and 2 bytes to follow, or conversely “3 4”, node id 3 and 4 bytes to follow. This sorts out the data streams from different sensors, while doing a very cursory check that it is not malformed.

The first gotcha is that I tried to check for it containing “6 bytes read 3” or the like, so as to be more sure that it was not malformed, but this did not work, which is probably something to do with the buffer not being exactly a string.

Once the data is sorted into the correct streams, the next thing to do is to parse it. I chose to split the payload into an array, using space as the delimiter, and then use pop() to read each byte in turn. Here’s the second gotcha: the buffer object needs a toString() before it can be split(). The third gotcha is that it also has a newline on the end, so throw away the result of the first pop().

Also be aware that the data is in bytes, and of the byte order.

// function: Parse pH

var dataArray = msg.payload.toString().split(‘ ‘);

dataArray.pop(); // last element is newline

var pHMSB = dataArray.pop();
var pHLSB = dataArray.pop();
var pH = 256* parseFloat(pHMSB)+ parseFloat(pHLSB);

var pHMsg = {payload: pH};

return [pHMsg];

The pH is a single sensor, but the roomnode includes data from various sensors, in our case temperature and humidity, so the code is a little more complex and the function has two outputs, one for each sensor:

// function: Parse Roomnode

var dataArray = msg.payload.toString().split(‘ ‘);

dataArray.pop(); // last element is newline

var tempMSB = dataArray.pop();
var tempLSB = dataArray.pop();
var humidity = dataArray.pop();
var temp = 256* parseFloat(tempMSB)+ parseFloat(tempLSB);

var humidityMsg = {payload: humidity};
var tempMsg = {payload: temp};

return [humidityMsg, tempMsg];

Because of the way we have the gain set, some of the data needs dividing by 10 or 100 after that, hence the scale functions.

Onward …

My next steps for this:

1. Get a better understanding of what the rfm12b_read script does, and why the data can’t be read directly from the /dev/ or if it can, then what I was doing wrong when I tried it.

3. Understand the buffer object and therefore maybe be able to use some of the metadata as a check against corruption. Otherwise, avoid reading in the date and time etc. just to then throw it away.

The post Reading multiple sensors – rfm12b_linux and node-red appeared first on layer zero labs.

Now we use Freeboard to display data – there is a freenode node for node-red in the contrib section – it makes it super easy to setup and configure. See http://incredibleaquagdn.no-ip.info/?load=dashboard.json for an example of how it looks.

A simple node-red web page

In the aquaponics installation we’re working on, node-red is running on a raspberry pi controlling an aquaponics system. It receives mqtt messages every second containing the readings from various sensors.

I wanted to create a simple web page that displays the data from each sensor, updating every 2 seconds.

I’m quite new to the Internet of Things and to event-driven programming in general, so if you are already an expert you will probably think my solution is hacky for all the wrong reasons. If so feel free to comment … constructively For example, I suspect a “proper” node-red web page solution might involve node-red pushing data to the page in real time, but I’m going to keep it simple here and let it poll for its data.

Components:

1. A web page (HTML and Javascript) that sends an HTTP request to node-red every 2 seconds  and displays the data returned

2. A node-red object that knows the latest values of all the sensors

3. An httpRequest node configured to accept the page’s requests, triggering a flow that grabs the sensor values and returns them to the page via a httpResponse.

Http request and response in node-red

I jumped in with the node-red bit first, being the most fun. To simulate the messages containing sensor data I mocked up some streams of data using injectors.

Data buffer

The data buffer keeps hold of the latest sensor data, passing it through to the http response when a request comes in. It works like this: when a message arrives on a sensor data topic, it updates its array of sensor values, and exits. But when it receives a message via the http request node, it adds the latest data into the message object.

context.data = context.data || new Object();
switch (msg.topic) {
    case "concavity":
        context.data.concavity = msg.payload;
        msg = null;
        break;
    case "altitude":
        context.data.altitude = msg.payload;
        msg = null;
        break;
    default:
        msg.data = context.data;
}
return msg;

Page template

This is the html for the full page.

Hello there 
Altitude: {{data.altitude}}
Concavity: {{data.concavity}}

Other configuration

The http request node is configured for the url /boo and the GET method. The http response node needs no configuration.

Full flow

[{"id":"66f381b0.990c8","type":"http response","name":"http out","x":657,"y":233,"z":"ad00793e.52ff88","wires":[]},{"id":"ec3dfdc9.13c2","type":"http in","name":"http in","url":"/boo","method":"get","x":129,"y":329,"z":"ad00793e.52ff88","wires":[["ab90d0fa.546f3"]]},{"id":"cad43099.352bd","type":"template","name":"Page Template","template":"Hello there <br />\n\nAltitude: {{data.altitude}}<br />\nConcavity: {{data.concavity}}","x":485,"y":232,"z":"ad00793e.52ff88","wires":[["66f381b0.990c8"]]},{"id":"1c8929d0.e376d6","type":"inject","name":"","topic":"altitude","payload":"3","repeat":"3","crontab":"","once":false,"x":140,"y":216,"z":"ad00793e.52ff88","wires":[["ab90d0fa.546f3"]]},{"id":"315341ba.ceacbe","type":"inject","name":"","topic":"concavity","payload":"65","repeat":"2","crontab":"","once":false,"x":138,"y":271,"z":"ad00793e.52ff88","wires":[["ab90d0fa.546f3"]]},{"id":"ab90d0fa.546f3","type":"function","name":"Data buffer","func":"context.data = context.data || new Object();\nswitch (msg.topic) {\n    case \"concavity\":\n        context.data.concavity = msg.payload;\n        msg = null;\n        break;\n    case \"altitude\":\n        context.data.altitude = msg.payload;\n        msg = null;\n        break;\n    default:\n    \tmsg.data = context.data;\n}\nreturn msg;","outputs":1,"x":319,"y":230,"z":"ad00793e.52ff88","wires":[["cad43099.352bd"]]},{"id":"261b1fb8.d9e4e","type":"inject","name":"","topic":"altitude","payload":"2","repeat":"2","crontab":"","once":false,"x":143,"y":169,"z":"ad00793e.52ff88","wires":[["ab90d0fa.546f3"]]}]

If you deploy this and point your browser to localhost:1880/boo then you should see the (very simple) page. It won’t update automatically, but if you keep refreshing you should see the altitude changing from 2 to 3.

Node-red really is awesome. It’s amazing how quickly you can get something up and running, end to end. This delightfully bare-bones way of getting started was inspired by this node-red web page suggestion by knolleary here. 

Auto-update using Javascript

Well I thought I was starting with the node-red bit and would have to go on to web servers and static templates and so on later. But in the course of looking for a simple way to add the auto-update functionality, I ended up with a totally node-red web page – everything about it is programmed in node-red.

There are two urls serving http requests – /web and /data. When you go to /web it serves up a simple page with a placeholder div and a js script. The script sets a function to run every 2 seconds. The function sends a request to /data and replaces the text in the div with the response, i.e. the latest sensor data (here mocked out by injectors publishing timestamps).

Auto Update Script

The auto update script node is also just a template but it contains the script that will kick off the auto-updating. The URL is hard-coded.

<script>
    setInterval(function(){	
	    var theUrl = "http://localhost:1880/data";
	    var xmlHttp = new XMLHttpRequest();
	    xmlHttp.open( "GET", theUrl, false );
	    xmlHttp.send( null );
	    document. getElementById('data')
	    	.innerHTML = xmlHttp.responseText;
    },2000);
</script>
<div id="data">... Loading ...</div>

The result is that if you go to localhost:1880/web it should say “Loading …” for a few seconds and then start to display the data, updating every 2 seconds as required.

Future Improvements

Clearly this is just a proof of concept. Where to go next?

• Appearance. Present the data in a nice format on the page.
• Improve the code. The hard-coded url is yucky and the html markup is … minimal. Also something doesn’t feel right about having the js script as text in the template node, but maybe it’s fine.
• Add the ability to send requests in the other direction, from the web page and have node-red act on them.
• Add a download option for historical data
• etc.

Comments welcome

Have a nice day

The post Node-red web page – an example to get you started appeared first on layer zero labs.