Which approach to use for new hardware

[zion_uk]

Hi,

I've just taken the plunge and ordered a TR60 RS485 Thermostat form the US (I'm in the UK). Whlie its in transit I want to start on the interface to Housebot. I was hoping someone could give me some advice on which approach to use? I'm going to use an RS232 converter so it will be an RS232 interface.

How the TR60 works

The TR60 can be polled using a variety of messages (of variable length) and returns a load of ASCII characters in its respone (again variable length). For example in terminal you type “A=1 R=1” which is a status request for a TR60 at address 1, and returns something like: "A=00 O=1 Z=1 T=68 SP=70 SPH=70 SPC= 74 M=0 F=0". I have the full protocol documentation.

What I want to do:

1) Display all current thermostat settings in housebot / remote - i.e. poll all the settings and display them or mirror them in some housebot variables
2) Set all current thermostat settings in housebot / remote

Options for attack

It seems like there are several options for attacking this:

1) Use the "Generic Serial Plugin" as in the online tutorial here: http://www.housebot.com/frame_content_tutorials.htm; and try to exploit the existing capability
2) Write a VB script (I've only ever written very basic scripts in VB using housebot)
3) Write a new hardware and/or device plugin

Questions

What do people suggest? Has anyone done anything similar? Will option 1) provide me with all the flexibilty I need? Do I really need to do option 3) - I don't really understand what this involves?

I have basic C/C++ skills and am happy with scripting.

Thanks in advance,

Z.

[Steve Horn]

I'm surprised you didn't get any replies to this. Anyway - you have one now, for what its worth. I'd go with the generic serial plug-in at the hardware interface level and use a VBscript to load the received data into properties (appropriate to the data you get) of a T-stat null device you create. Use the same null device and script to send data to the stat. Richard Naninck uses this approach with the scripts he's created for interfacing with A/V devices. You could modify one of the more straightforward ones (an A/V receiver, for example), since you're basically doing the same thing - sending commands and capturing the replies. Once you've captured the data you can display it (or modify it in the script if necessary).

[Richard Naninck]

Yep, go with option 1 and 2 combined like Steve mentioned.
Not only AV equipment but lots of domotica equipment as well got interfaced like this.
The variable length shouldn't matter. If more than one messages are packed in one Received Data, you could opt for a faster Response Timeout in the Generic Serial Device or look which character is used to separate the messages. When a message is isolated you could parse it like this:

Code: Select all

Data = GetPropertyValue("Your Device.Received Data") 'A=00 O=1 Z=1 T=68 SP=70 SPH=70 SPC= 74 M=0 F=0
arrData = Split(Data, " ")

For n = 0 to UBound(arrData)
   strData = Split(arrData(n), "=")

   Select Case strData(0)
      Case "A": intAVal = strData(1)
      Case "O": intOVal = strData(1)
      Case "SPH": intSPHVal = strData(1)
   End Select
Next

All of this just came out in one minute so there are most probably much cleaner ways of doing this. Just to give you a hint.
You can create a NULL Device containing all of the values the protocol provides and rebuild this data to your needs for displaying them in your theme. If you know C, vbscript should be a p of cake.