Anyone use Quiet Mode with Samsung ASHP to reduce cycling?

SarahH · 18 September 2025 09:32

I’m not quite sure that I understand your question (maybe because I don’t use HA), but are you saying that you succeeded in writing a value to 0x42F1? Based on the discussion on the Contribution: Samsung ASHP NASA link <-> MQTT bridge (Home Assistant) thread, I had been under the impression that the only Message Addresses we could write to were those associated with FSVs (like the 0x40A7 you mention for #5051). Personally I use SNET-Pro2 v1.14.3 to reset my FSVs (on my laptop), as the packet syntax for outgoing messages is a bit daunting (all those 0x55555555555s…)

Topaz · 19 September 2025 05:03

Dear Sarah,

Yes I’ve succeeded in writing to fsv 0x42f1. Altgough it’s format is highly constructed.

Abour 55…5 I’m not bothered by it this only preamble data for bus decoders sync. To eliminate a few collsion they use it and relt on a csma/cd (iirc my networks courses).

Also for fun I’ve made an ndoor controller python emulator to mess around with the remote controller display. I’ve already uncovered the fsv descrptor fetch and decode (to know unit/max/min/default values of fsv on the remote, useless but refreshing)

Abour FR and DR i’ve already seen the effect on dhw production, but not yet on space heating (summer sure lasts this year).

Cheers

SarahH · 19 September 2025 08:39

Good work, @Topaz !

Can you share any details?

This sounds like it does what SNET-Pro2 does (have you used SNET at all?)

Again, can you give us details? I’m also fooling around with a Python-based proxy to intercept data traffic between SNET and the MIM. I can understand most of the traffic leaving the MIM, but that leaving SNET has a really weird syntax (typical packet 55 AA 55 00 25 80 1B C0, though sometimes something like 32 00 1F 80 FF 00 B0 FF 10 C0 11 59 01 06 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 38 CF 34, preceded by about 100 0x55s). This latter is similar to the FSV reset code that SNET writes, though with the 0x061A and its 15 data bytes replaced by the target address such as 0x40A7 with just a single data byte following.

Any insights greatly appreciated!

Topaz · 19 September 2025 08:55

@SarahH Please share full logs of your proxy, I may be of help

Concerning reverse of the FSV structure, although not perfect, here’s the draft of the format

"""
LOGS:
# reverse fsv structure
#temp unit
2025-09-15 14:04:42,509 INFO Thread-1 520000200000c011f001461203f3ffffffffffffffffffffffffff
2025-09-15 14:04:42,515 INFO Thread-1 src:520000 dst:200000 type:normal ins:read nonce:0xf0
2025-09-15 14:04:42,523 INFO Thread-1   0x4612 (STRUCTURE): 461203f3ffffffffffffffffffffffffff
2025-09-15 14:04:42,690 INFO packetgateway 32001f200000520000c015f001461203f3010a0100b400fa00fa01000000519e34
2025-09-15 14:04:42,695 INFO packetgateway src:200000 dst:520000 type:normal ins:response nonce:0xf0
2025-09-15 14:04:42,701 INFO packetgateway   0x4612 (STRUCTURE): 461203f3010a0100b400fa00fa01000000

#temp unit
2025-09-15 14:08:39,604 INFO Thread-1 520000200000c011f001461203f4ffffffffffffffffffffffffff
2025-09-15 14:08:39,608 INFO Thread-1 src:520000 dst:200000 type:normal ins:read nonce:0xf0
2025-09-15 14:08:39,616 INFO Thread-1   0x4612 (STRUCTURE): 461203f4ffffffffffffffffffffffffff
2025-09-15 14:08:39,788 INFO packetgateway 32001f200000520000c015f001461203f4010a01003200b400a001000000785a34
2025-09-15 14:08:39,804 INFO packetgateway src:200000 dst:520000 type:normal ins:response nonce:0xf0
2025-09-15 14:08:39,818 INFO packetgateway   0x4612 (STRUCTURE): 461203f4010a01003200b400a001000000

# on off unit
2025-09-15 14:17:14,732 INFO Thread-1 520000200000c011f00146120fddffffffffffffffffffffffffff
2025-09-15 14:17:14,737 INFO Thread-1 src:520000 dst:200000 type:normal ins:read nonce:0xf0
2025-09-15 14:17:14,744 INFO Thread-1   0x4612 (STRUCTURE): 46120fddffffffffffffffffffffffffff
2025-09-15 14:17:14,917 INFO packetgateway 32001f200000520000c015f00146120fdd01010000000001000101000000369534
2025-09-15 14:17:14,925 INFO packetgateway src:200000 dst:520000 type:normal ins:response nonce:0xf0
2025-09-15 14:17:14,934 INFO packetgateway   0x4612 (STRUCTURE): 46120fdd01010000000001000101000000

#minute unit
2025-09-15 14:19:34,721 INFO Thread-1 520000200000c011f00146120fcdffffffffffffffffffffffffff
2025-09-15 14:19:34,728 INFO Thread-1 src:520000 dst:200000 type:normal ins:read nonce:0xf0
2025-09-15 14:19:34,737 INFO Thread-1   0x4612 (STRUCTURE): 46120fcdffffffffffffffffffffffffff
2025-09-15 14:19:34,911 INFO packetgateway 32001f200000520000c015f00146120fcd0101030001001e000101000000de2934
2025-09-15 14:19:34,917 INFO packetgateway src:200000 dst:520000 type:normal ins:response nonce:0xf0
2025-09-15 14:19:34,923 INFO packetgateway   0x4612 (STRUCTURE): 46120fcd0101030001001e000101000000


NASA DESCRIPTOR REQUEST

520000200000c011f001461203f3ffffffffffffffffffffffffff
strc
|
|   fsv_as_int
|   |   13 FF bytes
v   v   v  
461203f3ffffffffffffffffffffffffff

NASA DESCRIPTOR format:
- All values are BIG ENDIAN FIRST encoded
         step     min  max  dflt unknown(4bytes)
         v  div   v    v    v    v
            v  unit
#1011          v
461203f3 01 0a 01 00b4 00fa 00fa 01000000
          1 10  1   18   25   25  1
#1012
461203f4 01 0a 01 0032 00b4 00a0 01000000
          1 10  1    5   18   16  1

#4045 
46120fcd 01 01 03 0001 001e 0001 01000000

#4061
46120fdd 01 01 00 0000 0001 0001 01000000
          1  1  0    0    1    1  1
"""

sample_nasa_desc_ehs_gen7 = {
  1011: "010a0100b400fa00fa01000000",
  1012: "010a01003200b400a001000000",
  4045: "0101030001001e000101000000",
  4061: "01010000000001000101000000",
  5012: "010a0100b4012c012c01000000",
}

Topaz · 19 September 2025 08:56

Also, 061A, once decoded means the struct of index 1A and of format 0 (generally a single byte, but structure, hey!)

I can poke around my system just to see. Also, in my proxy, I added a field from home assistant to play random hex encoded request, just decorated with CRC and start and stop bytes before sending. proven very useful to uncover all those mysteries

Topaz · 19 September 2025 09:00

Finally, details on 42F1 encoding. From “Installation manual Modbus Interface Module MIM-B19N / MIM-B19NT”

hence 2 bytes: struct.pack(“>BB”, enabled, limitvalue), with enabled is 0 or 1, and limit value in [50;150] range.

Hope that helps

Edit: the 42F1 is only accepted once fsv #5051 is set to 1. else, the value is discarded.

SarahH · 19 September 2025 09:31

Here’s an extract from one of my proxy logs from a few days ago, @Topaz :

[2025-09-13 13:55:41.247] [INCOMING] (69 bytes): FD FD FD FD FD 32 00 3E 10 00 00 B0 00 FF C0 14 64 0C 82 44 00 00 82 45 00 FF 82 48 00 FF 82 54 01 A4 82 5A FF FF 82 5B 00 00 82 5C 00 03 82 5D 00 00 82 78 00 00 82 7A 00 FC 82 80 01 76 82 9A 03 AC CD 30 34
[2025-09-13 13:55:41.291] [INCOMING] (4 bytes): FD F1 F9 FD
[2025-09-13 13:55:41.332] [OUTGOING] (8 bytes): 55 AA 55 00 25 80 1B C0
[2025-09-13 13:55:41.338] [INCOMING] (63 bytes): FD 32 00 3C 20 00 00 B3 00 FF C0 14 05 08 02 02 00 00 04 02 00 A0 00 00 04 09 00 00 00 00 04 0A 00 00 00 00 04 0B 00 00 00 00 04 0C 00 00 00 00 04 0D 00 00 00 00 04 0E 00 00 00 00 2A A4 34
[2025-09-13 13:55:41.385] [INCOMING] (8 bytes): FD FD FD FD FF 32 00 3E
[2025-09-13 13:55:41.432] [INCOMING] (33 bytes): 10 00 00 B0 00 FF C0 14 65 0C 82 9F 00 7A 82 A0 00 82 82 B2 7F FF 82 B5 00 34 82 B8 00 00 82 BC F8
[2025-09-13 13:55:41.432] [INCOMING] (20 bytes): 40 96 7D 01 41 82 E0 01 4C 82 E3 00 50 82 E8 01 E0 42 46 34
[2025-09-13 13:55:41.496] [INCOMING] (1 bytes): FD
[2025-09-13 13:55:41.529] [INCOMING] (56 bytes): FD FD FF FA 32 00 32 10 00 00 B0 00 FF C0 14 66 07 82 ED 00 EA 82 F6 00 14 82 FC 00 00 84 08 00 00 00 18 84 0B 00 00 00 00 84 0C 00 00 00 00 84 1A 00 00 00 00 23 2E 34
[2025-09-13 13:55:41.636] [INCOMING] (67 bytes): FD FD 77 FD 32 00 3C 20 00 00 B3 00 FF C0 14 06 08 04 10 00 00 00 00 04 11 01 2C 00 00 04 12 00 32 00 00 04 13 02 26 00 00 04 14 00 96 00 00 04 15 00 50 00 00 04 16 00 00 00 00 22 F7 00 0F B6 46 34 FD
[2025-09-13 13:55:41.708] [OUTGOING] (120 bytes): 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 32 00 12 80 FF 00 B0 FF 10 C0 11 48 01 82 BC 00 00 F8 11 34
[2025-09-13 13:55:41.715] [INCOMING] (66 bytes): FD FD FD F7 32 00 3C 20 00 00 B3 00 FF C0 14 07 0C 22 F9 00 00 22 FA 00 01 22 FB 00 DF 22 FC 20 61 22 FD 00 00 22 FE 00 09 22 FF 00 03 24 FB 00 00 01 2A 40 00 01 40 01 04 40 02 04 40 06 03 73 CD 34
[2025-09-13 13:55:42.005] [INCOMING] (1 bytes): FD
[2025-09-13 13:55:42.007] [INCOMING] (4 bytes): FD FD F9 F1
[2025-09-13 13:55:42.009] [INCOMING] (65 bytes): FD 32 00 3E 20 00 00 B3 00 FF C0 14 08 10 40 0F 00 40 10 00 40 15 01 40 19 00 40 1B 01 40 23 00 40 24 01 40 27 00 40 28 00 40 29 00 40 2A 00 40 2B 00 40 2D 00 40 2E 00 40 31 00 40 35 00 4B 4B 34
[2025-09-13 13:55:42.092] [INCOMING] (69 bytes): F9 FD F7 F1 FD 32 00 3E 20 00 00 B3 00 FF C0 14 09 10 40 43 00 40 46 00 40 47 01 40 48 00 40 4F FF 40 51 00 40 59 01 40 5F 00 40 60 00 40 65 00 40 66 00 40 67 00 40 68 00 40 69 00 40 6A 00 40 6B 00 4A F8 34
[2025-09-13 13:55:42.315] [INCOMING] (69 bytes): FD F6 FD FB FD 32 00 3E 20 00 00 B3 00 FF C0 14 0A 10 40 6C 00 40 6D 00 40 6F 01 40 70 00 40 73 00 40 74 00 40 77 00 40 7B 00 40 7D 00 40 7E 00 40 85 00 40 86 00 40 87 00 40 89 00 40 8A 00 40 95 03 39 54 34
[2025-09-13 13:55:42.348] [INCOMING] (5 bytes): F9 F9 F7 FD FD
[2025-09-13 13:55:42.351] [INCOMING] (64 bytes): 32 00 3E 20 00 00 B3 00 FF C0 14 0B 10 40 96 00 40 97 02 40 99 00 40 9A 02 40 9C 00 40 B5 00 40 C4 00 40 C5 00 40 C6 00 41 17 00 41 1A 00 41 1E 00 41 24 00 41 25 00 41 27 04 41 28 00 2F 22 34
[2025-09-13 13:55:42.352] [INCOMING] (2 bytes): FD FD
[2025-09-13 13:55:42.391] [INCOMING] (67 bytes): FA F6 FD 32 00 3E 20 00 00 B3 00 FF C0 14 0C 0C 42 01 01 2C 42 02 01 8D 42 03 00 C8 42 04 01 38 42 05 00 CD 42 06 FE 0C 42 0C 00 96 42 11 00 00 42 12 00 44 42 13 00 00 42 17 00 00 42 29 00 73 A3 11 34
[2025-09-13 13:55:42.475] [INCOMING] (68 bytes): FD FD B7 FD 32 00 3E 20 00 00 B3 00 FF C0 14 0D 0C 42 35 01 40 42 36 01 41 42 37 00 FC 42 38 01 4C 42 39 FE 0C 42 3E FF FF 42 47 01 2C 42 48 00 00 42 4A 00 F0 42 4B 00 A0 42 4C 01 2C 42 4D 00 B4 CF 96 34
[2025-09-13 13:55:42.722] [OUTGOING] (74 bytes): 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
[2025-09-13 13:55:42.725] [INCOMING] (69 bytes): FD FD FD FD FD 32 00 3E 20 00 00 B3 00 FF C0 14 0E 0C 42 4E 02 08 42 4F 00 FA 42 50 01 2C 42 51 00 A0 42 52 02 26 42 53 01 2C 42 69 00 03 42 6A 02 58 42 6B 00 0A 42 73 00 FA 42 74 01 2C 42 75 00 96 FE DB 34
[2025-09-13 13:55:42.725] [INCOMING] (69 bytes): FD F9 FD FD F7 32 00 3E 20 00 00 B3 00 FF C0 14 0F 0C 42 76 00 A0 42 77 00 FA 42 78 00 FA 42 79 00 96 42 7A 00 96 42 7B 01 2C 42 7F 01 8D 42 8C FE 0C 42 8D 00 00 42 CE 01 E0 42 D4 FE 0C 42 D6 01 2C 57 89 34
[2025-09-13 13:55:42.898] [OUTGOING] (46 bytes): 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 32 00 12 80 FF 00 B0 FF 10 C8 11 48 01 82 BC 00 00 E6 CB 34

Note that:

my proxy is very basic - I’m new to Python .
the heat pump probably wasn’t running at the time I grabbed the above log, so the data may not be very interesting.
the packet data aren’t always cleanly separated. For example, look at the packet starting at [2025-09-13 13:55:41.385] - you can see that it’s spread over 3 log entries.
some packets seem to mistime/misinterpret the EOL character and get an extra byte added. See [2025-09-13 13:55:41.636] where an otherwise valid packet has a 0xFD nailed to the end.

I assume that there must be faults in my proxy coding somewhere…

SarahH · 19 September 2025 09:49

I was under the impression that the data length for each message could be inferred from the register address. For example address 0x40nn or 0x41nn would have a single byte of data, 0x42nn would be 2 bytes, 0x44nn would be 4 bytes, and 0x46nn would be “the rest of the message (prior to the CRC bytes)”. Similarly for 0x0nnn and 0x8nnn.

Have I got this completely wrong? (I’ve built this syntax into my Python code so any error needs to be corrected asap…)

SarahH · 19 September 2025 11:07

Great detective work, @Topaz.

To confirm my (layman’s) understanding, 0x4612 is used to define the operating limits of any FSV (i.e. min/default/max, as listed in the User Manual), with the measurement unit coded as a hex byte (1 = degC, 3 = min, 0 = no unit etc). (By contrast, the current FSV value is stored in other registers, such as 0x424A for FSV #1011.)

I see in the NASA codes list Samsung NASA Codes.docx (77.1 KB) that 1) 0x4612 bears the Description “Source_Address_Class: WiFiKit” whereas in the Packet Structure table, “WiFiKit” appears (packet byte 03) as 0x62. Have you resolved this apparent inconsistency?

I presume that the FSV operating limits (as defined by 0x4612) are fixed for any given heat pump model, and that any FSV change request (either from the Remote Controller, or from SNET via F1/F2) will only be honoured if it complies with the operating limits.

I believe that we have already determined the syntax of an SNET FSV change request, in Contribution: Samsung ASHP NASA link <-> MQTT bridge (Home Assistant) , post #59 onwards. Presumably an FSV change request from the Remote Controller would be similar (I haven’t tried my proxy on F3-F4 yet).

Topaz · 19 September 2025 11:50

x6xx means “structure” as per the java code provided by samsung ehs kit.

in this case the number of entries in the packet must be exactly 1. and though the total length of the data is determined by the packet length (after the starting 0x32 byte). At least I think this is correct.

Topaz · 19 September 2025 11:53

I also observed invalid data on the bus sometimes. My packetization engine is coded with a state machine that waits for the 0x32 byte, then decode the 2 following big endian bytes to get the total lenth, then append every following byte. and expect a 0x34 as the last byte.

before the last byte are 2 bytes of crc, which is recomputed and verified. If the 32, 34 and crc are correct and at the expected place. then I continue with decoding the packet, else I discard it. This way you can strip off every 0xFD (preamble/postamble bytes) and 0x55 (weird but probably related to perturbation on the line maybe).

Topaz · 19 September 2025 11:58

My understanding is that its enumeration only. It does not bear the actual values, but the remote controller “asks” for the definition of the FSV to change the way it’s displayed and know the limits of the FSV edition. I confirmed that by spoofing values returned by 4612 and the remote controller changed its display.

Well, 4612 is not a regular field, it’s a structure, and according to my this is like an “extension” of the poorly designed 2 bytes based NASA protocol. In my mind, x6xx are a collection of additional functions. 4612 is meant to describe the FSV encoding (min/max/default/type/unit)

I hope I’m not telling lies though haha.

Cheers,

mrsimonbennett · 24 October 2025 10:09

Does anyone know how to control this via modbus and home assistant I am pulling my hair out trying to understand the regsiter addresses

SarahH · 24 October 2025 10:28

@Michal_S ?

Michal_S · 24 November 2025 17:33

@Topaz one question, are you able to set values like 55% or 73% ? Seems when I try to set e.g. 311 in decimal which corresponds to 55% I can’t to it and always lower value is set in this case 50% - 306 decimal. I don’t know why but I don’t like it. So I can set either 22Hz or 27Hz but I can’t set e.g. 25Hz. So between 50% and 60% it makes 5Hz difference in compressor speed what is maybe 1kW of heat more. For some better regulation I would like to limit it more finer. Any idea ?

I have different experience. I thought as well but the I’ve found that 42F1 always reset after one hour to 0. This gave me an idea that maybe if this register is written then #5051 is ignored for the time being until 42F1 > 0. Indeed. I’ve disabled @5051 back and wrote 42F1 and it uses FRC as requested.

Note: Once 42F1 is reset to 0 FRC still is enabled at 50% while #5051 is active.

This is actually a good behavior because I don’t need rely to home assistant working. In case there is some issue and FRC can’t be set automatically every 1h then it resets to 0 and the pump works like FRC is not enabled.

Sorry, control what you need ?

mrsimonbennett · 24 November 2025 17:40

I did manage to get it to work

Mixed results playing with it. Good for dhw slower

I’ve found you can only do 306 +10 increments to 406

it won’t accept any other value

Michal_S · 24 November 2025 17:43

Yeah this is also my finding. I don’t know if it because frequencies at those intermediate steps are not stable or it’s just another Samsung controlling stupidity. Why for the god sake I can’t set 55% ???

And also it does reset after 1 hour to 0.

And sorry for late reply

Topaz · 24 November 2025 18:03

The peecentage can only be in x0%. other values are rounded.

Also the setting is discarded after an hour, hence I set it every 30 sec

Michal_S · 24 November 2025 19:20

Same observations. Thanks for confirmation.

mrsimonbennett · 2 December 2025 16:39

So I have writen an automation to help with cylcing when starting, I have found when starting the heat pump, it would ramp up to full power very quickly to get the LWT to target. Sometimes this would cause a few start stops before we got to a steady state. I am unsure why, maybe the fact the PWM pump won’t even attempt to ramp down for 20 minutes. Insights welcomed.

Fixed (ish)

I have built automation around the FR control to limit the compressor to an estimated 1.2x the heat loss of the house.

When we are doing DHW we limit to 50% (unless the water is really low and someone is trying to have a shower) and when we are doing CH we limit to what the heat loss is.

I am hoping this will help reduce the defrosts too