[Release] Logitech Harmony Hub Driver v0.1.20230311

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

1 Like

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 :wink: ). 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!

2 Likes

They're definitely types. Hubitat mostly follows the SmartThings model and they are types there. Also, even though it's not explicitly documented on the Hubitat side yet here is a glimpse from somebody official that this is the case:

If you don't provide a map of maps the single String or array of Strings is considered to be a type(s). You can prove this out by looking at the data types of the parameters passed to commands. For example, if you type it as "NUMBER" the parameter's type is BigInteger instead of String.

1 Like

Ah OK - I did have a look at a few other custom drivers including the "Echo Speaks" app/drivers and they were just using it as a description, but taken on board for this project

Testing works for me and now been looking into the getConfig output as it lists some quite useful information. As much as I could create a list of commands that one might expect to be used, if for each device and activity we pull the commands available, it will be much more personalised to all users needs.

One thing I've picked up on...

We're using a deprecated method for the websocket
https://docs.hubitat.com/index.php?title=Websocket_Interface
However, if we upgraded to the non-deprecated commands, it would rule out people running hubitat pre-2.1.2 when current minimum is 2.0.3.114 (I'm on 2.1.9.115)

Any way to pick which commands based on hubitat version, such that if the commands are dropped in a later release completely, system still works without forcing people on less that 2.1.2 to upgrade?

The deprecated methods and the non-deprecated methods for the websocket from what I remember about a post from Chuck use the same code underneath without any differences. Since we don't have to worry about compilation warnings or even deprecated annotations it's less complicated just to keep using the deprecated location of the client for now. I'm for crossing that bridge later.

1 Like

Works for me! :blush:

I had something weird happen today.

My LG OLED TV (for some weird reason I'm still trying to figure out) has been turning on at 3am daily for the last week. I have a rule in Rule Machine that turns on a Harmony Activity when the TV's input changes to that activity's TV input. So as an example. if the TV is manually changed to HDMI4, the rule turns on the Harmony TiVo activity (as a delayed cancelable action after 15s). This way, the Harmony stays in sync even if the TV is controlled through another means. An example of the rule is below and it's worked very well.

Today, the TV came on at 3:02:55am and went to the TiVo input at 3:03:45am (50s even though it normally takes 500ms).

channelName Tivo LG TV channelName is Tivo DEVICE 2020-03-08 03:03:45.650 AM EDT
power on LG TV is on DEVICE physical 2020-03-08 03:02:55.653 AM EDT
switch on LG TV is on DEVICE physical 2020-03-08 03:02:55.639 AM EDT

At 3:04:04am, the rule kicked in and turned on my "Living Room TiVo" Logitech Harmony activity.

RM Triggered 2020-03-08 03:04:05.795 AM EDT
RM LG TV channelName Tivo 2020-03-08 03:04:05.729 AM EDT

For some weird reason, my Living Room Tivo (child device) actually never turned on though.

switch on DEVICE 2020-03-08 01:00:04.388 PM EDT
switch off DEVICE 2020-03-07 10:08:23.244 PM EST

However, the parent device (Living Room TV) did turn on without updating the current activity

Activity Watch Fire TV DEVICE 2020-03-08 07:05:57.631 AM EDT
switch on DEVICE 2020-03-08 03:04:24.675 AM EDT
Activity PowerOff DEVICE 2020-03-07 10:08:23.335 PM EST

Please any idea why the parent device would have switched on but the child device didn't? Because it didn't, the parent device's switch was on but the current activity was "PowerOff" which should never be the case.

Thanks!

I have a Harmony Hub Elite with the home automation buttons. I know this [awesome] driver does not support those buttons yet. I migrated from Smarthings and this is the last of the Hubitat unsupported things I have. I am not sure what to do as I do want to use those buttons to control 2 dimmers (and rocker switch) and 2 scenes in Hubitat. What should I do?

  1. Use Hub Connect to mirror scenes/devices from hubitat to smarthings and use the button/ST integration
  2. Use webcore on Hubitat and ST to call a POST API to trigger the scenes? - boo no dimmer/rocker button support
  3. something else?

:point_up_2: This is what most folks have done.

If your lights are Lutron Caseta or Philips Hue, then you could use the Harmony Hub to Lutron/Philips integration directly, bypassing Hubitat and SmartThings altogether.

Successfully set up my 3 hubs. This was one of the two things I was still using ST for.

2 Likes

I want to execute a rule in Hubitat when I push off (end an activity) on my Logitech Harmony remote. Will this driver allow me to do that?

Yes. Each Harmony Activity will be represented as child “Switch” device within Hubitat. When you press OFF on the remote, the active Activity will turn off. The Parent Device will also be usable to know whether or not any Activity is on, or if they are all off. The Parent Device implements a Switch attribute that represents this. This can easily be used within RM, or any other App that can be triggered by a switch changing states.

2 Likes

This is brilliant. Working so well after I had facepalm when I realized Harmony wasn’t being friendly and I got a Hubitat.

I’m probably missing something obvious, but I’m not seeing any of my Harmony stuff showing up in the rules app. Any ideas?

Each of your Harmony Activities should have been created as a Switch device, named the same as each activity. If you’re not seeing those, did you add my Child Switch driver per the ReadMe instructions?

1 Like

Ah! Switch... as I was reading that I realized I had seen them in switches when making another rule. Outstanding. Thank you. Still learning my around.... you guys are an amazing help and doing amazing stuff. This is a game changer for me.

Next step is to try and figure out how to start music off so it’s playing when I walk through the door.

1 Like

Lots of options for this and most will depend on what speaker devices you have on hand. Off-topic for this thread so if you don't find your answers by using the search functionality start a thread specifically for that purpose. I'm sure there are threads out there about this though. I'm not sure how searchable they are.