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…)
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).
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.
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
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…
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…)
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).
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.
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).
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)
.