Arduino with TFT Touch Shield

TFT Touch ShieldAfter the TFT Touch Shield I ordered had arrived and some playing around with the examples that were part of the library that can be found here, it was time to do some testing.

For starters I made a small sketch with just a string, 3 ‘touchable’ areas and an icon. The first challenge was making the drawLine() function from the library working; somehow it had problems with drawing the left side of the roof of the ‘home’ icon. No clue why, but it just didn’t work. Only after I changed the parameter types from unsigned int to int and replaced the algorithm with the simplified version of the Bresenham line algorithm the home was correctly drawn.

Next thing I did was printing some touch related information to the Serial and this is what I saw:

X = 611, Y = 442, P = 575
X = 609, Y = 443, P = 536
X = 606, Y = 444, P = 507
X = 599, Y = 447, P = 457
X = 599, Y = 447, P = 449
X = 600, Y = 440, P = 486
X = 601, Y = 434, P = 522
X = 642, Y = 604, P = 470
X = 634, Y = 609, P = 468

Well, so far so good… on to the next phase!

Extra user interfaces

I’ve been looking for an easy way to add some extra user interfaces to my Domotica system, particularly for upstairs. Now that we have a bunch of Radiator Thermostats and Roller shutters both up- and downstairs, the wish for some extra User Interfaces (bedrooms, office etcetera) increased the last couple of weeks. Yes, the Radiator Thermostats can also be operated manually, but that’s not always that convenient; I want something more flexible and versatile.

Should I buy a tablet and put it on the wall? Neh, too pricy and therefore not expandable enough – we would be bankrupt before I could finish this project ;-) .

Or is it better to create a User Interface for the smartphones? Useless for this particular ‘problem’, cause we all have the habit of leaving our smartphones downstairs – no one has the urge to Tweet or call while in bed (yet…). Besides that, guests in our house should also be able to lower a roller shutter without too much hassle.

What I’d like to have is something small & simple, touch-driven, communicating wirelessly, with an easily adjustable User Interface without having to change the code too often and, if possible, suitable to take in your hands.

For that I bought this Touch Shield to tinker with during the next weeks. There are some nice videos that demonstrate what you can do with these Touch shields and they look well enough to give it a try. This particular shield can be used with the Adafruit library, which takes care of the low level stuff and provides functions for stuff like drawing lines, circles, rectangles and text on the screen – with an SD card it should even be possible to draw 24-bit BMP files – well, let that be be step 2 for now.

While this Touch Shield is on its way, I started thinking of how to make this Touch Shield cooperate with my Domotica system. As I said, I don’t want to change the sketch when I want to add another menu option or button or anything else that comes to my mind; the ‘definition’ of the screens, menus, buttons should not be defined in the sketch, but somewhere else. Preferably somewhere on the network in a file; another good option could be stored on a SD card.

This file should contain everything that can be regarded as being subject to change when multiple Touch Shields are going to be used throughout the house: menu options, shapes, buttons, colors, text, actions; so the basic idea is: 1 sketch which can handle multiple User Interface definitions, designed for a specific location/room. So I definitely need some sort of User Interface Markup language for that, like XAML is.  But the markup language to be used should also be really ultra-light-weight, cause we’re still dealing with an Arduino here, where RAM is limited and every bit of overhead leads to problems, very quickly. I mean, you could define a button like this:

<Button Background="Red" Foreground="Green" Content="Light on" Action="C02 ON"/>

but that will consume more memory than

B;BRED;FGREEN;TLight On;AC02 ON

So maybe I’ll create my own Markup ‘language’; we’ll see.

The way in which an action will be communicated with my Domotica system will be something comparable to how our Ethernet Doorbell communicates with the system; for example, when the touch of a button should result in a light going on or off, I can just let the Arduino send a string (the Action property in the examples above) to my system and it will take care of the rest.

Big plans, which also bring a lot of new challenges – and I’m sure, a lot of fun!

Today the color is…

Orange!! ;-)

 

Well, it could just as well have been any other color of the 256*256*256 colors these RGB LEDs can produce, but since today is Koninginnedag, Orange was the most appropriate color I could think of for today.

The last 2 days I started with putting these RGB LEDs in the ground, under the gazebo.

Removing the stones to get the 20 meters of cable under the terrace, grit around the poles and putting everything back in place took me 2 days and I’m still not completely done yet; I think I need another afternoon for the ‘finishing touch’.

 

 

Just for fun I made a small beginning with controlling these LEDs from my system by using scenarios or lighting sequences; here’s what the “random” color scenario looks like:

 

I’m also going to use a remote for these RGB LEDs; I still have an old 433 MHz remote with 8 buttons that can be re-used to select the different scenarios. This remote will be attached to one of the poles of the gazebo so we won’t need to go inside to change the lighting.

