Struggling to write multiple registers to modbus

scratching my head and trying to get this to work. Have modbus connectivity, quite some experience with reading modbus data, but never had tried to write something back.
Using eshome 2024.11.2, trying to control MasterPact MTZ mains switch.
This is the command I try to achieve - basically sending values to 8000 and subsequent registers.
image

I understand I need to use function code 16.
Wonder can it be done nicely with a switch component?
Or is there a way to send directly the serial string/package to modbus uart?
“01 10 1f 40 00 06 0c 03 88 00 0a 11 01 00 01 12 f0 12 fo 1e 78”

Appreciate any hint or direction. Thank You so much!

I would try with custom command, just leave it without crc.

1 Like

getting closer

      - lambda: |-
          esphome::modbus_controller::ModbusController *controller = id(modbus);

          // Create the payload with the values to send
          std::vector<uint16_t> payload = {904, 10, 4353, 1, 0x3030,0x3030};

          // Write both values (904 and 10) to registers 0x1F3F and 0x1F40
          esphome::modbus_controller::ModbusCommandItem write_multiple_command = esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(controller, 0x1F3F, 6, payload);
controller->queue_command(write_multiple_command);

Can read the registers back and see values populated … only the last two - for password - looks suspicous :frowning:
image

By documentation it should be 0x30303030 … trying to send the 0x3030 twice … or is it normal that it’s reading back in decimal representation?
image

I don’t follow now… 0x3030 is 12336 so what’s wrong?

wrong - that the damn thing is accepting the values … but not doing anything :smiley:
And then I got confused by that user manual description
|OCTEC STRING|0000=0x30303030| and seeing 12336 on screen … though chatg friend is also saying hex 0x3030 is decimal 12336 (I’ve always been bad w base conversions :cry:).

In few days will get back to the device and check what it is giving back if sending wrong password. Meanwhile also learned the registers for execution status codes.

Last but not least, might be I need to have 4609 and not 4353 in 8001 … found both mentioned in the documentation, but away from the device. At least that gives a hope :slight_smile:

might be it’s all been down to a shady document link. Got referred to one on schnieder site … yet another destination code (but here it’s been used consistently across the document). Will have something to try. Thank you for the initial hint/direction, Karosm!
https://www.productinfo.schneider-electric.com/mtz_modbus_communication/doca0105-masterpact-mtz-modbus-communication/English/DOCA0105EN-10.pdf#page42

all good with the esphome and modbus custom command. Receiving status code 0 back (and different codes if doing w wrong password or wrong command address). Must be some “enable remote operation” config on the switch. Will keep digging :exploding_head:

      - lambda: |-
          esphome::modbus_controller::ModbusController *controller = id(modbus);

          std::vector<uint16_t> payload = {905, 10, 5377, 1, 0x3030,0x3030};
          esphome::modbus_controller::ModbusCommandItem write_multiple_command =
              esphome::modbus_controller::ModbusCommandItem::create_write_multiple_command(controller, 0x1F3F, 6, payload);
          controller->queue_command(write_multiple_command);

I don’t know your device, but in standard modbus protocol successful response for function code 16 is just:
slave address : function code : start address : quantity : CRC
8 bytes, it doesn’t include the values you “wrote” to registers.

you are righyt here that’s the case as well.
I am “reading” the values back as I have them configured in the esphome yaml for display purposes.

Receiving the code back - was meant for reading the command status register (once command has finished). Have reached out to manufacturer to figure out what’s wrong. As if there was some configured protection - then the device typically is responding with the proper code. In my case it responds with Command status code=0 as for success … but does not do anything. Will see what they say.
image