It seems Home Remote does not always choose the right device ID to fetch the status (parent vs child)
For example, I added a light (should be 453) but Home Remote designer added 452 (which is the parent and has no status):
api.txt (6.8 KB)
This is intentional. This allows us to map multiple Capabilities onto a single Home Remote Device object. During a sync the app will choose, by default, a parent Id when possible because of this added flexibility. It may not make sense for some devices but this was necessary for thermostats & a few other devices. That parent-child relationships are stored in the JSON from the Fibaro controller. The Home Remote is smart enough to determine which child device it needs to use for the selected capability. You can certainly change the Ids if you want but that is unnecessary.
Well if it wasn’t necessary to change the ID I wouldn’t have posted here 
Default by Home Designer:
After correcting the ID:
I understand what you are saying, but it seems necessary to see what device we are talking about.
Your solution will work better for sensors I don’t think the same should be used for switches.
The device I mentioned in my OP has 2 actors so they need to be separate, the parent device has no status and therefore not usable for a tile.
Beamer:
No point in having the parent ID.
Would you mind posting or emailing me the entire JSON file? That’ll make it easier for me to hook up to my developer tools to test.
Just to clarify, yes, I will change it. But I need your JSON to help me test the changes I make.
Sure, sent
Can you please explain this statement?
From what I can see. 453 is the only real actor. It is the only visible device in the group.
I did find & fix the issue. Your 453 device is not listing “turnOn” & “turnOff” as valid actions. As you can see the “actions” are empty. The current child search tries to find a device that supports those 2 actions. That’s why it isn’t currently working. I made a change so that it’ll assume all devices of type “com.fibaro.binarySwitch” support these actions, even if they aren’t listed. In the next release you won’t have to change the id of 452 to 453. 452 will work.
I do get some of your concern about the scenario of a parent having multiple child switches. That is already accounted for. During a sync, if the app detects that a parent has multiple child switches, it will separate them & use the child Ids. That issue was fixed a while back.
I’m just not comfortable making a change to where the sync prefers the child Id for switches but not others. I’d like to keep everything consistent especially since there is ne real “need” for this change. I fought this for a while today but I just can’t pull the trigger. If I were to make this change, duplicate device objects would be created for all existing users when the sync. I don’t think they would like that.
And look at your device 715 “Zwembad: Verwarming”. That is another perfect example that demonstrates the benefits of using a parent Id for switches. This device has both binarySwitch & temperatureSensor devices. Wouldn’t you rather see these grouped onto a single object instead of 2?
I get your point though. That maybe the software is a little confusing because of these parent/child ids, but I just don’t see enough reason to change it right now. If it was breaking something, then yes, that would be reason to change it.
{
"id": 453,
"name": "Front door",
"roomID": 364,
"view": [
{
"assetsPath": "/dynamic-plugins/com.fibaro.binarySwitch/assets",
"jsPath": "/dynamic-plugins/com.fibaro.binarySwitch",
"name": "com.fibaro.binarySwitch",
"translatesPath": "/dynamic-plugins/com.fibaro.binarySwitch/i18n",
"type": "ts"
}
],
"type": "com.fibaro.binarySwitch",
"baseType": "com.fibaro.actor",
"enabled": true,
"visible": true,
"isPlugin": false,
"parentId": 452,
"viewXml": false,
"configXml": false,
"interfaces": [
"deviceGrouping",
"fibaroFirmwareUpdate",
"light",
"zwave",
"zwaveMultiChannelAssociation"
],
"properties": {
"pollingTimeSec": 0,
"zwaveCompany": "Fibargroup",
"zwaveInfo": "3,3,52",
"zwaveVersion": "2.2",
"categories": [
"lights"
],
"configured": true,
"dead": false,
"deadReason": "",
"deviceControlType": 2,
"deviceGroup": [],
"deviceGroupMaster": 0,
"deviceIcon": 1010,
"emailNotificationID": 0,
"emailNotificationType": 0,
"endPointId": 0,
"firmwareUpdate": {
"info": "",
"progress": 0,
"status": "UpToDate",
"updateVersion": "2.2"
},
"isLight": true,
"log": "",
"logTemp": "",
"manufacturer": "",
"markAsDead": true,
"model": "",
"nodeId": 28,
"parametersTemplate": 357,
"productInfo": "1,15,2,2,16,2,2,2",
"pushNotificationID": 0,
"pushNotificationType": 0,
"remoteGatewayId": 0,
"saveLogs": true,
"serialNumber": "",
"smsNotificationID": 0,
"smsNotificationType": 0,
"state": true,
"updateVersion": "",
"useTemplate": true,
"userDescription": "",
"value": true
},
"actions": {},
"created": 1605352321,
"modified": 1605352321,
"sortOrder": 49
I did not even know that device had a temperature sensor 
I see what you mean, an idea is maybe check if the device is of type “type”: “com.fibaro.zwaveDevice”,
If that is true and it has more than one actor -> split, if not not -> combine
What do you think?
In regards to the “zwembad” device, it would depend if the sensor is more for the load temperature or ambient temperature… (device can switch up to 90A)
Maybe you could have a field where you can put in comma seperated device id’s that the user wants split?
That’s because the secondary is not used at this point, nothing is connected to it.
Device 454 is the other, unused, actor.
If you were to hook up 454, wouldn’t they both 453 & 454 turn on the same light?
In other words, wouldn’t the state for 453 & 454 always match?
From the app’s perspective, it wouldn’t really matter which actor it chooses, 453 or 454 since they are controlling the same light.
What I have right now is a check on the child device types. If multiple visible children exist that all share the same type, they are going to be split. That same logic is shared by switches & all other types.
If you were to attach 454 after you did the initial sync, that would obviously not be good because now we have a scenario where that child search will have multiple valid choices.
Maybe it will be better to always use the child Id for switches. I’d like to learn a little bit more about how this 454 “secondary” device will work if you were to connect one. Can it control a different light?
These are physically 2 different switches with each it’s own state.
It’s a module with 2 relays that can draw 1.5kW each and costs as much as module with 1 relay that can draw 2.5kW. For that reason I buy the ones with 2 relays as the devices that require that much power and need to be switch by Fibaro are few. This does mean of course that some secondary relays are not used and set to invisible.
Thanks for the explanation. That does clear things up. I do think I need to make another change then. That rule I have that only looks at the “visible” children when determining whether it should split the devices, needs to look at all children. Not just the visible ones. In the next release, when you do a sync, it’ll assign 453 as the id.
Your 715 “zwembad” device only has 1 child switch so we won’t have to worry about splitting that up. That can stay on the parent as it currently is.