With the Arduino acting as web-interface to the hardware, my domotica system and this remote I think we can really enjoy these RGB LEDs during those many upcoming long, hot summer nights!

Broken cables and Ethernet Shield trouble

It’s time for some work outside.. Last summer the play set  in our garden with slide and swings was hardly used, so I guess the kids won’t miss it. The swimming pool has to be filled with water again, the pump has to be put back in its place, the terrace needs some adjustments and of course, the gazebo RGB LED project needs attention cause the crate with the 6 RGB LEDs, DMX decoder & Arduino has been standing in the office since the end of last summer, so it’s time to finally complete this and get those 6 RGB LEDs where they belong – in the garden. I started with the last job ;-)

The first thing I did was completing the indoor part of it all, e.g. putting the adapter, DMX decoder, Arduino with 2 shields (DMX & Ethernet) in a enclosure. This whole setup has already been tested with something I developed last summer. It had a Colorwheel control with which it was very easy to pick a color and control the RBG LEDs. But this is not enough; I still needed to integrate those RGB LEDs into my Domotica system. By doing that, my system is now in full control over the RGB LEDs and they can be controlled based on events, from the GUI (touchscreen) in the living room etcetera. This integration involved creating a Device Class for the RGB LEDs and a suitable interface to ‘talk’ to the hardware.

But not all things went as smooth as I had hoped. First, a power adapter cable was broken, which made the whole setup stop working every few minutes or so. It cost me half the afternoon to find out it was just a piece of cable that was bugging me…

I also applied the ‘Ethernet-shield-powered-from-the-adapter-plug’ fix I wrote about before, but it didn’t help enough. Sure, 4 out of 5 times it worked, but not always. And that’s not good enough, so I searched for another solution and I found one here, and this one worked always – well, successfully powering up 30 times in a row convinced me that this works well enough. So now there’s a wire going from the RESET pin to pin 4 (the Ethernet shield is underneath the DMX shield).

Ethernet Shield fix

The code that comes with it is simple but very effective:

void init_ethernet()
{
 pinMode(DO_RESET_ETH_SHIELD, OUTPUT);      // sets the digital pin as output
 digitalWrite(DO_RESET_ETH_SHIELD, LOW);
 delay(1000);  //for ethernet chip to reset
 digitalWrite(DO_RESET_ETH_SHIELD, HIGH);
 delay(1000);  //for ethernet chip to reset
 pinMode(DO_RESET_ETH_SHIELD, INPUT);      // sets the digital pin input
 delay(1000);  //for ethernet chip to reset
 Ethernet.begin(mac,ip,gateway,subnet);
 delay(1000);  //for ethernet chip to reset
 Ethernet.begin(mac,ip,gateway,subnet);
 delay(1000);  //for ethernet chip to reset
}

Calling the init_ethernet() function from the setup() is all that’s needed to get a fully functional Ethernet Shield. Finally this RGB LED project is finished; well, I still have to dig 6 holes and get the RGB cable under the terrace – after that, summer can begin!

 

Got it!

Yes, yes, YES! I love it :-)

The rethinking of the OpenTherm bit capturing strategy I did a few days ago really did improve things quite a lot, as can be seen on a screendump of my OT Decoder:

"My" OpenTherm decoder

Below is what the Opentherm Monitor, a tool that belongs to the OpenTherm Gateway (yep, I’ve got one of those too, since a week or so ;-) ) is showing in the log:

Gateway Opentherm Monitor

This is great, wonderful result! And the time it took to come this far was well spent, cause I’ve learned a lot in the past days. I’m starting to know the Opentherm Data ID’s by heart, I know some more about the ATMega timers and Manchester decoding has no secrets for me anymore.

You may notice that in my case only the Master (lines with a ‘T’ in them, in both screendumps) frames are decoded and not the Slave response frames (Slave=Boiler, starting with a ‘B’ in the lower screendump), but that’s because I added a delay that causes the sketch to skip the Slave responses.

So the sketch is going to be the next thing I’m going to work on in the next couple of days. But for today, I’m going to relax and and stop thinking about microseconds, timers, prescalers and ISRs;  it’s time for something completely different: a Somfy RS-485 RTS Transmitter for our rolling shutters which will (hopefully) arrive in  a few weeks! That’s why I like Domotica so much – the diversity of things to do and learn.

 

Arduino OpenTherm Monitor Shield

Yesterday Freddy Martens contacted me. His name rang a bell, because I had seen his name before.. yep,  he is/has also been working on the Pale Blue Dot Opentherm Monitor as can be seen in the comments at the bottom of the page. He sent me an email and told me that  he had some Eagle designs for an Arduino Shield for the OpenTherm Monitor. His design is based on the schematic he found on the Pale Blue Dot site which I mentioned before – here and in earlier posts. And he asked me if I could host his Eagle files. Sure!

