I’ve had a couple T3-TB in production controlling radiant heat zones. Generally fine with two concerns.
=> I have 10K type 2 thermistor inputs and many of the channels jump by a few tenths of a degree each sample. I’ve tried bumping the filter up to big numbers like 32 or 64 and it smooths the output a bit, but I’d expect a lot more smoothing. Anything to look at?
=> I’m using a BACNet binding I got for OpenHab 3.0 which is not available for the current version 5,0, so I need to reintegrate using ModBus over TCP. Any plans to add MQTT support to the controller which would make it more “cloud ready”? My alternative is to swap out the T3-TB for small industrial PLCs, but that’s a lot more work!
Smoothing:
Sounds like a grounding problem, tie the T3 controller GND to earth near the device and also at the power supply. I cant say I’ve heard of anyone needing to go further than adding some grounding here & there but here’s a couple more ideas:
Use a program to do further smoothing in control basic, this would smooth it by 100 scans through the program, several seconds. Swap all references of the sensor with the new virtual ‘SMOOTHSENSOR’.
SMOOTHSENSOR = ( OLD READING * 99 + SENSOR ) / 100
OLD READING = SMOOTHSENSOR
Try temporarily hooking up a sensor with a very short cable, if that smooths it out then your cable is picking up noise from the space. Maybe you need to consider shielded cables on your projects.
Put a capacitor across the temperature sensor input, right at the terminal block.
Bacnet:
I am a fan of the OpenHab system and will do what we need to make it more friendly there. We’re currently adding SNMP for data centers. MQTT is also on the roadmap for that very same project so it won’t be long.
The wiring to the thermistors is very long runs of single pair. I think it’s HVAC wire so not sure there are even any twists. Nothing I can do about that now!
Are you suggesting to ground the 12VDC minus terminal? I don’t see another ground lug on the unit. I have 13 zones spread across two T3-TB units. Some of them fluctuate a lot and others are fairly stable. I’ll try your smoothing program which might be easier than smoothing on the OH side.
Neither OpenHab nor Home Assistant are very BACNet friendly. Disappointing because BACNet seems like such a good solution for multizone HVAC. If you add MQTT support suggest you look at the “homie” convention because it facilitates discovery in the automation platforms. MQTT is much better supported than BACNet and Mosquitto, the open source MQTT server, seems very robust.
Grounding: At each power supply and each main control cabinet, tie the GND there to earth. Any metal pipe or beam. You need to shunt the noise in the system away from the devices.
Smoothing: That is a work around, it’ll be best to sort out some good grounding and earthing.
MQTT:
So many good ideas, so few developers. We’ll get there. I am hiring so reach out if you have time.
I looked at my wiring and got very excited when I saw the frame ground terminal on my power supply was disconnected. Reconnected it and no change with the jitter. Then tried connecting -V on the output (that internally connects to frame ground through a capacitor) and still no joy. Interesting thing is it’s only a couple of thermistor channels and they’ve settled into a pattern of climbing from 84F to 92F and then dropping back to 84. Like there’s some long time constant RC oscillator.
I experimented with moving averages on the T3-TB then moved them over to the Openhab side. One interesting side effect is I’m using the raw thermistor data to feed into the PID loop on the T3TB, so I’m not sure it’s doing exactly what it should. Loops are set to P=1, I=0, D=0, Time=min, Bias=0.
If you want to chat happy to reach out. Let me know best way to reach you.
Try hooking up a regular resistor to one of the spare inputs.
Temporarily swap the thermistor connections between a “good” channel and a “bad” channel at the T3-TB terminal block.
Plot the remote sensors, swapped sensors and the resistor on a trend log and report back here please.
This is far beyond what you should have to do to get a reliable temperture reading, there’s something going on with this install, ground loops or …not sure.
I ran through your suggestions and saw the oscillations were following a couple of ports but not the thermistors. Even with a 10K resistor the port readings were bouncing around by several degrees over a 10 second interval.
I looked at the input port configs and noticed I had bumped the Filter parameter on those ports up to 128. I moved them back to 32, like the other ports and everything has settled down again.
This screenshot shows the port with thermistors swapped and a fixed resistor. The stable section at the end is with Filter set back to 32.
I also have a simple way insert the moving average into Openhab.
Now my plan is to port the binding from BACNet to Modbus, just because Modbus is better supported by the automation platforms.
I also scoped the thermistor leads. There may be some induced AC on the runs but really hard to say whether it’s measurement artifacts in a noisy equipment room.
Thanks for all the help. The T3-TB is an amazing device!
Good feedback. Setting the filter from 128 down to 32 shouldn’t have changed anything except slowing down any jitter. Doing the program to smooth the signal down is not something you should have to be doing. I will have our team see if they can repeat any of this.
One thing you mention up above is ‘connecting -V on the output through a capacitor to frame GND, and still no joy’. What’s going on in that test?
My Meanwell power supply has an internal capacitor between -V and frame ground. Don’t know the value.
Meanwell tech support said it’s ok, so I tried connecting -V directly to frame ground, shorting out the capacitor. I didn’t see any difference in the behavior.
My takeaway is there is some electrical jitter on the thermistor signal AND the filter field may be doing something screwy with values bigger than 32. Overflow? IDK.
Between the 32 filter value and a 10 sample moving average (technically I guess it’s an exponential moving average!) the numbers are stable enough for my application. I’m feeding the filtered numbers into the PID loop but the averaging is post processing for display purposes.
The switching supplies like those Meanwells can be quite noisy and they are completely isolated from everything they power. Tie the GND of this supply to earth please.
Most of our products get hooked up to 24vac transformers with the benefit being you can power many devices in parallel over long distances without power droop and they dont introduce high frequency harmonics into the system.
I suggest a solid GND at the power supply, also at the T3 device will clean up a lot of the noise. The long cable run to the sensor may be picking up some noise and interacting in some subtle way with the isolated GND of the meanwell supply. if possible earth the GND on the sensor and any other field devices in the system, tie the GND to earth at as many places as practical and continue checking with the scope.
Meanwell Supplies: You use them with your HF radio equipment… maybe its the radio equipment causing the noise in your system!! Just throwing that out there.
Stable Inputs: You ask are the inputs stable while the programs are running and show some logic for smoothing it looks like. Maybe I am missing something here but the inputs should be stable no matter what your program looks like. The virtual smoothed reading should just be the algorithm I showed up above.
In summary:
Things are getting quite complex, you shouldnt have to be going to all this effort to get smooth temperature signals. Can you show us some logs of the temperature using the onboard logging features and T3000 to view the readings. (Not the Open Hab readings you showed up above).
I don’t know how to configure the trend logs. Doesn’t match the user manual I am looking at. I have an input called Z1AT but not clear what to put in which field
When I ask about stable inputs I’m asking how the task scheduling works. Is it single threaded, round robin so you read the input values, then run the programs in order? Or multiple threads?
If I put a WAIT directive in a program does it slow down all the input port scanning?
It’s not clear from the user docs if the value of an input can change during program execution because it’s in a different thread.
Graphing: type in the input, output, variable name here. You can use the 8 char label or the direct 1IN1 reference method. Panel number first, it can be any panel in the system, then the object reference like in, out or var.
Tip: To see the help system just hit the F1 key to pull up the help system and search though there.
We’ll update the help system to match the new trend log system but the principles are the same.
Tasks, Single Threading and WAIT:
This is getting way too deep for simple reading temperatures.
Inputs get read on their own task and updated throughout the system on their own time.
Same for programs working on vars, they have their own task and get propogated at the END of the program. There’s lots of references on this forum but the basic idea is let your program run to the very last line. The program will let the rest of the system know the results once all the logic has been scanned.
The value of variables and the state of outputs are calculated in a buffer as the program runs its course. When the last line of the program is executed the program exits, at that time the contents of the buffer are sent out to the variables table and the outputs table, to the real world outputs and variables.
Trend Logs: I would update the T3000 application for starters, the one you are showing is the original trend log system. While you are at it update the T3 controller firmware, its in the same dialog box.
T3000 → help → check for updates.
