Contribution: Samsung ASHP NASA link <-> MQTT bridge (Home Assistant)

Hardware Heatpump
, , ,
121

Excellent, @toadhall.

Just out of interest, here is an extracted typical controller output packet using some Python code (mine is very basic code compared to yours - just reports the message number and converts its payload to decimal):

81154 ms 0x4253 = 300, 0x4254 = -20, 0x4255 = 200, 0x4256 = 520, 0x4257 = 360, 0x4258 = 500, 0x4259 = 350, 0x4093 = 1, 0x425A = 250, 0x425B = 400, 0x425C = 250

As my #2011 is set to -2degC and 0x4254 is reporting -20, your assumption that 0x4254 is in tenths of a degree is correct.

122

Thanks for confirming that.

I started this NASA protocol journey more out of interest than necessity, however the Modbus interface has marginally failed my reliability criterion (must run for at least a year without crashing, requiring update, rebooting, etc.). The Modbus interface has now gone weird twice in two years.

  • First time the measurements stopped updating. It still responded to Modbus requests but the values reported were frozen. I assumed I was polling it too fast, so reduced polling rate, power cycled the system, and all was well.
  • Earlier this summer it did the same thing. This time I set the water flow temperature setpoint to 65 degC to see if it was completely locked up, or just measurement reporting had failed. The outside unit responded to this, and I inadvertently discovered a way to reboot the system. Only the primary loop was active, so the flow temperature shot up rapidly. It went through 65 degC and then the entire system rebooted, and the Modbus interface was back to normal. I guess this is a safety feature in the outdoor unit, if it sees the flow temperature exceeding 65 degC it assumes something has gone horribly wrong and tries rebooting to fix it.

So I will complete the NASA development and if it proves reliable, retire the Modbus interface.

I also have a theory why there seemed to be a mystery poll of the Silent Mode Register in earlier logs, which I thought might be a bug. As expected the Modbus interface just caches all the register values it sees broadcast on the NASA bus and returns those values when you make a Modbus request. But it also has a notion of “staleness” of values. It checks how old the value in it’s cache is, if it is beyond some limit (maybe 90 seconds) it polls NASA for a new value.

123

If you perfect this, @toadhall, you might have a winning solution to the problem of heat removal from the DHW tank per the frost prevention algorithm, as eloquently expressed by several users part way through Samsung R32 ASHPs - when is a defrost not a defrost? (e.g. @Michal_S et al). Presumably you could just write a “1” to 0x4089 every 55 minutes (followed by a “0” a few seconds later) - thus sidestepping the frost prevention cycle requirement - if you were sure that a real frost prevention cycle wasn’t required (e.g. if you have glycol in your circuit).

You and @Topaz appear to be well ahead of the field in understanding the Samsung NASA protocol subtleties. Have you considered summarising your combined knowledge into an idiot’s guide?

124

Hi Sarah,

Thanks for the tip! This would be amazing if this works! I will give it a try for sure.

But currently what I need to achieve as well is to set #2021, #2022 and possibly #2041 and #2042. No matter I do nothing is written on that address. I’ve took it from NASA protocol but no matter what the values are not updated on those addresses. There is some value stored but some old one and not updating. This is when connected to F1 and F2 on modbus board (not control unit).

Do you have maybe an idea why ? Do I really need to connect to F3/F4 with @toadhall board to be able to change these stupid FSV values ? I saw you were able to do it in that windows tool over F1/F2 connected directly to HP control unit but why the heck this is not working via modbus :slight_smile: I just need it configure once and forget so maybe even your solution would be enough for me. So you are connected directly to F1/F2 on control unit?

Thanks for insights.

@toadhall do you still have some boards available ? I would be really interested to buy one because I need to find a way how I can change #2021 programmatically. Thing is, wired controller won’t allow me to use lower than 10C degree temperature and I need to set it to 0C@40C water temp. My pump is super inefficient with anything lower than 40 because I don’t have floor heating. If I set temp curve as I need then at 10+C outside it will use water temp around 30C which is unusable.

