TZB43 thermostat and xbee series 2 communication

XBee & XBee Gateway XBee - Zigbee
1

Hey everyone

I am working on the home automation project that has TZB43 thermostat which has Xbee on board configured as router/end device, and one Xbee connected to a PC configured as a coordinator. I am able to receive the data from the thermostat, however I can’t figure out how to build a packet to make a remote change on the thermostat. I have figured out most parts of the packet, like where is payload and stuff. But there are certain bytes in the packet that I have no idea where they are coming from and what they are for. If anyone can help me figure this out I would greatly appreciate it.

P.S. I’m new at this, started to learn all this about couple of weeks ago.

2

I am also interested in this as I recently acquired this same thermostat. The embedded XBee module is Digi’s and is running ZB 2341 API Router firmware.

Thanks!

3

I too acquired a TZB43 on EBay and do have it communicating with an XBee module conneced to my PC’s serial port.

I was just wondering what is the latest version of firmware
available for the TZB43 since mine has an annoying behavior where the screen locks up and the device is no longer responsive to button pushes (usually the lockup occurs when I am pushing the front panel buttons). The unit still seems to be working but the user interface is hosed.

The firmware version can be found by navigating via the front panel to the Menu -> Thermostat Info
page. Mine shows 2.00.15.
Thanks,
Joe

4

You might both be interested in a little (hah!) program I wrote a while ago, called packet-check. You type in (or paste) a packet and it decodes it for you and prints the details, together with any error or warning messages it can spot. It works for 802.15.4, Digimesh, Zigbee and ZNet.

The program does its best to spot and diagnose errors, so it can be handy when you’re composing your own packets and wondering why they don’t work.

I typed your (Velocity) packet into it and this is what it said. Note a few things. First, packet-check is a command line program: no GUI here. Second, the first time I tried it, it assumed you were using API mode 1. That gave errors, so I tried API mode 2 (-api2 as the command line argument) and that showed the packet as good. Third, if you copy and paste the output into a text editor so that you see it in a fixed-width font you’ll find things line up better.

The following shows the whole transaction, from invocation of the program to the output it generated.

[john@eccles ~]$ packet-check -api2
API Packet analyzer version 1.2 for XBees (802.15.4, DigiMesh, ZNet, ZB)
Escape characters enabled (AP=2)
Note: if it prompts for more bytes and you’re done, hit return
Enter packet: 7E 00 1E 90 00 7D 33 A2 00 40 48 95 A3 23 3E 01 41 3D 30 30 20 4F 3D 31 20 5A 3D 31 20 54 3D 37 36 0D CA

Original packet: 7E 00 1E 90 00 7D 33 A2 00 40 48 95 A3 23 3E 01 41 3D 30 30 20 4F 3D 31 20 5A 3D 31 20 54 3D 37 36 0D CA

Unescaped packet: 7E 00 1E 90 00 13 A2 00 40 48 95 A3 23 3E 01 41 3D 30 30 20 4F 3D 31 20 5A 3D 31 20 54 3D 37 36 0D CA
7E // Correct packet header byte
00 1E // payload length (decimal 30)
90 // Packet type: ZigBee receive packet
// Valid for DigiMesh, Znet2.5, ZigBee
00 13 A2 00 40 48 95 A3 // 64-bit source address
23 3E // 16-bit source address
01 // Rx options: ack
// TX data (18 bytes) [1]
41 // transmitted data ‘A’
3D // transmitted data ‘=’
30 // transmitted data ‘0’
30 // transmitted data ‘0’
20 // transmitted data ’ ’
4F // transmitted data ‘O’
3D // transmitted data ‘=’
31 // transmitted data ‘1’
20 // transmitted data ’ ’
5A // transmitted data ‘Z’
3D // transmitted data ‘=’
31 // transmitted data ‘1’
20 // transmitted data ’ ’
54 // transmitted data ‘T’
3D // transmitted data ‘=’
37 // transmitted data ‘7’
36 // transmitted data ‘6’
0D // transmitted data CR
CA // checksum - correct

Notes:
[1] Max 100 bytes on 802.15.4, or 72 on DigiMesh or ZNet2.5
[john@eccles ~]$

=== (End of program output).

So your mystery bytes are the 64-bit source address (9 bytes because one was escaped), the 16-bit source address and the Rx Options (ACK in this case).

