Trouble reading inputs from HUM-D

Thank you fro your help so far… I have finally solved my issues with the Tstat8’s with your advice. I have them all on bacnet now and they seem to work okay. I can read them at least…

My next issue is with the two HUM-D units I have installed. They are connected via Ethernet. They show up in T3000 no problem. I can see the values. I can load modbus poll tool and see the registers I want to read into a variable. Clearly T3000 can read these inputs… I just dont know how to call them.

I have code like this, but it does not work.

10 VAR19 = 2.201.MB_REG101 / 10

Then I thought maybe I dont need the “2” as that is the T3-BB panel number. Im not actually pulling these inputs through the BB as they are on Ethernet directly. So i tried this code, but it doesnt work either.

10 VAR19 = 201.MB_REG101 /10

I have also tried to pull it as Bacnet input like this:

10 VAR19 = 114338AI1

Im a little lost… Ive tried to search the documentation for this and Im just missing something. Ive attached a pic of the screen showing that I can read the HUM-D. I just need to know how to read the register in a program.

Okay I solved this myself. Im a bit of a dummy.

My HUM-D was on IP addr with modbus id 201
SO… I needed to do this.

10 VAR19 = 3.201.MB_REG100 / 10

Its all begining to make sense now. I hope this helps someone.

1 Like

I assume you’re working over the RS485 subnetwork, it will be best to work in Bacnet mode, try setting the protocol of the subnet port and the device itself to bacnet. Then the program would be like so:

10 VAR19 = 2.201.AI1

Note: The bacnet subnetwork features have been undergoing some updates lately, you may have to update both the T3000 front end and also the device firmware to make this work correctly. If you need to work in modbus we can get set up here and help out in more detail.

I dont see any firmware available for the HUM-D… Can you point me in the rite direction? The T3000 firmware tool does not find it. The FTP site has firmware listed for HUM-R but if I try to flash it, it will not load. The exact message I get is “Your device is CO2NET but the file is fit for HUM-R”

I dont want to just randomly pick firmware to load,

hi, Dave
Hum-R is not for your device, it is another product type, so the ISP tool shows an error message.
I have tested the T3000 → help → check for updates → download firmware and Update function, it works.
The T3000 version I am testing with is Oct/17/2018, see below screen shot. The newest firmware version is REV35 which I think you already have in your device. Note that the Hum-D, Hum-W and CO2 products all use the same firmware.

I need to revisit this topic.

I changed everything to Bacnet by your recommendation.

These HUM-D sensors are attached by Ethernet, not RS-485.


MSTP chosen on both HUM-D

The HUM-D get their IP from DHCP with a reservation forcing them to the addresses above.

I can see and communicate with the HUM-D in T3000 with no issues.

Im unable to sort out how to communicate with them in a program on the T3.

I’ve tried:
10 RETTMP = 113609AI1 ***doesn’t work. 113609 is the “serial number” listed in T3000. I think this is the instance number but you’ll see below I cannot get the Bacnet tool to talk to them either.

10 RETTMP = 201.AI1 ** doesnt work and the compiler changes it to = 201AI1 dropping the period.

per your example:
10 RETTMP = 2.201.AI1 ** doesnt work and the compiler changes it to = 2AI1 dropping .201.

If I run the Bacnet tool and search the network, I find only the T3-BB itself and the 5 Tstat8 i have connected to the T3 on RS485 main, nested under it. . It doesn’t find the two HUM-D on ethernet. The T3000 software though can see them just fine? I feel like I’m missing something. I dont want to go back to modbus. I really want to stick with Bacnet. I have a VFD and humidifier showing up soon also on bacnet so I need to sort this out. If you read my post above, I was able to get the T3 program to read these HUM-D in modbus mode so I would say its technically possible with no good reason why it shouldn’t also work in Bacnet. I attached a pic that shows the HUM-D’s in T3000 and I just pinged Supply successfully.

