My test was just a proof of concept and I didn't finish it as I didn't have a need to. The code wouldn't work with @ogiewon's implementation anyways as it would have to be rewritten for his code.
If you are looking to do something yourself, just take a look at the data returned from the device and you can parse out all of the devices, their numbers and their available commands and create child devices based on that data.
Thanks, I'll try to do that. Might learn a thing or two while doing it 
is it possible to use the Harmony Companion "smart home" buttons to control various lights and / or plugs? Hubitat is amazing, but this is the only thing that I'm missing from switching from ST.
I don't see how that could be done unless (very big IF ahead) you can reprogram the buttons on the remote using Logitech's Servers to talk to the Hubitat hub instead of the Harmony hub. Perhaps you can ask Logitech how they do the ST integration?
Not directly... What type of lights are you trying to control? Philips Hue and Lutron both have native integrations with Logitech's Harmony Hub. So, if you enabled one of these integrations (i.e. bypass Hubitat) then you would be able to map the Logitech remote control buttons to smart devices. You could still use my Hubitat Harmony Hub integration at the same time.
Another solution is to use HubConnect to mirror a few Hubitat lights back to SmartThings. Then use the SmartThings-2-Logitech Harmony Hub integration to map and control those lights from the remote control.
So, there are a few options available.
Unfortunately, Logitech has stopped adding new integrations. Thus, the Hubitat team cannot simply write an official integration to the Harmony Hub until Logitech opens things back up again for third party integrations.
@ogiewon Hey Dan - Been working on the Logitech Code to allow other commands like menu, left right, up, down, play, pause that weren't integrated before and I've worked out how to add these, along with a few bug fixes in your code in relation to the way it sends the command to Harmony.
Can I discuss this with you and hopefully push a few updates over. It will also mean that we could get the device to show as a media controller in hubitat.
Let me know, else I'll just end up with a forked out of date version.
I am happy to review and accept pull requests. Sounds like some nice enhancements!
I've sent a merge request - I might look at adding in a code variable so a default navigation device can be used, but even at present, it will allow it to be used by an actuator through RM
Hmmmm... 
I just checked my email and my GitHub repository and I do not yet see a Pull Request.
Do I have to be listed as a contributor first? My username on it is "Ellenby".
Not that I am aware of. Others have submitted PR's without me having to do anything special.
This is the repo you're trying to submit the PR to, right?
If it doesn't work for some reason, feel free to Private Message me a copy of the code and I'll merge it in, after a quick review.
Again, thank you very much for helping to improve this driver!
I think I've managed to send the request now... I did one on the main file and a second on the readme
I see it now!
I have a few questions...
You have added a series of custom commands, which is fine, however the data types for these are not properly defined in their declarations...
Also, your "customCommand" seems like it may be redundant with my existing "deviceCommand". I see that one calls "deviceCommandPressRelease()" and the other calls "deviceCommandPress()", but I don't understand what the difference is? Do you think we can consolidate these two commands?
command "customCommand", ["command", "deviceID"]
command "leftPress", ["deviceID"]
command "rightPress", ["deviceID"]
command "upPress", ["deviceID"]
command "downPress", ["deviceID"]
command "okPress", ["deviceID"]
Should probably be something like...
command "customCommand", ["String", "Number"]
command "leftPress", ["Number"]
command "rightPress", ["Number"]
command "upPress", ["Number"]
command "downPress", ["Number"]
command "okPress", ["Number"]
Thoughts?
Here is what I have come up with to properly constrain data type and provide a description of each field that is visible when interacting with the device from the Hubitat Web Admin Device Details page.
Thoughts?
command "customCommand", [[name:"Command", type: "STRING", description: "Harmony Hub Command", constraints: ["STRING"]], [name:"DeviceID", type: "NUMBER", description: "Harmony Hub Device ID", constraints: ["NUMBER"]]]
command "leftPress", [[name:"DeviceID", type: "NUMBER", description: "Harmony Hub Device ID", constraints: ["NUMBER"]]]
command "rightPress", [[name:"DeviceID", type: "NUMBER", description: "Harmony Hub Device ID", constraints: ["NUMBER"]]]
command "upPress", [[name:"DeviceID", type: "NUMBER", description: "Harmony Hub Device ID", constraints: ["NUMBER"]]]
command "downPress", [[name:"DeviceID", type: "NUMBER", description: "Harmony Hub Device ID", constraints: ["NUMBER"]]]
command "okPress", [[name:"DeviceID", type: "NUMBER", description: "Harmony Hub Device ID", constraints: ["NUMBER"]]]
Regarding
["String", "Number"]
versus
["command", "deviceID"]
I believe that it is not a data type, unless you have documentation showing otherwise, but what it shows to the user on the device page so there is some kind of indication of what to put in the box, and therefore when inputting data, you can see easily without going into the driver code (as an end user) that one wants the deviceID and the other the command. If you don't label as such, say if you have 'string' and then another 'string' the end user wouldn't know which data to put in which.
Regarding the duplicate of the customCommand - that uses the command that does a press&release versus the deviceCommand does just a push (and effectively holds). Maybe we could just link to the press and release command, as I'm not sure when you would need just press.
do you want to test the following, to see if everything still works, else I'd suggest having separate press and pressrelease commands
def deviceCommand(command, deviceID) {
sendMsg('{"hubId":"' + state.remoteId + '","timeout":30,"hbus":{"cmd":"vnd.logitech.harmony/vnd.logitech.harmony.engine?holdAction","id": "0", "params":{"status": "press","timestamp": "0","verb": "render", "action": "{\\"command\\": \\"' + command + '\\", \\"type\\":\\"IRCommand\\", \\"deviceId\\": \\"' + deviceID + '\\"}"}}}')
}
as
def deviceCommand(command, deviceID) {
sendMsg('{"hubId":"' + state.remoteId + '","timeout":30,"hbus":{"cmd":"vnd.logitech.harmony/vnd.logitech.harmony.engine?holdAction","id": "0", "params":{"status": "pressrelease","timestamp": "0","verb": "render", "action": "{\\"command\\": \\"' + command + '\\", \\"type\\":\\"IRCommand\\", \\"deviceId\\": \\"' + deviceID + '\\"}"}}}')
}
other option would be to add in another variable into deviceCommand to allow selecting press or pressrelease
Do you follow?
I'd be hesitant to fix in code deviceID as a number, as you never know what changes Logitech will make, possibly adding in hexadecimal for example and leaving as text keeps things safer.
But yes, if that allows a custom description that way, can alter that
This is where I found the pressrelease vs press, which made sure the commands only triggered once
Yes, I understand the logic. I think only one of the two custom commands is required. I'll do some testing using the "pressrelease" to see if it behaves the same way things are behaving today (if not better 
). If so, we can default to that one.
Fair enough, I'll tweak those to be STRINGS instead.
I'll run some quick tests and will post my results in a few minutes.
@rebecca - Testing was all good with the changes that I made based on our discussion above. I have updated the version in my GitHub repo. Please grab the latest version and give it a test. I have added a comment in the change history attributing credit to you for your work.
Thanks again!
Download the Hubitat app