Compare that with the packet description in the ZNet product manual and you should be able to make more sense of it.

I make the packet-check program freely available on my website. It’s written in Tcl, so if you don’t already have it you’ll need to download the (also free) Tcl interpreter. The whole lot will run on pretty much any platform, certainly including Linux, Mac and Windows.

For more details, hop over to the 802.15.4 forum and check out the pinned posts at the top. If you haven’t already seen this stuff, the FAQ might also be of interest. The cookbook, however, will be of less interest since it’s written with 802.15.4 in mind.

If all that’s too much to bother with, I do monitor these forums and I try to respond to questions about API packets such as this, so feel free to post other packet questions. On the other hand, having your own copy of packet-check gives you the ability to get answers fast…

Edit: One small suggestion - if you want help with a packet it’s good if you can supply it in the message body instead of or as well as a JPEG. That way it can simply be pasted into tools like packet-check rather than having to re-type it. No flames, just a suggestion :slight_smile:

Hope it helps

5

Thanks johnf!

6

2 johnf: Thanks a lot! Really appreciate your help. I hope your program will help me build the packet.

2 Herman: I don’t know how far you got with your project with this thermostat, but I called RCS the maker of this thermostat. It turns out that the design for Xbee enabled thermostat is a proprietary and it was made for one particular company called BreezeWay or smth, i got it written down somewhere. Anyway, RCS refused to provide any documentation for the protocol or specs. They told me to contact that company which is from North Carolina and then the tech support added that the company apparently doesnt exist anymore, so he wished me good luck and hung up. BTW these thermostats apparently werent made for public sell. I do have a datasheet for a protocol that some of the RCS’s thermostats are using and it looks very similar to what I’m seeing from the Xbee on the thermostat. So if you need it I can email it to you or smth.

P.S. still having a hard time trying to change thermostat’s setting remotely.

edit: 2 johnf: I finally looked and tried your packet-check program…I should admit you’ve done an amazing job. Thanks for all this hard work. So I made a packet and ran it through the program and got a weird error; I’m attaching a screen shot to show the error but here is also a packet i’m trying to send from the pc to the remote zigbee is there something I’m doing wrong?

The packet:
7E 00 2E 10 01 7D 33 A2 00 40 32 16 DF FF FE 01 41 3D 31 20 4F 3D 30 30 20 5A 3D 31 20 53 50 3D 37 35 20 53 50 48 3D 34 30 20 53 50 43 3D 37 30 0D C5

7

I also came to this thermostat.

Does it communicate without security? As you haven’t mentiontioned setting a trust center key, I guess so?

So, it wouldnt join a HA Profile network.

8

I’m using this thermostat without any security. I had a hard time figuring out how the controller on the thermostat communicates with the Xbee. I figured out how to change temperatures and stuff. And I guess the controller that is installed on these thermostats is using same protocol as other RCS made thermostats. I got the PDF from their website. Its actually really easy, most troubles I had were Xbee related. Bbut like I said I’m a newbie, I have a lot to learn. Oh and one more thing, I found out that you have to use API mode 1, not 2 since controller will not understand the escaped bits. Not sure about AT mode.

9

Hi Velocity

First: thank you for the bug report. The packet-check program should never crash, but on this occasion it clearly did. I’ll look into it.

As for your packet, it looks as though you may have missed out the TxOptions byte. Would that make sense?

10

@Velocity:

Sorry about the packet-check bug. Version 1.3 is now up on the web site, with that bug and another one fixed.

Good luck with the project!

11