hi dave,

  1. T3000 and Yabe can discover Humidity.
    We can see the humidity sensor instance number is 109148 and AI1’s value is 30.7.

  2. Next we write a simple program code to read AI1 of the humidity device, here we see the local variable 2 has updated to match the temperature reading of the humidity sensor, the temperature has gone up a little to 30.9. The network transfer shows up in the network points table as a trouble shooting aid.

  1. Depending on what you are doing with the remote points you don’t really need to create this local variable. You can trend log remote points directly, use them in your free cooling program directly and so on. The local var2 just shows an example of how to work with the data from remote devices. The devices can be on the Ethernet (main) network or on the RS485 (sub network).

  2. Final Note: I noticed the Bacnet instance number is not in the GUI, we will add it so you can change the instance number to make things easier to remember as you work. Next version you will be able to edit it here.

I appreciate the response but I have tried everything you have suggested here and I clearly say that in my previous message.

Yabe does NOT find the two HUM-D

T3000 Finds them and communicates with them just fine.

This is the relevant part of my program.

The variables do not populate

If I view the network points, I see it still shows modbus in items 10-13. I was previously addressing these HUM-D with modbus but changed to Bacnet by recommendations here.

Below are the settings on the HUM-D

I have tried with the port at the default 502 and 47808 with no change.

I had similar issue with CO2 sensor, couldn’t read CO2 values from some devices using instances on BACnet. I solved it by connecting 0-10V signal from co2 to controller. Strangely there are no issues reading data by 3rd part devices (I get readings in Catnet perfectly), but not T3-TB.



Now co2 values are gone:


Thanks for all the screenshots and photos, from which I can see its probably a netmask issue. You can update latest firmware rev40 of HUM by T3000 automatically, we discovered and fixed a netmask issue in rev40.

T3000->Help->check for update->download firmware and update


The issue you’re seeing looks more like general connection issue, not a netmask issue. Please do all the usual network checks: known good cable, try a different hub or direct cable connection to the PC, worst case connect by RS485 and get in to get at the network settings from there. Standing by to help more.


Thank you very much for helping with this issue. I thought my firmware was up to date but I clearly did not search correctly. I have been using T3000->Tools->Load Firmware for many devices->Get firmware from server. This does not find new firmware for the HUM sensors. If I select the HUM and then use help->check for updates as you say above, it does find the new firmware. This is quite confusing to have two different ways to search for firmware with different results.

Either way, now that I know, its not a problem I guess.

My sensors are working well on Bacnet now. I am addressing them by instance and input and it is working correctly. 10 VAR1 = 114338AI1 does in fact work now. Yabe also finds the HUM devices immediately. Thank you for helping me to find the problem. Im getting closer to completing the system. When it is done, I will publish pictures and documentation as Maurice has suggested. I can’t say enough about how great it is that you guys personally help us here on the forums. I will continue to use your products mostly because of the personal help you all give here. Thank you again.

Thanks for the heads up, Fandu will fix the multiple devices update system. I will be very glad to see some project details Dave, that is the kind of community spirit we’re working to build.

Update: I checked the multiple device update system, I was able to update most devices in our demo system at the office but the user interface needs some work, some devices didn’t get the updates. Added to the todo list.

5 posts were split to a new topic: Firmware Updates

I logged data from Bacnet in two ways, directly from sensor and as variable in t3 controller. This is logs for 3 CO2 sensors 85; 17; 106.

106 CO2 sensor readings directly and in T3 are almost same, this is how it should be.

17 co2 sensor readings directly are ok, in T3 readings not reliable.

85 CO2 sensor situation is similar T3 can’t read data from CO2

To dig into this further we will need to see a data capture from the network. If you are logging this data over Ethernet its quite easy to log data using a PC running wireshark. If its over MSTP the steps are a little more involved. Set up some filters to keep the logs small. Send me a network diagram and I can help in more detail.

Another idea to help debug would be to log directly on the T3 controller itself, this would help rule out communications issues between your logger and the devices you are communicating with. You’ll need an SD card on board the T3 controller, the SD slot is on the side opposite the Ethernet jack.

Ok so at first next week i plan to be on site, i will insert card to controller.