Absolutely nothing! The homely app is very much control only, you tell it what temperature you want when and that is about it. You can view if it is calling for heat or hot water but nothing else. The Samsung control panel remains active though so you can view the flow temps energy consumed and energy produced on there to get an estimate of the COP.
I guess the Homely unit is designed to stop user interface!
Thanks Glyn - all very useful. I just wanted to point out that on my system you have to enable some of the “new registers” [as Samsung calls them in the manual] first, before you can read or read/write them.
Page 18 on the manual I have.
Is this on the HP itself or a different emonHub config?
You enable these registers via the modbus interface, so I am assuming the modbus iterface module is translating between modbus and something on the heatpump. It seems from page 18 that you configure a specific message set ID for each PDU address you are enabling. Hence my assumption.
I wonder if a different message set ID would allow us to get the flow rate in real time, though I am not going to experiment with that, don’t want to brick the heat pump.
[edit] - I plan on doing this direct from my Linux laptop for more control. Then will plug the system back into my HA instance.
Correct, the emonHub interfacer should do this
No, I don’t think it does because the Samsung modbus interface does not report the electrical energy consumed.
In my experience Samsung does a very poor job of providing accurate monitoring data because of temperature sensor inaccuracies. At least on my ASHP Samsung is underreporting heat delivered by about 30%, see my post here on this thread:
1 Like
Great thanks. I have worked out that if you don’t use “write multiple holding registers” you get very strange results. Either nothing, or the value not updating.
After writing as directed in the manual, I seem to be getting [near] real time data from the flow sensor.
The manual states “If there are multiple functions to add, they must be written all at once using command 16 (Write multiple holding registers)”
I saw in your code [EmonHubMinimalModbusInterfacer.py]. You only write 3, and there is a 0.5 second gap between writes. You may want to write all 8 using command 16 and see if the reliability of the flow sensor readings improves.
I will run for 24 hours and compare with the flow sensor in the pump. My quick tests showed that when I changed the pump speed the reported flow rate changed. Readings below are at 10 second intervals as I dropped my pump from 100% to 90% power.
|[87]: |265|
|[87]: |265|
|[87]: |261|
|[87]: |261|
|[87]: |261|
|[87]: |261|
|[87]: |234|
|[87]: |234|
|[87]: |234|
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.1.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