Jeenode – Tor's blog

The upcoming JeeNode Zero • JeeLabs is at it again!

Jeelabs (the people that renewed my interest in electronics and micro controllers) have been quiet for a couple of years, but it look like they are back again, with a very much updated version of my favourite micro controller, the Jeenode.

I highly recommend following the excellent series of articles from them :

The upcoming JeeNode Zero • JeeLabs: “The upcoming JeeNode Zero Dec 21, 2016

Lately, I’ve been keeping busy with a brand new board. It’s called the JeeNode Zero:

Shown here is the ‘rev3’ prototype, and it’s starting to shape up nicely. Sooo… without further ado, let me tell you more about it:

Working on the JeeNode Zero – Wed Some specs and comparisons – Thu This node speaks Forth (and C) – Fri Taking the JNZ rev3 for a spin – Sat JNZ testing and availability – Sun This isn’t about being the first or cheapest ‘node’ out there, in fact this isn’t about any.

The JeeNode Zero is about creating exactly the node I’ll want to use for my projects. My hope is that this week’s articles will also help explain what is guiding my preferences and choices, and where it might lead to.

“

(Via.)

DFRobot flame sensor

I bought a couple of flames sensors from DFRobot – mainly to get a better way to measure if a boiler is on or off (checking whether there is a pilot flame or a full flame).

And I found it problematic to how it up until I found the following

NewImage

It turns out the pinout on the card was changed at some stage! Correcting for this and it all started working.

Jeelabs and JET

One of my favourite hardware and software “hackers” runs a community/blog/ecosystem/shop call “jeelabs” (yes its the guy behind all the Jeenodes I use in our house”. And he’s now starting on another journey with JET :

JET, as seen from 9,144 meters • JeeLabs: “The JET project name is an acronyn for ‘JeeLabs Embello Toolkit’. And with that out of the way, please forget it again and never look back. A few more acronyms will be explained when the subsystems are introduced – none of them particularly fancy or catchy – it’s just because we can’t move forward without naming stuff. Names and terms will be introduced in bold.

As will become clear, this is a long-term project, but not necessarily a big one: this is not about creating a huge system. It’s more about making it last…”

(Via.)

We are getting closer to BBQ automation

In the end I decided that I will not build all the parts of the BBQ automation myself – but buy a open source system to start everything off, realising that prime barbecuing season is close, and that realistically the timescales for building everything are short.

So I’ve ordered the HeaterMeter standard kit – and had confirmation of the order already! Exciting.

“

Thank you for placing your order with HeaterMeter!

This email is to confirm your recent order.

Date 03/14/2015

1x HeaterMeter v4.2 Kit – Thermocouple PCB / No Blower / No Raspberry Pi”

My Jeenode monitoring kit

This is the display of my Jeenode wireless monitoring kit. It’s actually a Raspberry Pi with a piTFT display mounted on top of it.

The Raspberry Pi is directly connected to a Jeenode “serial port” – where the Jeenodes are running Demo sketches. In other words what you are seeing is the payload of the wireless packets being transmitted from the various Jeenodes around the house. If you look at the payload in the picture the ID of each Jeenode is the first set of digits after the “OK”.

I2C Scanner for JeeNoodes

At long last I found a I2C scanner I can use on my Jeenodes – just as I have a need for one!

I was frustrated by problems with an I2C device and needed to check the address, but all the scanner sketches I could find were geared towards arduino users utilising the hardware I2C port (arduino pins A4 & A5).

So I adapted a sketch that I found to use the JeeLib and learned something about how I2C devices are set up in the process. But my learning is not over yet !! so if you see something that I’ve done badly then please say so that it can be improved, for example to handle running on a jeenode micro?

[From I2C Scanner for JeeNodes – JeeLabs Café – JeeLabs . net]

flow for Housemon

This is where jcw’s “flow” package is residing – this is exciting stuff

This is the core of the dataflow package.

The flow package implements a dataflow mechanism in Go. It was greatly inspired by Paul Morrison’s Flow-based Programming (FBP) and Vladimir Sibirov’s “goflow” implementation – see also https://en.wikipedia.org/wiki/Flow-based_programming.

[From flow – GoDoc]

Where jcw’s Housemon is moving

jcw (father of the Jeenodes) is still working on his home monitoring/home automation system – and he is moving it in a interesting direction, partially along the same lines as I have been (slowly) moving my own monitoring system.

He’s now moved a significant portion on by using Go – something I have not looked at yet.

Here’s where I’m headed with all this:

Flow is the foundation for it all: dataflow programming is – p e r f e c t – for real-time apps such as HouseMon and Tosqa. The fact that it’s called 0.1 just reflects my inexperience with it all. But there’s no way back. There are lots of “worker” components in the 0.1 release already. They don’t really belong there, but it was easy to develop them that way. These will be moved to JeeBus soon – due to the registry, this won’t affect the program code (just a few “import” lines).
JeeBus will collect all the functionality which is generally useful for HouseMon and Tosqa: a HTTP web server, MQTT messaging (client and server), websockets, the LevelDB database, a JavaScript engine for implementing logic not built into the core, and AngularJS with CoffeeScript on the browser side. I’ve been repeating this for some time now, and it won’t change. Lua is out (but it could easily be tied in as external MQTT client, same for any other language). With Flow now in the picture, JeeBus will also include lots of fairly general “workers”, tying into the serial port, websockets, MQTT, etc.
HouseMon is simply a small “main” application built on top of the JeeBus package. It needs less than a dozen lines of code to make a usable application. In addition, HouseMon is where additional home-monitoring and -automation specific stuff can be implemented: in Go, as dataflow Workers and Groups, as JavaScript / CoffeeScript definitions, and as external processes: shell, Lua, Python, Ruby, Java, you name it. I see HouseMon as the proving ground for everything else, with the option to migrate whatever makes sense to JeeBus or Flow.
The other thing which hasn’t changed is “developer mode”. This is a setup now in JeeBus, which adds node.js and “gin” to the mix, to support live reload while making changes. I’ve briefly stepped away from it while hacking on Flow, but will definitely bring it back to the foreground once HM/JB and client-side development enter the picture again.

[From HouseMon + JeeBus + Flow – JeeLabs Café – JeeLabs . net]

The new Jeenode radio (?)

This seems to be the new radio that is supported by “jeelib” – so I can only assume that there is a future Jeenode utilising this. The exciting part is that the software has support for RSSI, i.e. signal strength. I can see lots of uses for this.

he RFM69CW is a transceiver module capable of operation over a wide frequency range, including the 315,433, 868 and 915MHz license-free ISM (Industry Scientific and Medical) frequency bands. All major RF communication parameters are programmable and most of them can be dynamically set. The RFM69CW offers the unique advantage of programmable narrow-band and wide- band communication modes The RFM69CW is optimized for low power consumption while offering high RF output power and channelized operation. Compliance ETSI and FCC regulations.

[From RFM69CW,RF transceiver – FSK Module – HOPE Microelectronics]

Jeboot

One of the new projects coming out of jeelabs is Jeebit – a wireless (over the air) boot loader and updater for Jeenodes. I am going to try this soon!

JeeBoot is a boot loader which gets control on a remote node when powered up. It performs three tasks: pairing, checking for upgrades, and re-flashing itself with new code.

Pairing – a pairing request packet is sent out, and broadcast on group 212. The node may not have been assigned a node ID yet, so this is like shouting in the dark. The request includes info about what type of remote node it is (JeeNode, JeeNode Micro, etc), as well as a unique “hardware ID” (this may be zero).

[From Design Notes – JeeBoot – JeeLabs . net]