Heating system with RS232

Developer's Corner General Dev Discussions
1

I want to control my ETA SH-30 with my Vera.
The ETA has an RS-232 connection, and I have a working USB-to-Serial adapter, so all hardware is in place. :wink:

I worked through the forum and wiki, and I think I have made a good skeleton of a device Luup file.
What I know about the ETA:
Serial settings: 19200/N/8/1
Commands are sent between { and }
e.g.: {ME00} (hex 0x7B 0x4D 0x45 0x00 0x00 0x7D)
The first digit is the length of the command, the last digit is a checksum.

To request temperature readings (there are a lot of sensors), you can use the command
{MC…}
E.g. to get a temperature reading of the boiler every 10 seconds:
{MC 04 31 0x0a 0x08 0x00 0x0d}
The ETA answers with:
{MD 05 188 0x08 0x00 0x0d 0x01 0xa6}

To start with, it would be enough to be able to send these commands and to display the response somewhere.
Could someone give me some hints where to put this code, and what it would look like?

TIA

2

@Pinx,
If you have a Copy or URL to the API Reference manual you should attach that to your post also.

Folks will probably want to see if there’s any other form of Delimiter in the Request/Response string pair, along with some of the semantics of the request.

eg. If I make the “every 10 seconds” request you indicate, will the Boiler/Burner call me back every 10 seconds from then on, or do you have to keep calling it?

eg. are there any [tt]CR[/tt], or [tt]CR-LF[/tt], characters in between requests or just the { / } chars.

If not [tt]CR[/tt], or [tt]CR-LF[/tt], you’re going to need the [tt]raw[/tt] [tt][/tt] tag in your implementation file, and you’ll have to process responses in a “byte-by-byte” manner.

Looking over your comments, it seems like the format might be more

  <byteCount> <openCurly> <char1> <char2> ... <char-n> <closeCurly> <checkSumByte>

There are a bunch of questions like these that’ll be easier for someone to work out with the Reference manual handy.

Given what you’re trying to do initially, it might be easier to start with the [read-only] Weather Plugin as the base for your code (since it has a way to render the Temperature) or perhaps the Somfy Blinds demo (since it’s doing low-level IO).

From there, you can overlay “pieces” of the [tt]I_GC100.xml[/tt] file to handle the IO. It’s probably not the best to base your code on since it’s a Device that creates/manages devices, with all the complexity that goes with that.

eg.
[tt][/tt]
…code with luup.io.read() calls
… clearing the buffer when you get a “{”
… appending to the Buffer otherwise
…bufferring the raw bytes until you see the “}”
… decoding the resulting “command response” from the buffer and doing something with it.
[tt][/tt]

[tt]raw[/tt]

and a few others that you can slice out of I_GC100.xml, and the Somfy Blind demo

Over time, as you learn it, you can move over to implementing the Thermostat controls, since you’ll presumably want to interact with your furnace (Temp Up/Down etc)

The key to writing this stuff is to start small, get it working, and then add to it. Simplifying your initial effort as much as possible will help you get some initial progress, early, and avoid frustration.

Some starting thoughts to get you going initially:

a) Get familiar with logging onto Vera directly, using SSH … you’ll need this a lot.
This is outlined in the Somfy walkthrough Wiki page if you haven’t seen that already.

b) reduce the [tt][/tt] block down to simply [tt]luup.log(luup.io.read())[/tt]
That’ll print everything coming in from the Burner. If you put on Verbose Logging then you’ll also see this data, as Vera’s framework will print it in the log files ([tt]/var/log/cmh/LuaUPnP.log[/tt])

c) Have your startup function use the [tt]luup.io.write()[/tt] call to write out some “binary” of a Command, similar to the commands you listed here.

 [tt]luup.io.write("...")[/tt]

If you get the above logic working, then you have a starter device to expand upon. With the above type of steps, the device would “request” something [once, at startup] and print diagnostics of the output.

