Preparing for the Arduino workshop

The Arduino workshop I mentioned before, is actually going to happen! πŸ™‚ This will be a busy day, for both the organizing party as well as the attendees! A short list of the things we will be doing during that day:

  • Building an Arduino on a breadboard
  • Soldering a JeeNode
  • The Arduino IDE and testing the JeeNode
  • Experimenting with sensors and actors
  • Building a Room board
  • HomeSeer integration.

Enough to fill a complete day I’d say!

For the HomeSeer integration we’ll be using a slightly modified version of JeeNode for HomeSeer. This script based solution will help the attendees to integrate the hardware they created into HomeSeer in a very simple way. And since all the source code is provided, everyone can extend and/or modify it so that it will fit their personal needs the way they want.

Although I’m not a HomeSeer user, I do have a HomeSeer license that was paid for by a fundraiser that took place earlier this year. So I can play with HomeSeer whenever I like without any dirty tricks while I’m working on the Plugins I created or when I’m doing stuff like this.

I soldered a new JeeNode v4, a Room Board, uploaded the JeeNode sketch and connected it to the AA Power Board:

JeeNode with Room Board

JeeNode with Room Board

The JeeLink sketch was uploaded to the, eh, JeeLink, and I added an extra line to the HomeSeer startup script to get the JeeNode script running. After some initial configuration like setting the JeeLink COM port and some RF related settings, I was good to go:

HomeSeer Status

HomeSeer Status

OK, it’s all working; I can see the Room Board sensors in HomeSeer. Now it’s time to upgrade the JeeNode sketch to make it more power usage aware, cause I assume that will be important for those who attend this workshop. Back at home, they’ll probably start creating their own battery powered sensors, so a good starting point is essential. And that’s what I’m working on right now.

Changing batteries

No, this is not regarding the batteries of my motion sensors πŸ™‚ Those are still running fine since July 29th (3 months); this is about my Oregon Scientific Temp/Hygro Sensors. These sensors are nice; they look good, they have a LCD display which is also useful, and as long as you don’t have too much of them, reception is reasonably good too. However, sometimes, when 2 sensors transmit at exactly the same time, one sensor can prevent another one from being received, but after a day or so this issue resolves itself. I can live with that for now. A more irritating “feature” of these Oregon sensors is that when the batteries are empty and they’ll have to be replaced, the address with which you can distinguish between sensors, changes. That’s not handy, because then you have to change a key value in your running Domotica application.

OS Temp/Hygro Sensor

In my Domotica application, all devices are represented by objects which reside in memory. And when the RFXCOM 433 MHz receiver detects a new incoming OS (Oregon Scientific) packet, it evaluates the packet to get the address and then forwards the complete packet to the corresponding object with that same address. (BTW, this is the only way to efficiently filter duplicate packets, for which all OS & X10 sensors are well known; send an identical packet many times and hope that at least one of them will be received…)

In the past, when I changed the batteries on a OS sensor, I had to look in my ‘valid but unprocessed sensor packet log’ to see what the new address had become, change this value in the database and restart my Domotica app. Not a very smart thing to do; so I changed this procedure a few months ago.Β  I added a new Reload method (called a procedure or function in Delphi) to the Device class of which all other device classes are inherited from. This method does nothing more then a complete reload of the ‘static’ information that is stored in the database: things like the Description, Location, Enabled and some more parameters that control the general behavior of a Device. And, of course, the Address is being refreshed.

This refreshing of the Address results in no longer having a Device object in memory with the old Address, but with the new one; new incoming packets are processed again and I don’t have to restart the complete app anymore: life goes on! All with the click of a button on some device management page on my website. Cool. However, I do still have to manually edit the Address in the database.

Next thing I want to try is make this even more ‘intelligent’ (a synonym for ‘automated’? :-)) : i mean, whenever a specific sensor hasn’t been received for a specific amount of time and another sensor with a new Address (of the same type) suddenly appears, would it be doable to do all this changing of Addresses all by itself? Of course! But, it’s also potentially dangerous; I don’t want my database getting messed up automatically cause that wouldn’t very intelligent!

Another issue is that this has to be dealt with on Interface level, cause that’s where all packets are ‘seen’ before they are distributed and therefore it’s the only place where such decisions can be made. And this goes against my wish to keep an interface class as stupid as possible… OK, maybe I’ll just leave it as it is now…

