Talk with "Saia PCD ALD1D5FD" energy meter

[jedie]

I have a "Saia PCD ALD1D5FD" energy meter and a RS485-USB-Adapter...

The energy meter docs are here: https://sbc-support.com/de/produkt-index/axx-energiezaehler/ald1-1-ph-modbus/

I set the address of the energy meter to 0x1 and tried this:

    client = ModbusSerialClient(
        port,
        baudrate=9600,
        bytesize=8,
        parity='N',
        stopbits=1,
        timeout=1,
    )
    print('connected:', client.connect())
    print(client)
    for address in range(5):
        print('try address:', hex(address))
        for slave_id in range(5):
            print(f'{slave_id=}')
            print('read_input_registers', client.read_input_registers(address=address, count=1, slave=slave_id))
            print('read_coils', client.read_coils(address=address, count=1, slave=slave_id))
            print('read_device_information', client.read_device_information(address=address, count=1, slave=slave_id))
    print(client.recv(128))
    client.close()

See: https://github.com/jedie/energymeter2mqtt/pull/1/files#diff-8e0abb9935b0f79b94d6d451a521d65e8f317a799a9a5e20eeea26ff1f7a6688R305-R323

But i get nothing:

In the end client.recv(128) raised a ConnectionException...

Think 9600 with 8N1 is correct.

What is the best approach to systematically tackle this and exclude errors!!?

[janiversen]

Run with debug.
Try if the framer is correct.
Study the doc more carefully.

[janiversen]

Try with different baudrate, why should 9.600 be the default.
try with the software the producer suggest.

[jedie]

I tried different baudrate/parity/stopbits and different framer. No response at all.

Maybe my RS485-USB-Adapter is just broken. lsusb list him as:

1a86:7523 QinHeng Electronics CH340 serial converter

I ordered a other stick and will retry, after arrive..

[janiversen]

and maybe your cabling is not correct, did you remember the terminating resistor.

[jedie]

No, i have no resistor applied. Is polarity important? (But i already switched them back and forth)

[janiversen]

Please read about rs485 cabling, it does not have polarity.

[git-developer]

I have the same problem with the same counter.

My setup:

• Digitus RS485 USB-Stick (FTDI chipset, Pins 485+, 485-, +5V, GND) <-> 0.5m Twisted pair cable <-> SBC ALD1D5FD00A3A00 counter
• Wire 1 from 485+ to D
• Wire 2 from 485- to D/
• 120 Ohm resistor from D to D/
• 120 Ohm resistor from 485+ to 485-
• 740 Ohm resistor from 485+ to +5V
• 740 Ohm resistor from 485- to GND
• Slave ID taken from LCD (1 for displayed text Adr 001)

I tried swapping A and B and different combinations of omitting the resistors. I tried different software configurations (baud rate, parity, stop bit). I tried changing the slave ID. I tried a different counter (same model).

The only thing I ever get is a timeout, no error code, no invalid data. I'm running out of ideas.

@jedie, did you actually solve your problem? Could you describe your cabling?

[janiversen]

You have a lot of resistors, that is not proper cabling. RS485 only uses one resistor (normally built into the device) at the end of the 2wires.

Did you try with a different framer, modbus serial support 3 different framers.

[git-developer]

Thanks for your quick response!

I now removed all resistors but one: 120 Ohm between D and D/ at the counter. Quote from the operating instructions):

The interface don’t have a terminal resistor, this must be provided external

My software setup is now based on jedie's project energymeter2mqtt which uses the ModbusRtuFramer. I changed it to ModbusBinaryFramer and ModbusAsciiFramer (leaving everything else untouched), but the behaviour is unchanged, timeouts as reported above by jedie.

Removing the resistor and swapping A and B has no effect.

I tried 3 different counters now (all of the same model), the same behavior.

The USB dongle is working fine when connected to a different device (SDM 120).

Any other hints?

[janiversen]

Did you try the different framers with a debug log, to verify the differences.

Did you confirm the serial settings, e.g. 9.600 is quite unusual.