If it helps, when I first wrote one of these I first worked by having a Terminal emulator (under Windows, but Mac would work also) connected to the USB-Serial port. I got very familiar with the codes being sent/received in my Alarm Panel and when that information would come.

Then I started with very minimalist Luup code blocks ([tt]I_Xxxxx.xml[/tt]) derived from the Somfy examples to get the initial communications going.

3

I’m still waiting for the API, but in the meantime I expanded the D, I and S files.
For me, it’s a lot of guesswork as to what is necessary and what isn’t…
I entered several sections to see how they turn up in the Vera GUI. I get scenes, events and commands in my Vera, so that’s looking good.
Next step would be to connect the serial cable to my computer and see what data Vera sends out.

Two things that I want to start with:

  • Command: switch heating circuit 1 on and off (there’s two circuits)
  • Event: receive temperature

If anyone cares to comment on my files…
Is rs232</…
enough to hook up the ETA device to the serial port?

BTW: I could not find this TestSerial.xml that’s mentioned everywhere.

4

A few comments:

In D_Eta1.xml…

[ul][li]The [tt]serviceId’s[/tt] declared in the Scene list don’t match those declared in [tt]serviceList[/tt] block.

I believe these need to match, since they get “generated” into an actual Method name in your Implementation, by Vera when you upload, and it won’t be able to find them at runtime unless they match “by name” (both [tt]serviceId[/tt] + [tt]action[/tt] are used by Vera to build the internal naming… in the internal workings of Vera that is…)

[/li][li]The Labels (etc) in the Service List don’t have to have the “1” in them.

These are usually the pretty strings that get displayed to the User in the Selection lists during Scene creation. Make them as readable as possible, so people know what they are selecting when building Scenes (etc).

[/li][li]Your Actions are currently declared without Arguments/Parameters.

… which is fine, but in the Scene versions of them, you’re passing an argument/parameter called “[tt]newTargetValue[/tt]” which doesn’t exist in the Action definitions (S_Eta1.xml).
[/li][/ul]

In I_Eta1.xml…

[ul][li]serviceId’s are different again.

Throughout all your declarations (etc), the [tt]serviceId[/tt]'s that are used should be consistent. Across the 3x files, you have used the following id’s, and these need to be aligned to a single standard:

[tt] urn:micasaverde-com:serviceId:Eta1
urn:upnp-org:serviceId:Eta1
urn:eta-co-at:serviceId:Eta1
[/tt]
[/li][/ul]

To hookup to the Serial device, you first attach the USB-Serial Cable to Vera. Once that’s done, Vera will/should automatically recognize it.

It then appears under the menu:

Devices → Luup Plugins → Serial Ports

See the Sticky thread on Serial cables if it doesn’t appear. In that UI, you can configure the Baud Rate, Parity, etc, etc, along with the Device-association.

If your ETA Plugin code is installed, and fully recognized by Vera, then you should see it listed in the Drop down list.

The Serial Port UI/Configuration screen looks like:

http://wiki.micasaverde.com/index.php/Image:ParadoxAlarm-VeraSerialConfig.png
5

Hello Pinx, how is working with your plugin development? Let us know if you need any further assistance.

6

Hi,

I still haven’t received any information from the manufacturer, so I’m trying to get further with information like this:

There´s some code samples for calculating the checksum and such.

To test the serial connection, have connected my laptop to the Vera and my laptop to the ETA. Both seem to work.
I have found a way to make the ETA send a few characters, and I can see them on my laptop. I haven´t succeeded in making the Vera receive anything.
I don´t know how to test this in the Luup code test form. Is it at all possible there?
I have defined an segment in I_ETA1.xml, but I don´t see anything happening in the log, so it seems that receiving data does not work.

I have searched everywhere for I_TestSerial.xml. On the wiki page ¨Luup somy walkthrough¨ it is mentioned, but I can´t find it.
I don´t know if it would be of any help, because most serial devices are about sending commands to it, not receiving data from them.

