Hi Benoît
Thanks for the update, I will try it with HA and let you know
Rofiq
Hi Benoit
Unfortunately in HAOS, I did’nt managed to get systemctl running nor systemD to launch the service directly.
But launching the script in terminal did work perfectly 
. Doing so, even If I reboot, HA reconnects to mqqt without any action, so this is not an optimized solution but at least it works !
Also Mqtt login works fine and mqqt has been discovered with 37 entities. 
I have copied also your cards and this is simply brillant and thanks to you my old dietrich is alive and monitored in HA 
Now I will try to go from power% to an estimated energy consumption per day… 
Merci encore
Rofiq
Hello,
I thank you for your feedback and happy to see you manage to get some results.
I started to have a look to generate an HA add on with a python script but I’ve only understood that there are several step to do, eg generate a package usable with docker, be able to get settings from HA etc… As I have already a big to do list in the pipe, it won’t be possible to deliver something before weeks/months.
I had a look on the web to try to find a reusable example for python scripts to HA add on, but didn’t find any links.
If somebody reading this post have one …
Regards,
Benoit
Hi Benoit,
I have a de dietrich heater and I have it connected to home assistant for about 2 years, using the built-in modbus read/write. It is however not very stable. Reading from the heater works very well, but when writing, some other addresses get overwritten, which is of course very annoying.
So to get a more stable integration with home assistant, I would like to use your integration. However I think I am using a slightly different de dietrich heater than you (although the modbus registers seem to match). I have a de dietrich mca 25. See link.
Do you (or anyone else) have experience with this heater? Is it fully compatible with your MQTT interface?
Kind regards,
Thomas.
Hi Benoit and all
I’ve managed to get numbers for gas consumption converting power% (value 0-100) of sensor.power to Watt by multiplying by 24500/100 (=>sensor. gas_power). See the table extracted from brochure where power is proportional to power%:
Then integrating these values of sensor. gas_power give energy in kWh (sensor.energie_gaz).
Using an average value of PCI/PCS we can deduce the quantity of burned propane in kg (sensor.conso_gaz) by multiplying sensor.energie_gaz x 0.075146.
Then I deduce an equivalent of %propane consumed in my tank (knowing 1 kg of propane corresponds to 0.0786% of my tank level (deduced from my last refill of 585kg tank => level from 38% to 84%)
We can finally estimate the tank level using a correction factor (input_number.gaz_correction) and deducing the % consumed calculated above. (correction factor use to correct the calculation and for future refill :-))
Here the details:
In sensors.yaml (or configuration)
- platform: template
sensors:
gas_power:
unique_id: puissance_chaudiere
friendly_name: 'Puissance chaudière'
unit_of_measurement: 'W'
value_template: "{{ states('sensor.power') | float(default=0.0) | multiply(245) | round(1) }}"
device_class: power
gaz_conso:
unique_id: conso_gaz
friendly_name: 'Consommation Gaz'
unit_of_measurement: 'kg'
value_template: "{{ states('sensor.energie_gaz') | float(default=0.0) | multiply(0.075146) | round(3) }}"
pourcentage_cuve_conso:
unique_id: cuve_conso
friendly_name: '% cuve consommée'
unit_of_measurement: '%'
value_template: "{{ states('sensor.gaz_conso') | float(default=0.0) | multiply(0.0786) | round(3) }}"
pourcentage_cuve:
unique_id: cuve
friendly_name: '% cuve'
unit_of_measurement: '%'
value_template: "{{ '%0.1f' | format(states('input_number.gaz_correction') | float - states('sensor.pourcentage_cuve_conso') | float) }}"
- platform: integration
source: sensor.gas_power
name: energie_gaz
unique_id: energie_gaz
method: left
unit_prefix: k
unit_time: h
round: 2
in configuration.yaml
utility_meter:
daily_energy_propane:
source: sensor.energie_gaz
cycle: daily
input_number:
gaz_correction:
name: "Correction cuve de Gaz"
min: 0
max: 1000
step: 0.1
mode: box
unit_of_measurement: '%'
Finally add energy_gaz in energy panel of HA.
You’ve done it and this is confirmed in energy distribution:
I do not know if this raw estimate is fully correct and time will confirm but I think it could be interesting to get numbers in kWh and to monitor gas consumption (even in € using energy management in HA)
Benoit you are free or welcome if you think is usefull to integrate this in your script and thank you again to your very stable script and to make this happens.
Kind regards
Rofiq
PS: Edited to correct the integration method from default (trapezoidal) to left
Hello,
I understood, but not sure, that Diematic Isystem modBus is always in slave mode . => So the Diematic3 MQTT interface should be adapted to work with an Isystem regulator. It shouldn’t be very complex but unfeasible without heater. I don’t know anybody who have done it.
Benoit
Thanks Rofiq for sharing of your application for gaz consumption/level monitoring
I’ve added a link to your post at the bottom of the github ReadMe.
Regards,
Benoit
Hi Benoit
After runing the gas consumption for several days, I’ve realized that by default the method of integration of the power% is the trapezoidal method which is not accurate for our dietrich boiler (specially when the boiler is off over long period during the night and restarts in the morning at high level). After some reasearch, it is best to use the “left method” of integration and with this simple trick, the monitoring is now quite accurate.
So the modification (method: left) of the integration is the following:
- platform: integration
source: sensor.gas_power
name: energie_gaz
unique_id: energie_gaz
method: left
unit_prefix: k
unit_time: h
round: 2
I have edited my previous post to reflect this change.
Thanks
Rofiq
hi
could you describe how you did it?
thank’s
Hi,
On Hassos you have to install the following addon in order to have terminal:
You can also install samba share to get access to Hassos file system from your computer
Then follow Benoit’s procedure by installing his script to the directory of your choice e.g addons/Diematic32MQTT and configure the conf file.
Then on terminal, browse to that directory :
cd addons/Diematic32MQTT
Install pytz package:
sudo pip3 install pytz
Install paho MQTT client:
sudo pip3 install paho-mqtt
Then run Benoit’s script
python3 Diematic32MQTT.py
Message on terminal: Connected to MQTT broker
Hope this help
1 Like
Hi,
docker images are now available. You can consult the Wiki
It could help to use it with HAOS. But I can’t explain how as I’m not using it.
Benoit
Hello,
I’m the owner of DeDietrich MCR/II 30/35MI boiler (made by Remeha).
Since a week I’m trying to configure it with Home Assistant, but without success.
Boiler is using the same remote control board as presented on the Diematic_to_MQRTT project:
Using the 4P4C (RJ9) connector on the board I connected it to the Elfin EE11A Modbus RTU to Modbus TCP converter:
Boiler is providing power to the Modbus converter on pins 1 (GND) and 4 (5V). Rx and Tx signals are configured on port 2 and 3 (as described on the Connecting DeDietrich MCR3 to PC via serial connection – skyboo.net page).
Device configuration:
When I start Diematic32MQTT.py, it’s able to connect to MQTT broker and to the Modbus Converter, but there is no communication on configured TCP port and no communication on the Serial interface.
In the logs I see:
2023-03-19 14:39:12,407 - Diematic - WARNING - Init Link with Regulator
2023-03-19 14:39:52,587 - Diematic - WARNING - Synchro timeout
2023-03-19 14:39:52,604 - Diematic - WARNING - Init Link with Regulator
I tried Simply Modbus TCP client to get any information’s from boiler and in this case I see some communication on the TCP and Send Frames/Received Frames on the serial interface of the Modbus converter, but with Slave 10 and different Registers I never got any response in the client.
I’m a newbee in Modbus world and I’m not sure what I’m doing wrong.
Am I using wrong boiler address?
Is there anything wrong in my converter configuration?
Hello,
it’s a little difficult to answer as i don’t know this kind of boiler ans serial interface.
But you shouldn’t use the modbus setting in the Elfin EE11A as the Modbus is decoded / encoded in the Diematic_to_MQTT interface with specific adaptations to the De Dietrich specific implementation (Master/Slave mode switch every 5s). Use something like serial instead (I don’t know this EE11A).
Setting the log mode to DEBUG should allow to log received byte stream.
Regards,
Benoit
Hi Benoit,
Very valid remark, I changed protocol to none (other options are modbus or frame):
Still Diematic32MQTT.py connects to TCP-server, but does not send or receive single packet.
When I try with nc 192.168.3.49 8899, I see data being transferred via Serial Port:
Device is not faulty. I tested it with second project, where I use ModBus protocol and I could directly integrate device with HA.
Elfin EE11A description: https://www.aliexpress.com/item/4000843861682.html.
When I set level=DEBUG there are no other information’s in the log.out.
Best regards,
Marcin
Thank you @BenoitS for the great integration. You saved me countless hours!
I am not really familiar with HA (as I just moved from OpenHAB) but I wanted to share the following steps I used to create an Addon from this project to automatically run the python scripts. I am most likely not following any best practice or anything but this works for me…
- SSH to HA (or use Samba)
- Create a new folder under /addons called HAAddOnDiematic_to_MQTT
- Within that folder, add a new file called DockerFile and containing the following
ARG BUILD_FROM
FROM $BUILD_FROM
# Install requirements for add-on
RUN \
apk add --no-cache \
python3
RUN python3 -m ensurepip
#RUN pip3 install --no-cache --upgrade pip setuptools
RUN pip3 install pytz
RUN pip3 install paho-mqtt
# Copy data for add-on
COPY run.sh /
RUN chmod a+x /run.sh
COPY src/ /
CMD [ "/run.sh" ]
- Add a new file called config.yaml containing the following:
name: "Diematic 3"
description: "Diematic 3"
version: "1.0.0"
slug: "diematic_3"
init: false
arch:
- aarch64
- amd64
- armhf
- armv7
- i386
startup: before
- Add a new file called run.sh and containing the following:
#!/usr/bin/with-contenv bashio
python3 Diematic32MQTT.py
-
copy the “src” folder of @BenoitS project
-
in the “src/conf” folder, update the logging.conf file as follows (this is to output the log in stdout so that it shows in the HA addon logs):
[loggers]
keys=root
[logger_root]
level=WARNING
#handlers=timedRotatingFileHandler
handlers=streamHandler
[formatters]
keys=timedRotatingFormatter
[formatter_timedRotatingFormatter]
format=%(asctime)s - %(name)s - %(levelname)s - %(message)s
datefmt=
[handlers]
#keys=timedRotatingFileHandler
keys=streamHandler
[handler_timedRotatingFileHandler]
class=handlers.TimedRotatingFileHandler
formatter=timedRotatingFormatter
args=('./log/log.out', 'W6', 1, 5, None, False, False)
[handler_streamHandler]
class=StreamHandler
formatter=timedRotatingFormatter
args=(sys.stdout,)
-
Optional: update the polling period in the Diamatic32MQTT.conf file to 60 (every 10 seconds was too frequent in my case and made the connection crash from time to time).
-
Once this is done, restart HA and this new local “Addon” should show up. The Addon can then be installed and started.
Hope this helps.
Note: as a side unrelated note, it took me a while to figure out that the BrokerHost is core-mosquitto and not localhost…
Hi Benoit,
I am very excited about getting my Diematic 3 control panel (for a GTU 125s Fioul Chaudiere) connected into Home Assistant. You have done amazing work, Bravo!
But I need some help, as I am new to all this! Apologies if I am asking stupid beginner questions, I very much appreciate your time and work - thank you in advance!
I am running HA in docker on a headless ubuntu desktop.
My USR IOT (USR-TCP232-410S) page is showing many more options than yours, and a seperate page for RS232 and RS485. Both with identical parameters that I can change/adjust.
I presume that Socket B is used for Tx and Socket A is used to Rx - is this correct?
For the Socket A parameters I have the drop down choice of
- UDP Client
- TCP Client
- UDP Server
- TCP Server
- Httpd Client
on the two TCP choices above there is after the option of either “NONE /or/ Modbus TCP” and also on the next line of parameters to either “KEEP /or/ KICK”.
Finally on the “Registry Type” , I have a choice between "NONE/USER Register/USR Cloud/or/ MAC as Register.
Final question : I can only get the Conn Status (ETH)B: Connected and the TX count increasing, when I have set the Socket B parameters to UDP Client - is this the correct configuration?
192.168.1.8 is the fixed IP of my ubunu desktop with HA
192.168.1.11 is the fixed IP of the IP to Serial box.
Many many thanks for some suggestions!
Brendan
Hello,
it’s difficult to answer as the interface of your boiler (RS232 with TTL level ?) seems not to be the usual one. May be the data protocol is not the same also…
On the link you suggest
there isn’t any information on protocol.
Correct log looks like herafter :
2023-03-21 11:06:40,565 - main - CRITICAL - Modbus interface address: 192.168.1.101 : 8899
2023-03-21 11:06:40,566 - main - CRITICAL - Modbus regulator address: 0xa
2023-03-21 11:06:40,567 - main - CRITICAL - Broker: 192.168.1.11 : 1883
2023-03-21 11:06:40,567 - main - CRITICAL - Topic Root: hass/diematic/boiler
2023-03-21 11:06:40,568 - main - CRITICAL - Hassio Discovery Enable: True
2023-03-21 11:06:40,568 - main - CRITICAL - Hassio Discovery Prefix: homeassistant
2023-03-21 11:06:40,568 - main - CRITICAL - Regulator type is Diematic3
2023-03-21 11:06:40,704 - Diematic - INFO - Using tzinfo (‘Europe/Paris’) for Boiler time sync
2023-03-21 11:06:40,711 - Diematic - WARNING - Init Link with Regulator
2023-03-21 11:06:40,829 - main - CRITICAL - Connected to MQTT broker
2023-03-21 11:06:40,831 - main - INFO - Publish :hass/diematic/boiler/status Offline
2023-03-21 11:06:40,865 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:40,865 - Diematic - DEBUG - Bus status switched to SLAVE
2023-03-21 11:06:41,011 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:41,155 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:41,285 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:41,443 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:41,569 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:41,748 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:41,898 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:42,099 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:42,226 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:42,400 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:42,548 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:42,747 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:42,897 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,075 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,206 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,353 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,478 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,625 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,766 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:43,914 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:44,055 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:44,220 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:44,383 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:44,532 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:44,711 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:44,859 - DDModbus - DEBUG - Frame received: 0b1001b40001020000d38400
2023-03-21 11:06:46,362 - Diematic - DEBUG - Bus status switched to MASTER after 5.496228933334351
2023-03-21 11:06:46,363 - Diematic - INFO - ModBus Master Slave Synchro OK
2023-03-21 11:06:46,363 - DDModbus - DEBUG - Send read request: 0a030001003f556100
2023-03-21 11:06:46,653 - DDModbus - DEBUG - Answer received: 0a037effffffff0530000c00060002009000be001e000100040001000000d200d2003c000800d2000300090161640c00c800a0003c0008ffff0003000700c801f40000ffff000000c800a0003c0008ffff0003000700c801f40000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff02260000000401ca0000a03c000000
2023-03-21 11:06:46,655 - DDModbus - DEBUG - Answer valid
Settings of your EE11A seems correct. You can have a similar example here (with an RS485 interface)
Regards,
Benoit
Hello brannett,
I think you should use only socket A ( a socket allow both tx and rx) , tcp server, option keep none (don’t choose modbus)).
Check your wiring. Have a look in the logs (mode DEBUG).
Regards,
Benoit
Hi Benoit,
After research I found that protocol used in my case (De Dietriech MCR/II 30/35 MI) is not using Modbus. I have Easymatic regulator using Easymatic / r-bus Remeha protocol. The only page I found about it: Protocol decoder:easymatic - sigrok and related thread on the forum: Easymatic-De Dietrich (City 1.24 BIC II) - Support - Domotique-fibaro
Unfortunately I could not find any example how to do integration with HA 
Best regards,
Marcin