kingsleyadam
commented
1 month ago If you click into the switch or event sensor entity, what does the entity ID look like?
Closed derjoerg closed 1 month ago
kingsleyadam
commented
1 month ago If you click into the switch or event sensor entity, what does the entity ID look like?
derjoerg
commented
1 month ago 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
commented
1 month ago 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
commented
1 month ago 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"
}
}
}
}
}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
commented
1 month ago 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:
I would propose two modifications:
kingsleyadam
commented
1 month ago 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
commented
1 month ago 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
commented
1 month ago 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
commented
1 month ago 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.
kingsleyadam
commented
1 month ago @derjoerg , I did a quick test against my setup, if I exclude channels not assigned to the floor plan I would be excluding 3 SwitchActuator channels. These are ones that I disassociated with a physical switch, but I'd still like to have them made available in Home Assistant. The corresponding Device is still associated with the floor plan.
I then tested against devices (not functions/channels) not assigned the floor plan and I would be excluding a single SwitchSensor device, I believe this is exactly the same type of device that you have.
With that in mind, I think it's best to target devices that are not associated with a floor plan and exclude them. But keep any channels that are not associated with a floor plan.
Let me know if that would work for your setup.
kingsleyadam
commented
1 month ago @derjoerg , I did a quick test against my setup, if I exclude channels not assigned to the floor plan I would be excluding 3 SwitchActuator channels. These are ones that I disassociated with a physical switch, but I'd still like to have them made available in Home Assistant. The corresponding Device is still associated with the floor plan.
I then tested against devices (not functions/channels) not assigned the floor plan and I would be excluding a single SwitchSensor device, I believe this is exactly the same type of device that you have.
With that in mind, I think it's best to target devices that are not associated with a floor plan and exclude them. But keep any channels that are not associated with a floor plan.
Let me know if that would work for your setup.
This brings me back to my original thought the first time around. If you have an actuator and switch sensor not associated with the floor plan this change would remove it from Home Assistant. Even though it's a physical actuator, now a user wouldn't be able to control it via Home Assistant. Is that ok? It's tough to say, not sure how often that scenario comes up.
derjoerg
commented
1 month ago I think I'm a bit lost here. I have a 2-rocker device. This device is, as it is a physical device, located in a specific room. But as I have no usage for it as of now it is not paired to any light or switch or ... The config-output looks like this
"ABB700DAD641": {
"deviceReboots": "51",
"floor": "02",
"room": "07",
"interface": "TP",
"deviceId": "1002",
"displayName": "Sensoreinheit 2-fach Markise ",
"unresponsive": false,
"unresponsiveCounter": 0,
"defect": false,
"channels": {
"ch0000": {
"floor": "02",
"room": "07",
"displayName": "Sensoreinheit 2-fach Markise ",
"selectedIcon": "1e",
"functionID": "0",
"inputs": {
"idp0000": {
"pairingID": 256,
"value": "0"
},
"idp0001": {
"pairingID": 18,
"value": "0"
},
"idp0002": {
"pairingID": 273,
"value": "0"
},
"idp0004": {
"pairingID": 261,
"value": "0"
},
"idp0005": {
"pairingID": 278,
"value": "0"
}
},
"outputs": {
"odp0000": {
"pairingID": 1,
"value": "1"
},
"odp0006": {
"pairingID": 4,
"value": "0"
}
},
"parameters": {
"par0002": "50",
"par0001": "50",
"par0007": "1"
}
},
"ch0003": {
"floor": "02",
"room": "07",
"displayName": "Sensoreinheit 2-fach Markise ",
"selectedIcon": "1e",
"functionID": "0",
"inputs": {
"idp0000": {
"pairingID": 256,
"value": "0"
},
"idp0001": {
"pairingID": 18,
"value": "0"
},
"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"
}
}
},
"parameters": {
"par000c": "1"
}
},This device, with the channels, should be included in HA for sure (the channels are assigned to a floorplan). Your recent changes look good with the channel_id in brackets. I would just include the channel_id also in the entity_id because as of now I still have "...switch_sensor" and "... switch_sensor_2".
A totally different "beast" are the other devices I'm talking about and which are installed in the central "fuse-box". Such a device has no room and floor at all. Only the channels are associated to a floorplan (or not). Here is the config-output (only for the sensor-channels, I removed the actuator-channels):
"ABB28CBC3651": {
"interface": "TP",
"deviceId": "B008",
"displayName": "Sensor/switch actuator, 8/8gang, MDRC",
"unresponsive": false,
"unresponsiveCounter": 0,
"defect": false,
"channels": {
"ch0000": {
"floor": "02",
"room": "0A",
"displayName": "Bad ",
"selectedIcon": "51",
"functionID": "f",
"inputs": {},
"outputs": {
"odp000c": {
"pairingID": 53,
"value": "0"
}
},
"parameters": {
"par0010": "2"
}
},
"ch0001": {
"floor": "02",
"room": "07",
"displayName": "K\u00fcche rechts ",
"selectedIcon": "51",
"functionID": "f",
"inputs": {},
"outputs": {
"odp000c": {
"pairingID": 53,
"value": "0"
}
},
"parameters": {
"par0010": "2"
}
},
"ch0002": {
"floor": "02",
"room": "05",
"displayName": "B\u00fcro links ",
"selectedIcon": "51",
"functionID": "f",
"inputs": {},
"outputs": {
"odp000c": {
"pairingID": 53,
"value": "0"
}
},
"parameters": {
"par0010": "2"
}
},
"ch0003": {
"floor": "02",
"room": "0B",
"displayName": "Haust\u00fcr",
"selectedIcon": "51",
"functionID": "f",
"inputs": {},
"outputs": {
"odp000c": {
"pairingID": 53,
"value": "0"
}
},
"parameters": {
"par0010": "2"
}
},
"ch0004": {
"floor": "03",
"room": "03",
"displayName": "Bad ",
"selectedIcon": "51",
"functionID": "f",
"inputs": {},
"outputs": {
"odp000c": {
"pairingID": 53,
"value": "1"
}
},
"parameters": {
"par0010": "2"
}
},
"ch0005": {
"floor": "03",
"room": "02",
"displayName": "K\u00fcche ",
"selectedIcon": "51",
"functionID": "f",
"inputs": {},
"outputs": {
"odp000c": {
"pairingID": 53,
"value": "0"
}
},
"parameters": {
"par0010": "2"
}
},
"ch0006": {
"displayName": "\u24d6",
"selectedIcon": "1e",
"functionID": "0",
"inputs": {
"idp0000": {
"pairingID": 256,
"value": "0"
}
},
"outputs": {
"odp0000": {
"pairingID": 1,
"value": "0"
}
},
"parameters": {
"par0010": "1",
"par0043": "1"
}
},
"ch0007": {
"displayName": "\u24d7",
"selectedIcon": "1e",
"functionID": "0",
"inputs": {
"idp0000": {
"pairingID": 256,
"value": "0"
}
},
"outputs": {
"odp0000": {
"pairingID": 1,
"value": "0"
}
},
"parameters": {
"par0010": "1",
"par0043": "1"
}
},As you see, the first 6 channels are assigned to a floorplan and even have their own names. The last two channels are not used and not assigned to a floorplan. So I can't even control them through through the F@H UI. From my perspective these last two channels (not assigned to a floorplan) should not be added to HA.
At the end :smile: this is really a minor issue (as long as the naming and the entity_id is correctly set). We now already talk about that for two days !!! We can also leave it as it is and e.g. I can just disable or hide the unused entities and/or events in HA.
kingsleyadam
commented
1 month ago Since the entities have already been added to your system the entity id won't change. If you remove the integration and re-add they'll get the new entity id with the channel id included.
On the second note, I think what I'll do is expose adding the orphan channels as a configuration option. By default it'll be false. If people seem to want those channels they can update their configuration and they'll appear.
I'm also adding in the ability to "reconfigure" the integration so they can update this (along with username/password) without having to delete and re-add they'll integration.
derjoerg
commented
1 month ago Since the entities have already been added to your system the entity id won't change. If you remove the integration and re-add they'll get the new entity id with the channel id included.
Perfect, working
On the second note, I think what I'll do is expose adding the orphan channels as a configuration option. By default it'll be false. If people seem to want those channels they can update their configuration and they'll appear.
Sounds great
I'm also adding in the ability to "reconfigure" the integration so they can update this (along with username/password) without having to delete and re-add they'll integration.
Cool
kingsleyadam
commented
1 month ago I've opened two new issues to cover the channel filter. The switch event and switch sensors have been renamed. I'll close this one out.
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.