It feels a bit odd to give this piece a software a version number, since it’s all so early still, but I’m releasing it as HouseMon 0.5.1 anyway, to set a baseline for future development.
Note that the instructions so far were all about development. To get an idea of the true performance on a Raspberry Pi, you should start up as follows (make sure HouseMon is not running already): cd ~/housemon && SS_ENV=production node app.js – this’ll take a few minutes while SocketStream combines and “minifies” everything the first time around. After that, all web accesses will be a lot snappier than in development mode.
But let’s not get ahead of ourselves… tons of work to do before HM becomes useful!
I suspect that this project will lead to more questions than answers at this stage, but I guess that’s what you get when following the “release early, release often” approach of open source software. There seems to be no other way to go through this than just bite bullet, get a basic release out in the wild, and see how it holds up when installed in more places.
Here’s an attempt to map out what’s in the 0.5.x release:
The dotted lines indicate that logged and archived data is being saved but not used yet (logged data is the raw incoming text from serial interfaces, etc – archived data is per-sensor information, aggregated hourly).
This diagram is still too complicated for my tastes. Part of the process is getting to grips with complexity: multiple sensor values per reading, “de-multiplexing” different types of packets from the ookRelay, mapping node ID’s to locations, ignoring some repeated data which contains no extra information, and more real-world messiness…
There is currently very little error checking and error messages can (will!) be cryptic.
Which is all a long-winded way of saying that HouseMon is still in its very early stages. Let’s see how it evolves, and please do comment and hack on it if you are interested.
Note that HouseMon is a moving target. The “develop” branch is already moving ahead:
As you can see, it’s all made up of “briqs” which can be added and enabled as needed.
PS. I’ve added some documentation on how to track changes in the development branch.
I must say it’s already looking good :)
Have you thought about how other people can contribute to this project*, or will it stay mainly a one-man undertaking?
This has been one of the goals from day one: creating sufficient “plumbing” that adding stuff is worth the effort of learning how to do so, while keeping it all as much as possible modular.
Briqs are not yet modular enough, in that you can’t just add a directory with a few files to the “briqs/” directory and start extending the system that way, but if you’re willing to put the files in three different places for now. it already should be possible to add and tinker with what’s there.
I’ve added an issue to help get this going – https://git.jeelabs.org/housemon/issues/44
Thanks for the diagram. I started looking into HouseMon recently and this helps to see where I need to make changes to support my sensor data telegrams where each sensor adds a tag and its data to the node’s telegram (so I can have e.g. a node with a roomboard and two TMP36s and decode this into three separate readings).
Note that the demo in the DIJN series bypasses all the state mechanism, i.e. readings and status, and just sends out special-purpos events directly to the client(s). For real use, it’s better to push the readings through a driver, make them end up in readings, and set up all the info needed to get the final values into the status collection. This is the central dispatch for incoming data, really. Any briq can hook into “status.set” events and pick up the incoming updates (both server-side and client-side).
I have been eagerly following your HouseMon series and learning a little bit in the process about the Node.js and CoffeeScript technologies you are using. Your integration of all this while maybe a little messy at the moment is still pretty cool.
I’m building a 3W solar powered, Arduino based, 1-wire weather station at the moment and am wondering when an example of the plotting brig might go live?
Graphs are available in the development branch, see the docs/updates.md info for how to switch to that – I’m using it all the time. The trick, and perhaps the stumbling block right now, is to make your data appear on the status page. Once you reach that point, the history, archive, and graphs briqs all work as soon as you install them.
works well while using the drivers created, roomNode for example. Now when I do a driver derived from roomNode stops working and goes erratic … operate the new and not the first .. I’m a bit blind … for example the ‘announcer’ I do not know what it is and just increase …
I need more documentation … and better known of node.js, javascript etc … of course ….
It’s work in progress, and very early days. Does the information in docs/ help? See the “drivers” docs, in particular.
Welcome to the real world (of monitoring your home), where things aren’t always that ‘clean’ as you’d expect them to be ;-)
Yes JCW, very helpful … I know it is a young project … and I thank you … :)
Very interesting project, I currently have a raspberry in my basement logging temperatures of about 30 onewire sensors (solar, heating, venting… for 2 households). I am currently expanding this network by using a JeeLink and various JeeNodes in the places where I cant or wont run a cable so this fits my use case quite well ;)
Maybe its interesting for Raspberry/NodeJS users: https://github.com/sysrun/node-raspi2c
Its a native nodejs module for i2c communication and i2c device wrapper. i have build a first “device driver” for the DS1340 Real time clock (Jee RTC Plug)
Small example: var DS1340 = require(‘../../lib/devices/DS1340’);
// Deviceadress 0x68 // Raspberry i2c-bus no. 1
var device = new DS1340(0x68, 1);
device.getTime(function(error, timeObject){ console.error(error); console.log(timeObject); });
Driver for the LCD-Plug (based on MCP23008) should be the next device (text output is working) :)