Modbus/TCP Thermostat


Recommended Posts

I am looking at replacing 75 or so thermostats in a building that all need to be centrally managed and monitored (via DF). In addition, I will be installing other sensors for monitoring, e.g. light/lux, motion, humidity, etc...

I found an interesting product (would need to connect it to the network somehow): MBus_Io10_LCD

I have also looked at some of the digi X2 gateway products (zigbee and their industrial application MODBUS/TCP interface) to reach out to zigbee connected sensors and devices.

Product info:

I have the X2 gateway and a combo sensor to test the MODBUS/TCP, have not yet been able to get the X2 and DF to talk together yet. The X2 is loaded with Python, suppose to be customizable.

Any thoughts or recommendations?


Link to comment
Share on other sites

The datanab device looks pretty cool. Looks cheap, but probably will do the job in non-industrial, non-critical environments. Certainly doesn't look any cheaper than the thermostats you get a your local hardware store, and it supports Modbus. I might have to get one to play with at my house! Throw a DAQBridge in and you have complete Internet monitoring without security issues.

As for the zigbee, I have not actually used it, but others have. You really want a device that just acts a transport layer translator, that ignores the protocol (like the raw port on a serial to Ethernet converter). That way, you can just tell DF to connect to the base over Modbus, and whatever wireless stuff happens, its completely handled in hardware, much the way standard 802.11b wireless would work. If not, you'll either need to make a little protocol driver in DF to communicate with the zigbee portion, hopefully then being able to switch to Modbus for communications with the device (which is easy in DF), or you might have to program a modbus gateway into the base station.

But, as I said, I haven't directly worked with zigbee stuff, so maybe others can chime in.

Link to comment
Share on other sites

The Digi X2 gateway is a gateway that is suppose to gather all the zigbee sensor data and act as a either a MODBUS master and/or slave. I am still fumbling through how set up the Digi X2 to be polled as a MODBUS device (master or slave). You can configure the X2 gateway MODBUS settings through the IP address (built in web server) on the "Industrial Applications" tab (attached photos).

You can configure MODBUS by creating a table (mine is x2table1 in the photo). You can configure it for MODBUS/TCP or UDP or ASCII, as well as the port and timeout.

I am new to MODBUs so I am fumbling along. My hope is that the X2 can poll and control sensors and relays (Digi has a product called smart plug that is a 110/120V 10 amp controllable relay) as a gateway onto Ethernet to connect to DF.

The benefit of using zigbee is low power consumption (batteries could last a couple of years) and lower cost of gear.

I attached screenshots of the X2 gateway web configuration interface.




Link to comment
Share on other sites

First page looks ok. I'm assuming "Receive messages..." means the unit is the Modbus Slave. The second page, however looks wrong. It looks like you have the message source correct, but then you are telling the system to reject all messages as an error.

In DF, you'd want to connect over Ethernet using Modbus TCP on port 502.

Link to comment
Share on other sites

I would think it would be Send messages to network device, but its still unclear to me whether this is just routing the traffic, or actually looking at the protocol. My guess its just routing the traffic, which means you'd likely need to create a separate connection for each remote device, each on a different TCP/IP Port, and set the routing appropriately. You might just call Digi and ask them how to use their devices to send Modbus commands from a Modbus Master running on a PC to remote devices connected through their ZigBee network, then make sure and post the solution.

Link to comment
Share on other sites

The digi gateway needs to be configured (via python objects) in the gateway for each zigbee connected device. It is suppose to be flexible enough to configure how each sensor/device coming over zigbee is translated (mapped) into Modbus. Digi does have a nice object based developing environment for python called ESP. I like it, but the hardware is a rats nest to figure out what you need.

see this link for example:

I learned that there are lots of "different" implementations of zigbee (wireless communications technology, OSI data-link layer I think) that are NOT compatible. This is a big problem trying to determine which zigbee components are compatible from digi, let alone other vendors.

So, right now I have only 1 device (combo sensor, light/temp/humidity) compatible with the X2D gateway from digi. Hardly worth the effort, I need lots more.

