I’m attempting to write ST device for a pool controller using st-device-sdk-c-ref. Yes, others have done it but, AFAIK, not with this SDK. I’ll need child devices for the pump, heater, blower (got a jacuzzi), etc, while the parent device will report temp, chlorine and ppm data.
Does anyone have any examples of child devices using this SDK?
It’ll be interesting to see the response. I thought the concept of parent/child devices in SmartThings had gone the way of the dodo and components was the way things were going.
If I think I know what you mean, then I’m not sure how that would work. How do I tell Alexa to turn on the jacuzzi if it’s just one component of a massive device?
The “Jacuzzi” child would, when turned on, turn on the pump, the heater, and set the valves to a predetermined position.
Component vs Child Device has me wondering what the practical difference is, other than being accessed through a device header. I suppose pairing as one device would be the thing that stands out, so maybe being on one module, then?
I’ve been working on a “device” which actually is comprised of components. Essentially a motion sensor which triggers a multi-channel LED controller to have different outputs based upon different conditions.
Knowing I’m probably not being helpful, but this got me to wondering why LED controllers are typically one “device”, with what would otherwise be several Child Devices.
Anyway, maybe that would be a place to have a look, the LED controllers.
The only time when a Composite Device Handler (I.e. Parent/Child) design was required in the Groovy DTH design, is when the physical device implements multiple, identical, “Capbilities”. For example, a power strip that has 6 “Switch” devices, yet pairs as only one physical device. In order for each “Switch” to be made available to SmartApps, a child device needs to be created for each of the 6 outlets on the strip.
I appreciate that info. I had a look at some of the discussions on the subject, but sort of lost interest knowing that the custom DTH would be going the way of the …
I haven’t really looked at the SDK, and don’t know if there any examples to draw from, relative to the OP’s question, but those LED controllers seem to have so much potential with custom DTH.
One of these days, I hope to build something from the module up. I hope there will still be people here who share, when I try.
I the case of your 6 switch power strip, how would you address an individual plug from Alexa?
Do you mean, like… When there are multiple switches on a device, how do you activate one through Alexa?
In the case of the eWelink Zigbee multi-realy, each switch/relay can be activated by name. There is some limitation on how you categorize the switch. Like, you can’t designate the switch to be a door lock, for example, for security purposes, while using voice execution. I believe that’s still the case.
I think there is a larger discussion going on concerning how child devices are not exposed to Google, which I thought might be where this topic was headed. My thoughts being, that LED controllers, essentially being multiple dimmers didn’t appear have an issue.
My sliding door actuator, hooked up to the eWelink relay. I have to say “Alexa, turn on (or off) Open Patio Door”, or “Alexa, turn on (or off) Close Patio Door” The bolded being the switch names.
Anyway, I hope that helps in some way.
I really agree with this.
Child devices are useful especially in multi switches, such as multi-gang wall switches and power strips.
Ok, since I’m not getting the responses I had hoped, I’m digging into to figuring out the API.
first step, try support for two switches.
I get a context from st_conn_init and I call caps_switch_initialize twice with two different names for the switches. It seems that only “main” is acceptable here. Is that correct?
My next guess would be trying multiple contexts, but if the SDK has any global data hiding around, that’ll probably break. Maybe someone that’s been down this road already can tell me how to approach this?
Hi, @dcabot25
That second argument that the caps_switch_initialize or any capability initializer function needs is the name of the component referred at the device profile you created at the Developer Workspace, hence, if you’re trying to integrate the Switch for every component of your pool, you should specify them at your device porfile, e.g.:
{
"name": "{ Your Pool Profile }",
"components": [
{
"label": "main",
"id": "main",
"capabilities": [ ... ],
"categories": []
},
{
"label": "heater",
"id": "heater",
"capabilities": [ ... ],
"categories": []
},
{
"label": "blower",
"id": "blower",
"capabilities": [ ... ],
"categories": []
},
{
"label": "pump",
"id": "pump",
"capabilities": [ ... ],
"categories": []
}
],
"metadata": { ... }
}
Then you can initialize these components and its capabilities at the capability_init handler, e.g.:
static void capability_init()
{
main_switch = caps_switch_initialize(ctx, "main", NULL, NULL);
heater_switch = caps_switch_initialize(ctx, "heater", NULL, NULL);
blower_switch = caps_switch_initialize(ctx, "blower", NULL, NULL);
pump_switch = caps_switch_initialize(ctx, "pump", NULL, NULL);
// default state: switch - off
main_switch->set_switch_value(main_switch, "off")
heater_switch->set_switch_value(heater_switch, "off")
blower_switch->set_switch_value(blower_switch, "off")
pump_switch->set_switch_value(pump_switch, "off")
}
This way you’ll handle different switch states for each component under the same context.
Perfect. So the API must have been expecting to see “main” as the first one. Thanks for the explanation.
Thanks Erick. That’s exactly what I needed. That, and using virtual switches, I’ll be able to control from both ST and Alexa.
Hi Erick, I developed a device with one main device and 4 component switches, but the last component switch doesn’t show up in the ST app. The separator line does, but not the switch. It just looks like a NULL component.
Is there a limit to the number of components?
Hey, @dcabot25
The support of four additional components shouldn’t be an issue.
When you add the device through the SmartThings App, are you able to see the state update of every component through the terminal?
Yes, without errors.
I do see this one issue
E (24515) [IoT]: _iot_mqtt_process_received_ack(423) > There is no ack packet matched
it doesn’t happen consistently.
I even tried rearranging the order that the ESP8266 code sends the components. Everything ACK’d. Order in the display is the same and the last one doesn’t have the two caps that were set.
@dcabot25 This is very odd, I’ll check it out.
In the meantime, check if the status of the device is being submitted properly at the API and post it below without the Ids that it may contain.
You can use the following curl command to do so (just patch the respective values between “< >”):
curl -X GET "https://api.smartthings.com/v1/devices/<device_id>/status" \
-H "Authorization: Bearer <personal_access_token>"
Hey @dcabot25
I’ve been trying to replicate this issue but my components are showing as expected, so If you could share with me the components array from your device profile, I can try to use the same component-capability set and see if it is specifically that.
For a better reference of what I tested, I’ll attach below a gist of the device profile I used.