Things I could try now:

  • Send a command from the Vera to the ETA that will trigger some action.
  • Send a command from my laptop to the ETA that will trigger the ETA to start sending data. I have to figure out how to send hex codes… I´m using Minicom on Kubuntu.
  • Send data from my laptop to the Vera to find out if I can get the Vera to receive and log incoming data.
7

attached are the Somfy drivers. Whatever you were going to get from [tt]I_TestSerial.xml[/tt] you can probably extract from these.

I “Installed” the Plugin (from the Catalog) and just saved these sources to save you the extra steps.

Can you confirm that the USB-Serial Port is recognized if plugged into Vera, and that you can set the Serial Port Baud Rate etc to what’s required by your furnace?

Can you also confirm that you get no errors in Vera’s [tt]LuaUPnP.log[/tt] file when you install/run your plugin, especially after you Configure the (Serial Port Configuration) section of Vera to Assign your new Serial port to your Plugin code?

8

Hi,
I had a look at these Somfy files before. I used some parts of it.
I also used some parts of DoorLock, because this is a device that receives input.
However, the handling of received data is not in an I_DoorLock.xml, so that is a part I have to make up myself.
Serial communication is ok, no error messages in the log.
When I do luup.io.write in the script test form, I see that on my laptop (minicom). The other way around - from my laptop to the Vera - is what I can’t get to work.

I am probably making stupid mistakes. It’s so difficult to figure out how to attach the three files (S, I and D). It is also difficult to understand what needs to go where.

Thanks

9

There was an error in the files.
I used verbose logging, which helped.
These files do not give errors, but still do not work, though.

10

@Pinx,
You’re certainly closer.

You can see that parts of what you’ve written are working. Trying running a URL Like:

http://192.168.x.y:49451/data_request?id=lu_action&output_format=json&DeviceNum=55&serviceId=urn:eta-co-at:serviceId:Eta1&action=Heating1On
against your Vera. Substitute in your Vera's IP address, along with the Device # as listed in the Luup Plugin Devices list.

I temporarily installed the codebase into my Vera, and it allocated “55” as the Device#. Using the URL above, I get something like the following (with Verbose Logging level enabled):

[tt]10 01/11/10 22:52:32.565 luvd_get_info_data_request starting /data_request?id=lu_action&output_format=json&DeviceNum=55&serviceId=urn:eta-co-at:serviceId:Eta1&action=Heating1On pMem 0x9a3000/10104832 diff: 3104768 <0x2c0c> 10 01/11/10 22:52:32.567 JobHandler_LuaUPnP::HandleRequest id lu_action request pMem 0x9a3000/10104832 diff: 3104768 <0x2c0c> 10 01/11/10 22:52:32.568 sbrk JobHandler_LuaUPnP::HandleActionRequest pMem 0x9a3000/10104832 diff: 3104768 <0x2c0c> 08 01/11/10 22:52:32.569 JobHandler_LuaUPnP::HandleActionRequest device: 55 service: urn:eta-co-at:serviceId:Eta1 action: Heating1On <0x2c0c> 08 01/11/10 22:52:32.570 JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=55 <0x2c0c> 08 01/11/10 22:52:32.571 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:eta-co-at:serviceId:Eta1 <0x2c0c> 08 01/11/10 22:52:32.572 JobHandler_LuaUPnP::HandleActionRequest argument action=Heating1On <0x2c0c> [b]50 01/11/10 22:52:32.574 luup_log:55: ETA action Heating1On <0x2c0c>[/b] 10 01/11/10 22:52:32.576 luvd_get_info_data_request creating file buffer /data_request?id=lu_action&output_format=json&DeviceNum=55&serviceId=urn:eta-co-at:serviceId:Eta1&action=Heating1On pMem 0x9a3000/10104832 diff: 3104768 <0x2c0c> 10 01/11/10 22:52:32.577 luvd_get_info_data_request done /data_request?id=lu_action&output_format=json&DeviceNum=55&serviceId=urn:eta-co-at:serviceId:Eta1&action=Heating1On ret 0 pMem 0x9a3000/10104832 diff: 3104768 took 0 info 0x7e3ffb48 <0x2c0c> 10 01/11/10 22:52:32.579 luvd_open /data_request?id=lu_action&output_format=json&DeviceNum=55&serviceId=urn:eta-co-at:serviceId:Eta1&action=Heating1On FileBuffer 0x7c61f8 <0x2c0c>[/tt]
In the middle, in red (my coloring), you'll see the output from your method call's [tt]luup.log[/tt] starting with a "50" status code.