The surprise-package

As I mentioned earlier, an unexpected package arrived 2 weeks ago. Guess who the sender was: Remeha! That means Remeha must have read my earlier postings about the wonder cable, since this is what came out of the box:

Remeha Recom USB version

The letter that came with it, told me that this cable is a prototype of the Interface cable I wrote about earlier, and that they wished me happy testing with it πŸ™‚

I must admit that this is a very nice gesture of Remeha! Thanks guys!

And of course this prototype is USB; have you ever seen a laptop with RS232 port lately?? No, it’s all USB these days, so if you would ever send out a technician with a laptop to a boiler in trouble, a USB cable is much more convenient than RS-232.

This cable looks very much like the ones i use for my Digi XBees:

3.3V FTDI cable

3.3V FTDI cable

They fit right onto an XBee Adapter and all the stuff that is needed to communicate with a TTL serial device is embedded in the USB connector. That’s why the USB connector is a bit longer than usual. The price of this FTDI cable is around USD 20, so I’m very curious of the price for this new Remeha cable…

Of course, I know why the ‘old’ Recom Interface cable was so expensive; Remeha tries to (partially?) recoup the software development costs by selling it at an unusually high price. But OTOH, these Interface cables are not made for the average consumer, but for professionals; technicians that deal with Remeha boilers on a daily basis and that need the cable for inspection with the use of Recom. I’m curious…

Remeha Calenta connected

The TTL-RS232 converter

The TTL-RS232 converter (click for more detail)

After nearly a full afternoon of soldering, testing, debugging I finished the board shown above. This is not my cup of tea, that’s for sure… πŸ™

I forgot to add 1 wire (the red one to the right of the MAX3232) and the whole thing didn’t work… so I checked if all the wires were there, and I still thought they all were; next I checked if the cable coming from the Remeha was 100% OK – it still was; I re-checked all connections; and finally, after 2 hours, I found that capacitor with one leg connected to nothing. That can’t be right.. after I fixed this everything worked as well as on the breadboard. Pfff.. Next time when I solder something similar, I’ll make a hard-copy of the schematic and I’ll mark the components and wires I finished soldering on that hard-copy, so I won’t make this mistake ever again! After connecting the female DB9 to the RFXCOM RS232 module, I was good to go.

This was the hardest part. From this point everything went very smooth:

  • I changed the Calenta Interface settings from using a Serial to using a TCP Connection, as in:
Connection=SER
COMPort=13
Baudrate=9600

to

Connection=LAN
IPAddress=192.168.10.131
IPPort=10002
  • I built my Domotica Delphi project (nothing more than Shift-F9 inside the Delphi IDE);
  • I set the Remeha Interface “AutoRun” property to True in the database, which means it will automatically start whenever my Domotica system restarts;
  • Created a backup of the executable I used until now (v145, with v1 being 5 years old right now);
  • Copied the newly built executable to my Domotica VM;
  • And restarted it…

Ooww yeah, this is it πŸ™‚

A long-cherished wish has been realized; unexpected, relatively simple and cheap!

Calenta charts

Calenta charts

Calendata

Connecting the Remeha Calenta

Normally, connecting a new device means more cables. And I want everything connected to my LAN (or WAN), so I need to convert the RS-232 to Ethernet somewhere.

Although I have Ethernet near the Calenta, that single cable I have over there is being used by my HA7Net, which takes care of counting the hot water usage with a 1-Wire DS2423 counter and measuring the Temperatures of the 5 floor heating groups. So that’s a no go; I can’t use that cable without adding another switch; and I don’t want to, for just 2 Ethernet connections.

Then I realised I still have an unused RFXCOM RS-232 module, and it’s put inside a RFXCOM LAN Interface that’s right above my head (between the ceiling and the roof, that is). This RS232 module was once used for one of my Sony EVI-D30 PTZ cameras with VISCA-protocol, but since this cam has been replaced with a fixed one I don’t actively use this RS-232 module anymore. This saves me a RS-232 to Ethernet converter with another power adapter…

So now I had to find a way to get the cable from the Calenta to this LAN Interface. Getting a 4-core flat phone cable through 2 narrow holes in 30 cm thick walls which are already populated with a bunch of other cables is no fun, but after a few hours I managed to get it through without damaging anything. Pffew..

