Better naming for switch sensors and switch events

[derjoerg]

Hi,

would it be possible to use the F@H namings for the switch sensors and switch events. The current generic naming makes it hard to correlate everything together.

[kingsleyadam]

If you click into the switch or event sensor entity, what does the entity ID look like?

[derjoerg]

binary_sensor.sensor_switch_actuator_8_8gang_mdrc_switch_sensor binary_sensor.sensor_switch_actuator_8_8gang_mdrc_switch_sensor_2 event.sensor_switch_actuator_8_8gang_mdrc_switch_event event.sensor_switch_actuator_8_8gang_mdrc_switch_event_2

[kingsleyadam]

Got it, I should just remove the translation text and rely on channel name. Looks like it's taking the device name as entity id which we won't really want. I think I know what needs to be done here.

[kingsleyadam]

Can you share your device config for this one?

For me, the local api is returning the Device Name for each sensor instead of the sensor name I've labeled it in Free@Home. So using the channel name wouldn't help us much if that's the case. But I want to double check what you have. We'd have no way to know for sure which "sister" channel these sensors are for.

The only thing that makes mine unique between the two is the channel id (e.g. ch0000), we could append that to the name but that won't make much sense to end users, but at least it makes each one unique? The only way to know would be to test each sensor and manually update the name in HA accordingly.

Here's mine. You can see for both my sensors I'm getting Guest Bathoom Rocker, which is just the name of the device. In Free@Home I have them labeled "Left Rocker" and "Right Rocker".

{
  "00000000-0000-0000-0000-000000000000": {
    "devices": {
      "ABB7F62F5275": {
        "deviceReboots": "30",
        "floor": "04",
        "room": "10",
        "interface": "TP",
        "deviceId": "9110",
        "displayName": "Guest Bathroom Rocker",
        "unresponsive": false,
        "unresponsiveCounter": 0,
        "defect": false,
        "channels": {
          "ch0000": {
            "floor": "04",
            "room": "10",
            "displayName": "Guest Bathroom Rocker",
            "functionID": "0",
            "inputs": {
              "idp0000": {
                "pairingID": 256,
                "value": "0"
              },
              "idp0001": {
                "pairingID": 18,
                "value": "1"
              },
              "idp0002": {
                "pairingID": 273,
                "value": "0"
              },
              "idp0004": {
                "pairingID": 261,
                "value": "0"
              },
              "idp0005": {
                "pairingID": 278,
                "value": "0"
              }
            },
            "outputs": {
              "odp0000": {
                "pairingID": 1,
                "value": "0"
              },
              "odp0006": {
                "pairingID": 4,
                "value": "0"
              }
            },
            "parameters": {
              "par0002": "50",
              "par0001": "50",
              "par0007": "1"
            }
          },
          "ch0003": {
            "floor": "04",
            "room": "10",
            "displayName": "Guest Bathroom Rocker",
            "functionID": "0",
            "inputs": {
              "idp0000": {
                "pairingID": 256,
                "value": "0"
              },
              "idp0001": {
                "pairingID": 18,
                "value": "1"
              },
              "idp0002": {
                "pairingID": 273,
                "value": "0"
              },
              "idp0004": {
                "pairingID": 261,
                "value": "0"
              },
              "idp0005": {
                "pairingID": 278,
                "value": "0"
              }
            },
            "outputs": {
              "odp0000": {
                "pairingID": 1,
                "value": "0"
              },
              "odp0006": {
                "pairingID": 4,
                "value": "0"
              }
            },
            "parameters": {
              "par0002": "50",
              "par0001": "50",
              "par0007": "1"
            }
          },
          "ch0006": {
            "floor": "04",
            "room": "10",
            "displayName": "BK",
            "selectedIcon": "01",
            "functionID": "7",
            "inputs": {
              "idp0000": {
                "pairingID": 1,
                "value": "0"
              },
              "idp0001": {
                "pairingID": 2,
                "value": "0"
              },
              "idp0002": {
                "pairingID": 3,
                "value": "0"
              },
              "idp0003": {
                "pairingID": 4,
                "value": "1"
              },
              "idp0004": {
                "pairingID": 6,
                "value": "0"
              }
            },
            "outputs": {
              "odp0000": {
                "pairingID": 256,
                "value": "0"
              },
              "odp0001": {
                "pairingID": 257,
                "value": "0"
              }
            },
            "parameters": {
              "par0015": "360",
              "par0014": "1"
            }
          },
          "ch0007": {
            "floor": "04",
            "room": "10",
            "displayName": "BK",
            "selectedIcon": "1",
            "functionID": "7",
            "inputs": {
              "idp0000": {
                "pairingID": 1,
                "value": "0"
              },
              "idp0001": {
                "pairingID": 2,
                "value": "0"
              },
              "idp0002": {
                "pairingID": 3,
                "value": "0"
              },
              "idp0003": {
                "pairingID": 4,
                "value": "1"
              },
              "idp0004": {
                "pairingID": 6,
                "value": "0"
              }
            },
            "outputs": {
              "odp0000": {
                "pairingID": 256,
                "value": "0"
              },
              "odp0001": {
                "pairingID": 257,
                "value": "0"
              }
            },
            "parameters": {
              "par0015": "360",
              "par0014": "1"
            }
          }
        },
        "parameters": {
          "par000c": "1"
        }
      }
    }
  }
}