This with frozen modbus interface is interesting. Maybe that’s why #2021 FSV is not updating on mine but other values are updated so I don’t know. I pool the address but it still shows me some older value. How do you restart it ? Just cut the power to outdoor unit ?

125

Dear @SarahH,

The 0x4089 sounds like a read only register.
I’ve just tried writing into it:

2025-10-07 12:23:25,030 INFO Thread-1 520000b0ffffc012f0014089012025-10-07 12:23:25,036 INFO Thread-1 src:520000 dst:b0ffff type:normal ins:write nonce:0xf0
2025-10-07 12:23:25,040 INFO Thread-1   0x4089 (ENUM_IN_STATE_WATER_PUMP): 01
2025-10-07 12:23:25,176 INFO packetgateway 320011200000520000c015f001408900cfb134
2025-10-07 12:23:25,181 INFO packetgateway src:200000 dst:520000 type:normal ins:response nonce:0xf0
2025-10-07 12:23:25,184 INFO packetgateway   0x4089 (ENUM_IN_STATE_WATER_PUMP): 00
2025-10-07 12:23:25,674 INFO packetgateway 320011200000b000ffc014b401408900f79934
2025-10-07 12:23:25,691 INFO packetgateway src:200000 dst:b000ff type:normal ins:notification nonce:0xb4
2025-10-07 12:23:25,697 INFO packetgateway   0x4089 (ENUM_IN_STATE_WATER_PUMP): 00

And then I tried “requesting” its value (a subtle difference of the nasa protocol for some requests), but the request is ignored:

2025-10-07 12:26:15,721 INFO publisher 520000b0ff20c014a50241180142da00c6
2025-10-07 12:26:15,732 INFO publisher src:520000 dst:b0ff20 type:normal ins:notification nonce:0xa5
2025-10-07 12:26:15,739 INFO publisher   0x4118 (ENUM_IN_ROOM_TEMP_SENSOR_ZONE2): 01
2025-10-07 12:26:15,745 INFO publisher   0x42da (VAR_IN_TEMP_ROOM_ZONE2): 00c6

Then I’ve tried notifying it (yet another implicit write request mode, NASA really is full of subtlenesses), notification is also ignored.

2025-10-07 12:27:09,952 INFO Thread-1 530000b0ffffc014f001408901
2025-10-07 12:27:09,964 INFO Thread-1 src:530000 dst:b0ffff type:normal ins:notification nonce:0xf0
2025-10-07 12:27:09,980 INFO Thread-1   0x4089 (ENUM_IN_STATE_WATER_PUMP): 01

To sum up, writing to 0x4089 doesn’t sound like a valid idea

Cheers

126

Dear @Michal_S,

Some values are frozen when written from F1/F2 (from what I experienced with the zone’s ambient temperature injection). However, for the FSV you mention, they should be modifiable through F1/F2 link, as those FSV are basic configuration from SNetPro.

Cheers

127

Hi Topaz.

Yes exactly, that’s why I don’t understand it. It really looks like frozen.

I’m writing this to address 7000:

sequence:

  • data:
    hub: samsung
    address: 7000
    value:
    • 16487
    • 16492
    • 16519
    • 16580
    • 16968
    • 17023
    • 17099
    • 17129
    • 16984
    • 16985
      slave: 1
      action: modbus.write_register
      alias: Write Modbus Registers 7000 - Indoor (Backup)
      description: “”

Last two values are #2031 and #2032

But here you can see those values weren’t updated for 2 days. That time I had different address mapped there so that’s why it shows 9.2 but -50 makes no sense at all….

image
image959×646 10.6 KB

128

From my understanding of the ASHP, the -50C is the default returned temp for unknown temp sensor :frowning:

129

Hi @Michal_S (you’ve been quiet of late - I miss your rants…)

At the risk of showing up my poor grasp of things, I note that SNET-Pro2 can write to #2021/2 and #2041 via F1/F2 (presumably using 0x4256, 0x4257 and 0x4093 respectively). Indeed I use SNET (via F1/F2) to update all my FSVs (when required) rather than the remote controller (which is a pain to use).

