DRU fireplace control using OH2, NodeRed & Modbus

The DRU bridge only allows one simultaneous session/connection. Polling too fast will result in 1 session still open while the other is already trying to establish … this is most likely the cause of the errors you are seeing.

I poll all of my DRU modbus settings at a 10 second interval, but i make sure every poll for each individual item is delayed by 200ms to avoid multiple simultaneous polls.

Br

Roel

With the Modbus binding, you can poll all registers in one hit to reduce overheads.

By default, the binding will close the TCP connection between polls (thus allowing other apps to have a turn, so you’d probably want to keep it that way)

Writes are ad-hoc, asynchronous, so they could pop up in rapid succession. The binding does allow you to set a minimum time between transactions, probably needed in this case to allow TCP connection to close tidily before making a new one. Try 200mS.

I have 1 ModBUS poller which was running with an interval of 1000ms.
Changed it to 5000ms and looks like the errors are gone now. I will monitor it…

Update:

Unfortunately increasing the interval doesn’t seem to help.
I am not writing much values so don’t think that the problem either.
See screenshot for the errors I am getting.

It’s illegible. Please copy/paste sample error log text.

Note that your Modbus things configuration is still secret.

EDIT I found out how to view a better image.
You’ve got a
Modbus Slave Exception Error Code = 11

That means the remote end has rejected a request rom openHAB with a response 11.
This is quite a rare code, I’ve seen one description as -

Specialized use in conjunction with gateways, indicates that no response was obtained from the target device. Usually means that the device is not present on the network.

I understand this fireplace setup does actually employ a gateway box between modbus and device? Sounds like the communications between those in trouble.

Following is NOT a fix, it’s a suggestion to get better use from the bindings retry mechanism in your situation. It MIGHT improve automatic recovery - or it might not.

By default, the binding will retry a failing transaction three times before declaring it terminally failed.

Because this transaction is rejected by the remote end quickly, there’s little time between these retries. Whatever is wrong at the remote end, we’re not allowing it much time to go away.

