Modbus binding issues with De Dietrich Diematic 3 / 2 masters / 5 second interval in/out


I’m trying to connect my heating boiler to my openHAB using the modbus binding without any success. Before switching to openHAB, I had done a python script using minimalmodbus lib which get all my needed values without any problem (it still works!)

The “problem” is, I think, that my boiler is a De Dietrich with a Diematic 3 controller which have a strange modbus 2 master implementation - from what i’ve seen as I’m not a specialist at all on modbus protocol.

In summary, the boiler send bits for 5 seconds then switch to listen mode for 5 seconds and so on. While sending, it always send all its registers.

In that scenario I don’t know how to configure my modbus polling.

Does anybody has already connected such a boiler using Diematic 3 or a similar modbus implementation ?

Thanks in advance,


Are you trying to “eavesdrop” on an exchange between controller and boiler?
Even if this is really modbus, and not just something like it, I still don’t think you will be able to use openHAB modbus binding. That’s a ‘master’ and cannot deal with unsolicited data.

If you were a reaally keen DIYer, and have established that “proper” modbus protocol is used. You could use an RS422 4-wire adaptor and use only the RX wires. Or modify an RS485 to disable the TX.
Then you could “trick” OH modbus to poll the slave of the conversation, with a long timeout. No poll would actually get sent, but when a data packet does come along, the binding will think it is the response.
I’m not sure how messed up things will get when it also sees the real masters real polls. I think they’d get ignored.

There is specialist hardware to interface de Dietrich to “proper” modbus (at a cost)

But - I think you should be able to use your working python script to pass data to openHAB. This seems like the low cost, least intrusive way. Send your data as JSON over HTTP perhaps.

1 Like

I would go with that. Don’t break what is working.
If your python script works, extent it a bit to send data to OH via MQTT or HTTP(REST)

Thanks for the quick answers!

No, i’m not trying to eavesdrop any transmission, it’s the implementation of this “kind of modbus” inside Diematic 3 that is sending its states every 5 seconds and then waiting for commands for the next 5 seconds over and over again.

I agree that it’s does seems like an awkward behavior but it’s the way it is apparently implemented.

In fact, my first idea was obviously use my working script to sent data to OH, but as I’ve seens that there was a modbus panel I was hoping that by using it I could send command to my boiler such as “heat domestic water”, “heat circuit A”, …

So with your saying, it confirm what I was thinking, that this binding cannot support this modbus behavior.
I’ll see what I can do with my python script.

Anyway, thanks both of you for the hints!!

I expect you’ve seen this, a bit of technical detail and a php script (that apparently writes as well)éalisation_d’une_Interface_Web_pour_une_chaudière_De_Dietrich_équipée_d’une_régulation_Diematic_3

This long forum post has some good info, amongst some irrelevant about ‘opentherm’

This project was maybe never finished, but looks a good idea; a python script to read the boiler and publish via MQTT. Maybe writes as well.
openHAB use with MQTT is well supported. Possibly combine with your existing script.

Read quite a bit now about de Dietrich modbus, see next post.

Indeed I’ve seens the two first long time ago when I wrote my python script. I’ve also found somewhere an Excel file with the various registers descriptions.

I’ve never seen the last one. After a quick look it seems quite similar to what I have done (using minimalmodbus as well). It seens to decode a huge list of register while I just needs some.

I think I’ll go with my script and add the “to mqtt” functionality in a way that it is stay simple stupid and thus easy to maintains.

I’ll try to add it to my github account and post a link here if anyone is interested in it some day.

Thanks for the follow up!

A specialist script for this oddball boiler (with comms to OH) does sound like the best way to proceed.
Use of MQTT comms should be future proof and useful for non-OH people too.

I was curious enough to have a long think, though. So far as I can make out from many parts of many translated posts of other peoples experiments :crazy_face:

Some de Dietrich boilers run modified modbus-RTU. (Bastardised I would call it - verging on abuse :wink:)
Physically, there are two miniDIN connectors for RS485 (allowing easy cascade cabling).

For 5 seconds, boiler acts as a modbus master, sending “write registers” to a set of slave addresses. Apparently if one responds, there can be a dialogue. The boiler/master then issues a “read”, and the slave can feed modified registers back. Seems the expected responses are not-quite-standard modbus, extra padding added.
People have hacked into that by emulating the expected slave, but not something we can do directly in openHAB.

‘Delta’ versions do only this master mode, and are simply dormant for the next 5 seconds. Slave emulating would be the only way to go.

‘Diematic’ versions however, spend the next five seconds being modbus slaves. During this period, another modbus master can read/write to the boiler at address x0A

It would take a lot of trial and error experiments - but it may be possible to get openHAB binding to play nicely during this period.

You would need to set long timeout periods, and possibly inter-message gaps, to make sure attempted polls from OH can get over the “bad” 5 sec. Just trying your luck like this is going to log errors and retry like crazy, which doesn’t feel good.
It’s going to cause real collisions on the bus - this could potentially upset the boiler as well.

Need a way to synchronize the OH end to only work during the “good” 5 secs. Otherwise it’s either write your own code or use extra hardware, which defeats the point of attempting to use existing OH binding anyway.

The only straw I can think of to grasp at is OH binding setting for a minimum inter-message gap, or quiet time.
If - if - that takes account of other people’s traffic, and if the boiler chatters fairly continuously during its own turn with the 5 secs - then a gap setting of a second or so would synch OH into the good 5 secs. Should work for writes, as well as reads? (OH writes are asynchrounous rather than scheduled polls, but modbus message is modbus message either way)

That still leaves the issue of whether OH binding will simply ignore incoming alien ‘master’ messages, or flag the unsolicited data as error.

I do not know. And there may be other pitfalls I haven’t thought of. Do you have an opinion here, Sami @ssalonen ?

Just as an aside, I would never try to put any other modbus devices on this same RS485 serial bus. Fortunately OH binding allows more than one bus if needed.

The amazing world of modbus adaptations once again kicks you straight in the face :joy:

No. In general, the binding reads the serial line only after it has sent request.

What you can do is detect the 5s periods separately, and then use the binding when it is meant to be used - as a slave.

In practice, you can disable automatic polling and poll on demand using REFRESH command. Alternative which might work (has not been tried) is to disable and enable the poller thing on demand.

1 Like

Yeh, I think that may be the hard part. Some script perhaps to monitor serial port activity, but might be difficult when binding has reserved the port.
And if you’ve got a special script, it might as well do the whole job.

But as a proof of concept, I’m pretty sure that a 5s poll with a 2s timeout and 2 retries will work most of the time, once it’s roughly synched itself.

The worry would be the errors generated during the other 5s by unexpected incoming traffic. Although … if the binding is ignoring incoming data when not expected - it could all work smoothly.

I think it’s worth trying out a simple set up with the poll described above.
Up to the man with the boiler :smiley:

Agree for sure, much more maintainable solution…