Archive for the ‘Super-Secret Project’ Category

…jumps over the lazy dog!

Quinta-feira, Fevereiro 17th, 2011

There is one part of the HMI system I did in a somewhat “lazy” way. I’m creating display objects (JFrames, charts) in memory for each of the display elements. While this ends up being a nice tradeoff between memory and speed (changing between elements is near-instantaneous), I should probably reduce the memory footprint of the HMI application.

Then again, this version has quite a lot going on (charts, threads, etc), and I should probably leave it alone and develop an alternate, slimmed-down version (to run on embedded and tablet machines). Without charts or Swing widgets, pure raster graphics, like a game. After all, I won’t need charts on every element in every control point of the home automation. Most of the time I just want an overview of the house, give some commands, check out the results, and be done with it. Quickly. If I must analyse something, the historic screen is a very capable tool.

Next up, is creating a simple, yet good Web-based interface, or at least a simple dashboard. Check out this project’s web interface, it’s really cool!

And while I’m at it, create a version of the server app without the JFrame… and a socket I can connect to to send commands (Start/Stop).

The quick brown fox…

Quinta-feira, Fevereiro 10th, 2011

In your home, when you touch a button, you expect the associated lamp to light immediately. For example, if you open the door to your basement, you need light right now to go down the stairs safely. Waiting a couple of seconds for the lamp to light is not expected, nor desirable. After all, the most basic and primitive lighting controls work directly on the power source, and act immediately, so when you have a state-of-the-art home automation system installed you expect the very same performance.

But, from a developer point-of-view, when you have a network of almost 20 nodes, you need to pay close attention to your data paths if you want to achieve lightning-fast response times. I’m working on the near-realtime domain, but I need to be as close as possible to real-time.

So, I’ve been finetuning my home automation’s data subsystem. I think is it of the utmost importance that the controls feel immediate, quick and nimble. And the physical controls (wall buttons) need to behave real-time, or very, very close to it. The HMI (geared towards touch panel use) needs to behave accordingly, and flow at least as fast as your mind can move your finger. That’s why I’ve developed my home automation’s HMI to be that fast.

Usability is a heavily studied subject, but a historically highly neglected one (although nowadays things seem to be improving). Thankfully I’ve had some training on the subject (and I must thank my University teacher that introduced my to the art, she was inspiring), and you can be sure it won’t be neglected.

I’ve had to tweak the data gatherer thread on the server application, adapt the nodes’ firmware, and scatter data polling in the time domain. Talking in numbers, I reached a half-second (median) response time in the physical control buttons, which seems to be perfectly acceptable. This performance is on a 500Mhz AMD K6-III CPU, 196MB RAM, still running under Windows XP. The final target machine will outperform this test-bed in every aspect (and it will not normally run Windows, but a very light Linux distro, AmigaOS, or MacOS X), so I’m quite happy with the results so far.

Obviously, I have a plan B to accelerate this even further if needs be. It involves bypassing each nodes’ polling overhead, by centralizing data in the header node and fetching in one go (asynchronously). Heck, I even have a plan C to respond in the minimum time possible, involving a full duplex protocol on the header node. Plan C will eventually get implemented (once I sort out the asynchronous communication arbitration between nodes), since it is the best way to do it.

Onwards! :)

My house is growing up

Segunda-feira, Fevereiro 7th, 2011

My super-secret project advances pretty well! Ok, so my home automation project is not that super secret anymore, but the progress is definitely there.

The network of nodes is working perfectely, lighting and blinds control is 100% done in terms of logic (I still need to prettify these elements visually), as are the temperature sensors. The sensors still need some low-pass-filtering, because the noise is a bit harsh for the logic I need the nodes to execute in “Emergency Mode”.

Yes. Emergency Mode. When the control machine is offline, the home automation keeps on going. The nodes, when not talked to for a few seconds, take control of their critical systems. Lights, blinds and climate control keep on going in a basic way, so that you still can control your house. You loose special control routines, like turning on lights based on motion sensing, opening blinds to harvest the sun’s heat in winter, blind positioning, earth tubes house air intake, etc, but the basic funcionality is always there.