Hi folks, sorry I’m late to the party. I’ve found this and more information and I’ve been busy putting my notes online ( http://ushomeautomation.com/Notes/TZB20/TZB20.html ). I haven’t added it so you can find it via the search engines yet but I will. I’ve just been a little busy. I have the TZB20 & TZB43. I also found that Smarthome sells a product that uses the TZB43 ( http://www.smarthome.com/68009/Advanced-Telemetry-CWT-XBEE-001-EcoView-Resource-Manager/p.aspx ).

The TZB43 seems to be based on RCS’s TR40 and the TZB20 seems to be based on the TR16. Assuming an engineers mind for reuse and you have part of the protocol to communicate with the thermostats.

I hope to have more later as I get time to play.

Edit: corrected the URL

12

WooHoo! I’ve got communication!

I’m using a XB24-B with ZigBee AT Coordinator firmware and the TZB43 is still using it’s default ZigBee AT Router firmware.

Thermostat
TZB43 - 0013A200 403ABB28
XB24-Z7WIT-003 revA
Coordinator
USB - 0013A200 4064EFF3

ATDL 403ABB28
OK
ATID FFFF
OK
Tx: A=1 O=00 R=1
Rx: A=00 O=1 Z=1 T=78 (seems to take a while to respond, maybe 10 seconds)

Don’t type in the Tx: or the Rx:. I just used those to make it clear what was sent (Tx:) and what was received (Rx:). The 78 degrees matches the screen.

13

Okay, I’ve done some further playing and I’ve found that the commands sent will work with the on the end. I’ve found that the only command I needed to send to the XBee Coordinator is the ‘ATID FFFF’ to set the PAN ID. I figured this when my laptop went to sleep and the XBee lost power. I check the router settings (ATDH / ATDL) and they’re not set. Previously I ‘Installed the ZigBee network’ on the TZB43 with the PAN ID set to FFFF. I also did an ATWR to save the PAN ID. I set the Air Conditioner temp. to 74 (it was 82) and the unit responded and turned on the air (the room is at 77).

Tx: A=1 O=ME SPC=74
Rx: A=00 O=1 Z=1 SP=62 SPH=62 SPC=74
Rx: A=00 O=1 H1A=0 H2A=0 C1A=1 C2A=0 FA=1 SCP=20

So as you can see it works. :slight_smile: I’ll try adding in one of my other thermostats to the ZigBee network (these are the TZB20s) and setting it’s ID to something else.

The one thing that bothers me is that I don’t know how to change the address of the TZB43. It’s currently 1 and I can’t seem to figure out a way to change it to anything else. So I won’t be getting a second TZB43 (but I don’t need one as I have the TZB20s :wink: )

Now that I think I understand what’s going on I’ll document it better on my TZB20 web page. Hmm, I still haven’t gotten the ZBPLM into this, maybe later.

My TZB20 page: http://www.ushomeautomation.com/Notes/TZB20.html
It’s currently just a jumbled collection of my notes but I intend to clean it up in the next few weeks. I’ll also attempt to add my TZB20s to the ZigBee network and communicate with all the devices at the same time. :slight_smile:

14

I’ve been working on implementing the TZB43 in a multi-zone HVAC configuration and will share what I found in getting these working properly.

There are multiple firmware versions of these stats, 2.00.16, 2.00.17, etc. but all appear to implement Zigbee the same. I have a network of 6 thermostat zones running now, all with different versions and haven’t yet seen anything different.

Configuration must be done using X-CTU or simular before installation:

  1. The module must be configured as an API Router or End Device. That “AT” in the version number of some units means nothing. If you use AT then you will not be able to see Zigbee info on the settings menu, nor be able to use the add/remove from network command on the installer menu, nor send commands to the unit. You will only get broadcasts…assuming the network join even works right.

  2. These options must be set:

  • JV must be set to 1.
  • AP must be set to 1.
  • AO must be set to 0.
  • SM must be set to 0 (important! - TZB43 will not wake from sleep).

  1. Set NI to the node name of choice. This and the network address are the only thing you will have to be able to identify a particular TZB unit if you have more than one. Thus your software and coordinator will also have to be API based in order to see the Zigbee address on the messages from the thermostat. RCS has a network address (the “A=” parameter in the protocol) but the is no way to set it from the physical unit itself.

  2. After configuration, place the Zigbee module in the unit, go to the installer menu, select Zigbee Install and select Yes to join.

At this point you should be able to discover the node on the coordinator and send commands using the RCS protocol format. This is NOT an HA profile device, it uses the RCS proprietary format. The protocol document is available online. Search for “RCS HVAC protocol 4.3”.

In addition the TZB43 will send a “broadcast” to the coordinator for any temperature or setting change.

There are some hangups with how these units work. One thing I’ve found is that if I change the network by adding routers the thermostats stop sending or responding and I have to go to each one effected and re-join them from the installer menu. It may be necessay to keep all of these configured as end devices on a seperate PAN ID.