[kingsleyadam]

Here's what it looks like for me when I append the channel_id to the name. This may be the best we can do.

[derjoerg]

OK, so it took me a moment to find out what's going on here. You are absolutely right with physical rockers, they behave exactly for me like for you (it doesn't matter how the left and the right rocker is labeled, in the config-output they are named exactly like the device name so the only meaningful addition would be the channel-name and the end-user needs to make a meaningful renaming). But the device I showed at the top is a different one. It is installed in the central fuse-box and provides 8 actuators and 8 sensors. In my case the 8 sensors are setup the following way:

• 6 of them are configured as "windows door sensors" [FID_WINDOW_DOOR_SENSOR] - each with a dedicated name also in the config-output (as this is not yet included in the component, they are not shown in HA)
• 2 of them are unconfigured (they are not assigned to a room), so it looks like they are reported with FID_SWITCH_SENSOR and as display-name they have these strange character-in-a-circle

I would propose two modifications:

1. As you suggested, I would add the channel_id to the switch-sensors of a device
2. If I remember correctly we already wrote about that, but again, I would exclude all channels, which are not assigned to a room. Such channels are not usable in F@H and even that they can be controlled and respectively the state can be retrieved through the Rest-API, F@H should have the lead, which means, not-usable.

[kingsleyadam]

In your testing (because there's no documentation to support this), a device is unusable if it's not on the floor plan? I did do some testing myself and it does seem like the outgoing parings are disabled in the ABB interface if there's no position. I'm just slightly hesitant because it seems logical that a device is still usable even if there's no position.

We can adjust the naming logic for different types of sensors. It seems like Window sensors will get their own channel in the config? If so we can ensure when those are added the channel name gets used. My movement detector on the other hand acts similar to the switch sensor in that the brightness and movement do not get their own channel name and instead get the device name. This is most likely because the API doesn't expose the name for each individual pairing id (sensor) and instead expose it for the channel which can have multiple pairing.

[derjoerg]

In your testing (because there's no documentation to support this), a device is unusable if it's not on the floor plan? I did do some testing myself and it does seem like the outgoing parings are disabled in the ABB interface if there's no position. I'm just slightly hesitant because it seems logical that a device is still usable even if there's no position.

At some point - I think - we need to stop to try to get the logic behind the F@H rest-API 😄 The following picture shows a sensor in the F@H-webGUI without a room: I have no configuration option at all

And here as soon as I add a room to the sensor I can fully configure and use it

We can adjust the naming logic for different types of sensors. It seems like Window sensors will get their own channel in the config? If so we can ensure when those are added the channel name gets used. My movement detector on the other hand acts similar to the switch sensor in that the brightness and movement do not get their own channel name and instead get the device name. This is most likely because the API doesn't expose the name for each individual pairing id (sensor) and instead expose it for the channel which can have multiple pairing.

That is also my analysis: A device in F@H is a device in HA. A device in F@H can have one to multiple channels. Easily said, a channel in F@H is an entity in HA. With a very strict approach this would mean e.g. for the MovementDetector, that it has a state (movement) and everything else (e.g. the brightness) would be an additional attribute in HA (and the user in HA would be responsible with a template sensor to make an own entity out of the brightness [if wanted]). But this is - as stated - a very strict approach and and doesn't needs to be handled that hard :smiley: In general (!!!) each device has a name and each channel has an individual name and the entities in HA should reflect the channel-name. BUT (and now comes the "logic" from F@H) for whatever reason rockers - even that you can add individual channel names in the F@H-webGUI - have in the config-output for the channels the same name as the device.

From my point of view - especially for rockers - it is OK to just add the channel-id to the naming and let the end-user do a proper renaming. The naming of the device should point someone to the right rocker and then you just need to do two presses to find out the correct pairing.

Perhaps as a general rule: If the channel-name is different to the device-name use the channel-name. If the channel-name equals the device-name use the channel-name + the channel-id? And if you want to expose additional info of a channel as dedicated entity instead of an attribute then just use the above rule + a dedicated naming (e.g. _brightness)?

[kingsleyadam]

That sounds good, I do think we can use some discretion when it comes to naming additional entities for a device. For a movement detector device/actuator, I wouldn't expect it to have more than 1 Brightness or Movement pairings, in those cases we should be relatively "safe" to just a translations e.g. Movement, Illuminance.

In the case of these switch sensors it's possible to have more than 1 pairings because of multiple switches. In those cases we can append the channel id just to ensure uniqueness.

I'll mess around with excluding devices without a floor plan association.

[kingsleyadam]

I just pushed a new version that'll adjust the names for SwitchSensor events and sensors. This should make it easier when adding door sensors to allow it to "fallback" to the channel name if no translation is given.