Digi is really pushing their iDigi platform, they want to be a clearing house for M2M data points. The critical flaws in the iDigi platform are that they have no storage option and are a single point of security risk. Not sure why I would want to use iDigi without a storage component, and am charged for every transaction leg, e.g. from gateway to iDigi, iDigi to application (whatever application, web service, storage, etc...), then any web service request to iDigi as well as any call function from iDigi to the gateway. So I may be charged for 3 or 4 transactions that should really only be 1. Also, not a secure service (yes, they have typical passwords and encryption) but devices do not come with a default password, I can freely telnet into or web config the device out of the box. In addition, if your application is hacked, hacker has the potential own your environment/control/application. Any Digi gateway connected to iDigi can be reconfigured through iDigi if compromised. The dependance on iDigi also means that any control is dependent on an Internet connection (that service guarantee from your ISP becomes much more important).

Most zigbee thermostats use the "smart energy" version of zigbee not compatible with other implementations of zigbee, according to Digi. Digi does have a Zigbee "Smart Energy" gateway that is targeting the residential market to collect smart meter data. The problem is that the X2 "smart energy" zigbee is small with limited range, memory, and processing power. Not made for any industrial type of application. The Smart Energy X2 will not be able to run the code for Modbus AND Python at the same time (not enough memory).

On top of that, there does not appear to be zigbee "standard" I/O modules I can buy (at least have not found any yet). Digi has reference designs and parts that I can make my own out of--not something I want or can do at this point. Digi does have I/O modules for their DigiMesh (zigbee) 2.4 GHz and 900 MHz versions of the X2 gateway. But none of these are compatible with "Smart Energy" zigbee thermostats.

Digi appears to have an interesting development environment... if your familiar with developing with their products, bit of a hurdle to get there.

I may have to return mine, opt for a better solution environment from another vendor that does not require reinventing the wheel.

Guess I'm back to asking for recommendations on thermostats I can use with DF.

Link to comment
Share on other sites

Well, I'm not sure you want to get me started on iDigi since we are directly involved with DAQConnect, a similar, but far superior (in my opinion) product. DAQFactory doesn't charge per transaction, nor does it require access to the hardware, so your hardware can remain safe behind firewalls.

What's wrong with the datanab stuff? Seems like its just a wiring issue, in which case you aren't looking for other thermostats, but rather other wireless platforms.

Link to comment
Share on other sites

I had been tasked with finding a wireless solution, the Datanab thermostat looks good. I am afraid that the Datanab needs a gateway to work in wireless environment (maybe one per floor?). I think it would simply be much cheaper to wire it. Zigbee offers the lowest cost products, just gotta figure out how to get the Datanab connected. I still have to come up with a wireless option.

Agreed, DAQConnect is far superior on a number of levels: programmability, security, compatibility, flexibility, etc... I like it a heck of a lot better after I have had a couple of weeks unsuccessfully wrestling with iDigi.

Gonna research how to put the Datanab on wireless, Zigbee or 802.11 (Wifi).

Link to comment
Share on other sites

The DataNab thermostats (MBUS_io10_LCD, $105) are RS485 that need to connect to a device that can put the thermostat (or however you use it) on the network with Modbus via the Brix BarioNet. There are several models to choose from, however if you want the MBUS_io10_LCD to be able to run its own schedule (for thermostat) then you need the BarioNet RTC (with real time clock).

I am thinking of buying a pair to test. I was told that I will likely need one BarioNet RTC for every 12 or so thermostats. The price is not bad (roughly $340 for each BarioNet RTC), but they (the thermostats) will need to be wired. Once wired to the BarioNet RTC, the network connection can be 802.11 Wifi or wired Ethernet.

To put it in prospective, that's roughly $30 on top of each thermostat. That would give me a cost of roughly $130 for a smart programmable, OEM-able thermostat that connects to DF via Modbus. An Ethernet Wifi bridge will cost another $60-120. With Wifi, I will not have to deal with running Cat5 cable in the plenum (ceiling space).

Seems like a reasonable solution. The BarioNet RTC will need to be programed for the thermostat schedule. This is something that DataNab can do for a price, or I can figure out (given enough time). Seems like a good cost effective combination.


Link to comment
Share on other sites

Sounds pretty reasonable to me considering a programmable thermostat from Home Depot starts at $35 or so and that's without any connectivity. If you don't need local display of temperature or changing of settings then there are other options.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.