Where does the pump flow rate come from? Are you getting it directly from the Sika sensor?
If you can post what you have actually done, it may well help others (even if that has modified the interfacer).
I have two flow rate sensors, one in the pump pump about ±10% accuracy and the Sika sensor ±2% accurate. Both read via modbus.
I have the Grundfos Magna3 - as I wanted to be able to control and monitor the pump via modbus - have since decided, it is an extravagance I could have avoided. In any case it has the useful feature of being able to estimate the pump flow rate using the pressure sensors and [I assume] other data from the pump … I read this [estimated flow rate] via modbus.
I then decided to follow the path Glyn took, and added a modbus module to the samsung heat pump as well.
** disclaimer ** messing with modbus may be unsafe, proceed at your own risk
Please read pages 17 and 18 in the manual “Modbus Interface Module MIM-B19N/MIM-B19NT”.
The two commands that I used were (please double check the Message Set IDs and their order before you execute these commands)
mbpoll -m rtu -0 -r 6000 -b 9600 -d 8 -t 4:hex /dev/ttyUSB0 0x8238 0x8204
mbpoll -m rtu -0 -r 7000 -b 9600 -d 8 -t 4:hex /dev/ttyUSB0 0x411E 0x42D7 0x42D6 0x4087 0x406C 0x42E9 0x42F1 0x4067
The version of mbpoll I used is is as follows.
mbpoll/jammy,now 1.4.11+dfsg-2 amd64 [installed]
command line utility to communicate with ModBus slave (RTU or TCP)
I am using the “Waveshare Industrial USB to RS485 Converter with original FT232RL”
One final note: I am not sure if this is permanent or needs to be run after each power cycle of the heat pump. Will test this on the weekend.
1 Like
I have a fancy [and expensive] pump - Magna 3, with an ethernet modbus module installed, which estimates flow rate, but it is not as accurate as the Sika. When I setup the system I was not aware I would be able to get the Sika data without some [potentially risky] interventions such as “sharing” the cable out the Sika with the controller. Thanks to Glyns work, I was able to get there reasonably safely and quickly.
Ah thanks for reminding me, I had fixed this issue locally on my system but forgot to update the remote git repository, I’ve now pushed up my changes which do exactly as you describe to set all the registers at the same time. I now get real-time flow rate updates:
The data is coming from the Samsung outdoor unit via modbus which is in turn reading the flow rate from the Sika.
Same here, I’ve also got a heat meter which has a flow sensor. The readings from the Sika via Samsung modbus match the Sontex heat meter readings very closely:
Wow, I didn’t know such a pump existed. That’s very fancy 
Once issue with Samsung modbus that i’ve not yet been able to solve is the fact that it cannot report negative temperature readings. When the outdoor temp drops below zero the Samsung outdootT reports a very large number 6552. This sounds like some sort of variable overflow, but I can’t see any issue with the modbus reading code. Anyone got any ideas?
1 Like
Two’s complement?
The minimal modbus documentation does mention two’s complement which aligns with what Brian suggested. But that would not be 6552 - probably a typo on your part.
1 Like
Thanks, yes I think you’re right.
I’ve enabled the two’s complement conversion as per MinimnalModbus docs which is the modbus library emonhub is using: Internal documentation for MinimalModbus — MinimalModbus 2.0.1 documentation
This should now be fixed, but I just need a cold night to test it!
I’m definitely seeing 6551.5 on the Emoncms graph, but there’s a 10x scale factor applied, so the actual figure will be 65515, but possibly something else in Emoncms is limiting the value
1 Like
does the devices Modbus docs say anything about the encoding?
I’ve thought for a while we should have ‘dev’ branches on all the Repos so changes that we are no 100% sure about go into dev for testing, moved to ‘master/main’ once OK and the Stable once part of a release.
Bit more work but stops relatively untested changes being commited directly to a branch, quite a few folk use.
Not really, it just says Celsius value x10 (-41℃ to 100℃).
I added the integer reading section of MinimalModbus emonhub interfacer specifically for this Samsung interfacer, so I don’t think it will be used by many others. The only negative effect I can think of this change will limit the maximum positive integer from 65535 to 32767 which I can’t see being an issue. Thanks for your help.
Modbus details — MinimalModbus 2.0.1 documentation
If 65535 = -1, then 65515 = -20 = -2.0°C
That looks about right.
1 Like
I can confirm the fix had worked, a couple of nights ago the temperature dropped below freezing and emonhub Samsung modbus correctly returned a negative reading 
Great.
I do think this needs the option for an integer and a signed int as you cannot assume everything will always be within the signed int range.
1 Like