The new code is progressing nicely. First step was to get a test table, updating in real time:
(etc…)
It was a big relief to figure out how to produce graphs again – e.g. power consumption:
The measurement resolution from the 2000 pulse/kWh counters is excellent. Here is an excerpt of power consumption vs solar production on a cloudy and wet winter morning:
There is a fascinating little pattern in there, which I suspect comes from the central heating – perhaps from the boiler and pump, switching on and off in a peculiar 9-minute cycle?
Here are a bunch of temperature sensors (plus the central heating set-point, in brown):
There is no data storage yet (I just left the browser running on the laptop collecting data overnight), nor proper scaling, nor any form of configurability – everything was hard-coded, just to check that the basics work. It’s a far cry from being able to define and configure such graphs in the browser, but hey – one baby step at a time…
Although the D3 and NVD3 SVG-based graphing packages look stunning, they are a bit overkill for simple graphing and consist of more code for the browser to load and run. Maybe some other time – for now I’m using the Flot package for these graphs, again.
Will share the code as soon as I can make up my mind about the basic app structure!
The 9 minute cycle could be: 4 minutes heating and then 5 minutes off “anti-pendel” mode… At least, that’s what my heater does. Do you have floor heating?
You’re progressing nicely! I’ll just wait patiently and harvest your code, as I’m not capable enough to make it myself!
That 9 min cycle points at a classic “hunting” control loop, typical of on/off control. The gas boiler may have limited modulation of the actual flame size, so is fundamentally strong heat input/(medium heat)/no heat input. Since the heat demand does not match heat output, there is no choice but to PWM the boiler on a very slow clocktime.
Interestingly, the mark/space ratio gives a good indication of the residual capacity in the system. A common error is to size the heating system for the estimated heating losses of a dwelling – fine for steady state, but totally inadequate for getting “stone-cold” from say after a long weekend break, up to a comfortable temperature in a reasonable time.
Why not use RRDTool and cacti, instead of reinventing the wheel? Or are you just going for something super light weight?
More responsive, more dynamic, more in the browser, is my aim. I haven’t decided on data storage – am still looking around, but NoSQL solutions don’t seem like a good match to me for what is essentially scientific data processing and storage. And yes, light weight by all means: I’ve only written a few hundred lines of code so far, most of it for the decoders.
I’ve been using Flot as well, until now. Works pretty good, though visually it’s not really stunning.
Hope to look into Jit this weekend, the examples looks promising, and the code to generate them seems clean enough for me (got a little “flot” feeling to it, on first look).
http://philogb.github.com/jit/
NoSQL, like Redis, look like a great way to store current state and also transfer informations between different modules. Why not use this as kind of a bus to transmit raw packets from different sources into the central (node.js) server? Then decode packets in the server and push the resulting state out to Redis again. So everyone is able to build his/her own modules just by conencting to Redis.
Using FIFOs on Redis could implement some additional buffering if the node server is not available for whatever reason. Additionally the Pub/Sub channels would allow realtime-notifications not only inside node.js but also to external programs, even on different systems.
As jcw already wrote, NoSQL is not that useful for historic data. Even big network monitoring products use a bus-system for data acquisition, current state propagation and alarming but a classic SQL database for historic data. A combination of NoSQL (current state, FIFO, even configuration data) and SQL (for historic data) looks like the way-to-go for me.
I used Highcharts for nice client-side graphs. Works well, looks nice but it’s a commercial product (free for personal use).
What software are you using to transmit the data? I’ve started using the TinyTX sketches in order to transmit in a manner that OpenEnergyMonitor can capture if required, and my own Python app to push the results from RF12Demo onto the MQTT broker for later reuse.
Actually, that was an ill-advised post. It’s all so flexible, it’s probably roomnode, etc :-)
Node.js connects to a JeeLink running RF12demo via serial/USB/FTDI, decodes the packets, and sends them out to clients via SocketStream (which uses WebSockets internally). Yes, that last graph uses data, coming mostly from a bunch of room nodes (also some otRelay and ookRelay feeds).
As you say, trivial stuff really. Since RF12demo is generic, it’ll report any RF12-based packets.