amazing

[dannydegaspari]

amazing

[michelebergo]

Hi Danny, I have tried to sniff the communication between my MWR-WE10 wired control unit + duct unit (NH045LHXEA) but I have some difficulties on understanding what it is happening. differently respect to what you are observing it seems in my case the starting byte is 0x33 instead of 0x32 so I'm lost. I have attached what I'm observing with the logic analyzer.

and the log from your sniffer

Capturing on: /dev/serial0
73 65 FB FF FF FF FF FF FF FD 26
73 DD F9 F3 F9 C7 F2 C7 FE FF 3F
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 DD F9 F3 F9 C7 F2 C7 FE FF 3F
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 65 FB FF FF FF FF FF FF FD 26
73 5D E9 F7 67 CC FF FD FE FF 03
73 DD F9 F3 F9 C7 F2 C7 FE FF 3F
73 75 FB FF FF FF FF FF FF FF 55
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 65 FB FF FF FF FF FF FF FD 26
73 5D E9 F7 67 CC FF FD FE FF 03
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 5D E9 F7 67 CC FF FD FE FF 03
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 75 FB FF FF FF FF FF FF FF 55
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 65 FB FF FF FF FF FF FF FD 26
73 DD F9 F3 F9 C5 F9 C5 FF FF 3F
73 75 FB FF FF FF FF FF FF FF 55
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 65 FB FF FF FF FF FF FF FD 26
73 5D E9 F7 67 CC FF FD FE FF 03
73 7D E9 B5 97 E4 27 ED FF FF D1
73 E5 FB FF 01 E1 0D 7E BE FF 83
73 65 FB FF FF FF FF FF FF FD 26
73 DD F9 F3 F9 C5 F9 C5 FF FF 3F
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 6D F9 0B 89 79 B0 8E FE 51 C2
73 65 FB FF FF FF FF FF FF FD 26
73 5D E9 F7 67 CC FF FD FE FF 03
73 6D F9 0B 89 79 B0 8E FE 51 C2

can you help me interpreting what it is going on?

cheers,
Michele

[DannyDeGaspari]

Hi Michele,

Can you add the '-f' parameter to the sniffer to show the full message ? By default it strips of the 1st and 2 last characters. But since it displays messages with the expected length, I think it sees the start byte 0x32 correctly.
From the log it seems that '73' is the address of your MWR-WE10 trying to send out messages but does not receive anything.

[michelebergo]

Hi Danny,
after a debug session with the oscilloscope I have found out that the rs485 signal coming from the controller was corrupted by long wire reflections. I have twisted the wires and now the communication is as it was intended to be. The controller is sending a message starting with 0x32 followed by the source and destination address. Log reported below:

32 84 20 63 00 00 00 00 00 00 00 00 C7 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 52 00 00 00 00 00 00 00 00 F6 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 53 00 00 00 00 00 00 00 00 F7 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 54 00 00 00 00 00 00 00 00 F0 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 64 20 00 03 1B 00 00 00 00 F8 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 70 00 00 00 00 00 00 00 00 D4 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 52 00 00 00 00 00 00 00 00 F6 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 53 00 00 00 00 00 00 00 00 F7 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 54 00 00 00 00 00 00 00 00 F0 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 64 20 00 03 1B 00 00 00 00 F8 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 71 00 00 00 00 00 00 00 00 D5 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 83 00 FF FF FF FF FF FF FF D8 34
32 84 AD D1 01 00 00 00 00 00 00 00 F9 34
32 84 20 52 00 00 00 00 00 00 00 00 F6 34

You can see the sequence of the commands sent (0x52, 0x53, 0x54, 0x63, 0x64 etc) comprising the message you identified as broadcast.

Thank you again for the support. In these days I'm pushing Samsung to provide to me (us) the communication protocol details under NDA. let's cross the fingers.

BR,
Michele

[michelebergo]

Hi Danny, now I have some difficulties to use your ac_control.py (some errors). do you have an updated version? thank you in advance

BR,
Michele

[DannyDeGaspari]

Great that it works now!
This is the latest version, what errors do you get with ac_control ?

[michelebergo]

Hi Danny, fixed also the control part. I'm able to send some command (for example to turn on the duct) but I'm not getting the answer from the destination. (as you can see from the snapshot)

Any suggestion?

BR,
Michele

[DannyDeGaspari]

Looks like you have contention with the end of the broadcast message (address 0xad) and the beginning of your transmission. You might need to add some extra delay of roughly 50 to 100 ms after detecting the broadcast message. You can do that by adding a sleep command in line 89 of lib_hvac.py. I did not have to add any extra delay there because on my system the transmission is on the right time. You might have a faster system then my raspberry pi 2.