In the beggining, this emergency mode was the mode the home automation was running in, every day. Now the control “server” is online, the system is accessible remotely, and complex control can easily be achieved.

The climate control system is now coming along nicely, including control of radiant floor valves via temperature sensors, solar hot water tank (with solid fuel boiler support), and earth tubes for the house air intake (with direct exterior air alternative).

The roadmap includes the complete security system (that is presently working but via a very quick and dirty hack, needs reimplementing) with volumetric and periferic sensors, the botanic manager (gardens, vegetable growing, fruit trees, greenhouse, etc), and meteorology center. There are a couple of very advanced (and useful) features planned, but that will be a surprise… :)

Stay tuned for more info!

Muito movimento

Terça-feira, Setembro 28th, 2010

Há pouco tempo comecei a procurar sensores de movimento para o meu projecto ultra-secreto; mas nas lojas aqui da zona (electrónica, electricidade, chinesas…), só encontro sensores com alimentação de 230V, alguns até preparados apenas para ligar uma carga de 230V (o neutro da carga é comum com a alimentação). Ora eu preciso de sensores com alimentação a baixa tensão para não ter problemas de “certificação” (12V era óptimo) e com relés independentes, que não precisam de ser grande espiga em termos de capacidade de carga, porque apenas vão dar sinal a uma entrada digital de um microcontrolador.

Finalmente descobri que aparentemente, todos os sensores de centrais de alarme são assim, ou muito parecidos. Como não conseguia encontrar nada cá, encontrei uma loja na Internet que me parecia boa e encomendei alguns sensores: uns caros e uns mais baratinhos para experimentar. Duas semanas depois chegou a embalagem com os 5 sensores. Estou a pô-los à prova enquanto defino a estrutura do quadro eléctrico, e depois dou novidades!

Depois vou ver se encontro uma loja aqui neste jardim à beira-mar plantado que me venda este equipamento…

Dealing with PT1000 probes

Terça-feira, Agosto 3rd, 2010

I designed my new central heating system in the most flexible way: it basically has heat generators, heat consumers, and a heat store. It has a hot water cylinder, used as the store; the generators are 6 solar panels (thermal, not photovoltaic), and a wood-based water boiler (the livingroom fireplace); the consumers are the hidraulic radiant floor (used to warm-up the house), the domestic tap hot water, and the swimming pool.

My new system as just been installed (a Rigsun Stratus cylinder with Alpin panels) and is working very well (a big thankyou to the HotSeason guys! ;) ); now I want to keep a record of all the relevant system’s temperatures. The solar controller has acess to many, but I also need to know the radiant floor intake and return temperatures. For that, the fitters installed a couple of sheaths to receive Rigsun (actually, Resol) PT1000 probes.

I’m using an Arduino to bridge the software to the PT1000 probes, so now I only needed to study the details of the sensor reading circuit. The PT1000 changes it’s resistance with temperature, more specifically 3.85Ω per degree Celcius. I’m looking for the simplest solution that fully satisfies my needs (read: cheapest possible). A simple voltage divider circuit will give me a voltage value the ATMega can read. The PT1000 ranges from 1000Ω to 1385Ω from 0-100˚C, wich translates to a small voltage range. A simple study showed me which was the best candidate for a company fixed resistor that gives the bigger voltage swing:

I simply plotted the voltage divider equation. The red curve is the output voltage, the blue curve is the voltage swing in function of the companion resistor value. In the best case resistor (about 1150Ω, that’s the highest point in the blue curve) we have a 0.4V swing, but values in the 2.5V area. In the simplest cases, the ATMega reads values from 0-5V or 0-1.1V (internal reference). With the 5V reference, that’s a 1.2˚C resolution, not great.

I tried to change the resistor to lower the working voltage (to be within the 1.1V reference); that gave me a 5500Ω resistor, 0.23V swing, and a final resolution of 0.45˚C. Much better. Obviously, a better approach was to use an opamp to amplify the signal, or buy an off-the-shelf PT1000 4-20mA converter. But remember, I’m looking for the simplest/cheapest solution. Half a degree Celcius of resolution is good enough for what I have in mind.

I know I said this worklog would be in portuguese but hey, this post was already written by then… sometimes the Internet time flows in wierd patterns… :)