The following are supported for an app
List<InstalledApp> getAllChildApps()
List<InstalledApp> getChildApps()
InstalledAppWrapper getChildAppById(Long childAppId)
InstalledAppWrapper getChildAppByLabel(String childAppLabel)
I'm not sure what the difference is between getChildApps() and getAllChildApps() though.
there is no difference in Hubitat between these, one is just an alias for the other.
Thank you for the fast reply. I uncommented my older getChildApp() code and it worked. I have a bit of recoding to do.
In SmartThings:
getChildApps() Gets child apps that are in "COMPLETED" status
getAllChildApps() Sets all child apps inluding those that have not be "Completed"
Is there a link for the information you posted?
In SmartThings, zigbee.parse(String description) can be used for a SmartShield generated map of ZigBee catchall messages. Some examples:
catchall: 0000 0013 00 00 0040 00 0030 00 00 0000 00 00 413000D64ED801008D150080
is parsed as
SmartShield(text: null, manufacturerId: 0x0000, direction: 0x00, data: [0x41, 0x30, 0x00, 0xd6, 0x4e, 0xd8, 0x01, 0x00, 0x8d, 0x15, 0x00, 0x80], number: null, isManufacturerSpecific: false, messageType: 0x00, senderShortId: 0x0030, isClusterSpecific: false, sourceEndpoint: 0x00, profileId: 0x0000, command: 0x00, clusterId: 0x0013, destinationEndpoint: 0x00, options: 0x0040)
catchall: 0104 0000 01 01 0040 00 0030 00 00 0000 0A 01 050042166C756D692E73656E736F725F6D61676E65742E61713201002003
is parsed as
SmartShield(text: null, manufacturerId: 0x0000, direction: 0x01, data: [0x05, 0x00, 0x42, 0x16, 0x6c, 0x75, 0x6d, 0x69, 0x2e, 0x73, 0x65, 0x6e, 0x73, 0x6f, 0x72, 0x5f, 0x6d, 0x61, 0x67, 0x6e, 0x65, 0x74, 0x2e, 0x61, 0x71, 0x32, 0x01, 0x00, 0x20, 0x03], number: null, isManufacturerSpecific: false, messageType: 0x00, senderShortId: 0x0030, isClusterSpecific: false, sourceEndpoint: 0x01, profileId: 0x0104, command: 0x0a, clusterId: 0x0000, destinationEndpoint: 0x01, options: 0x0040)
Maybe I'm dreaming, but it seems the Hubitat hub used to do the same, but currently (as of hub v2.0.8.113) the output from zigbee.parse(String description) of a catchall message is not a map and completely different. Here's what the Hubitat hub does with the same two example catchall messages:
catchall: 0000 0013 00 00 0040 00 0030 00 00 0000 00 00 413000D64ED801008D150080
is parsed as
com.hubitat.zigbee.SmartShield(19, 0, [65, 48, 0, 214, 78, 216, 1, 0, 141, 21, 0, 128], 0, 0, false, false, 0, 0, null, 64, 0, 48, 0, null)
catchall: 0104 0000 01 01 0040 00 0030 00 00 0000 0A 01 050042166C756D692E73656E736F725F6D61676E65742E61713201002003
is parsed as
com.hubitat.zigbee.SmartShield(0, 10, [5, 0, 66, 22, 108, 117, 109, 105, 46, 115, 101, 110, 115, 111, 114, 95, 109, 97, 103, 110, 101, 116, 46, 97, 113, 50, 1, 0, 32, 3], 1, 1, false, false, 0, 0, null, 64, 260, 48, 1, null)
The Hubitat output appears to be a list, but although I can match the data: portion inside the brackets, I am not sure of what everything else is supposed to represent.
So, what - if anything - can I use to parse catchall messages into a map on Hubitat?
Tagging @mike.maxwell since he's probably the only person who can answer this.
Is it alright if I give it a shot?
Nope, thats an object
Yep
Nope
You are looking at the string output of an object (SmartShield). Our toString() method is clearly different than ST's implementation. I have plans to fix up that object and populate the text field properly. I will change the toString while I'm in there. The properties are all there already: text, manufacturerId, direction, data, number, isManufacturerSpecific, messageType, senderShortId, isClusterSpecific, sourceEndpoint, profileId, command, clusterId, destinationEndpoint, options. You can use them if you want, but I get the impression that is only supposed to be for the ThingShield parsing.
use: zigbee.parseDescriptionAsMap(String)
https://docs.hubitat.com/index.php?title=Zigbee_Object#parseDescriptionAsMap
It will give you a map with the following keys: raw, clusterId, sourceEndpoint, destinationEndpoint, options, messageType, dni, isClusterSpecific, isManufacturerSpecific, manufacturerId, command, direction, data
def descMap = zigbee.parseDescriptionAsMap(description)
As an fyi, you guys crack me up, complaining about the lack of example drivers, and yet no one even looks at (much less studies) what we do have posted...
Line 65: HubitatPublic/GenericZigbeeRGBWBulb.groovy at master · hubitat/HubitatPublic · GitHub
How does that difference work in ST? What is the difference from the user perspective with an app that is completed vs one that is not?
Nope. Not true in my case. And I haven't been complaining about a lack of example drivers.
I did look at that driver, and the previous line 64 does a return on any catchall: messages, so why would I expect zigbee.parseDescriptionAsMap(description) to do the trick?
Also, I did look at the Hubitat Documentation page on the ZigBee Methods, and I could swear the entry for parseDescriptionAsMap was not there when I looked a couple hours ago. Perhaps I missed it.
Honestly, I find it offensive that it's implied I am wasting your time asking dumb questions when I do spend the time to research as best I can, rarely ask any questions in general, and have never contacted support after my second instance.
The work I do on device drivers is unpaid, not my as my form of employment, and the time I have to dedicate to it is limited. I am not a programmer by trade, and can't be expected to know as much as you well seasoned professionals do. I just don't see how it warrants taking pot-shots when I do occasionally ask for help.
Nevertheless, as much as I am less and less inclined to ask for it with these kinds of responses, thanks for the reply.
Excellent question that should have been asked, however, if parseDescriptionAsMap didn't parse something from that string, there would have been no need to throw it out before hand...
No, you are not going crazy. when someone asks a question about specific methods I tend to go into the wiki and add it there as well. It was listed below as one of the methods to document but I just added the full documentation for it.
I'm not saying that all, I have no idea if anyone's actually looking at these or not.
I certainly don't get any questions regarding them.
The community wanted to extend the Halo driver with the weather buisness, so we posted that, nobody's submitted any pull requests to it...
I'm not intending to be dismissive here, I just feel on occasion that what little we currently have available to developers isn't advantaged, be this may be my own bias or reality, it tends to make me cranky.
I'll do better next time.
just looking at some of my code so in an App this
iconUrl: "https://s3.amazonaws.com/smartapp-icons/Convenience/App-LetMyFriendsIn.png",
iconX2Url: "https://s3.amazonaws.com/smartapp-icons/Convenience/App-LetMyFriendsIn@2x.png",
iconX3Url: "https://s3.amazonaws.com/smartapp-icons/Convenience/App-LetMyFriendsIn@2x.png",
must be?
iconUrl: ",
iconX2Url: "",
iconX3Url: "",
Is the rule applicable to Device Handlers?
Drivers dont have icons.
So I can leave icons in apps, but have to take them out of drivers
So my ST device handlers have icons, do I have to remove them from them to be drivers in HE or can I ignore them?
we have some example drivers posted here:
Thanks for the link, do I need to delete the tiles section from my ST drivers or are they ignored by HE?
ignored, but why leave unused cruft in a driver?
I'm trying to port a driver and am having mixed success. An example of the problem I'm having is with this code:
hubitat.app.DeviceWrapper macChild = getChildDevice (mac)
I've converted from physicalgraph to habitat but get an unresolved class. I've tried removing the class hierarchy but I still get an unresolved class on DeviceWrapper. I have the same problem with ChildWrapper.
Any suggestions?
Download the Hubitat app