I don’t think you changed your TCP Things parametertimeBetweenTransactionsMillis` to 200 mS as recommended yet? The log of retries shows them happening at around the default 60mS intervals.

Try 200. This will space out the retries - maybe it will recover.
If still failing all three tries, try 500. I wouldn’t go further than that, or it will begin to affect ordinary running.

Hi Guys,
As winter has rolled on, i have finally gotten round to wanting to set this up.
i have no experience with modbus (nor node-red) and would prefer to do this using the old school rules engine.

does anyone have a couple of quick screen grabs to help me get going?
I took this on with gusto - but go as far as adding things and realizing there are 4 options… and with that the gusto disappeared. Don;t really want to take risks with fire… and kids in the house

Took a stab in the dark - set the Honeywell up as a TCP slave and it looks OK (appears online etc)

After this, I had a crack at creating the read register (40203) - this is what I have set:

Unfortunately though, this does not work - I get the error:

Status: OFFLINE - CONFIGURATION_ERROR Thing modbus:data:1c46a4cb readStart=40203, and readValueType=uint64 were specified even though the data thing is child of endpoint (that is, write-only)!

Have I made simple, but stupid mistake?

Modbus is a polling technology.

The binding implementation requires a hierarchy of three Things for reading:
A Bridge Thing, TCP or serial, essentially defines the “device”.
Poller Thing(s), defines a block of registers to be read on schedule or demand
Data Thing(s), defines how to interpret one or more of the polled block.

You need to set up a Poller and have your data Thing as child of that. Normally you’d poll a bunch of registers in one hit, and have multiple Data things making sense of them.

Exceptionally it is possible to attach a Data Thing directly to a TCP Bridge for writing only - you’ve done this by accident, to explain the error message.

Thanks - you’re a legend. I’ll have a crack at it tonight.
I thought the 2 steps I had was enough, clearly misunderstood the design, but It’s a bunch clearer now.
I suspect this should be enough for me to get going. Thanks

Hmmm… a quick look shows this on the poller:

I am guessing I only need one?
Could you possibly share your config for this (and potentially the last of the 3 config too?) - pretty please

I tried and failed :slight_smile:

Status: OFFLINE - COMMUNICATION_ERROR Error with read: org.openhab.io.transport.modbus.ModbusConnectionException: Error connecting to endpoint ModbusTCPSlaveEndpoint@3299d674[address=192.168.0.49,port=502]

I couldn’t say. It depends on what you want to read, and how often. You may have more than one poller e.g. handling different register types. You may only need one poller to fetch a block of multiple similar registers.

Nope, I don’t have one. That’s okay, you can learn as we go :smiley:

'Length" parameter for a Poller Thing is specified in Modbus protocol native “raw units”. For holding type registers, that is 16-bit registers. You will certainly need more than one of those to make the 64-bit value that you were looking for earlier. I don’t know if you actually want a 64-bit value.

Some slaves will be smart enough to know their own register structure is 32 or 64-bit and blow out silly requests for partial data length or starting on the wrong odd/even address boundary etc. I couldn’t say what yours does.

I think that’s all incidental for now, though -

That looks pretty fundamental, cannot get the TCP connection to device.
Note, I think someone pointed out it only does one TCP connection at a time - cannot do openHAB and other app at same time?
Confident in your IP address and slave ID ?

@rossko57 - I appreciate your help.
I’ve tried hitting this from every angle - I’ve installed several apps to try trap mod is config.

Although the remote app for the fireplace is working, Abu connection from any other app returns a message like:

# CAS Modbus Scanner 0.0.19

11/12/2019 13:38:05

Analysis of Task: 192.168.0.49, Addr 2, Read Holding Register 40201-300

TX (Request)
02 03 00 C8 00 64
Slave ID, 2, (0x02)
Function, Read Holding Registers, (0x03)
Starting Address, 40201, (0x00 0xC8)
Quantity, 100, (0x00 0x64)

RX (Response)
02 83 0A
Slave ID, 2, (0x02)
Function, Exception, (0x83)
Exception Code, Gateway Path Unavailable, (0x0A)

If I change my config settings targeting a different IP or space id, the message is different. (Consistently so, so I am sure I have the right values here)

The fire place is as per the original dru spec at the start of this thread and so I would assume the config would be the same?

For those that have DRU fireplaces up and working… is there anything required on the Honeywell gateway to allow connectivity from Openhab (that I missed) do I somehow need to pair the gateway to my OH instanced? Also, did the DRU app continue functioning after adding Openhab?

It’s starting to feel like having both working is never going to happen?

Any help much appreciated.

That is a different ID to the one in your TCP Thing

That’s the error @petermdevries was having, which we did not get to the bottom of. It does mean the target device (Honeywell gateway?) is responding to us - TCP address is correct, hurrah! - but does not like what is being asked to do.
That may be about config or something else - gateway busy, device on other side of gateway missing, asleep, busy.

Modbus stuff doesn’t usually require any kind of “pairing” but there’s no way to know what goes on in the Honeywell black box. It’s not impossible it only accepts queries from friends.

Yes, I’m trying to connect direct from an app (to figure out slave Id etc)
This is correct I think (also according to the docs above) - still gateway issues though

Maybe this can/will help you. Below screenshots of my configuration. I implemented it a couple of weeks ago, so don’t know everything by heart anymore :grimacing:

BRI-DRU-01 is the (host)name of the gateway. First the Modbus TCP slave:

image

Then a/the status poller:

Then I have a couple of things to read/write values:

For example, to get/set the Main Burner:

At some points I created a transform function to read/write correct values. For this item DruActionMainBurner.js

// variable "input" contains command string passed by openHAB
(function(inputData) {
    var TURN_BURNER_OFF = 3;
	var TURN_BURNER_ON = 101;
    var out = 0;
    if (inputData == 'ON') {
         out = TURN_BURNER_ON;
    } else if (inputData == 'OFF') {
         out = TURN_BURNER_OFF;
    } else {
         // No Action
         out = 0;
    }
    return out;
})(input)

And for example the Room Temperature:

with an helper function to convert the value.

// Wrap everything in a function (no global variable pollution)
// variable "input" contains data passed by openhab
(function(inputData) {
    // on read: the polled number as string
    // on write: openHAB command as string
    var DIVIDE_BY = 10;
    return parseFloat(inputData) / DIVIDE_BY;
})(input)

It’s quite a lot to share everything, but perhaps this gives some help.

The only thing I still have (didn’t spent much time yet) are the errors like posted before.
Also noted that sometimes I need to restart the modbus binding for some reason.

1 Like

Wow - that’s an awesome post. Thanks. Im out and about tonight but will feed back as soon as I play. Thanks so much everyone for the help.

Only question… is the mobile app still working and did you have to pair the Openhab server with the bridge somehow, or did this just work straight up?

Between what you’ve said and @rossko57 has helped with… I must be able to sort this now

Thanks again

Do I see you writing individual bits in a register there?
There are other approaches to that - should you need to avoid setting/unsetting other bits in the same register

1 Like

Yes, mobile app is still working. I don’t believe I had to pair the Openhab server with the bridge. I have only paired the bridge with the Dru itself once, but you’ve probably done that already to get the mobile app working.

Guess- thanks so very much fire all the help.
In the end, it seems the problem was that my slave ID is actually 3 (which is not what the documentation says)
I am able to read the fire status now (my primary goal) - so can move onwards.

As a matter of interest, I truly love my DRU fireplace, despite always choosing charcoal / wood when cooking outdoors, but my main chaser here is the lack of fire crackle. I’ll be hiding a small Bluetooth speaker beneath the fireplace and playing the crackling sound manually now :stuck_out_tongue_winking_eye:

1 Like

This is awesome. Great work!
Is there any way to get this in a homebridge plugin? :slight_smile:
Or maybe using the Homebridge-modbus plugin?

What a great work. I’m using Domoticz at the moment (unfortunately) but I’ve used the code to control my fireplace with it as well.

Only one problem occurs when configuring the Wave pattern.

I use the flow as suggested for that:

[{"id":"fb6a7742.8e6508","type":"inject","z":"fb344059.73db6","name":"","topic":"","payload":"1","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":250,"y":1500,"wires":[["6624e634.fec378"]]},{"id":"6624e634.fec378","type":"function","z":"fb344059.73db6","name":"Startup Values","func":"msg.payload = { value:[2569,3340,3854,3342,2572,1801,773,514,1027,2054], \n'fc': 16, \n'unitid': 2, \n'address': 40421, \n'quantity': 10 } \nreturn msg","outputs":1,"noerr":0,"x":420,"y":1500,"wires":[["e24f425c.735fb"]]},{"id":"e24f425c.735fb","type":"modbus-flex-write","z":"fb344059.73db6","name":"test flex write","showStatusActivities":true,"showErrors":true,"server":"e702863e.44b568","x":600,"y":1500,"wires":[[],[]]},{"id":"13b4349f.9fdcdb","type":"comment","z":"fb344059.73db6","name":"Eco Wave COMFORT","info":"","x":280,"y":1460,"wires":[]},{"id":"1f4db27c.1bcafe","type":"function","z":"fb344059.73db6","name":"Startup Values","func":"msg.payload = { value:[1797,2312,2569,2313,1800,1029,259,257,513,1283], \n'fc': 16, \n'unitid': 2, \n'address': 40421, \n'quantity': 10 } \nreturn msg","outputs":1,"noerr":0,"x":420,"y":1600,"wires":[["e24f425c.735fb"]]},{"id":"9d606100.4b5e3","type":"inject","z":"fb344059.73db6","name":"","topic":"","payload":"1","payloadType":"num","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":250,"y":1600,"wires":[["1f4db27c.1bcafe"]]},{"id":"1cfcc137.ff23df","type":"comment","z":"fb344059.73db6","name":"Eco Wave ECO","info":"","x":260,"y":1560,"wires":[]},{"id":"e702863e.44b568","type":"modbus-client","z":"","name":"DRU","clienttype":"tcp","bufferCommands":true,"stateLogEnabled":false,"tcpHost":"172.16.11.51","tcpPort":"502","tcpType":"DEFAULT","serialPort":"/dev/ttyUSB","serialType":"RTU-BUFFERD","serialBaudrate":"9600","serialDatabits":"8","serialStopbits":"1","serialParity":"none","serialConnectionDelay":"100","unit_id":1,"commandDelay":1,"clientTimeout":1000,"reconnectTimeout":2000}]

But nothing happens and reding the debug I get the following message:

msg : error
"Error: Modbus exception 3: Illegal data value (value cannot be written to this register)"

On this page the error is described but I cannot find out what is wrong with the value that I send. Anyone experiencing the same problem?