Well, I’ll try. The problem splits neatly into 2 parts.
-
Get the data into/out of the Samsung system into a PC/RaspberryPi/etc.
-
Use the data in the PC/etc. to take control of the Samsung system.
I will do this in a few posts otherwise it will just get humungous. Caveat is that I hate Microsoft and Windows, so the control part will be heavily biased towards Linux based solutions.
Part 1 - Get the data into/out of the Samsung system
There are once again 2 obvious ways to do this
- Using the Samsung MIM-B19N Modbus interface. This is freely available in the UK from the likes of Midsummer/City Plumbing/etc. at 150GBP-ish. However, you can get it from Europe cheaper, for instance
If you look at the documentation that comes with this it looks like only a limited subset of registers are available over Modbus, but this (and many others) lists how to get more
The MIM-B19N connects to F1/F2 (which is the internal Samsung NASA bus). The installation instructions tell you to put it in the outside unit, but of course, it is an RS485 bus so you can equally connect it (more conveniently) at the indoor unit F1/F2 connections, doh!
Mine has been running reliably for years now. The only trouble it has given was locking up after a few months. I was polling Modbus too fast (10ms), reducing to 50ms and it has been reliable ever since.
So you now have a Modbus RTU interface (RS485). You now need a USB<->RS485 convertor to get it into the PC. You could use one of the cheap FTDI convertors
but I prefer to galvanically isolate systems from each other where possible, so this is a better solution
A bit of 2/3 core wiring, 120R Modbus termination resistor and you’re done.
- Directly to the F1/F2 Samsung NASA bus. This is extensively discussed in
Now, I would normally point you to
https://wiki.myehs.eu/wiki/NASA_Protocol?action=edit&redlink=1
which had a description of the NASA protocol and all the Samsung registers, but the content seems to have disappeared, maybe Samsung have got annoyed that their proprietary information was being published, or maybe it is just temporarily broken, I don’t know. Anyway a trawl of Github should produce the same information.
So you can connect the USB<->RS485 convertors listed above (although in this case I would definitely advise the galvanically isolated one) and look at
to implement a protocol convertor.
RS485 is a physical layer, not a protocol. It does not define the structure of messages on the bus. Modbus RTU defines the structure of the messages, and NASA defines a different structure. Modbus is a master/slave protocol, there is one master that polls (requests data) and a slave responds (response data). So NASA could work in a similar way, or they could have defined some multi-master protocol to allow different masters to poll for data/send commands. If you just want to listen to messages on the bus, decode them and display, there is no problem. However, if you want to set register values, then you need to understand the multi-master protocol (if it exists) so that you can send write commands at the appropriate time. You could probably figure it out looking at a packet trace from S-NET …
This route is not for the faint hearted, if you have not got at least some software development experience, I would spend the 80EUR, it will be much less grief.