First thing was to extend the ookRemote GUI, by adding these definitions to ookRemote.tcl:

With this change, the configuration section in “config.txt” supports CTX15 buttons:

These new buttons will send X10 commands to the CTX15 module. But this needs a bit of wrapping to turn them into frames, including the proper checksums. So I added two methods to “sketches/ctx15try/host.tcl”:

The “send” method overrides the existing one and sets up a frame before calling the original method with it.

That’s it. I can now make the Marmitek AM12 switch “clunk” with my mouse – audible feedback! :)

First I created a new folder called “sketches/ctx15try/” with a file “host.tcl” in it, using this code as quick test:

The reason there is nothing more, is that I changed the ctx15try.pde sketch a little to return lines starting with “CTX15″ – since these are the easiest to tie into JeeMon. The change affects these lines in yesterday’s demo:

I’ve also wrapped the received frame in {}’s, because that simplifies processing in JeeMon (Tcl interprets $’s and []’s unless escaped).

To activate everything, I added an extra line to the config.txt configuration file, so that the output from the JeeNode USB (serial# A900adwo) automatically gets picked up as sketch:

Here is an example of the above code running:

Good. CTX15 events are coming in. They are easily recognizable as (unit#, command) pairs.

But as you can see, these pairs don’t always arrive in the same frame. So we have to add a bit of logic to get things right. Here’s an updated version of host.tcl:

The solution used above is as follows: if it looks like a unit code (A..P + 1..16), then save that as last one seen. If it’s anything else, use the last saved location. I’m not sure this covers all possible scenarios, but for this very simple test it seems to work. Here’s a screen shot of the real-time status window:

As you can see, the CTX15 event was turned into an “AOFF” command for the “ctx_A01″ device, which was created on-the-fly by this code.

Hmm, looking further, I think the “A” prefix needs to be stripped from “AOFF”. Oh well, it’s all scripted, I’ll adjust that when I get to using this stuff for real.

So that’s it. A few dozen lines of C code in the JeeNode to act as pass-through and do the polling, and a few dozen lines of Tcl code to tell JeeMon how to interpret the incoming data. Now we get notifications whenever any X10 activity is detected on the mains power line.

Onwards!

That’s a live 220V power-line connection in the top right corner!

I’ve connected the CTX15 module through a UART Plug, with a 4.7 kΩ resistor in series with the RX signal (yellow from CTX15). This is because the signal swings up to 5V, whereas the UART plug only accepts 3.3V voltage levels. The module is powered from the PWR pin, which on a JeeNode USB carries 5V.

The CTX15 is a bi-directional interface, it can send as well as receive A10-type power-line commands (a superset of X10). The trouble is that it needs to be polled to read out what has been received and buffered so far.

Here’s a sketch which takes care of that:

And here’s some sample output:

As a test, I powered up yesterday’s XM10E test setup as well, to send out on and off commands to unit A.1 every 3 seconds. As you can see with the CTX being read out every 5 seconds, multiple received packets will sometimes be combined and returned as one reply.

Here’s is a sketch which turns a remote appliance on and off every 3 seconds:

I used the Arduino X10 library (had to mess around with the use of headers to get rid of compile errors, and enable the pull-up on the zero-crossing input).

This sketch runs @ 3.3V on a JeeNode with some stuff attached to port 1:

It’s just a simple re-wiring to an RJ11 connector. This in turn, plugs into the XM10E opto-isolated interface:

There’s also a X10 receiver built into the XM10E, which I’m going to ignore for now.

X10, in its simplest and oldest form, is a power-line transmission system, i.e. the signals to control a switch are sent over the same wires as the AC power itself (using a 120 KHz signal injected at the zero crossings). Proper mains isolation is essential, of course – as built into the XM10E unit.

The result is that you can plug this device into any outlet in the house and it’ll switch on and off as defined in the above sketch:

It’s hard to miss – the relay built into that thing switches on and off with a very loud “clunk”!

The power consumption of this switch is 0.6 W off and 0.9 W when on, according to the Cost Control. Not bad, until you start installing many dozens of these switches around the house … then it will add up!

First of all, a new JeeNode USB with improved voltage regulator setup:

The Dimmer Plug contains a 16-channel LED dimmer with independent PWM brightness control, using I2C:

The Lux Plug contains a sensitive light meter with high dynamic range, using I2C:

The Gravity Plug contains a 3-axis accelerometer with 2..8G range, using I2C:

The Proximity Plug connects up to 8 contacts as capacitive sensing switches, using I2C:

The Input Plug supports 16 inputs, as either analog or digital inputs (not I2C):

And three more boards. One of them is a mystery sensor – I’ve masked out its name for now :)

The other two boards are experimental boards of a different kind – I’ll describe ‘em when they work.

I’ve started setting up documentation pages for these new PCBs, but so far that’s just the EAGLE files. Will add more info in the coming week – with luck they’ll be back here for testing within the next 10 days.

I guess the best tactic for me now, is to just forget about this and work on some other stuff for a while. Drat.

Patience, patience, patience. I hope it pays off!

In the Netherlands, there is a subsidy as encouragement for people to place solar panels on their roof tops.

The system works as follows:

You’re considering setting up a couple of photovoltaic solar panels.
You quickly find out that the government is handing out money for this.
Yippie … and then you get into the rules and regulations bit:

• You can’t apply for the subsidy before March 1st.
• There is a limited amound of funding.
• On the day when submissions exceed funding … it’s roulette day!
• … the remaining subsidies are assigned at random.

The result?

On March 1st – everyone submits their proposal for solar energy.

On March 2nd – sorry folks, we’re all sold out, try again next year!

It turns out that some 17,000 people signed up for 2010. And about 5,000 of them will win that lottery ticket.

Tell me, please, what’s the meaning of the word “encouragement” again?

Anyway, so much for silly incentives. The reason I’m posting this is that we’ve been looking into solar energy and have decided to install 18..20 solar panels on our roof. It’s relatively well-positioned, and even the cabling in the house turns out to be very easily adapted for it. And yes, I’m one of the 17,000 who signed up for the Dutch Solar Casino. Except that we’re going to go ahead regardless of the outcome (3 months from now!).

The numbers are much better than I expected:

• With 18..20 panels, we can fill the smallest half of our roof
• Modern panels can produce about 3600 “Watt peak” total
• Heading and tilt are such that we’re still at ≈ 90% of optimal
• Estimated yearly output will be 2500 kWh, 20% more than we need
• Unused power is fed to the grid and billed at the same rate, as credit
• In other words, the electricity grid will become a – very – big capacitor for us :)