Now it’s time to get the MAX3232 from the breadboard into an enclosure. I was thinking of creating something like this:

Add a few capacitors, wires, female DB9 connector, a small box and I’m done; and that’s what I’m working on right now. The fact that I’m not able to connect the Remeha directly to my PC anymore (to test the new interface) doesn’t really bother me anymore; I’ve seen enough comparisons of results of my Domotica system and the Remeha Recom software (which needs a COM port) that I’m confident enough that I won’t need Recom anymore to check things; and if I do, I can always use an 32-bit XP machine and a virtual COM port driver for that… it’s time to Ethernet-enable my Calenta and move on!

More about the Remeha protocol

This evening i spent some time on trying to figure out the meaning of all the bytes that make up the response. I already knew where to locate the information inside a packet by a brief analysis of the packets a few days ago, but to make things a bit more stable, I knew I had to dig a bit deeper to find out as much as possible. Cause the more you know, the more checks you can build into the software which results in less chance that invalid packets slip through that could possibly crash the system.

When I started analyzing the responses from the boiler, I started with the Sample command. Here’s an example:

0201FE064802018C145A140080008080F3008003100080401F
701700800000000000BC020000006400000010C20B1000FFFF
00000000FFFF1700BC0200000000000000000000002C4303

I already found out that the part marked in blue contains the payload e.g. the ‘interesting stuff’ some days ago, so let’s focus on the remaining bytes:

0201FE06480201 and 2C4303

The 02 at the beginning and 03 at the end are common values for start- and end bytes, so let’s assume this is the case here also, so now the unknown bytes left are:

01FE06480201 and 2C43

The size (2 bytes) and the position inside the packet (at the end) made me think that the 2C43 could very well be a checksum, and it is: it’s the CRC16 (Modbus variant) of the complete packet without the start- and end byte (and of course the checksum value itself); so based on the packet above the bytes of which the CRC is calculated are:

01FE064802018C145A140080008080F3008003100080401F
701700800000000000BC020000006400000010C20B1000FF
FF00000000FFFF1700BC020000000000000000000000

The Modbus variant of CRC16 calculation differs from a “standard” CRC16 calculation in that the initial value isn’t 0 (zero), but $FFFF. Being able to validate the checksum is very valuable and adds a lot to the robustness of this interface.

So now all that’s left are these leading bytes:

01FE06480201

To understand the 01FE part, I looked at some outgoing packets, these look like this:

02FE010508020169AB03

Again, after removing the start- and stop byte and the checksum we see this:

FE0105080201

Compare thisΒ  with what is still unknown from the response:

Incoming: 01FE06480201
Outgoing: FE0105080201

The first two bytes seem to be the addresses of the source and destination device; this is not that strange as it seems; although this is a 1:1 communication, since there seems to be some Modbus inheritance in this protocol (the CRC16) and knowing that Modbus allows for more devices to be on the same bus, it ain’t that strange at all. Looking at other packet types (blockings, lockings, counters) I always see these 2 bytes coming back, so it’s fair to assume these are used for addressing. Now we’re down to 4 bytes:

06480201

$48 = 72 decimal. Packet size! Another important item to validate the incoming data stream.

Believe me, (I won’t bore you with examples of all the other packet types) 0201 is the function code or command code or whatever you like to name it. It identifies what the payload is about. 1 byte left, the 06. Protocol version? I don’t know yet. Maybe some day I will…

Subscribing to comments

One thing I really don’t like about commenting on other peoples blogs, is that you always have to go back to see if there has been a reply to your comment. Most of the times I forget about it. Last evening i bumped upon a WordPress Plugin that takes care of just that. Well, that’s not entirely true: it does, but only for commenters on my own blog of course. So this Plugin doesn’t help me, but it will help those who leave a comment here. That was good enough for me to install this Plugin, cause why wouldn’t others feel the same way about the annoyance of having to revisit a weblog just to see if a reply was made? So enjoy this Subscribe to Comments Plugin.

Calenta Interface under construction

I don’t think I ever wanted temperatures to drop and be forced to wear a coat when going outside. No, the warmer the better for me… but this time it’s different… I want to test my newest Interface! But as you can see by the chart below, the weather is not really cooperating:

Thermostat setback and temperature in the living room

Thermostat setback and temperature in the living room

