Movement sensors – how to utilise them

We have a number of movement sensors in the house – with most of them sitting on a number of Jeenodes – where there are also sensors for temperature, light and humidity (and others).

We also have cats – they register on some of the sensors.

So how do I turn this into useful information to tell (as a example) the heating systems that we are actually at home, and please keep it warm enough, or that we are out so heating in all rooms can be turned down?

So far I’m collecting data to let us have a minimum number of movements in a room per hour to eliminate cat movement….


Securityspy setup for a Megapixel camera

I’ve used the excellent Securityspy server software running on a Mac Mini for years – it’s rock stable, and it just works.

But with every new camera you either need to find it among one of the pre-configured devices, or you have to cut-and-try.

And the camera I just bought as a outdoor camera is among those – so to help others trying to do the same – here is a working setup:


Btw. this is the camera :


PiFace and movement sensors – a lesson learnt

The picture shows one of our Raspberry Pi’s with a PiFace board on top of it, and 2 PIR infrared sensor I’ve bought from someone on the internet – really inexpensive PIR’s/

These are connected directly to input 1 and 2 of the PiFace, which btw. apparently has pull-up resistors enabled on these particular inputs, so all should be ok.

Btw. I’m running Domoticz – a home automation system on this RPI. I have linked the 2 top LED’s on the right hand side of the board to show whenever the RPI triggers. But this did not work terribly well. As you can see from the partial screenshot below it has been triggered a rather disturbing number of time – even today.


This is improbable, even with cats in our house.

Therefore I’ve added 2 more pull-up resistors to see if the problem is noise on the input lines. And it now looks a lot better – but I will have to let the test run a bit longer.

– Posted using BlogPress from my iPad

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]

Updated FHEM for our heating control

We are running a multitude of home automation systems – but the one that communicates with all the heating is still FHEM, one of the few that can actually communicate with our FHT80b thermostats.

Here is tonights picture of our houses heating :


The green line show how open each actuator (aka valves on our radiators) are in each of the 3 heating zones in the house.

The red line is the actual temperature in the zone.

There’s another part to it as well, controlled by a set of bespoke routines for turning on and off the main valves for the hot water and the heating water circulation as well. Included in this is software for turning on and off the circulation pumps.

Graphing the Fritzbox

At long last I’ve managed to stabilise the code for graphing the bandwidth usage from the Fritzbox – i.e. our ADSL line.


It’s not as straight forward as it should have been – but the Fritzbox does not offer these counters up in any normal sensible form such as SNMP.

So it’s a combination of a script. some Ruby code and Graphite.

It should be easy to deduce that I got up late today!

JeeLabs is still alive!

I have really missed the jeelabs site since jaw stopped his daily updates – so I was really happy to see this update from him:

So here’s the new TL;DR version:

A driver for the new RFM69CW modules is being re-written from scratch to support these new modules in “RF12-compatibility mode”. This means new nodes with that radio will be able to inter-operate with all the exiting nodes out there based on the RFM12B and the RF12 driver, without change.
I have reverse-engineered a driver for the RFM12B to make it run in the other direction, i.e. sending and receiving packets from an RFM69 module running in its native mode, with hardware buffering and CRC generation.
JeeBoot has almost reached the point where it can be deployed on standard JeeNodes with ATmega328’s. This is not so much about the boot loader code, which has been running here for over a year now, but about the entire process of node discovery, pairing (assigning node ID’s), and managing software uploads and revisions for an entire network of nodes. After a couple of false starts I now have a simple “JeeBoot server” running on node.js which drives a standard JeeNode/JeeLink running the RF12demo sketch and turns it into a boot server. It’s really fascinating to be able to re-flash all the nodes remotely and robustly, and to see them all come back to life with their new sketches.

[From From 2013 to 2014 – JeeLabs Café – JeeLabs . net]

Our new smokealarm

Who should have thought that a smoke alarm could create so much hilarity

The new Nest


speaks to you in a almost perfect female voice saying things like :

“There is a lot of smoke in the kitchen, the alarm may sound, it’s very loud”

whereupon you can see whoever is in the kitchen when this happen leaping around waving their arms to turn the alarm off….

Webdis – a simple way to update Redis

Webdis is a very simple way to update Redis through the use of a structured url.

A good example :


will set the variable “motion_sensor_1” to the value on in the space “house”.

Easy to use from for example Domoticz where state changes for switches can now trigger a url.