All in all, I think it’s a good deal. There will always be better deals in the future, but this is fine.

As for buying more stuff to save and join the green hype: panels also need to be produced and shipped. The energy needed to do so appears to be less than what those panels produce in their first 18 months. So the electricity in the next 20..30 years after that is free, green, and effortless.

I was very surprised to find out that solar energy is practical at 52° latitude, but it really is.

Sooo… apart from seasonal swings and energy storage, Jee Labs will be “slightly off the grid” later in 2010!

Then I went back to my Mac and opened a browser window:

It works! You’re looking at a little web server running on a tiny Technologic TS-7500 board:

ARM based, 64 Mb RAM, µSD card socket on board, running Debian (lenny). It’s not very high powered, but in return it only uses 400 mA @ 5V, i.e. it can run off USB power.

I haven’t yet figured out how to get the FTDI USB serial driver on there, but once that’s solved this little unit will be able to act as host for USB-connected JeeNodes or JeeLinks.

The RAM and storage is more than sufficient to run even a very elaborate JeeMon setup, I expect.

This might be an interesting low-end always-on home sensor & automation system!

So I ordered a few more by direct mail, from a Dutch office supplies shop on the web.

Sure enough, one day later – a big courier delivery truck from DHL stops by and delivers a 25×35 cm box with the requested goods:

They could have dropped it in a padded envelope, added €1.60 postage, and dropped it in the mail. Which – in the Netherlands – is guaranteed to reach me in 24 hours, IOW just as quickly, along with all my other mail. Delivered to my doorstep by our friendly mailman, who services the whole neighborhood … on bike.

Instead, I’ve caused this ridiculous packaging and delivery nonsense. Yuck.

Update – I’ve re-ordered some more (slightly larger) bags from another Dutch supplier suggested by someone after reading this post. Not only did that supplier do the right thing – they even alerted me to the fact that another item would have pushed postage up to an unreasonable level, and proposed to omit that extra item. Hurray for vendors who use their common sense when serving their customers!

The Pachube site is one place to send measurement results. I’ve set up a test feed to use with JeeMon, with two data streams. One of the nice features is that you can easily produce and embed graphs from that system:

Here’s how I implemented it in JeeMon. First, I created a configuration section:

(I’ve omitted most of my private API key, but anyone can sign up and get their own …)

Next, the code, in the form of a “pachube.tcl” file / module / rig:

Note how the configuration file in fact contains “settings” which are simply evaluated as a script: the two lines starting with “Fetch …” are handled by the Fetch proc in pachube.tcl, using the JeeMon notification mechanism to get called back whenever either of the “meter1″ or “meter2″ readings changes. The Update proc then updates the “latest” variable accordingly. Lastly, SendToWebSite periodically does an HTTP PUT request in the background, supplying all the info needed to successfully submit to the Pachube website.

Btw, this simple example is flawed, in that it does not calculate averages – it just sends the last reading. But things like averaging require a sense of history, and persistence. Haven’t added that to JeeMon yet…

The missing link, as usual, is a line in the application file to start the ball rolling:

There’s a lot of flexibility at the protocol and network levels. Such as creating an XML request via templates, if the remote server needs XML. This isn’t limited to HTTP requests, or to using port 80 – send emails, FTP files, etc.

There are quite a few details in the above code which I won’t go into. Again, I’m doing this mostly to show how little code it takes to initiate periodic HTTP client requests to an outside website.

Apart from sites such as Pachube, this could also be used from a tiny embedded Linux running JeeMon, to submit incoming data to a different setup elsewhere on the LAN, for example. IOW, JeeMon can be a front-end for other systems. It’s not about lock-in. It’s a switchboard. It can glue systems together. It bridges gaps.

So let’s create another real-time status display, but as web application this time:

As before, I’m leaving out the lipstick – just showing the core functionality.

Here’s what I did to generate this page. First of all, I’m re-using some functionality which is already in the GUI version, to dynamically construct a matrix with the proper columns and rows, so the “statusWindow” code has to be running for the above to work. For real use, that code should probably be reorganized into its own rig.

The main task was to create a HTML template in a file called “statusPage.tmpl”:

This uses a simple templating mechanism based on Tcl’s “subst” command. The meta tag sets up the page to self-refresh every 5 seconds. The last line tells the Wibble web server to deliver the page as HTML.

To launch the server, this line was added to the main application file (port 8080, current dir is doc root):

That’s it – there’s very little to activating a web server in JeeMon, as you can see. Which is important, because on tiny embedded Linux systems, an HTTP server will probably be the only option to present information.

Creating a full-blown site with CSS, JavaScript, and Ajax is a matter of adding more files – the usual stuff…

Did I mention that it’s all 100% open source, so you can browse / extend / change all of this? – I did? Oh, ok ;)