No - see above. And I think you are confusing @toadhall with @Topaz when it comes to boards. I know nothing of Modbus - I don’t have a MIM-B19N, just an RS485-Ethernet adapter sitting on F1/F2 with a VCOM on my laptop - so cannot say why Modbus isn’t co-operating.

Even SNET v1.14.3 only allows me to set #2021 down to 17degC. I guess this value is hard-coded into the EEPROM for a good reason. You may not be able to go lower however hard you try.

130

Hi @Topaz, very interesting information but…

…I think not - see my reply to @Michal_S about SNET’s ability to write to it. I’m pinning my hopes on @toadhall’s new-found above insights into writing data into 0xnnnn directly.

I also see 0x4089 appearing in the RS485 output. For example here is a packet showing it:

86458 ms 0x406C = 0, 0x406D = 0, 0x406F = 1, 0x4070 = 0, 0x4073 = 0, 0x4074 = 0, 0x4077 = 0, 0x407B = 0, 0x407D = 0, 0x407E = 0, 0x4085 = 0, 0x4086 = 0, 0x4087 = 0, 0x4089 = 0, 0x408A = 0, 0x4095 = 3 (My HP wasn’t running at the time, so unsurprisingly the pump was “off”.)

(For the avoidance of any doubt, I don’t poll the MIM for data, I just watch what’s coming out of F1/F2 using Python code.)

Edit: just to see how often 0x4089 appears, I’ve just run my Python code again, and see:

[PROMPT] Enter register (e.g. 8254) or for all: 4089
[INFO] Filtering for register 0x4089
81964 ms 0x406C = 0, 0x406D = 0, 0x406F = 1, 0x4070 = 0, 0x4073 = 0, 0x4074 = 0, 0x4077 = 0, 0x407B = 0, 0x407D = 0, 0x407E = 0, 0x4085 = 0, 0x4086 = 0, 0x4087 = 0, 0x4089 = 0, 0x408A = 0, 0x4095 = 3
244254 ms 0x406C = 0, 0x406D = 0, 0x406F = 1, 0x4070 = 0, 0x4073 = 0, 0x4074 = 0, 0x4077 = 0, 0x407B = 0, 0x407D = 0, 0x407E = 0, 0x4085 = 0, 0x4086 = 0, 0x4087 = 0, 0x4089 = 0, 0x408A = 0, 0x4095 = 3
406491 ms 0x406C = 0, 0x406D = 0, 0x406F = 1, 0x4070 = 0, 0x4073 = 0, 0x4074 = 0, 0x4077 = 0, 0x407B = 0, 0x407D = 0, 0x407E = 0, 0x4085 = 0, 0x4086 = 0, 0x4087 = 0, 0x4089 = 0, 0x408A = 0, 0x4095 = 3

So that’s every 162 seconds or just under 3 minutes. (The HP is still off, BTW.)

131

@SarahH

Yes, about 0x4089, I’ve tried writing it, but the value is not retained. If you want to manually switch the main water pump, you should engage it using test mode (I’ve added that support to home assistant, to individually switch various valves/pumps manually).

0x4089 is mainly used tp notify the water pump state FROM the controller, it is not intended to be written (you can try to write it and make it switch, using SNET or what not, it won’t work).

Cheers

132