You could now go and add a [tt]luup.io.write(…)[/tt] call instead, and you’d see that data being “sent” to your furnace. If it’s a well-formed command, then the furnace will likely respond with some characters back.

Data coming “back” from the furnace, will be logged as something like:

[tt]52 01/09/10 18:07:55.832 0x47 0x30 0x30 0x31 0x4e 0x30 0x31 0x36 0x41 0x30 0x30 0x31 (G001N016A001) <0x3c10> [/tt]
This example is extracted from my log files for the Alarm Panel, but you'll get a "52" status code preceeding the data coming back (before your "incoming" block is called), and a "51" for anything you send with [tt]luup.io.write(...)[/tt]

It’s entirely possible that you’ll never get anything back from the furnace until you send it a valid command. There are lots of “Client-Server” apps like that where the Client must initiate the request, and only then the Server will respond.

My Panasonic TV works like that. It will not send you anything until you send it a valid command.

My Alarm Panel is more Event driven, so you can get data from it any time, and send it data at any time.

Anyhow, if you have a command string that’s valid, try sending it in one of these action methods, and see if the Furnace responds. Hopefully you can find a benign command to send/test like “what’s the temperature” (instead of “please burn my house down” :slight_smile:

btw, in [tt]D_Eta1.xml[/tt], my original comment:

Your Actions are currently declared without Arguments/Parameters.

still applies. You’re passing a parameter that the Method doesn’t have. Instead this should be declared as:

<sceneList> { "group_1":{ "cmd_1": { "label": "Circ. 1 ON", "serviceId": "urn:eta-co-at:serviceId:Eta1", "action": "Heating1On" }, "cmd_2": { "label": "Circ. 1 OFF", "serviceId": "urn:eta-co-at:serviceId:Eta1", "action": "Heating1Off" } } } </sceneList>

It wont hurt you for now, but if you tried to add the code into a Scene defn, to create a Button to test it for example, then it would likely error out.

11

Hi,

It did some further testing, to track down the problem with the Vera not receiving data over the serial interface.
I attached the USB-to-serial adapter to my linux laptop, and was able to minicom from ttyS0 to ttyUSB0 on the same machine. When I type in one window, it appears in the other, and vice versa. So, the USB adapter is working fine.
I am receiving data from my furnace on my laptop, so it’s not the cable or the furnace.

Minicom always says it’s offline, but it does display {M?} when I push a specific button on the furnace.
I can send data from my Vera to my laptop, so that part is working.
So, in my opinion, there is something on the Vera blocking incoming data. I don’t get any log messages starting with 5 when I send data to the Vera.

Could it be that the Vera does not receive data when the serial interface says it’s offline?

When I do luup.io.write(“test”) I see in LuaUPNP.log:

10 01/16/10 22:45:23.965 luup_io_write 4 size: 4 <0x2c0c> 51 01/16/10 22:45:23.966 0x74 0x65 0x73 0x74 (test) <0x2c0c> 10 01/16/10 22:45:23.967 luup_io_write 4 result: 1 <0x2c0c>

I made the cable myself: I soldered a 9 pin connector to the two ends of a UTP cable. I connected pins 1 to 6, so maybe that’s the problem.
I just found out that there are RJ-45 to D connectors. I ordered a pair, so I can make a more standard type of connection.

Until next time…

12

I did some further testing with the serial communication.
This is the setup:

  • Vera Test Luup code page in browser
  • minicom connected via serial to Vera
  • ssh window with tail -f LuaUPNP.log | grep “5”
    (I did “/usr/bin/VerboseLogging.sh enable” in the ssh window)

If I do luup.io.write(“test”) in the browser, I see this text in minicom and in the log.
If I type something in minicom, I expect to see something in the log. This is not happening.
I tried luup.io.intercept() and luup.io.read() in the “Test Luup code”, but no result.

Where do I look for incoming serial data? What config to check??
I really hope I can get this solved, or all the rest is not going to work at all. :frowning:

13

Pinx, after you configure the “(Serial Port configuration)” to attach the Serial port to your Plugin/Device I wouldn’t expect that you could interact with it via the “Test Luup Code” page.

I haven’t tried it, but I wouldn’t expect it to work from there, since the “input” (from the Serial Port) is now logically attached to your Plugin, and any data received will be handed to the Lua code in your Plugin (inside of the [tt][/tt] block from your [tt]I_ETA.xml[/tt] file)

I’m somewhat surprised that [tt]luup.io.write(…)[/tt] works in this scenario, since I’m not clear how it would know “which” serial port to write to in that context (since you might have more than 1 in any Vera). The Serial Port Configuration is how it “knows” which serial Port the Plugin is going to talk to… normally :wink:

A few comments:

[list][li]Strip you code down and change from [tt]raw[/tt] to CR/LF
I believe this is just [tt]cr[/tt], and it will then expect all lines sent “to” Vera to have a CR at the end. Just press the Return after any line of text and yo should get some data through.
[/li]
[li]what does [tt]lsusb[/tt] and [tt]dmesg[/tt] indicate for your Vera?
Running these on the cmd line will tell us a bunch about your specific USB-Serial port interface, just in case it’s new or something a little different than what we’ve seen prior.

Specifically they’ll be looking to understand what USB-Serial Port you have running.
[/li]
[li]If Vera sees the data correctly, you’ll get status code “[tt]52[/tt]” (like my examples above)
So something is definitely amiss if you can write (status 51) but not read (status 52) data from the port. These will be in the LuaUPnP.log file and can be found using

tail -f LuaUPnP.log | grep "^5"
[ul]50 - Application log messages
51 - Data Written to Serial Port attached to Plugin
52 - Data Read from Serial Port attached to Plugin
[/li]

[li][tt]luup.io.intercept()[/tt] and [tt]luup.io.read()[/tt] usually only needed at startup.
Typically all Input from the Serial Port to Vera will come to your [attached] Plugin via calls to it’s block. This happens automatically once your Device is attached.

The only time you’d revert to using [tt]luup.io.intercept()[/tt] and [tt]luup.io.read()[/tt] is during special (typically “one-time”) startup processing.

If I understand it correctly, once you’ve issued [tt]luup.io.intercept()[/tt], you’re indicating you wish to bypass the [tt][/tt] block processing for a period and must do [tt]luup.io.read()[/tt] calls to get the data out. For what you’ve done so far, you should not need to use these methods.

You’ll likely need them later when you boot your Plugin, and introspect the “initial settings” from the furnace device.[/li]

[li]What Vera firmware version are you running?[/li]

[li]Is there a hosted version of the latest copy of your Plugin “so far”?[/li]

[li]If you still cant get it going, submit a trouble ticket and open Vera for MCV’s team to look at.
That’ll collect a lot of information for them, and they can likely look around to see what’s up.[/li][/ul]

14

Hi guessed,

The cr did the trick! Now I’m seeing data being picked up by my script.
I did not see log levels 52, but after editing (vim /etc/cmh/cmh.conf) and adding 51,52 to LogLevels, incoming data was printed twice in the Lua log: in raw format and by my script.
I guess LogLevel 51 and 52 are not (or no longer) default in the cmh.conf

Now the next problem: I need a new handler. I hope someone from Micasaverde is reading along…
All my messages from and to the furnace are prepended with a { and appended with a }. There’s no cr or lf.
Because the cr handler waits for a cr, this won’t work for me.

Oh, and as to the hosted version: I’ll put the files in my DropBox public folder.

15

Hey Pinx,
We should be able to get the [tt]raw[/tt] Protocol driver working, if the Furnace protocol doesn’t have the [tt][/tt] on the end of every line recv’d/sent as you’ve indicated.

The Somfy blinds stuff is using the [tt]raw[/tt] driver so it’s working in at least some respect.

If you can play around and get that working, I will help with the Lua syntax to get the “{” and “}” characters out of the resulting string, and adding them to stuff you want to [tt]luup.io.write[/tt] won’t be painful either.

This will get you moving without having to wait for MCV to write a special protocol driver.

One thought did cross my mind, is that it’s possible that the [tt]raw[/tt] driver’s read isn’t working (a Bug perhaps). The Somfy only writes, and I don’t have the [tt]I_GC100.xml[/tt] code handy to check if it’s using the [tt]raw[/tt] driver.

If that’s the case, then we’d need only get a fix for the [tt]raw[/tt] driver and you’d be a whole lot closer.

I guess LogLevel 51 and 52 are not (or no longer) default in the cmh.conf

Possibly. There were a lot of of Vera versions in the early days (extremely glad that’s slowed) and all sorts of tweaks were being done to diag problems in the tech Vera used prior to [tt]ser2net[/tt] (my code used to make it bail drop characters in the 7xx series releases)

16

Hi,

I tried sending data from the laptop to the Vera via serial, but the only thing that works is cr (or anything other than raw).
Nothing appears in the Lua log, so I assume there is no way to get data in in raw format.
Maybe sending from the Vera is ok, but they did not implement receiving?

I shared my files:
http://dl.dropbox.com/u/233761/Vera/D_Eta1.xml
http://dl.dropbox.com/u/233761/Vera/I_Eta1.xml
http://dl.dropbox.com/u/233761/Vera/S_Eta1.xml

I’ll send a request to Micasaverde to implement a “{}” protocol driver. I don’t know of any other way. I’m really stuck here.

17

btw, I just confirmed that the RAW driver isn’t invoking the [tt][/tt] block methods for READ data. Data written is fine, but you’ll not see a byte from the driver at all if it’s in RAW mode.

I was debugging something else (that needs RAW) and I can tell that the data written is going out but nothing can be read back using it.

You might get lucky to be able to control the Furnace without having to read anything back from it. In this case, you’d simply need to construct the right message to “send” to it (and then hope for the best :wink: … not the best strategy, but it might work for you, depending upon what type of interaction you’re looking for with the heater.

MCVO: What’s the best way to file a TC for this problem? Typically you need to be connected to a device that’ll send RAW data, which isn’t the easiest thing to repro.

18

Placed stub details in ticket #2107

19

I am glad to hear it is not due to my limited knowledge and abilities…

Z-wave has proven to be a disappointment for me, so my interest in the Vera is not as big anymore. I still want to try to connect it to my furnace, but this will have to wait now.
Z-wave in Europe is not at all a standard, and there are no controls that are supported very well. I think I will have to look for an alternative.
Zigbee might be one, but this also seems to suffer from limited standardisation. Micasaverde say they have plans to support it, but no timeframe yet.
EnOcean has an interesting system, where the controls do not need batteries: the energy for the signal is generated by the buttonpush itself. Several manufacturers support this standard, much like the Z-wave system (both have an “Alliance”).
There’s a serial interface, so maybe some day it will be connected to the Vera?

20

Hi Pinx, haven’t heard from you in a long time…

guessed provided a lot of useful information about the problem, and we quickly determined that it’s a limitation of the [tt]luup.io.open()[/tt] call. This call creates a TCP connection and attaches to a device. currently this connection loses incoming data if the protocol is set as [tt]raw[/tt]. But the same code does work (with any procotol, including [tt]raw[/tt]) if the user configures the device’s IO to use a serial port (which can be TCP based).

I don’t think your problem is exactly the same, since your code doesn’t use the [tt]luup.io.open()[/tt] call; but it could be related. if we can schedule a remote asistance tonight or during the weekend i might be able to check what’s the real source of your problem.