Recommendations for running a Samsung 6th Gen with Octopus

@toadhall @pantherale0

Thanks for the info, Folks

Clearly, we have 2 very different States here; you guys at the top - with a very good handle on this whole subject, and me - at the bottom, not understanding enough about NASA protocol / Modbus registers & addressing etc to understand how to translate your posts & data into something with which I can achieve my [fairly simple] goal.

I’ve read everything you both pointed me at (along with everything that @SarahH’s published) but despite working on this much of yesterday, I can’t translate it into a working model, which is most frustrating - bearing in mind that I’ve actually managed to get thus far - and interacted with my HP enough to be able to pull data from it, and send some commands to it.

I’ve re-read P.17 of the really useful (not) installation manual Lord knows how many times, but I can’t seem to get anywhere. For starters, I don’t understand the need to ‘Add New Modbus Registers’ when (in my head) they must all already exist, and we should just be able to R/W to them.

If you could spare the time, I’d appreciate a better of understanding the following:

  1. Why are we having to add new registers, at all?
  2. How do I know whether the functions I wish to add are ‘Outdoor unit’ (6000), or ‘Indoor unit’ (7000)? (The ones in question are 0x409A (FSV 3042 - Disinfection Interval Day), 0x4269 (FSV 3043 - Disinfection Start Time) - and I’m hoping to read from and write to, these. Once successful, I’ll probably wish to expand on these, a bit.
  3. What’s ‘Command 16, and how do I implement it? I read the notes about adding multiple functions, so I realise that they must all be done at once
  4. If I use command 16 to ‘Write multiple holding registers’ and subsequently wish to add more, do I just add the others to the code, then write the whole lot again, or do I need to store them elsewhere?
  5. I wish to keep my system as simple as possible, and at the moment have no NASA/Python/ pysamsungnasa/SamsungNasa installed on HA - so is this even possible to achieve with what I have so far - i.e. just using the HA Modbus and YAML?

Thanks very much, in anticipation.

I don’t use Samsung’s own modbus interface so I can’t help, however message IDs starting 0x4 are generally indoor unit messages, while 0x8 are outdoor units. There are some others in there too (0x2 which are network related messages, 0x0 which are generic messages most devices could share).

@Michal_S are you still there? You’ve been down the rabbit hole that @Sykes is now peering into. Maybe you can help here? (Happy New Year BTW :slightly_smiling_face:)

Answering this first as it is the shortest. I believe so, ZimKevs Github project contains only YAML. but (once again) I believe the HA Modbus implementation uses PyModbus “under the hood”. I do not use HA Modbus, so can`t answer detailed questions on that, but I do use the Modbus interface and have added new Modbus registers and can access them over Modbus.

This will be longer. The MIM-B19 is just a protocol translator, it converts Modbus to NASA and vice-versa. As supplied it comes with a fixed table mapping some of the normally used NASA registers to Modbus registers. If it contained a mapping for every NASA register the mapping table would be enormous since the MIM-B19 is used with many other Samsung systems. So Samsung have provided the “Add New Modbus Registers” as a way to extend the number of NASA registers that are accessible from Modbus.

@pantherale0 has answered this

Command 16 is Modbus “Write Multiple Registers”, meaning it will write a number of register values in one go rather than individually. In ZimKevs Github readme I assume that “service: modbus.write_register” sees there are multiple values and automatically uses “Write Multiple Registers” to send them (DuckDuck Go AI seems to agree). I use this as a Modbus reference

They should be written once at startup. If you need to add more, then just add them to the list. I don`t know if you have to power cycle the MIM-B19, but in my system they are written every time I restart my HEMS and that works fine, so it probably isn’t necessary to power cycle the Outdoor Unit.

OK - thanks Folks.
I’ve been beavering away with this all morning (luckily, it’s raining - so I can’t do much outside). I think I’m getting somewhere, as I’ve finally managed to get the B19 to correctly report the set day of the week back to HA - using only YAML - BIG step forward!

I’m now working on writing the day of the week, and if I can get that nailed, the rest should just be a read-over.

Thanks again for the answers.

Well - thanks to some top tips from @SarahH @toadhall and @pantherale0, and to ChatGPT, I cracked the nut, and now have a user interface within HA from which I can select day & time from dropdowns, and the disinfection gets changed in the HP - all using YAML only (to keep things as simple as possible), which is what I wanted to achieve.

There are a whole load more functions and data streams available, and I’ve only selected those which I’m interested in, but the main point is they’re all accessible from HA - some are read-only, and some are read/write, and some are not actually ‘mapped’ at all; it’s these ‘hidden’ ones that I had a struggle with, but have now overcome, so I thought it might help other Folk, if I reported back.

The board members I’ve already cited have all posted their own versions of some really helpful reference documentation, with which you can look up the various registers / addresses to incorporate into your code. Sarah H’s is here, the ones that toadhall pointed me to are here and here and pantherale0’s is here. There’s also some great info to be gleaned from Glyn Hudson’s @glyn.hudson Github repository. Some of the references are shown as hexadecimals and some as integers. It all takes a bit of reading (or did for me).

========================================================================

I feel the need to state early-on, that I’m not a professional in this field - simply an enthusiastic ammateur. I’m writing this in order to pass on some of my learning, to help other, like-minded Folk; please bear in mind that messing around at this level could, presumably, damage your system or software. Please therefore continue completely at your own peril, and only continue to use my ramblings as a guide - and be absolutely sure that whatever actions you take are of your own doing.

========================================================================

Sometimes, you can’t beat an example, and I think this may help some Folk a good deal - to get a foot in the door. Firstly, this is how I fired-up the MODBUS in HA, and got my first bit of useful data back - from registers that were already written - by Samsung. The ‘address’ can be calculated by reference to the Samsung installation manual that ships with your MIM-B19-N modbus interface module. You first need to know what the ‘address value’ is of your ‘indoor unit’ - the main box of tricks which does a lot of the system controlling. It’s big white tin box in your system, which is either attached directly to your Samsung DHW cylinder, or if, like me, you have a 3rd party cylinder (or none at all) the box may be mounted separately. There’s a photo of it earlier in this thread. It seems that in a simple system the address will be ‘0’ and this is the case for me. I didn’t use any other way to check the address, as 0 seemed to work correctly.

The address of the item you’re interested in, is calculated from:

(50 + (IU address [0, in my case] *50)) + a number - taken from the manual. IU stands for ‘Indoor Unit.’

If we look at the table above (an excerpt from the ‘Modbus Register Table’ in the MIM-B19 installation manual) - for ‘Hot Water Temperature’ we see that the ‘number’ to add in the formula can be taken from the ‘Modbus PDU address’ column, and in this case, is 25.so 50 +(0X50) + 25 evaluates to 75, and this is the address to use to pluck this data from your machine.

I found that this yaml worked for me - incorporated into my HA ‘configuration.yaml’ section:
modbus:

The top section is the configuration for the W610 converter - 192.168.1.3 is the static IP address I chose to set (previously mentioned). Replace this with whatever IP your router has assigned, and the port number with whatever you chose when you configured the W610. I’m showing the creation of just two, of many sensors I’m using in my project. Note the ‘address 75’ which is used for my ‘samsung_DHW_temperature’ sensor. As per my earlier post in this thread, I set my MIM-B19 address (using the dip switches & rotary selector) to ‘4’, hence ‘slave: 4’ in the code. Please ignore the ‘Disallowedextrapropwarning’ message - this is generated by Studio Code Server (the software I installed with which to edit my yaml). Having read data from the HP, I now wanted to send data to it…

I particularly wanted to control DHW cycles, and finding no easy way to remotely pre-program the time schedules in the ‘Remote Controller’ I at least found access to the DHW on/off register, and being read/Write (R/W) meant I could change it remotely. I opted for two sets of time-only HA ‘Date/Time Helpers’ for setting my schedules (I didn’t want to be messing around with having to set dates, too - as the times align broadly with our cheap energy slots, and as such I generally want the DHW to fire each day at the same time, but in order to have an easy way of disabling the slots, I also incorporated an ‘enable/disable’ switch:

This is the control code I ended up with, in ‘templates.yaml’ (I had to do two screenshots, but it’s all the same codeblock):

Note that we’re sending to ‘address: 72’ calculated from the top line of the above table snippet in the ‘Modbus PDU address’ column 50 + ([0] X 50) + 22 = 72 … where, once again, 0 is the address of my indoor unit (IU).

I’m no software engineer, so I’m positive that others can make a better job of it than me, but this does, at least, work.

Once again, ignore the red ‘patternwarning’ messages.

This, then, got me fairly straightforwardly to reading the data THAT SAMSUNG HAVE MADE AVAILABLE, but there’s a lot that isn’t ‘pre-programmed’ so-to-speak, and we have to add these ‘functions’ to Modbus ourselves if we wish to access them. You’ll need to wade through the previously-mentioned docs that Folk have published, in order to find which of these you want, and whether or not you need to self-add. P.17 of the Samsung MIM-B-19 manual contains some fairly crucial info on this:

Samsung aren’t known for their clarity-of-explanations, and this took me quite a while to decode, and take in.

It can be seen that if wishing to add functionality associated with the ‘outdoor unit’ (ASHP) then they should be written to addresses starting 6000, but adding those associated with the ‘indoor unit’ (the ‘White box’ MIM) then they need to be written to addresses starting 7000. I discovered that those in which I was particularly interested to control (DHW disinfection start time, and start day), were associated with the indoor unit.

In order to add these functions, one needs to ‘…write the corresponding MessageSet IDs starting from 7000.’ Turns out that ‘MessageSet IDs’ are the aforementioned hex codes, and you’ll need to trawl through the aforementioned docs, to find the published codes. An example would be Sarah Hanson’s very useful Excel workbook ‘NASA_Interpreter.xlsx’.(see earlier posts for link) sheet name ‘NASA Database’ where down in row 245 you’ll see in col A, a ‘Mess #’ of 4269. To get the hex, we need to precede this with ‘0x’ thus the MessageSet ID becomes: 0x4269. Now, referencing the Para 2 notes in the P.17 snippet above, we now write this to 7000…, in order to enable it for use. NB the notes also instruct us that if we need more than one, we need to write them all at once. You can add more in the future - but my understanding is that you can’t append the ones you’ve already created - you need to append your ‘writing’ code with the new ones, and write the whole lot again. I also found that to be successful, one needs to write more than just one MessageSet ID - two will do, I think. The notes suggested that one writes the first MessageSet ID to 7000, the second to 7001 etc, but my friend ‘CHAT’ who was helping me from (ahem!) time to time, suggested code which [successfully] wrote the three I needed, all to the same address of 7000.

I used the ‘Actions’ section of HA Developer Tools, to fire off the code for testing, but fully intended to write a proper script to easily fire from a button, as I believe that if the HP’s powered down for any reason (power cut etc) the registers will need re-programming, and it would make it a whole lot simpler to just be able to press one button for this purpose; note to self - must get ‘round to doing that…

Now, referring to para 2, note 2 above, we finally use the formula 50 + ([IU of 0, in my case] X 50) + 32 = 82, in order to reference the first item in the list (Disinfect DOW), 83 for the second (Disinf time) etc etc.

I appended the earlier ‘sensors list (see photo) with the appropriate additions (note the aforementioned addresses):

I use these sensors in my HA system to display the data - and for confirmation that the HP has the new data, if sent.

Finally, to write to these addresses, ol’ CHAT & I wrote some automations, which take inputs from my interface, and fire on the button-press…:

… from ‘Automations.yaml’ (once again, ignore red warnings)

Et voila!

Bit of a long post, but hopefully, it’ll de-fog the way for at least a few others.

Do let me know it it’s helped. Ta.

Come on CHAT, time for a beer…

1 Like

Brilliant summary, @Sykes :slightly_smiling_face:, but for the benefit of a completely fogged person (and I think I’m not the only one):
In words of one syllable, have your experiments confirmed that is it possible to write FSV values safely to the MIM-E03*N from HA using the MIM-B19N? If so, it may be worth learning yaml and investing in one. I don’t fancy trying the Python code that ChatGPT wrote for me to change FSV#2021 - last time I tried something similar it fried the MIM-E03EN processor and cost me a new PCB :face_with_diagonal_mouth:

A brilliant write up, actually I think this deserves it’s own post so it isn’t lost in the depths of the forum.

Even as a developer in the Home Assistant world, I find Samsung’s modbus docs are confusing at the best of times, so the fact you’ve managed to crack it is absolutely fantastic :slight_smile:

As an aside, heat pumps shouldn’t be this difficult to control in general, they also shouldn’t need an extra £200+ worth of hardware or 3rd party components either haha.

1 Like

@SarahH Glad you think that this may be of help.

Yes. I’ve successfully [‘safely?’] added the necessary ‘functions’ to the indoor unit (the MIM-E03*N) register 7000 which exposes the DHW tank disinfection DAY (FSV 3042) and START TIME (FSV 3043), and enables them for use. I’ve read from them, and written to them - all via the MIM-B19N. As per my earlier post, I access the B19N via a wired connection to my W-610, which hooks all the Samsung bits up to my WiFi network - thus allowing connection via any(?) of the bits of software capable of giving the end-user control (Home Assistant, in my case). I can’t speak for FSV#2021 specifically, as I’ve not tried it, but as an enthusiastic-amateur only, my findings so far give me no reason to think that this method wouldn’t work on all of the FSVs. We have the hexadecimal value for it (0x4256), so in theory it should behave the same way as all the others.

Sorry for the ‘political’ answer, but one can’t be too careful nowadays - particularly bearing in mind that Python & ol’ CHAT have together managed to fry one processor for you already!

PS I did try ‘words of one syllable‘ but kind of drifted off a bit… :roll_eyes:

1 Like

@pantherale0 Thank you, too.

Agreed.

For reasons I won’t go into, this Samsung unit was somewhat foisted upon me at the last-minute, and whilst it’s operation seems to have been reliable thus far, I find that the functionality, and access thereto, leaves a good deal to be desired. As already mooted, the manuals are quite ‘smoke & mirrors’, the remote control must have been designed by Old Father Time, and imagine my surprise (horror!) when I found out there wasn’t even a built-in network connection as standard - not even an ethernet cable!

All I can say is that thanks to having time on my hands, and a modicum of technical ability, and thanks to other, like minded Folk who take the trouble to help, it’s been an interesting journey, which has only helped to bolster the bit of knowledge I have - particularly WRT RS485 and MODBUS.

2 Likes

@SarahH @pantherale0 @toadhall

Folks

Little bit of head scratching; I’m using this to access the DHW heating element functions (ignore red ‘patternwarning’ messages):

What I’m seeing for the ‘Booster Heater’ ‘States’ (values) in HA doesn’t match what I’m seeing on the Samsung Remote Control display…

Function Remote Control value HA ‘State’ (value) Samsung FSV # Hexadecimal
Enable booster heater ‘Use’ 0 3031 0x4098
Booster Heater delay (mins) 20 0 3032 0x4266
Booster Heater Overshoot 1.0 0 3033 0x4267
Booster Heater Status Not displayed ‘Unavailable’ Unknown 0x4087

Before I even dare try to write to it, I need to reliably read from it, but there appears to be a disconnect.

Any ideas?

Not all messages are 4 bytes long, I’m not 100% sure how the modbus interface exposes the needed information but ON/OFF values are usually 2 bytes long and their raw values are either 01 or a 00.

For 3032, I believe this is an unsigned 2 byte payload too.

3033 I would imagine will be the same story.

For the booster heater status, that will be an on/off value.

Mind sharing the config you are using to parse the values?

FWIW, @Sykes, none of 0x4098, 0x4266 or 0x4267 routinely appear at F1-F2 according to my little Python sniffer. 0x4087 appears every ~160s.

But don’t despair. I just set and reset #4098 using SNET (as a test) and here’s what my VCOM saw:


You can see that (for the reset to 0 for example) packet #96 is the incoming SNET command (the 40 98 appears in the bottom window after all the 0x55 preamble bytes), followed by the MIM response in packet #98.

My conclusion is that you’ll only see certain NASA messages when the value/payload is changed, not in the normal course of events. This doesn’t, however, explain what happened with 0x4087. Did you give it long enough to appear?

First some background on the MIM-B19. I don`t know this for sure, just what I have observed while debugging. The B19 caches values from the NASA bus, it decodes all packets it sees and if they correspond to Modbus registers in the fixed table, or registers that have been added via hidden registers, it stores the values locally. Then when you make a request on the Modbus side it looks to see if it can return the value from its` cache. If it can, job done. If not it has to send a read out on the NASA bus to fetch the value. It has to wait until the bus is quiet before it can send the request, and this may take longer than the Modbus timeout, so @SarahH may well be on the right track with asking did you wait long enough.

Once such a request is made it will add this register to its` cache and subsequent reads should be fine. It seems to have a concept of staleness, so if a particular register in its` cache has not been updated by the regular NASA traffic after some time it will send a read out to refresh it.

I don’t suppose HA has a log (or a log can be turned on) of the Modbus packets, that would be my first port of call, since @SarahH has proved that the NASA side works fine.

1 Like

Thanks Folks

@pantherale0 Jordan. I’m not completely sure what ‘parsing’ is (that’s where amateur, and self-taught gets you!) but I’m guessing it’s getting the data back into a useable format?

I’m creating HA sensors for each piece of data I retrieve from the HP, thus:

These functions - like disinfection etc - have had to be ‘added’ but I’ve done the same as I have in the other registers (Disinfection etc) and they’ve all played nicely…

As they’re all 0x4xxx I’m assuming that they need exposing in the indoor unit address 7000.

@SarahH Sarah. I’m not at all au fait with that software - but it looks mighty useful for analysing comms. I tried changing the ‘Delay’ duration, and despite giving it 15 mins or more, the change wasn’t reflected in HA (I’m still watching it now - probably 2 hrs on). Perhaps this only happens if the payload is written from an external source? 0x4087 has been a bit of a question mark throughout my research on t’interweb. It would be handy to have, as I’d like to be able to monitor if & when it cut in, as it’s good for probably 2.5-3.0 kW or so, and therefore needs considering when I evaluate the overall effect on the property’s DNO fuse (only 80 amps, in my case).

@toadhall Alun.

Thanks; I’ll have a look at whether I can log Modbus traffic specifically; there’s definitely a log facility, but I’ve not used it much.

Correct, try uint16 rather than int16 for the data_type.

Possibly the case, but I really can’t be sure how the B19 works, I’ve avoided the modbus interface because of how complicated it is to setup and get working.

After spending far too many hours probing different attributes, there are some messages that are only automatically sent when its actual state is changed. 0x4087 is definately there and the indoor unit will respond to its value if a read request is sent on the NASA bus as seen below (ignore “response: 1”).

You could try setting the DHW mode to Power or Force which should kick the booster heater in.

> read 200000 0x4087
Reading from 200000, message 0x4087
Response: 1
> device 200000 0x4087
Device 200000:
  Last seen: 2026-01-29 11:54:07.863852+00:00
  Address: 200000
  Device Type: INDOOR
  Config: NasaConfig(client_address=1, device_dump_only=False, device_pnp=True, device_addresses=[], max_buffer_size=262144, log_all_messages=False, devices_to_log=[], messages_to_log=[], log_buffer_messages=False, enable_read_retries=True, read_retry_max_attempts=3, read_retry_interval=1.0, read_retry_backoff_factor=1.1, enable_write_retries=True, write_retry_max_attempts=3, write_retry_interval=1.0, write_retry_backoff_factor=1.1)
  Total attributes: 32
  FSV Config: {17020: 50.0, 16551: True, 17001: 4.0, 17002: 55.0, 17003: 30.0, 17102: 12.0, 16996: 95.0}
  16519: {'message_id': 16519, 'message_name': 'Booster Heater', 'unit_of_measurement': None, 'value': False, 'is_fsv_message': False}
>

That’s pretty much in-line with what @SarahH was saying, but I’m loath to try and write yet - before I’ve had a confidence ‘read’ first.

I’ve done that now. As an aside, I decided to get that ‘Mode’ functionality into HA, too; that’s an easier one, as it’s one of the Samsung ‘pre-mapped’ addresses, so it was fairly quick to get control of - Drop-down now fires an automation to send new mode to HP.

No sun (PV) today, so I’m waiting for our next octopus ‘Cosy’ slot before setting another DHW run going.

1 Like

It might be worth mentioning, @Sykes, that the appearance of a NASA message - particularly the “status” messages such a 0x4087 - doesn’t necessarily prove that a command has been fulfilled. When I set (to 1) and reset (back to 0) 0x4087 in the above test, the commands were sucessfully sent from SNET and duly acknowledged by my MIM (I could see them on my sniffer), BUT my immersion heater is electrically isolated so it couldn’t actually switch on, even though the MIM thought it had.

BTW I’ve tweaked my NASA message database/decoder spreadsheet (a handful of minor improvements and error corrections):
NASA_Interpreter.xlsx (74.1 KB)

Thanks @SarahH. I’d been thinking along these lines for several of the commands, too; sometimes, a return value might actually only mean ‘I’ve been put into this mode’ as opposed to confirmation that the mode is actually operational in the system.

@SarahH Oh, and thanks for the updated workbook. :+1: