First venture into MODBUS, how to send a password?

Hi,

This is my first venture into MODBUS, and I'm struggling getting things together. My setup is:
1) Heatpump with 2-wire RS-485 and MODBUS (According to manufacturer). Also a Wi-Fi module connected via RS-485.
2) Moxa IP-to-serial (NP-5430I) or simple RS-485 to USB, connected in parallel with the Wi-Fi module.
3) Preferred Home Assistant to control and read data from the heatpump, but due to lack of success, I've tried approx. 10 different MODBUS tools.

By using putty, I can see that the heatpump continuously sending it's serialnumber on the bus, but no matter which tool I use, I cannot read any values myself.
According to the manufacturer, the slave address is H37 (Assume 37 Hex), and I need to send a password "022", before I can access anything. Have no clue, how to do that.
I have gotten some luck with https://wiki.eltima.com/user-guides/spm-user-guides.html, which outputs what can be seen in the attached text file.
But I can't get my head around how to initiate the communication myself, and I don't see the 37 hex address in the bus log..

Any good ideas as to how I crack this nut?
 

Attachments

No, I have no idea why the checksum is bad. I did not place any resistor on the bus, maybe that's why? Cable is ~10meters long, and I assume that the Wi-Fi module has it's own resistors built in.

And no, there's only COM4 which is the USB<->RS-485 :(
 
yES MAYBE PULL HIGH LOW RESISTOR OR TERMINATOR should be used
Did you follow OEM user manual or over manual for troubleshooting
CHECK CORRECT POSITIONS OF DIP switches..
 
yES MAYBE PULL HIGH LOW RESISTOR OR TERMINATOR should be used
Did you follow OEM user manual or over manual for troubleshooting
CHECK CORRECT POSITIONS OF DIP switches..
Their manual states nothing about this. It's not officially supported, but I just asked them for the MODBUS documentation. I can't see any dipswitches on the heatpump :(
 
I've tried putty, that's where I saw the serialnumber of the heatpump. Right now I'm only using the Eltima tool.
The Moxa box is an older hardware, and do not have built-in resistors / DIP switches, so I have to put it in manually.
 
1. If you're getting bits back and forth, it is probaby not a hardware issue involving a terminating resistor. It could be, at higher baud rates and longer distances, but probably not.

2. Is it a Modbus protocol?

My first reaction is, is the protocol Modbus RTU, based on your statement, "I can see that the heatpump continuously sending it's serial number on the bus."

A heat pump is most likely a Modbus slave and slaves are silent unless spoken directly to by a Master. Slaves cannot broadcast in Modbus, by Modbus protocol rules/spec.

Just because some device uses RS-485 does not mean that it uses the Modbus protocol.

A. Why do you think the heat pump uses the Modbus protocol?

B. If you can "see the heatpump send its serial number" with Putty, presumably on the RS-485 port, then is there another RS-485 port for Modbus? Modbus will not co-exist on an RS-485 port with a protocol that broadcasts.

3. Serial-Ethernet converters

RS-485 serial-Ethernet used for Modbus should be one of a subset of commercial serial Ethernet serial servers that run a firmware version specifically for Modbus RTU that takes into account the timing requirements for Modbus RTU. The Modbus RTU versions typically cost a bit more that the non-Modbus, generic 438-t0-ethernet versions. Moxa is known for industrial electronics so your model might or might not be a Modbus RTU version. Does your 'simple' Moxa IP-to-serial run a firmware version for Modbus RTU?

4. Sniffer mode text file

The first message in the accompanying sniffer mode text file might appear to be a valid Modbus message given the Checksum is reported as OK, the probabilities or a false CRC evaluation is small. BUT . . . .

[06/06/2021 20:48:43]
Modbus Response (COM4)
Address: 2
Function: 3 (0x03) - Read Holding Registers
Byte Count: 11
Values: b9 00 5a
Register0: 47360
Checksum: 5635(OK)

A. Where is the polling message, the request from the Master? Shouldn't a sniffer program show all the traffic, polls from Master, replies from the slave(s)?

B. The first message reports a slave address of 02. You tell us that the slave address should be Hex 37, which is not 02. ? ? ? ?

C. The byte count does not match the displayed data.

Any FC03 response/reply includes the number data bytes being returned to the master. The sniffer reports 11 bytes being returned, presumably decimal 11

- decimal 11 is an invalid 'odd' (not an even) number. Modbus 16 bit registers are composed of two 8 bit bytes, so any count of Holding registers must be an even number, some register quantity times 2.

- the displayed data b9 00 5a is only 3 bytes out of 11 ? ? ?

- the reported value for register 0, 47360 decimal is B900. The first reported two bytes of the 3 bytes that are displayed are B900. Why does the sniffer program show only a subset of the 11(?) bytes of data?

I'm just not sure the sniffer is decoding the messages properly.

If the sniffer is just not displaying all the data and can be trusted then consider that the 14-16 subsequent messages following the first message are invalid messages (bad CRC). Then the sequence repeated, one valid message, multiple invalid messages.

If the sniffer can be trusted then that first valid message followed by multiple invalid messages could very well point to timing faults where the first message is recognized because its start bit is correctly recognized but incorrect timing interpretation causes the start bit of the 2nd message to not be recognized properly resulting in all the following bits for all the following messages to be out-of-sequence with the result that all the following messages are corrupted.
 
1. If you're getting bits back and forth, it is probaby not a hardware issue involving a terminating resistor. It could be, at higher baud rates and longer distances, but probably not.

2. Is it a Modbus protocol?

My first reaction is, is the protocol Modbus RTU, based on your statement, "I can see that the heatpump continuously sending it's serial number on the bus."

A heat pump is most likely a Modbus slave and slaves are silent unless spoken directly to by a Master. Slaves cannot broadcast in Modbus, by Modbus protocol rules/spec.

Just because some device uses RS-485 does not mean that it uses the Modbus protocol.

A. Why do you think the heat pump uses the Modbus protocol?

B. If you can "see the heatpump send its serial number" with Putty, presumably on the RS-485 port, then is there another RS-485 port for Modbus? Modbus will not co-exist on an RS-485 port with a protocol that broadcasts.

3. Serial-Ethernet converters

RS-485 serial-Ethernet used for Modbus should be one of a subset of commercial serial Ethernet serial servers that run a firmware version specifically for Modbus RTU that takes into account the timing requirements for Modbus RTU. The Modbus RTU versions typically cost a bit more that the non-Modbus, generic 438-t0-ethernet versions. Moxa is known for industrial electronics so your model might or might not be a Modbus RTU version. Does your 'simple' Moxa IP-to-serial run a firmware version for Modbus RTU?

4. Sniffer mode text file

The first message in the accompanying sniffer mode text file might appear to be a valid Modbus message given the Checksum is reported as OK, the probabilities or a false CRC evaluation is small. BUT . . . .

[06/06/2021 20:48:43]
Modbus Response (COM4)
Address: 2
Function: 3 (0x03) - Read Holding Registers
Byte Count: 11
Values: b9 00 5a
Register0: 47360
Checksum: 5635(OK)

A. Where is the polling message, the request from the Master? Shouldn't a sniffer program show all the traffic, polls from Master, replies from the slave(s)?

B. The first message reports a slave address of 02. You tell us that the slave address should be Hex 37, which is not 02. ? ? ? ?

C. The byte count does not match the displayed data.

Any FC03 response/reply includes the number data bytes being returned to the master. The sniffer reports 11 bytes being returned, presumably decimal 11

- decimal 11 is an invalid 'odd' (not an even) number. Modbus 16 bit registers are composed of two 8 bit bytes, so any count of Holding registers must be an even number, some register quantity times 2.

- the displayed data b9 00 5a is only 3 bytes out of 11 ? ? ?

- the reported value for register 0, 47360 decimal is B900. The first reported two bytes of the 3 bytes that are displayed are B900. Why does the sniffer program show only a subset of the 11(?) bytes of data?

I'm just not sure the sniffer is decoding the messages properly.

If the sniffer is just not displaying all the data and can be trusted then consider that the 14-16 subsequent messages following the first message are invalid messages (bad CRC). Then the sequence repeated, one valid message, multiple invalid messages.

If the sniffer can be trusted then that first valid message followed by multiple invalid messages could very well point to timing faults where the first message is recognized because its start bit is correctly recognized but incorrect timing interpretation causes the start bit of the 2nd message to not be recognized properly resulting in all the following bits for all the following messages to be out-of-sequence with the result that all the following messages are corrupted.
Thank you very much for your elaborate dive into this. Much appreciated!

Some answers:

1) Its 9600, so not very fast. One thing which baffles me, is that they mention a start bit. I have not been able to set that in any of the software / Moxa box, that I've tested with.
1623053226384.png

2) The documentation (PDF file) is named "RS485 MODBUS protocol", so I assume it's MODBUS. The reason for me seeing communication on the bus is probably that the Wi-Fi module is connected to their cloud and forwards misc. information / status. I can also see when using the apps, that the amount of traffic increases. So maybe the Wi-Fi module is a master, and I need to remove it, for a second master (PC with misc. software) will work?

3) The Moxa converter does not a explicit support for MODBUS. The simple USB<>RS-485 dongle is started as supporting MODBUS.

4)
A) I assume it's the Wi-Fi gateway. Maybe it has the 02 address?
B) The documentation clearly states "Slave address: parameter:H37" which I read as 37 Hex.
C) I get a bit lost here. MODBUS is new to me, and I'm not familiar with the protocol to that level :(.
 
1. Please confirm that there is only one and only one RS-485 port on this heat pump.

2. Please confirm that the Wi-Fi access point is connected to a USB/485 dongle which is connected to the one and only one RS-485 port.

3. Please confirm that the heat pump is communicating via WiFi to something, somewhere, in some cloud. Is the communication continuous or do you initiate a communications session?

4. What is "Preferred Home Assistant"? What is supposed to do?

5. You're not supposed to 'see' the start bit. The apps like Putty or the sniffer program, spm user, 'see' a start bit and interprets the bit stream and report what the results are.
 
Just found a very similar hardware and manual: https://www.oasisheatpumps.com/pdf/2019_Oasis_Ci_Pool_Heat_Pump_inverter_manual.pdf

1) There are actually two RS-485 ports, both the display and Wi-Fi controller are connected to pins 29-32. I'm also connecting to these pins.

2) It's not an Access Point, but a RS-485 based Wi-Fi device which connects to my Wi-Fi. I can then use their (poor app) to view status & control temperature away from home. The wi-fi module looks very similar to these.

4) Home Assistant is a home automation platform, where I read & control a lot of stuff in my house. It has a modbus integration, but I couldn't get that to work either. My goal is to read out the different values, switch it on/off and control the setpoint.

My pool-pump runs a properitary protocol over RS-485 (Which I cannot decipher), but that's another story :)

I'll try to dump data without the Wi-Fi module to see if the communication differs.
 
I interpret "Slave address: parameter:H37" as the Modbus slave address is configured by changing parameter "H37". Does the heat pump have a display/menu that allows you to configure parameters?

If the heat pump does indeed communicate Modbus, then your theory that the WiFi gateway is the master is probably correct. You will need to disconnect the WiFi gateway in order to communicate with it using your USB to RS-485.

Try using one of the following Modbus master software tools with your USB to RS-485 adapter (you will, of course, first need to determine the heat pump's Modbus slave address, i.e. the value of parameter H37):
ModScan (https://www.win-tech.com/)
Simply Modbus (https://simplymodbus.ca/)
Modbus Poll (https://www.modbustools.com/download.html)
 
Just realized that the display is also a MODBUS device.. doh! So that's perhaps the other device communicating with the controller. I've removed the Wi-Fi device and will try your suggestions. Thanks for your input so far!
 
Jschulze beat me to it while I was reading your reply.

Yes, parameter H37 configures the "unit address", which may be the Modbus slave address. Presumably the parameters are entered via the keypad HMI on the heat pump.

Yes, you can check the Modbus ability with the Modbus master slave tools as long as no other device is on the same port.

If there are two RS-485 ports, either or both could be Modbus enabled, or one of them might not be Modbus enabled. Without documentation defining port functionality, you're left to experimenting with a Modbus master. The RULE is that a Modbus RTU network supports one and only one master.

On the screen shot in post 14, I suppose "current seeting temperature" at register (4)1013 is the setpoint?

It appears that the 16 bit Modbus register value for the temperatures will be tricky to interpret. It appears that the 8 bit low order byte is an integer temperature value and that the 8 bit high order byte includes DIGI1 through DIGI6 codes/bits that are the multiplier for the decimal integer value in the low order byte. If that's a correct interpretation, you'll have to do some bit-banging to interpret the temperature and setpoint values.
 
Jschulze beat me to it while I was reading your reply.

Yes, parameter H37 configures the "unit address", which may be the Modbus slave address. Presumably the parameters are entered via the keypad HMI on the heat pump.

Yes, you can check the Modbus ability with the Modbus master slave tools as long as no other device is on the same port.

If there are two RS-485 ports, either or both could be Modbus enabled, or one of them might not be Modbus enabled. Without documentation defining port functionality, you're left to experimenting with a Modbus master. The RULE is that a Modbus RTU network supports one and only one master.

On the screen shot in post 14, I suppose "current seeting temperature" at register (4)1013 is the setpoint?

It appears that the 16 bit Modbus register value for the temperatures will be tricky to interpret. It appears that the 8 bit low order byte is an integer temperature value and that the 8 bit high order byte includes DIGI1 through DIGI6 codes/bits that are the multiplier for the decimal integer value in the low order byte. If that's a correct interpretation, you'll have to do some bit-banging to interpret the temperature and setpoint values.
Thanks for your input. So I've now learned:
- H37 isn't the unit address itself, but rather holds the unit address (Steep learning curve!).
- A master exists, so whatever i add to the bus, must be a slave.
- 1013 +1014 are current temperatures (Don't quite understand why you add a (4) to it?)

The Simply Modbus Slave seems quite happy with some of the data (CRC ok, but not all). 1163 messages with are valid, 689 are not.

I'm also a bit unsure how to read the data (e.g. 1013). Is it a holding register, input register or ?
 
Top