By the way I noticed a bug in ac_control, it is using the incorrect library. I updated it.

[michelebergo]

Hi Danny, yes I tried adding the delay but I think the issue is related still to the long wires connection. If you see from the snapshot when I'm trying to trasmit something the other line is not receiving correctly what I'm sending.

Yes,regarding your code you were referencing the wrong library and also the naming of the related function should be adjusted in accordance.

Which is the lenght of your wiring?

Thank you again for your support.

BR,
Michele

[DannyDeGaspari]

My cables are 4 to 5 meters untwisted. RS485 is designed to go with very long cables. Is the wired remote on the same transmission line ? If yes, you should use a different address for your own transmissions e.g. 0x85. Where do you measure the transmit signals, on the RS 485 line or on the TTL side ? Is the receiver reacting to your commands ? Maybe you reversed the 2 wires on your transmitter side ?

[michelebergo]

yes the wired remote controller is is on the same line respect to my TTL to RS485 converter. Ok I was using the same address of the wired remote controller (0x84) with the idea to emulate it. the signals you see on the screenshots are measured on the TTL side and from the one obe you can see (tx brown and rx white). when I'm trying to send something through the tx line the rx is not reproducing the message I'm sending. my TTL to RS485 converter has a max 13487 on board. what do you mean for having reversed the wires on my trasmitter line?

[DannyDeGaspari]

With reversed I mean that the A and B connection of the RS485 transceiver are connected to F3 and F4 lines in reversed order.
I also notice that your max 13487 has a 5V power supply, are you connecting it to a raspberry pi ? In that case the IO voltage might be too high for the pi's IO's.

[michelebergo]

Hi Danny, max13487 B- is connected to F4 and A+ to F3. If I revert the order I cannot receive the right codes using your python script. Regarding the rx terminal of the raspberry pi I'm using a level shifter to not destroy the IO. how are you connecting the F4 and F3 to your RS485 interface?

[DannyDeGaspari]

I'm using a TI SN65HVD11D transceiver, but I do not remember how I connected the wires. It was error and trial, but I did not write it down, and it is build into the wall now.
You don't see a correct response, but does your duct unit accept the commands, do you hear a bleep form it ?

[michelebergo]

Hi Danny, the duct is not accepting the command (I cannot hear the bleep) and it si not answering to my command. It is accepting only the commands coming from the wired controller. I'm investigating if it is a problem related to my transceiver. I will let you know of course.

[michelebergo]

Hi Danny, I'm arrived in a point where I'm stuck. what I can see at the oscilloscope is reported on the picture below:

In red the commands sent by the wired controller (+ slave response) and in red the command sent by me (zoom below):

the signal sent by me is not perfectly squared (A+). if I look to the other channel (B-) I have the same inverted (of course). do you think it's a problem of common mode? is my RS485 interface too weak? I have no idea why the slave is not answering at all.

BR,
Michele

[michelebergo]

image with the serial deconding. the purple signal is the one I use for triggering (coming from pi)

[DannyDeGaspari]

I'm afraid I can't really help on the analog electronics side. But the voltage levels from your transmission does not look right. I has been quite some time ago to remember exactly, but I also had issues with my first transmissions. I believe also similar to your scope plots. I didn't trust the RS485 transceiver and replaced it. See here.

[michelebergo]

Hi Danny, found out root cause (transmitter issue: too weak).
BR,
Michele

[DannyDeGaspari]

Great! Did you replace the transmitter chip or did you use another convertor ?

[michelebergo]

Hi danny, sorry for the late response. I use another chip and now I'm trying to bring everythin gon esp8266

[vespix]

Dear Michele,
Did you succes in obtaining the communication protocol from Samsung?

BR

[michelebergo]

Dear Michele,
Did you succes in obtaining the communication protocol from Samsung?

BR

Hi vespix,
Samsung has not sent yet the documentation. I'm waiting for the NDA.
BR,
Michele

[vespix]

Dear Michele,
Still no news from Samsung?

[lanwin]

You dont need the documentation from Samsung. First you need to know if you have and new device with the NASA protocol or and old one with the Non NASA protocol. There exists a S-NET pro 2 app for both. The NASA version is written in dotnet and can simply be decompiled and reverse engineered. There is all you need. Protocol parser and decode and a file with describes most of the messages. At least for NASA. But I bet it the same for the Non NASA version.

I created a working ESPHome component for NASA (with also could integrate Non NASA) here https://github.com/lanwin/esphome_samsung_ac