Modbus integration stuck between incomplete and overly specific

Feature Requests
1

I just thought I’d give modbus TCP a whirl to talk to a go-E Wallbox today. It works surprisingly well, but I noticed a lot of oddities such as there not being any way to have a generic component that is able to read and set values (aside from a “switch” for binary values) on the other hand there’s an awful lot of very specific components which don’t really seem to belong into a modbus interface (like fans, lights, etc.). I’ve checked a few other specific implementations building on modbus which are basically redefining such numeric controls constantly.

Wouldn’t it make sense to move the overly specific stuff into a dedicated module and add a generic numeric control to modbus directly? As it stands I will have to develop my own implementation, duplicating stuff from other integrations, although I’m otherwise totally fine to simply add support for my wallbox to configuration.yaml, which makes me a bit sad.

Of course I could implement custom controls in my dashboard and use the modbus services to achieve some interaction with the wallbox but that seems super meh to me.

2

Sensor is a generic read. Use home_assistant.update_entity to get an immediate read.

Modbus has 2 generic services modbus.write_register, and modbus.write_coil.

Are you asking for a number entity? If yes, then modbus is missing that. But you can make a modbus sensor in combination with write_coil/register to make a template number.

3

Yes, but the important bit from my post was the “and” betweeen read and set. Reading itself works just fine and I can use the values from the configured entity directly in my dashboard.

Yes, that’s what I’m asking for. I’m totally aware I can write my own components and use them, however that’s a lot of effort and essentially a one-off one, too. So far I’ve been able to do all of my “integration” via configuration only, however for the wallbox that means it’s pretty much read-only except for the few binary switches.

If I have to chose between spending many hours to write my own integration and figuring out how to actually get it into my HA container and being restricted to mostly read-only on the dashboard with the rest being available in a dedicated app – I don’t even need to check my calendar to know what I’m doing…

I just found it weird that modbus has a distinct lack in universal properties but then offers some super specific ones for HVACs and what not which may or may not even work with all HVACs since every vendor pretty much does their own thing…

4

… you don’t have to write your own integration. Make a modbus sensor and make a template number.

modbus:

  - type: tcp
    host: IP_ADDRESS_1
    port: 2020
    name: "modbus_hub"
    sensors:
      - name: sensor1
        address: 600

template:
- number:
  - name: sensor1
    state: "{{ states('sensor.sensor1') }}"
    set_value:
    - service: modbus.write_register
      data:
        ....
5

Thank you so much for this pointer. Yesterday I had a few hours (which were quite needed!) to kill so I looked into it. With a bit of tinkering and after watching a few videos I found out where to put this config (has to be configuration.yaml, not sensors.yaml as a video suggested), that it requires a restart and how to correctly configure the number sensor (no examples to be found anywhere) with the modbus.write_register service (which is quite picky).

So this is part of the working configuration now:

template:                                                           
- number:                                                           
  - name: go_e Vorgabe Ladestromstaerke                             
    state: "{{ states('sensor.go_e_vorgabe_ladestrom') }}"          
    step: 1                                                         
    min: 10                                                         
    max: "{{ states('sensor.go_e_maximaler_ladestrom') | int(16) }}"
    set_value:                                         
    - service: modbus.write_register                   
      data:                                            
        hub: go_e                                      
        address: 299                                   
        slave: 1                                       
        value: "{{ value }}"

It still would be nice if that was possible with the modbus configuration itself, rather than having to use a template.