Graph of boiler operation, click to embiggen
We recently upgraded our boiler to a high-efficiency modulating/condensing Triangle Tube Prestige Trimax Solo, and in perusing the manual, I found that the boiler has a ModBus interface . Woohoo, project! The final result is live charting like you see above; for more details, read on!
Per the boiler docs, the ModBus interface is Modbus/RTU using RS-485 for the physical layer. First thing, obviously, is to find an RS-485 adapter. Fortunately, I found one super cheap (under $10) at Amazon, a “Kedsum USB to RS485 Converter” [amzn] and despite the cheap price and appearance, it seems to work just fine:
Cheapo USB Adapter at Amazon
The adapter only has A and B connections, and no GND, but it works fine. I used a twisted pair from a CAT5 cable to connect to the A and B terminals on the boiler, plugged it into a spare Raspberry Pi, and was ready to test this thing.
Boiler ModBus Connections
Raspberry Pi w/ RS-485 Adapter
libmodbus makes communication simple; basically open the serial port and read addresses. A little test program I wrote verified that things are working:
# ./tt-status -s /dev/ttyUSB0 Status: DHW Mode Flame Present DHW Pump Supply temp: 168 °F Return temp: 145 °F DHW Storage temp: 102 °F Flue temp: 132 °F Outdoor temp: 35 °F Flame Ionization: 11 ?A Firing rate: 25 % Boiler Setpoint: 170 °F CH1 Maximum Setpoint: 143 °F DHW Setpoint: 125 °F
Ok! So to get the pretty graph above, I obviously needed some data collection; for this I used collectd simply because it already had a ModBus plugin. It did require some patching and hacking though; the non-bloggy details are on this page; the graph you see above was made by Visage.
Overall this has been very useful; the boiler controls are fairly involved, but primarily we want to get the outdoor reset curve tweaked so that we get nice long runtimes and low return temps, which keep the boiler in its most efficient condensing mode. My installer hit the default buttons and left, as contractors often do. Seeing how the boiler was working over time definitely helped me tweak things to improve performance, efficiency and comfort. Primarily, I drastically lowered the high end of the outdoor reset curve which defaulted to 170F For cast iron radiators, because we have much more radiation in this house than it needs at 170F output. I currently have the high end set to 140F. I may do another post on all that later… suffice it to say, doing a heat loss and measuring radiation and using that information to guide boiler setup is not rocket science, and you really need to do it for the sake of comfort and efficiency.
collectd, at least with the rrd output, doesn’t keep fine-grained data around for long. The current setup is useful for seeing how things behaved in the past couple days, but I’ll probably start logging fine-grained data to a database at some point, and can start doing fun things like using the firing rate to estimate gas usage over the month, look at therms per heating degree days in near real time, etc.
Other boilers have ModBus interfaces as well; in particular Lochinvar and NTI both mention the capability, although I haven’t yet found documentation on what data is available. If you have a boiler with ModBus and want to try this hack, drop me a line – I’d love to see how this looks in other homes, and I’d be glad to help you set up a collectd config file. I may see about creating a Raspberry Pi image to make this all more or less work out of the box.
Again, take a look at the the more detailed writeup for a bit more info, in particular the patches I used with the upstream tools, and if you try this at home & make it work, share what you find!
Hey this looks promising! I have that same boiler and want to use more of the built in functions such as this… later on the exported information would be so nice to monitor.
Also, I will be adding a wood boiler in parallel (ideally the gas source being backup only), so I wonder if somehow using the logic in the Trimax control could export and inform the pumps and relays on the wood side to mimic the precision of the gas boiler without having to buy and install redundant controls…?
I don’t know for sure that you could use the Trimax controls in the other direction, i.e. to inform a wood boiler, but take a look at the control supplement and see what you think.
I’d like to try this but my boiler does not currently support modbus. It’s a Weil-McLain HE II and the control board is a Gold GV Model 1013-200. Any suggestions on a control board I could swap in that would support modbus readout?
Hey Adam – I know very little about other boilers, sorry. My old boiler was a Weil Mclain, though – super basic, no smarts at all, and I set up an Electric Imp with LM75 temp sensors to do some data logging of supply and return temperatures. Not quite as slick, but it was still interesting.
I too have an older boiler. Can you give details on your electric imp setup? Cost, sample results, etc?
I didn’t find the results to be super compelling, but then I wasn’t graphing them terribly nicely. It certainly can show you supply & return temps, and give you an idea of when the boiler is running.
An Imp costs about $25, a breakout board is around $13, lm75 sensors about $1 each. You could also use 1-wire sensors; a pack of 5 DS18b20 is about $8 on Amazon. Other than that I just used an old USB charger for a power supply and some spare perf-board and wire to get it all rigged together.
Hi Eric, I’m tinkering around with this great tutorial. I have a new TT PT-60 boiler I recently installed. But I’m having problems with the tt-status utility. It’s not able to read anything from addr 0. Failure happens at “Error: Modbus read of 1 byte at addr 0 failed”
The error happens using the same USB-> RS485 adapter you used at /dev/ttyUSB0 and also a RaspiComm that appears as /dev/ttyRPC0. For development purposes I’m using a modbus slave simulator program on Windows instead of the actual boiler. Maybe that’s the problem?
I assume that it must be the simulator that’s the problem; I don’t know how you set it up and define the available registers, but that might be the problem.
There are at least 2 modbus register types, input and holding. Perhaps you need to be sure the simulator is set up so that address 0 is an input register?
I’m thinking it might be related to the simulator too. I’m monitoring the raw serial data at the moment. You can see here I run tt-status 13 times before it finally responds on the 000015 line. I have no idea why the receive packets are coming through differently on lines 0 thrugh 14.
000000-Rx:01 D0 00 01 4C FC
000001-Rx:01 D0 00 01 4C FC
000002-Rx:01 D0 00 01 4C FC
000003-Rx:01 D0 00 01 4C FC
000004-Rx:01 D0 00 01 4C FC
000005-Rx:01 D0 00 01 4C FC
000006-Rx:01 D0 00 01 4C FC
000007-Rx:01 D0 00 01 4C FC
000008-Rx:01 D0 00 01 4C FC
000009-Rx:01 D0 00 01 4C FC
000010-Rx:01 D0 00 01 4C FC
000011-Rx:01 D0 00 01 4C FC
000012-Rx:01 D0 00 01 4C FC
000013-Rx:01 D0 00 01 4C FC
000014-Rx:01 04 03 00 00 01 31 8E
000015-Tx:01 04 02 01 F4 B9 27
000016-Rx:01 04 03 00 00 09 30 48
000017-Tx:01 04 12 01 F4 01 90 00 7D 00 7D 00 64 00 00 00 64 00 19 00 7D 86 3B
000018-Rx:01 03 05 00 00 02 C4 C7
000019-Tx:01 83 02 C0 F1
It turns out that it was indeed just a terrible emulator. I downloaded a trial of WinModBus and it’s working perfectly. Now to configure the collectd values and post them to my web server.
Thanks for the work you put into this.
Sure thing! Let me know if/when it all gets up & running. :)
I’m running into troubles trying to get your .deb files with the patches to collectd’s modbus plugin working properly. Seems like it doesn’t want to connect to /dev/ttyUSB0 or /dev/ttyRPC0. The collectd log file is reporting:
Modbus plugin: Creating new Modbus/TCP object failed.
Modbus plugin: mb_init_connection ([hostname]/) failed.
I’ve modified the collectd.conf file’s Host section to point to:
Device “/dev/ttyRPC0”
Baudrate 38400
Interval 60
Not sure what to jump into next. So close )
It’s looking for a TCP target, but it sounds like you don’t have that.
I used mbusd (http://mbus.sourceforge.net/) to create a Modbus/TCP target. Alternately the patch at http://sandeen.net/modbus-boiler/collectd-modbus-rtu.patch should let it talk directly to a serial device. What does your collectd.conf look like? You’ll want something like:
rather than:
I do have something similar. I’ve tried
Device “/dev/ttyRPC0?
Baudrate 38400
Interval 60
That ttyRPC0 is the Raspicomm serial interface. I’ve tried it with the same USB to RS485 device you used at ttyUSB0. Both physical devices throw the same error.
I downloaded and installed your .deb files that (I thought) included the patched modbus plugin instead of attempting to apply the patches myself. (http://sandeen.net/modbus-boiler/collectd-raspbian/)
Yes, those debs should have both patches IIRC. Can you talk directly to /dev/ttyRPC0 with the tt-status utility?
Yes, works great with tt-status for ttyRPC0
BTW, I’m using WinModMBus to watch the modbus serial traffic and emulate the boiler’s registers. Very cool program.
Just an update: I was thinking that maybe the version of Rasbian that I’m using on the RPI may have updated/overwritten the modbus colletcd plugin from your patched debs. So I uninstalled all packages related to collectd and then reinstalled your debs. Still having the same problem.
I think the next step is to try to install collectd from source and apply your patches manually. Think that makes sense?
Btw, I see your patches will be included in the next release of collectd. Nice!
I’ve done a little more debugging on this issue. Not sure what’s causing host->conntype to be set as MBCONN_TCP.
In my collectd.conf I have the following:
Device “/dev/ttyUSB0”
Baudrate 38400
Interval 60
Oops didn’t mean to post so soon.
If I remove the Baudrate line then it will throw the error for “No serial baudrate has been specified” while parsing the config file. So at least at that point it’s thinking we have a MBCONN_RTU.
For some reason mb_init_connection is following the logic for host >conntype == MBCONN_TCP instead of the else block.
Still haven’t figured out why.
I’ve been playing with the order of the items in modbus.conf
If I use the ordering of your suggested additions modbus.conf. (data nodes first followed by the Host section) This is what the error log looks like on a colelctd service restart. Note it throws an error for each Data section.
[2015-04-09 13:04:14] Exiting normally.
[2015-04-09 13:04:14] collectd: Stopping 5 read threads.
[2015-04-09 13:04:14] collectd: Stopping 5 write threads.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] Modbus plugin: Creating new Modbus/TCP object failed.
[2015-04-09 13:04:16] Modbus plugin: mb_init_connection (localhost/) failed.
[2015-04-09 13:04:16] read-function of plugin `modbus-localhost’ failed. Will suspend it for 120.000 seconds.
[2015-04-09 13:04:16] Initialization complete, entering read-loop.
If I change collectd.conf so the Host is the first section the error log looks like this:
[2015-04-09 13:12:39] Exiting normally.
[2015-04-09 13:12:39] collectd: Stopping 5 read threads.
[2015-04-09 13:12:39] collectd: Stopping 5 write threads.
[2015-04-09 13:12:41] read-function of plugin `modbus-localhost’ failed. Will suspend it for 120.000 seconds.
[2015-04-09 13:12:41] Initialization complete, entering read-loop.
Here’s my conf file:
# Config file for collectd(1).
#
# Some plugins need additional configuration and are disabled by default.
# Please read collectd.conf(5) for details.
#
# You should also read /usr/share/doc/collectd-core/README.Debian.plugins
# before enabling any more plugins.
##############################################################################
# Global #
#—————————————————————————-#
# Global settings for the daemon. #
##############################################################################
Hostname “localhost”
#FQDNLookup true
BaseDir “/var/lib/collectd”
PluginDir “/usr/lib/collectd”
#TypesDB “/usr/share/collectd/types.db” “/etc/collectd/my_types.db”
#—————————————————————————-#
# When enabled, plugins are loaded automatically with the default options #
# when an appropriate block is encountered. #
# Disabled by default. #
#—————————————————————————-#
#AutoLoadPlugin True
#—————————————————————————-#
# Interval at which to query values. This may be overwritten on a per-plugin #
# base by using the ‘Interval’ option of the LoadPlugin block: #
# #
# Interval 60 #
# #
#—————————————————————————-#
Interval 20
Timeout 2
ReadThreads 5
WriteThreads 5
# Limit the size of the write queue. Default is no limit. Setting up a limit
# is recommended for servers handling a high volume of traffic.
#WriteQueueLimitHigh 1000000
#WriteQueueLimitLow 800000
##############################################################################
# Logging #
#—————————————————————————-#
# Plugins which provide logging functions should be loaded first, so log #
# messages generated when loading or configuring other plugins can be #
# accessed. #
##############################################################################
LoadPlugin logfile
LoadPlugin syslog
LogLevel “info”
File “/var/log/collectd.log”
Timestamp true
PrintSeverity false
LogLevel info
##############################################################################
# LoadPlugin section #
#—————————————————————————-#
# Specify what features to activate. #
##############################################################################
# Load required plugins:
LoadPlugin modbus
LoadPlugin match_regex
# Load required targets:
LoadPlugin target_scale
Device “/dev/ttyRPC0”
Baudrate 38400
Interval 60
Instance “Boiler”
Collect “supply-temp”
Collect “return-temp”
Collect “dhw-temp”
Collect “flue-temp”
Collect “outdoor-temp”
Collect “firing-rate”
Collect “boiler-setpoint”
RegisterBase 768
RegisterCmd ReadInput
RegisterType Int16
Type temperature
Instance “supply”
RegisterBase 769
RegisterCmd ReadInput
RegisterType Int16
Type temperature
Instance “return”
RegisterBase 770
RegisterCmd ReadInput
RegisterType Int16
Type temperature
Instance “dhw”
RegisterBase 771
RegisterCmd ReadInput
RegisterType Int16
Type temperature
Instance “flue”
RegisterBase 772
RegisterCmd ReadInput
RegisterType Int16
Type temperature
Instance “outdoor”
RegisterBase 775
RegisterCmd ReadInput
RegisterType Int16
Type percent
Instance “firing-rate”
# Note – setpoint is “32768” (invalid) if boiler is idle.
# I can’t figure out how to make this match in chains/rules
# below, so I simply changed the temperature type to only
# be valid from -100 to +200 and this value gets ignored.
# Bleah.
RegisterBase 776
RegisterCmd ReadInput
RegisterType Int16
Type temperature
Instance “setpoint”
PreCacheChain “PreCache”
# Boiler supply is in 0.1 degrees C; convert to C
Plugin “^modbus$”
Type “^temperature$”
TypeInstance “^supply$”
Factor 0.1
# Boiler temps are in degrees C
Plugin “^modbus$”
Type “^temperature$”
# F = (C * 9) / 5 + 32
Factor 9
Factor 0.2
Offset 32
Filter “*.conf”
Why don’t you shoot me an email, we’ll hash this out, and post the results back in the comments. Might work better. :)
Just to update all of this for people that might read it in the future. I was able to get everything working using my Rasipcomm serial interface at /dev/ttyRPC0. (no TCP to RTU daemon necessary.) I had to download the sources, apply the patches and compile/install everything. Works very well. Now to figure out how I’m going to use the data.
Thanks for all your help Eric and for doing the work on making this possible.
Hi Eric,
I like your article. I’m currently trying to use the same Kedsum USB 485 device in a rpi to talk to a piece of equipment that wants 9600 Baud, 7 Bits, Even Parity, 1 Stop Bit. What I have found is that if I put the kedsum in my laptop, and apply those settings, I can talk to the equipment just fine, but when I put the kedsum in the rpi and use stty to configure it I just get garbage, even though stty will report that the settings were applied. Did you have to load your own driver to the rpi for the kedsum to work properly?
Thanks,
Doug
I just plugged it in and it worked … how are you “talking” to it? Did you try my little ttstatus.c test program on the rpi?
Thanks for putting this all together!! As I am a year behind, some things seem to not be working. I ordered what *should* be the same dongle (lsusb reports:
Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter) Can you confirm that is the same dongle you have?
When I run the tt-status, I am thrown this error:
“Error: Modbus read of 1 byte at addr 0 failed”
I’ve checked the wiring and the boiler is set to address 1. Any ideas? Also the tt-status.c has a minor error that needs to be corrected prior to compiling by usining the correct comment code:
#warning slave ID needs to be an option too
A little late to the game, but from what I can surmise, collectd has merged in your changes (I’m running collectd 5.4.1). syslog has these errors in it:
Modbus plugin: Unknown configuration option: RegisterCmd
Modbus plugin: Data block “supply-temp”: No type has been specified.
Any help would be appreciated as I was planning on using this as my cornerstone of my home energy management system.
Thanks
Mine is also:
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapterAs for the warning in tt-status.c, that’s just supposed to throw a compile-time error; it was a warming to myself to fix that later.
Collectd did merge patches, but some options changed since the original version I was running locally. I’ts now i.e. –
RegisterBase 768
RegisterType Int16
# RegisterCmd ReadInput <-- that was the old way
ModbusRegisterType input
Type temperature
Instance "supply"
....
I’ll send you an email, and see if I can help you get things sorted.
I am having the same error, did anyone have any insight?
The collectd status gives the following information:
Modbus plugin: Data block “flue-temp”: No type has been specified.
Modbus plugin: Unknown configuration option: RegisterCmd
I get the same two errors for a few data blocks (but not all).
I’ve tried “RegisterCmd ReadInput” and “ModbusRegisterType input”, but there was no change.
running tt-status.c gives expected results, without errors.
also Eric, thank you for all your work here. This is great!
Hi Ben – I really should update this post now that all the modbus stuff is merged in current upstream collectd. I’ll send you an email, and when we get it sorted properly I’ll drop another comment here & update the post as needed.
After a year, we’ve been able to get this up and running. The fix seems to be the 3rd dongle I ordered (reports the same as the 1st). I’ve also implemented wunderground data using collectd’s curl-json to more accurately report temperature as the outdoor sensor that came with my boiler is always 5-10 degrees high.
Thanks
I’m diving in! I have a Lochinvar KH and just ordered a Pi.
Awesome! Please let me know how it goes. The Lochinvar almost certainly has different modbus addressing etc, but it seems well documented. Drop me a note if I can help.
Since I already have a NAS box, can I use it, instead of a Raspberry Pi?
Of course – let me know how it goes!
hi Eric. Little late to the game but I’m about to try this out. I have a Lochinvar KHN110 boiler and got the usb adapter and rasberry from amazon. What flavor if rasberry are you running?
Thank you
Alex
pi@raspberrypi ~ $ cat /etc/debian_version
7.6
It’s pretty old, TBH. :) I’d maybe start by modifying my little tt-status to try to talk to the Lochinvar if you’re able to do so. Did you find documentation on the Lochinvar modbus map?
I’d be happy to help modify my little C program to test communication if you need a hand, then once you know that’s all good, can work on the ongoing monitoring side of things. The Lochinvar docs seem straightforward.
That would be awesome. i downloaded the pdf file. Going to load OS on the rasberry and connect the usb dongle the the boiler. now that i looked at the pdf i’m not sure if it will work. I don’t think i have modbus/bacnet board, only modbus connection on the boiler but if i understand this correctly, pi will become the board so it should work :). I’ll try to get this going this weekend. Thank you for offering to help
Hm. Now that I read the doc more, it’s starting to look like you actually need the modbus board. But you do have a modbus connection on the boiler? The docs aren’t really clear. :(
Anyway, I pushed a “lochinvar” branch to the github project – if you have something to talk to, it should be able to talk to it, though it probably has a bug or two. ;)
$ git clone https://github.com/sandeen/tt-status.git$ cd tt-status
$ git checkout lochinvar
$ make
$ ./tt-status -l -s /dev/ttyUSB0
edit: still can’t tell from the manuals if it has modbus built in or not. If it does, you might need to dig through menus to enable it, or to find/set the modbus slave ID.
Its a bit confusing. I looked at the install manual and schematic for pins 45,46,47 are labeled MODBUS. Here is a screen capture.
https://photos.app.goo.gl/2vvqYlqVG1eo1Wa22
But it seems that all the settings and controls are on the modbus control module that is optional. It has dipswitches for addresses and other options. So I think modbus pins from the low voltage control board connect to the module and then usb adapter that you use connects to the modbus board. If thats the case then i can’t do much without the board. I’ll try to research it tomorrow.
Morning. So it looks like its not going to work without modbus board. I found the service manual http://www.lochinvar.com/_linefiles/100267829_2000508773_Rev%20D_KH%20SERVICE%20MANUAL%20(Fan%20Troubleshooting).pdf and there is no where to set the modbus address without the communication board. Communication board has dipswitches on it that are used to set the address. I sent an email to my hvac company to see if i can get a quote for this board
Hi Eric. I contacted Lochinvar and they confirmed that I do need the board for modbus to work. I placed an order today, should have it mid December. Will update you when it comes in.
Thanks for the update. Hope it wasn’t too expensive!
Not cheap. $280. Cheaper than getting it from my hvac company :)
What was the part number for the MODBUS board from Lochinvar? Would like to do the same!
KIT30071 I got it from https://www.supplyhouse.com/Lochinvar-KIT30071-Modbus-Communications
What lochinvar do you have?
I just got it installed today. Going to get the raspberry working tomorrow hopefully
Cool! I just checked and I hadn’t actually pushed any code to the “lochinvar” branch. It’s pushed now. ;)
Hopefully this will be a place to start, and we can fix it up to get out the values that you care about. (In reality, I’m still using collectd to gather my daily stats, but the test program will be nice to figure out what’s where).
$ git clone https://github.com/sandeen/tt-status.git$ cd tt-status
$ git checkout lochinvar
$ make
$ ./tt-status -l -s /dev/ttyUSB0
Hello. I got the modbus board installed. Got the laptop and made a rs485 cable. Connected A on the usb adapter to port 46 on the lochinvar board and B to port 47. Downloaded WinbusMod software. Configured it for com5, 9600 baud, no parity 2 stop bits. Software says port open. Am I suppose to see any activity? First time using modbus so I’m pretty new to this. Boiler is currently not running and in standby.
Any ideas how to test make sure everything works? :)
I’m installing raspbian stretch lite on the PI right now. Wanted to test with the laptop first
Pardon the stupidity of my question :)
Got raspberry up and running.
did these:
git clone https://github.com/sandeen/tt-status.git
$ cd tt-status
$ git checkout lochinvar
$ make
Got this:
pi@raspberrypi:~/tt-status $ make
gcc -lmodbus -o tt-status tt-status.c
tt-status.c:32:27: fatal error: modbus/modbus.h: No such file or directory
#include
^
compilation terminated.
Makefile:5: recipe for target ‘tt-status’ failed
make: *** [tt-status] Error 1
I’ll send you email
But for posterity,
$ sudo apt-get install libmodbus-devHi Eric, I have to say thanks for publishing this info. My goal is to take this info one more step by allowing a text or email if boiler goes off on alarm. However I have one question. All info reported thru modbus is accurate accept for the supply and return temps. The supply temp is alway 10-15 degrees lower than what the boiler indicates and the return temp is usually 2-3 degrees off. Have you run into this scenario?
Weird, no, I have not noticed that – you’ve set this up and observed a difference between what modbus says and what the boiler screen says?
I’ll have to double check mine.
Seems ok here:
Hi Eric,
Not sure if you are still checking this page, or if you are still working on this project, but I could use some help if you are interested. I just purchased and installed a Glenwood pellet boiler (locally made near me). The controller is a Love Controls 32B63 that uses modbus over RS-485. I was able to get your program running on a Pi 3 using a JBtek USB adapter (https://www.amazon.com/JBtek-Converter-Adapter-ch340T-Supported/dp/B00NKAJGZM/ref=sr_1_15?ie=UTF8&qid=1548033969&sr=8-15&keywords=usb+rs-485).
When running, it would fail at “Modbus read of 1 byte at add 0 failed”. I commented that out, and then it failed at the next one “of 9 bytes at add 0x300…”. Again, I commented that out, and I started to see some results. However, none of the results make sense. I played around with it a bit more, but couldn’t figure out how to translate the address fields from the Love Controls data sheet into the code.
Any help you could offer would be wonderful. All I am interested in is seeing the boiler temp, and any status of the motors if possible. You can find the data sheet here: http://www.dwyer-inst.com/PDF_files/E_90_BPC_rev5.pdf
Page 24 has the modbus info on it.
Thanks in advance!
Hi Austin –
The modbus map is unique to the device, so the program as written for my boiler is unlikely to give you any meaningful results for your device.
Page 24 of the PDF you linked to contains the registers, their sizes, and their meanings. Hopefully some of that is what you’re after; 0x1001 seems to be the setpoint, for example. You’d just need to change the program to read different registers, and present them with the units or descriptions that are associated with them.
Hi Eric,
Thank you so much for your fast reply. I’m a complete noob when it comes to programing a Pi, so I’m trying to wrap my head around how to change the address info. I found a Modbus tutorial, so I am going to go through that and see if I can get it working. I was able to successfully connect with a PC using the USB-RS-485 adapter running the Dwyer software, so I found the communications settings using that.
I’ll keep you updated with what I find out, and can post the code changes if anyone else is interested in it.
Thanks again!
Hi Eric,
thanks for dealing with collectd and modbus. I’m trying to collect data from several k-type thermocouples connected to an ICP DAS M-7019R modbus analog-to-digital module(https://www.icpdas-usa.com/documents/userManual-M-7019R.pdf page 153). When I’m using the qModMaster (a Master GUI) program I’m able to communicate with the device, taking the devices slave address 1, the function code 0x04, the start address 0 and the number of coils to read 1 or up to 8. So the basic setup with my USB/RS485 converter is working.. but the collectd configuration file is confusing me. I don’t get where to define for an example the slave address of my device. Is this defined by the “1” in ‘Slave 1’ ?? What RegisterCmd is for is obvious, but then again RegisterBase is not..
Can you please give me a hint on how it works? I tried to get a hint by looking at the source code, but I think I’m too inexperienced in C++ to learn anything from it. Thanks a lot!
Hi Martin –
Sorry for the late reply. The best reference for the modbus plugins is still the big collectd.conf man page, though perhaps you already found that.
Yes, “Slave X” should be the modbus device address.
If I remember right, this is the translation:
slave 1in theslavesettingRegisterCmd ReadInputRegisterBase 0RegisterType, i.e.Uint32would read 4 bytesHi Eric –
I’ve been tracking this project for awhile now and finally have time to try and hook up my boiler (TT Prestige). Hoping all goes smooth so I can get it dialed in before winter. I’m also starting to work with MQTT as a means to share data. Are you familiar, and do you have any idea what it would take to publish the info gathered from the modbus side of things to MQTT?
Thanks for writing this. It looks like you’ve helped a bunch of people get access to their boiler data.
When I first did this work I didn’t know much about mqtt but I’ve used it for other similar projects since, and that may well be a good way to go. The only thing I’ve sort of written from scratch using mqtt was something to watch my excess solar generation and throttle my EV charger to match it. I used mosquitto python bindings to hack that up IIRC, but there are probably several ways to do this sort of thing.
Hi Eric –
Finally getting around to trying this project. If you are still monitoring this I have a question for you. I’ve got a Triangle Tube Prestige boiler so I think it should work with your code without change. I also make sure my slave ID is set to 1 in the boiler. I got the program to compile correctly but when I run it I get “Error: Modbus read of 9 bytes at addr 0x300 failed”. I’m no expert at troubleshooting code but I see where that error is generated. I assume because it is getting past the “Read 1 register …” part of the code successfully that’s it’s communicating with the boiler but I could be wrong. Any thoughts on what I’m missing that would create the addr 0x300 error? Thanks in advance for any help, and thanks for posting the code and the instructions.
Pat
Hey Pat –
What’s the full output when you run it, can you paste it all? Also – I have been bad and don’t really have a canonical copy of that little tool, I really should have put it on github or someting to track revisions. Here’s a newer version, give that a try and if you get failures show me everything it returned?
Eric
First, I wanted to thank you for putting together this walkthrough. I just got it running on my Triangle boiler, but I am having some issues getting collectd and Visage working. It looks like Visage has possibly been discontinued. Would it be possible to get an updated walkthrough on the collectd/visage stuff? Any help would be greatly appreciated.
yeah, I gave up on Visage a pretty long time ago. I’m using collectd (to get modbus/tcp data), influx (as database), and Grafana (for viz) now. Writing up that walkthrough would … take a fair bit of time… :)
I used your modbus guide and this software to put together my own home monitoring system of my Triangle Tube boiler. Here is a link the monitoring software I hacked to work with the boiler. If you are interested, I can send you more details.
https://xavierberger.github.io/RPi-Monitor-docs/01_features.html
I can also send you screen shots on it. I have it active and on the web so I can view it anywhere anytime.
Hi George,
I would love to see your screen shots. I am trying to remotely monitor 3 boilers at my residence. I have a Master with 2 slaves operating in cascade mode and would love to optimize.
Matt
The easiest way to see what I did is to go to the website I set up.
http://walk-home.homeip.net:8888/index.html
Also, go to the Statistics page where you can select various to be parameters displayed graphically.