Running context for child devices + startup function

I would like to create a new device for the Sonos plugin that would have usual Sonos device as children.
I was able to do it but it looks like the startup function of the Sonos device is not called as soon as it is child of another device. The startup function of the parent device is of course called.

Does it mean that the devices have not their own running environment as soon as they are child of another device ?
And does it mean that there is a unique running environment for the parent device and all his child devices ?

Last question: does it mean that it is not possible to have child devices living their live as if they have no parent ?

PS: my aim was only to have a parent device to manage device creation/suppression, not to handle the behaviour of each child device.

[quote=“lolodomo, post:1, topic:174584”]I would like to create a new device for the Sonos plugin that would have usual Sonos device as children.
I was able to do it but it looks like the startup function of the Sonos device is not called as soon as it is child of another device. The startup function of the parent device is of course called.

Does it mean that the devices have not their own running environment as soon as they are child of another device ?
And does it mean that there is a unique running environment for the parent device and all his child devices ?

Last question: does it mean that it is not possible to have child devices living their live as if they have no parent ?[/quote]

Does the parent’s device file have

<handleChildren>1</handleChildren>

in it? I think this is the key to the different behaviors you’re looking for.

watou

[quote=“watou, post:2, topic:174584”]Does the parent’s device file have

<handleChildren>1</handleChildren>

in it? I think this is the key to the different behaviors you’re looking for.

watou[/quote]

Thank you for your answer.

No I have not defined this entry in the XML file.
I will try to add it setting the value to 0. Maybe the default value is 1.

Ok, finally it does not behave exactly how I just described.

The startup function of the parent device and the child device is called, (whatever the value of the tag “handleChildren”). The problem is the value of the parameter lul_device in this startup function. In case of a child device, this parameter is set to the id of the parent device, not the child device ! Is it what is expected ? How to get the child id in the startup function ?

I made a new test with 2 child devices.
The startup function of the child device type is called only one time. In this case, it makes sense to provide the parent device id as parameter.
So it seems that the parent device inherits the implementation file of his child devices ?
It is a strange behaviour. Is it something new with the new firmware ?

To make it clearer:

  • I have a device id 100 of type toto attached to D_toto1.xml, I_toto1.xml and startup tag referencing function totoStartup
  • I have 2 devices id 101 and 102 of type titi attached to D_titi1.xml, I_titi1.xml and startup tag referencing function titiStartup

If my titi devices are not child of my toto device, I got 3 calls:

  • totoStartup lul_device 100
  • titiStartup lul_device 101
  • titiStartup lul_device 102

If my titi devices are child of my toto device, I got only 2 calls:

  • totoStartup lul_device 100
  • titiStartup lul_device 100

I would have expected the same behaviour in the two cases.

That means each device type has to handle two different cases: not attached to a parent and attached to a parent.
And in the second case, I assume that the running environment is common for all the child devices; in fact it is a running environment for the parent device.