Ah yes you are quite right @Topaz - I can see in SNET that Water Pump (Indoor Unit Data tab) is not writable - I stand corrected (I was still thinking about @Michal_S’s #2021 problem).

Also you are right about -50degC being the returned value for a missing temperature sensor. I saw the following in my Python output:

5501 ms 0x4203 = 200, 0x4204 = 315, 0x4205 = 200, 0x4206 = -500, 0x420C = 139, 0x4217 = 0, 0x4236 = 335, 0x4237 = 216, 0x4238 = 335, 0x4239 = -500, 0x423E = -1, 0x427F = 405
5596 ms 0x428C = -500, 0x42D4 = -500, 0x42D8 = -500, 0x42D9 = -500, 0x42E8 = 43, 0x42E9 = 0, 0x4401 = 15, 0x4426 = 0, 0x4427 = 16962784

None of these sensors are installed on my setup.

133

Thanks @SarahH, universe continuity is validated :smiley:

I’m moving on with the DHW water heat stealing you mentioned earlier, I’ve never experienced it as my outer temp never got below 2.5/3C, BUT I guess this is a problem worth playing with.

The quick win solution I see is to disable the DHW when not in the heating moment. Therefore preventing heat stealing. I’m pretty sure this would work, but would wear out the EEPROM earlier (FSV writing implies EEPROM wearing).

Cheers

134

Yeah, seems so. Probably that value is never read by modbus, but probably I can set the value and it will be registered by the pump. I have to try it.

@SarahH I think I had it working last year but I can’t remember anymore. I know I was setting something and it was really changed. Wired controller won’t allow me to set it lower but I think programmatically I could set anything there. But not sure anymore. And sorry I have radiators so talking about #2031 and #2032 and #2011 and #2012. I need to set high ambient temp to 5C or 0C but it can goes only up to 10C.

And sorry for confusion for board creator :slight_smile:

Does it mean that I won’t be able to trick the pump to start pump to cancel this defrost?

135

Disabling won’t help, it always open DHW circuit for defrost or antifreeze cycles no matter what. Turning OFF DHW won’t help a bit sadly. Also what is worse it that it steals the heat from tank in summer when the pump is not heating the space! This is horrible. And there is at least one anti-seize cycle daily. Imagine you don’t have request for DHW heating for 2 days… Still the pump at least once per 24h runs anti-seize cycle and steals the heat from your DHW tank. And it’s not negligible. I have 250L tank and it always steal 2-3C per cycle. Really don’t know what i***t programmed this.

136

@Michal_S My idea is not to disable DHW operation, but to disable the DHW circuit at all. Meaning the controller won’t even think there is a 3 way valve, and therefore won’t try to operate it. I’m not sure if the valve position will be operated when the DHW circuit is “unpresencified”. The key concept here is that the ASHP does not forcefully have a DHW circuit builtin.

Translation in NASA world, it would mean to turn FVS#3011 to 0 instead of 1 or 2 (depending on your setting). And only turn the DHW FSV#3011 to 1 or 2 during a period of the day to generate some DHW.

I don’t know if this gets clearer.

Cheers

1 Like
137

SamsungNasaWriteFSV2021.zip (49.3 KB)

See log above, writing to FSV2021 (0x4256).

  • Search for 0x4256, then again. You will see a read of 0x4256 returning a value of 50.0 degC
  • Then search for “write”, you will see a Write Request writing 46.0 degC to 0x4256 followed by an ACK indicating success (or at least “I have received your packet OK”)
  • Search for 0x4256 again. You will see a read of 0x4256 returning a value of 46.0 degC.
  • Search for “write”, you will see a Write Request writing 50.0 degC 0x4256 followed by an ACK.
  • Search for 0x4256 again. You will see a read of 0x4256 returning a value of 50.0 degC

So it would seem you can write to FSV2021.

  • Can you see the raw frames on the RS485 bus (packet monitor)? If you are trusting HA to generate the correct packet without some confirming diagnostic information then it will be very difficult to debug, could be wrong channel, wrong address, wrong CRC, wrong byte count, wrong sequence number, etc. Too much “stuff” between what you are sending (or think you are sending) and the RS485 bus (IMHO).
138

How do we order!?

139

I can PM you the ebay link to buy the board. I still have 2 before I need to order some.

Cheers

140

Stage 1 complete

  • I decided to add the preamble to my Tx-s. I approximate it by sending 5 0xFDs separated by 10ms. My RS485 hardware has the property that it cannot hear its’ own transmissions, so if I hear anything on the bus during my preamble Tx, I assume it is the preamble from another node and abort, retrying again later. I guess there is some more complicated priority arbitration algorithm for more heavily loaded buses, but for the lightly loaded case here my implementation should be good enough. In the hours of monitoring so far I have seen one collision.
  • Stripped out most of the packet parsing debug. I will now add it into my live HEMS, but just monitoring, not actively controlling, and log the measurements to my dB. Give that a couple of weeks and if it proves reliable, then use it for active control.