Activate the pymodbus debug log, then you can better see what actually happens.

I cannot help you with the other project, make a simple version based directly on pymodbus. Please post the sample code.

[git-developer]

Did you try the different framers with a debug log, to verify the differences.

Yes. I can see in the log that the SEND values changes, e.g.:

• ModbusRtuFramer: SEND: 0x1e 0x4 0x0 0x0 0x0 0x1 0x33 0xa5
• ModbusBinaryFramer: SEND: 0x7b 0x1e 0x4 0x0 0x0 0x0 0x1 0x33 0xa5 0x7d
• ModbusAsciiFramer: SEND: 0x3a 0x31 0x45 0x30 0x34 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x31 0x44 0x44 0xd 0xa

Did you confirm the serial settings, e.g. 9.600 is quite unusual.

Yes. according to the manual, 4.800 - 115.200 is accepted (the counter device has auto-detection, so I unfortunately can't do anything else than try). I tried 9600 and 19200.

I cannot help you with the other project

I understand that. I created a small demo script to reproduce the problem (see down). The result is always [Input/Output] No Response received from the remote slave/Unable to decode response. The script uses slave id 30 (the counter show "Adr 030" on the display).

#!/usr/bin/env python3
#
# required modules: pymodbus 'pymodbus[serial]' ha_services
#

from ha_services.cli_tools.verbosity import OPTION_KWARGS_VERBOSE, setup_logging
from pymodbus.client import ModbusSerialClient
from pymodbus.framer.rtu_framer import ModbusRtuFramer
from pymodbus.framer.binary_framer import ModbusBinaryFramer
from pymodbus.framer.ascii_framer import ModbusAsciiFramer

def main():
    setup_logging(verbosity='DEBUG')
    client = ModbusSerialClient(
        port='/dev/ttyUSB0',
        baudrate=19200,
        bytesize=8,
        parity='E',
        stopbits=1,
        timeout=1,
        framer=ModbusRtuFramer
    )
    print('connected:', client.connect())
    print(client)
    for address in range(3):
        print('try address:', hex(address))
        for slave_id in range(30,31):
            print(f'{slave_id=}')
            print('read_input_registers', client.read_input_registers(address=address, count=1, slave=slave_id))
            print('read_holding_registers', client.read_holding_registers(address=address, count=1, slave=slave_id))
            print('read_device_information', client.read_device_information(address=address, count=1, slave=slave_id))
    print(client.recv(128))
    client.close()

main()

[janiversen]

Are you sure that your device accepts address 0-2 that sounds wrong.
And is the slave between 30-32 ?

client.recv() does not make sense, at least it's not supported.

Looking at the log it is clear that your device do not respond so this is not a pymodbus problem !

I think it is the first time I have heard a modbus device that automatically detect the baudrate, that is nearly impossible to implement due to the way RS485 timing works. All devices I know needs to be configured and surely your can be configured as well.

[janiversen]

and just fyi you do not start pymodbus debugging with a ha service ! we have a proper call, see documentation

Typically if you request something the device do not like, the rest of the communication is blocked.

[janiversen]

Are you sure that the device have input registers (bit relays, not values). I would have expected other client calls.

[git-developer]

And is the slave between 30-32 ?

The counter device has slave id 30 (it shows Adr 030 on its LCD).

Are you sure that your device accepts address 0-2 that sounds wrong.

In the device manual (PDF), the registers 1-40 are listed, so I expect registers with addresses 0 to 39 (0x00 to 0x27). 0 to 2 are firmware version, register count (40) and flag count (0).

[...] first time I have heard a modbus device that automatically detect the baudrate [...]

I kindly ask you to have a look at page 5 of the manual linked above, that's all I know about the device.

Are you sure that the device have input registers (bit relays, not values).

According to the manual above, only Read Holding Registers [03] are supported. Thus I chose read_holding_registers in the demo above. The call of read_input_registers is just a try to get at least an error message back from the device.

Typically if you request something the device do not like, the rest of the communication is blocked.

That would be bad, I hope to get one of the exception types ILLEGAL FUNCTION [01] or ILLEGAL DATA ADDRESS [02] listed in the manual. I will remove the read_input_registers call to be sure.

client.recv() does not make sense
do not start pymodbus debugging with a ha service

I will change that, thanks for the hints.

it is clear that your device do not respond so this is not a pymodbus problem

This is not a report of a pymodbus fault, sorry if you got this impression. I found this thread by searching for the the model ALD1D5FD. I'm using pymodbus to debug the problem without exactly knowing if it is caused by soft- or hardware. I tested 3 different devices of the same model now, different wires, cabling and resistors, using a USB dongle that works with different devices. Thanks to pymodbus I was able to change the framing, unfortunately without success.

I think it's unlikely that all my devices are broken; everything but the modbus part is working fine. I find it interesting that the thread author has the same problem with the same device model, so it may be a quirk of this device model or manufacturer.

Since I didn't find a solution or insight yet, I'm open for further ideas.

Thanks for your time and efforts to help out. I really appreciate that!

[janiversen]

I am here to support pymodbus, which as you say is not the problem, so I will leave this thread.

[git-developer]

I created a gist for the script and made the proposed changes.

[git-developer]

I found the cause for the problem and a solution. pymodbus is not part of the problem.

TLDR;

Cause: FTDI chipset of the USB stick

Solution

Cabling:

• Wire 1 from 485+ to D/, Wire 2 from 485- to D (reversed)
• 120 Ohm resistor from D to D/ (terminator)
• 750 Ohm resistors from 485+ to +5V and from 485- to GND (FTDI fix)

Serial settings:

• Baudrate: 2.400 - 115.200 baud (tested: 2400, 4800, 9600, 19200, 38400, 57600, 115200)
• Bits: 8N2, 8E2, 8O2, 8E1, 8O1 (i.e. anything but 8N1)
• Baudrate and parity are auto-detected. Detection requires 5-20 commands for training.

Details

I tried a different modbus software: e.g. pymodbus; mbpoll (Linux); modpoll, QModMaster, RMMS (Windows); iobroker; several Arduino-based projects. The behavior was always the same: No response.

Next try was to go one level deeper and send bytes to the serial device. I extracted a command from the pymodbus debug output: 1E 03 00 01 00 01 D7 A5, meaning: ask slave 30 (1E) for the holding register (03) with logical number 2 (00 01) and request 1 byte (00 01) as response. The trailing bytes (D7 A5) are the checksum of the command. According to the manual, this is a request for the number of supported registers and should always be 40.

I used HTerm (Windows) to talk directly to the serial device. Observations:

• Nothing connected to the USB stick => timeout
• (485+ <-> D) and (485- <-> D/) => timeout
• (485- <-> D) and (485+ <-> D/) => a single byte 00 is received
• (485- <-> D) and (485+ <-> D/) and slave device is turned off (power line physically disconnected) => a single byte 00 is received
• (485- <-> D) and (485+ <-> D/) and parameters 4800 8E2 => a response is received: 00 1E 03 02 00 28 2D 98 00
• (485- <-> D) and (485+ <-> D/) and different parameters => a single byte 00 is received

The response contains a proper answer from slave 30 (1E) for holding register (03) with logical number 3 (02) and decimal value 40 (28). But it has an unexpected leading and trailing zero byte (00). An unexpected byte is even received when the slave is turned off, so it must be related to the wires or the sender.

A web research revealed this user report in a forum:

The FTDI cables and modules produce a framing error and it receives a "0x00" charachter whenever you sent a byte or character out.

It also contains a statement from the chipset manufacturer FTDI:

Thanks for your informed feedback. FTDI designers have reviewed this comment and recommend adding 750ohm pull up on D+ and 750ohm pull down to GND to mask this issue. Alternative transceivers have been identified and will be considered in future design revisions.

After adding the resistors, the response 1E 03 02 00 28 2D 98 is received. So finally, we have a valid modbus-compatible response that is properly handled by modbus master software such as pymodbus.

Whenever the serial settings change, the device needs a few (5-20) commands to auto-detect the new settings.