So I think I’ll just have to wait a while for the temperatures to drop before I’m able to test my Interface really well. I finished the part that parses the samples from the Calenta and I created a page on my website that partly shows the values it returns (taken from a real sample coming from the Calenta), but I still have to look into the counters and blockings, of which the latter one can be very interesting with respect to being notified about problems with the Calenta. But first I want to thoroughly test the sample part before moving on. And I’m not going to raise the setback temperature just for the sake of testing…

Remeha Interface sample

Remeha Interface sample

So no more coding on this Interface until this first part is finished and working OK.

Ooh, BTW… DHL paid me a unexpected visit today with a nice surprise… more on that later! πŸ™‚

Monitoring the Remeha Calenta

Last week I attached some 1-Wire temperature sensors to the floor heating tubes to monitor flow- and return temperatures. While I was doing that, I looked at my Remeha Calenta again and thought what a pity it was that I failed to monitor the Calenta with the Remeha Gateway. I’ve known for a long time that there’s a 2nd solution to this: Remeha Recom. A “special cable” and the Recom software make it possible to monitor your Remeha Avanta, Quinta, Calenta (and more). However the price for this cable is rather high; you won’t be able to get it below 130 Euros with as only result a Recom window on your screen where you can see all kinds of things being monitored… all you can do is make a screen-dump or log the values to a file… πŸ™

And if I would buy that “wonder cable”, would I be able to understand the protocol? I didn’t want to risk the chance of buying that expensive cable and not coming any further than using Recom, so i stopped thinking about it. Untill last week.

I started roaming the Internet for more information; I read about “it” being a null modem cable; I looked at the PCB and saw the RJ-11 connector for the Remeha cable was labeled RS-232; I took a long cable with a RJ-11 plug and stuck it into the connector and started measuring with a voltmeter; I saw the outer 2 were 5V and the other GND; that leaves the inner 2 for the serial part. I started thinking about what this super duper Remeha cable could hide inside to make serial communication work? There has to be something special to it… converting TTL to RS-232 perhaps? Why not give it a try…

I have a MAX3232CPE laying around for some time; so I planted it on a breadboard, added some 0.1 ΞΌF capacitors and built this schema I found (click it):

Here’s the result:

TTL <--> RS232

TTL <–> RS232

Guess what… it works!! My Remeha Calenta was recognized immediately and I watched the data arriving in Recom:

Remeha Recom v4.1.1

With no more than 8 Euros I created my own interface cable; too ridiculous… Special cable?Β  My A!@&%#%^!!!

OK, but this was just the beginning. With a serial port sniffer i saw the Calenta being queried and I started recognizing the flow temperature, return temperature etc. in the responses that came back from the Calenta. These packets look like this:

02 01 FE 06 48 02 01 F0 14 AA 14 00 80 00 80 86 F3 00 80 B7 10

00 80 40 1F 70 17 00 80 00 00 00 00 00 BC 02 00 00 00 00 64 00

00 00 00 C2 0B 10 00 FF FF 00 00 00 00 FF FF 17 00 BC 02 00 00

00 00 00 00 00 00 00 00 00 C5 9B 03

After an hour or so, i knew where to find some temperature values and stuff like that. The F0 14 marked in red for example, means 53.60 degrees Celsius. That was easy… not good enough for a quiz πŸ™‚ But I also saw on the amount of values Recom could produce from the incoming bytes, some things had to be stored in bits; the on/off, yes/no, open/closed values appeared not to be stored in a byte, but ‘hidden’ somewhere in a bit maybe? Hmm, how do I know exactly when the Gas valve opens or closes, so how I can locate the bit for that? If it is stored in a bit? This could become a bit more challenging and time consuming than I would like.

Aha! There’s a config directory belonging to the Recom software package, containing XML files; one of them was named exactly like the model that Recom detected. Let’s have a look inside that file… Bingo! These XML files contain very detailed information; they tell me that I can find that Gas valve value in bit 0 of byte 38… Yeeha!

Now it’s just a matter of finding out some more about the leading and trailing bytes and I can start creating my own Remeha Calenta interface to my Domotica system.

Finally I’ll know what the Gas is being used for: DHW or heating. And when the water pressure drops below a value I find alarming, I can be warned before it’s too late. And I can see how much power is actually being produced; and …

Update: RJ-11 is incorrect; it’s a 4P4C connector!