-
-
Notifications
You must be signed in to change notification settings - Fork 34.5k
Description
The problem
I've recently switched my Keba integration from the internal integration (based on unreliable UDP protocol) to Modbus TCP. So far this is far more stable and controllable, as TCP is stateful protocol. One thing that bothers me (and others: https://community.home-assistant.io/t/modbus-sensors-unique-id-and-device-support/373428) is, that we create a "device" in yaml, under which we place binary_sensors, sensors, switches, ...
If you then look in Settings - Devices, it only lists the sensors as entities, but does not list the "main" device. It would be cumbersome to have some correction of this.
My config looks like this:
- name: KEBAP30
delay: 5
timeout: 5
type: tcp
host: 192.168.1.102 # your callbox IP address goes here
port: 502
sensors:
# Lesbare Sensoren
- name: KebaP30_charging_state
address: 1000
scan_interval: 30
data_type: uint32
unique_id: KebaP30_charging_state
- name: KebaP30_cable_state
address: 1004
scan_interval: 30
data_type: uint32
unique_id: KebaP30_cable_state
I would expect to see
- Device = KebaP30
- Sensor: sensor.KebaP30_charging_state
- Sensor: sensor.KebaP30_cable_state
I cannot fix this myself, but hope that you'll help the community and me.
Many thanks.
What version of Home Assistant Core has the issue?
core-2024.10.1
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Modbus
Link to integration documentation on our website
https://www.home-assistant.io/integrations/modbus
Diagnostics information
No response
Example YAML snippet
- name: KEBAP30
delay: 5
timeout: 5
type: tcp
host: 192.168.1.102 # your callbox IP address goes here
port: 502
sensors:
# Lesbare Sensoren
- name: KebaP30_charging_state
address: 1000
scan_interval: 30
data_type: uint32
unique_id: KebaP30_charging_state
- name: KebaP30_cable_state
address: 1004
scan_interval: 30
data_type: uint32
unique_id: KebaP30_cable_state
Anything in the logs that might be useful for us?
No response
Additional information
No response