Modbus register type ends up wrong

So I’m trying to get modbus working over an RTU/TCP bridge. The bridge and slave device are verified working using other software. HA gives me unavailable and log says IO error no response received.
Next step i tried a simulated slave using ModbusView to verify what actually happens. And what happens is that HA requests a coil register, while the actual register is of type holding. Input_type is specified as holding, yet coil is requested. I have read register_type in documentation and forum posts but that gives errors.
Code below.

- name: MBTCP1
  #  close_comm_on_error: true
  delay: 2
  timeout: 2
  type: rtuovertcp
  host: 172.17.32.11
  port: 502
  retries: 3
  sensors:
    - name: "Grid_L1_U"
      unique_id: 101
      scan_interval: 10
      slave: 1
      address: 8196
      state_class: measurement
      unit_of_measurement: "V"
      input_type: holding
      data_type: uint16
      scale: 1
      precision: 1

I am certainly no expert in HA Modbus, and I do most of my Modbus work in Node-RED, however I have recently started experimenting with the various HA settings for Modbus over TCP, like you using a test slave running on my PC. This allows quick and easy testing and also provides a monitor of the Modbus commands sent and received.

As an experiment I loaded your code into my config file - the Modbus server settings to match my test slave (type ‘tcp’) but keeping your sensor code ‘as is’. I can report that it all works. Function code 3, with an entity ‘Grid_L1_U’ and a correct value read from my test slave.

Your file extract shown above suggests your code is in an include file. Includes can be problematic if they result in an incorrect insertion at the wrong level, incorrect indentation, or under the wrong higher level item. Perhaps HA Modbus is somehow seeing your sensor as a binary type - have you tried running this, like me, within your primary configuration file?

If it still does not work it would suggest a difference between type ‘tcp’ and ‘rtuovertcp’, which I am unable to test.

HA appears to generate the (default & allowed) Modbus register type based on the top level settings, so for binary sensors and things like switches and binary covers, register type is ‘coil’ by default. For coils, it is possible to change the ‘input_type’ to ‘discrete_input’. There is also a ‘write_type’ for changing the default write register in more complex situations where, say, a binary device is being controlled by holding registers rather than coils.

For verification of a binary device (additional read after write) the default for reading back is the read register setting, default ‘coil’. It is possible to add register_type as ‘holding’ but I believe this only applies as a sub-option for the verification option. Exactly what options are available appears to depend on both the basic sensor type and where the option is being added, which I guess is why you are getting errors if you try to add “register_type” (rather than ‘input_type’) to something/somewhere that is not expecting it.

Yes the code is in an include. My entire configuration.yaml down below.
I have tried it in the primary conf, with the result that i get no read attempts at all, just a tcp connection.
I have tried both tcp and rtuovertcp. The former gets no connection at all, the latter gets the error discussed.
Would you mind pasting your working example so i can try and work from there?
I had some SNMP stuff in there but i tried it blank like this as well with the same result.

# Loads default set of integrations. Do not remove.
default_config:

# Text to speech
tts:
  - platform: google_translate

automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
modbus: !include modbus.yaml

I do not know what i did. But now it works. Everything i did now i had tried before, but obviously in some other variation.
I have tried commenting out close_comm_on_error again and it works. I had tried tcp instead of rtuovertcp before. No idea, but now i can finally go on. Maybe some more sharp eyed person than i can figure it out. And to be clear, the host IPs differ between posts. 11 is the test host and 201 is the real one.

- name: MBTCP1
  close_comm_on_error: true
  delay: 2
  timeout: 2
  type: tcp
  host: 172.17.32.201
  port: 502
  retries: 3
  sensors:
    - name: "Grid_L1_U"
      unique_id: 101
      scan_interval: 5
      slave: 1
      address: 8195
      input_type: holding
      state_class: measurement
      unit_of_measurement: "V"
      data_type: uint16
      scale: 1
      precision: 0
      device_class: voltage
    - name: "Grid_L2_U"
      unique_id: 102
      scan_interval: 5
      slave: 1
      address: 8196
      input_type: holding
      state_class: measurement
      unit_of_measurement: "V"
      data_type: uint16
      scale: 1
      precision: 0
      device_class: voltage
    - name: "Grid_L3_U"
      unique_id: 103
      scan_interval: 5
      slave: 1
      address: 8197
      input_type: holding
      state_class: measurement
      unit_of_measurement: "V"
      data_type: uint16
      scale: 1
      precision: 0
      device_class: voltage