Arduino OpenTherm Monitor Shield

 

The archive contains both a single-layer and a 2-layer design. He also told me that the designs are not perfect – for example, some of the pads are too small. But this could be a good starting point for others. So if you’re interested, just download the OpenTherm4Arduino archive.

Freddy also provided some images he made of his Arduino OpenTherm Monitor shield, which can be seen here.

Have fun!

Current status on my own OpenTherm Monitor project is that I’m getting lots of decoding errors- but I’m not giving up yet!

 

Bedroom lighting almost finished

A small update with some results on the bedroom floor lighting project.

Bedroom floor lighting

The small red dot in the center of the image above is where the hardware is (the boxed Arduino) with the PIR to the left. It’s hard to make a picture in almost complete darkness – keeping the picture sharp but also getting a result with colors that match with what my own eyes see is not that easy.. But the picture above resembles what I see when I get out of bed during the night well enough – and it’s exactly what I wanted! The LED strips (1.5 meters on both sides of the bed) light up the floor well enough to spot any obstacles, but it doesn’t light up the whole room. And the 15 seconds turn out to be the right amount of time to light up the floor; and the LDR  takes care of unnecessary lighting during daytime; so in one word, the only conclusion can be: perfect! 

One small glitch though, which points out the difference between a clean testing environment and usage in real life: some days ago, when I had to change the alarm clock, I switched on the bedside lamp so I could see the buttons on the alarm clock. This triggered the LED strips to go on!

This means that the switching of the 230V lamp resulted in a ‘spike’ on the PIR sensor input on the Arduino… hmm. I think I’ll have to redo some wiring and use shielded cables instead of the unshielded & untwisted ones I’m using right now. My bad…

Perhaps another solution would be to watch the incoming PIR signal on the Arduino more closely and detect whether it’s a short ‘spike’ or not and decide not to turn on the LEDs on a short ‘high’; but that just doesn’t feel right – cables first!

No more painful toes

This evening I wrote a sketch to protect my toes better. The sketch switches the LED strip on and off based on motion detection by 2 PIRs. It works ;-)

The blue LED on the Protoshield indicates when there is motion detected by the PIR. The motion detection turns the LED strip on and it will stay on until a period of 15 seconds with no motion has passed – only then, the LED strip is turned off again.

The sketch takes care of the “soft on/off” feature, by gently raising or lowering the brightness during a configurable time-span.

All that’s left to do is cleaning up the code, solder some wires, wait for the enclosure to arrive and give the LED strip, PIRs and Arduino enclosure a place under the bed.

Simple, yet very convenient automation :-)

Bedroom floor lighting

Last week I had some trouble getting out of bed during the night without hurting myself. So this evening I decided to do something about that; I need something that can light the floor while someone is walking through the bedroom at night. So I made a list of things with which I could make something useful for that:

  • An Arduino Duemilanove;
  • a Protoshield;
  • 2 PIR motion sensors;
  • a LDR;
  • a  IRLZ34N MOSFET to drive the LED strip;
  • a 12V power adapter;
  • about 2 m. of white LED strip;
  • 2 LEDs (one for power and the other for motion detection);
  • an Arduino enclosure.

 

Automatic Bed light for the night

There it is… our automatic bedroom floor lighting is being tested at this moment. The 2 PIR motion sensors will be mounted under the bed in a way that they will only be able to detect motion caused by moving legs, the LDR will be used to detect whether it’s dark in the bedroom or not and the white LED strips will be glued to the bottom side of the bed and will light the floor when motion is detected.

The fun thing is that this floor lighting is almost completely built from spare parts (except the enclosure). The 2 PIR motion sensors were the first motion sensors I ever bought, but the lenses were too big for my taste to actually use them. Under the bed the size of those lenses doesn’t matter. The Duemilanove is one of the many Duemilanoves I have laying around for testing/experimenting, so I can easily do with one less – I could also have picked an RBBB, Teensy or JeeNode. The number of unused protoshields made me decide for an Arduino. And all the other parts were all purchased in the past with the thought they’d be handy to have around for when you suddenly need them ;-)

No RF, Zigbee or Ethernet this time – this will be a solution that doesn’t need any other external input, nor do I think I’ll use the fact that someone’s walking through the bedroom in the rest of my system. Nevertheless, I’ll reserve some space on the Protoshield for a XBee Breakout board cause this would actually be a very good place for a Zigbee router on the 2nd floor!

The sketch will be a collection of code  from other sketches I’m already using, so I hope that at the end of this week I can finish this and never hurt my toes again ;-)