Sniff Documentation-fest

Lets be honest... no one likes writing documentation, and the Sniff docs haven't been the best. It's just more fun writing code than writing it up. We'd claim that all the information you need it there, either here on the blog, or in the examples folder but as the blog has got bigger (great - more resources and ideas!) its increasingly harder to find older posts. I'll admit I've googled my own posts to try and find instructions for a project I developed months ago.

While the examples folder is still the goto-place for code to get you started, the last few weeks have been spent trying to put together something more tangible, so you've a solid base of reference material you can work from. 

In fact we've always had a manual... you did read the manual right? Most of it was written way back when Sniff was very new. It's in the Sniff/docs folder when you download Sniff. We've now given it a bit of an overhaul, adding a few extra chapters to the tutorial section, updating the reference section, and adding an index of blocks, so you can look up "blocks" in alphabetical order. While the updated version will still be in the docs folder for download the pdf of the latest version is in the new online docs folder.

In addition we've updated the Device docs. "Devices" are external code to talk to specific hardware, so there are quite a lot of these (currently 145, though some of those are interdependent), and keeping track of how to use each device can be quite hard. Again there were some docs for a couple of the Devices: Filesystem and Sprite, as these are two of the more complex Devices with many commands, but now we've added documents for some of the simpler devices on the basis that these are the ones you'll encounter first, and need the most help with. They should be suitable for printing out, and keeping a few copies around when you're working with a particular device.

For each documented device, there's a page on the hardware (of appropriate), a page defining the Variables used, and then a list of all the commands that the device recognise. For each method, the variables that it uses as parameters are shown in a table, with a brief statement on their meaning. Finally there's an example.

We're still refining the format and the documentation only exists for a small subset of the available devices, but hopefully by establishing a standard format for documenting devices, we can do better in future (and at least document new devices better).

Currently there are documents for DHT11/DHT22, DS18b20, text LCD's, the Motor Controller shield, NeoPixels, IR Receiver for use with Arduino, and for Hosted systems there's Filesystem, Sprites, Flotilla and Window. There's also a generic DisplayDevices which applies to all bitmapped screens.

You can get The Docs online now, and we'll be including them as PDF's in future distributions of Sniff. The Sniff distribution will also include the LaTeX source for the main manual, and Pages files for the Devices so you can edit them (If you're PC based, then you can still edit pages on iCloud).

Simple Reation Timer

Yesterday I ran the first of a series of workshops, making fun stuff with Sniff on Arduino. We started with an Arduino and an LED, then added a button and a potentiometer (dial). That neatly covers inputs and outputs, both digital and analog, so we can declare all that hardware with something like:

make led1 digital output D13

make led2 analog output D9

make button digital input D4

make dial analog input A0

Then we can use the button to control the "digital led"

when start

.forever

..set led1 to not button

use the potentiometer  to control the brightness of the analog led:

when start

.forever

..set led2 to dial

or we can use the dial to set the speed of a flash:

when start

.forever

..set led1 to on

..wait dial secs

..set led1 to off

..wait dial secs

we can even make the button control a flashing LED

when start

.forever

..if not button

...set led1 to on

...wait dial secs

...set led1 to off

...wait dial secs

The idea was then that we could build something fun or useful using the components. The code for a simple ration timer is:

when start

.forever

..set led to off

..wait pick random 1 to 5 secs

..set led1 to on

..reset timer

..wait until not button

..say [timer]

You can extend this a little to prevent cheating by checking that the button isn't pressed before the LED comes on:

when start

.forever

..set led to off

..wait pick random 1 to 5 secs

..if not button

...say "Cheater!"

..else

...set led1 to on

...reset timer

...wait until not button

...say [timer]

Hopefully everyone had a fun time with this, and I've got some ideas for a Xmas/Winter project next month...

Flotilla and MQTT

I've not played with the Flotilla for a few months, but when I was playing with MQTT last month, I kept thinking that I should integrate the flotilla Weather sensor into the MQTT network that we built.

Previously I used and Arduino with a temperature sensor, pushed the data to MQTT, processed the data in Node-Red and finally pushed a message back through MQTT to an LCD screen. You'll need MQTT and Node-Red servers running already, along with the Node-Red flow I built in the last post.

Rewriting it for the Flotilla is mainly a case of changing a few declarations:

make mqtt device

make networkPeer string

make networkConnected boolean

make clientid string

make message string

make topic string

make retain boolean

make flotilla device

make sensor flotillaWeather device

make temperature number

make pressure number

We don't need an ethernet device,  as the MQTT device doesn't need to drive the hardware directly. And I've just replaced the DHT11 with a flotilla dock and weather sensor.

when start

.set clientid to "flotillaSensor"

.set networkPeer to "raspberrypi.local." 

.

.repeat until networkConnected

..tell mqtt to "connect"

.

.say "connected"

.

.broadcast measureStuff

.

.set topic to "text"

.tell mqtt to "subscribe"

.set topic to "office/text"

.tell mqtt to "subscribe"

.forever

..tell mqtt to "loop"

..if not message = ""

...say message

There are a few minor tweaks to change the name of the client, and specific that the MQTT server is on raspberrypi.local before we subscribe to the text topics  Currently there's no text based screen for the flotilla (an i2c 16x2 LCD would be nice...) so when we get the message we just print it on the terminal with "say".

when measureStuff

.forever

..tell sensor to "update"

..

..set retain to yes

..set topic to "office/temperature"

..set message to [temperature]

..tell mqtt to "publish"

..

..set retain to yes

..set topic to "office/pressure"

..set message to [pressure]

..tell mqtt to "publish"

..

..wait 10 secs

The script to do the measuring is essentially the same too, though now we're recording temperature and pressure, rather than temp and humidity.

And that's it! Neat huh? Lots of scope for fun... Have one set of sensors running, and let everyone tap into them, or place sensors all over the place and collect data from them. Have one group of kids responsible for posting data, and other for displaying it - on the same or separate computers.