...and when you're done trying to figure out 'another way' to do IR ... there is always the Global Cache IP2IR devices, Driver and App, all ready to go. 
Hey, Google... turn on Watch TV. Sure, turning on the Watch TV (Stereo, TV and Cable box magically turns on)
Hey, Google... turn on ABC. Sure, turning on the ABC (cable box changes channel to ABC)
Remote controls!? Don't need 'em! 
Is there an easy way to do macro commands. The main reason I set up the mdhiggins method was because there was no easy way to send a string of commands without changing the current activity.
Eg.
I wanted to swap between my samsung soundbar speakers and my 2 rear M3's (don't ask why...home acoustics is the short answer). To do this with the Harmony remote requires loading a separate "device" menu and a string of about 10 button presses. A real PITA for a simple task. With my NodeMcu, I simply ask alexa to "switch to the back speakers" and voila. All 10 commands execute with proper pauses in between and I don't need to touch my Harmony remote or change the activity.
Do you think this scenario...or a version of it ...is possible with the Hubduino solution...please say yes 
In a specific sequence? I don't know. I've never done that. If you can't post on the ST forum I can post on the thread where it was developed.
I can post on ST... but I'll just stop being lazy and actually read through the link you posted. It would probably be apparent once I understand how that method controls the IR transmissions.
I looked at the code. Its nothing special but because its websockets we can't implement it the same way in hubitat. And the only way to update the device is via polling.
That being said you could still use ifttt to trigger activities. Its not nice.
I was able to put together something. But it does require a node server to be running to handle the websocket stuff and it requires polling to update the hubitat device. Its not pretty, has lots of bugs and will probably break but its all local and runs pretty fast. I'm hoping they will figure a way to avoid polling soon. We will see.
So I have been able to reproduce what the Hass.IO folks have done for using Python, websockets and Harmony. I am able to connect to my device, query the activities. I just now need to figure out how to watch for changes in the activity itself.
You have to poll the box.
You can use the following websocket command
ws.send(r'{"hubId":"${hub_id}","timeout":30,"hbus":{"cmd":"vnd.logitech.harmony/vnd.logitech.harmony.engine?getCurrentActivity","id":"0","params":{}}}')
Then parse the response. The current activity is stored in the result.
ws_data = ws.recv()
hub_data = json.loads(ws_data)
print(" Current Activity: " + hub_data['data']['result'])
At this point I don't see a way to have it report automatically.
Also as an activity is starting it will see 3 status messages via the websocket. I think at the start, during and once complete. I don't really think we care about them though.
Isn't this exactly what is needed to do away with polling? From the XMPP solution that is now defunct, State Digests would be sent when an activity was started or stopped. It sent the activity ID along with a status of 0, 1, 2, or 3. Sounds like this could be the same thing?
Still looking into it. I have a couple ideas though.
From my other attempt here
Status Code 0 means hub is off
Status Code 1 means activity is starting
Status Code 2 means activity is started
Status Code 3 means hub is turning off
harmonyClient.on('stateDigest', function(digest) {
var statusCode = digest.activityStatus
var currentlyOn = digest.runningActivityList
var targetActivity = digest.activityId
switch(String(statusCode)) {
case '0': //Hub is off
if(currentlyOn == '' && targetActivity == '-1') {
console.log('- Hub is off')
} else {
console.log('- Activity ' + currentlyOn + ' is off')
changeSwitch(currentlyOn, 'off')
}
break;
case '1': //Activity is starting
console.log('')
console.log('Received state digest (' + new Date() + ')')
console.log('- Activity is starting...')
break;
case '2': //Activity is started
if(currentlyOn == targetActivity) {
console.log('- Activity is started')
} else {
if(currentlyOn == '') {
console.log('- Activity ' + targetActivity + ' is on')
changeSwitch(targetActivity, 'on')
}
else {
console.log('- Activity ' + targetActivity + ' is on')
console.log('- Activity ' + currentlyOn + ' is off')
changeSwitch(targetActivity,'on')
}
}
break;
case '3': //Hub is turning off
console.log('')
console.log('Received state digest (' + new Date() + ')')
console.log('- Hub is turning off...')
break;
}
})
Ya.. it looks like that code is based off a library that used the old XMPP method that they shut down.
The new method using websockets is a bit different. But very local.
At a minimum, that broadcast on activity change could be used to trigger a refresh, rather than polling periodically...
That is the problem. I don't see anything being broadcast.
When I start an activity I see replies from the hub about the state. But that is just during starting.
If there is an actual broadcast and somebody knows how to capture it, that would help.
Oh, I was misunderstanding then. I thought you were saying you were getting this info any time an activity started, which I assumed to mean even when starting an activity from the physical remote.
Oh ya. When I start it via Hubitat I see a response. I'm not sure how the HA guys are handling this. I don't see anything obvious in their code but its a little bit confusing to me.
Logitech are reversing the fix.
Logi_WillWong (Logitech - Smart Home Group)
Hi folks.
I have updated the original post with the following:
We’ve heard your concerns. We understand that some customers are frustrated with the recent security fix we put in place, as it closed access to private local API controls. While security continues to be a priority for us, we are working to provide a solution for those who still want access despite the inherent security risks involved.
If you would like to participate in an XMPP beta program, which will allow access to local controls, see the below instructions. Over the coming weeks, we will qualify a regular firmware release that still allows XMPP control for those who need it. We expect to send out an update that will be available to all Harmony customers in January.
Here are the instructions to access the program by updating the firmware on your Hub.
Launch the MyHarmony software on your desktop computer.
From the login page, press the following keys to access the tool:
On Windows - Press Alt + F9
On Macs - Press Fn + Option + F9 or Option + F9.
Scroll down to the bottom where it says “FIRMWARE TO ENABLE XMPP. FOR DEVELOPERS ONLY.”
Be sure to read through the short warning and disclaimer to understand the impact of installing this firmware.
Click on Update Firmware.
Plug in your Harmony Hub via USB and click on Install.
Thank you
This is great as it kind of makes it official...
Here's what caused the closure to begin with:
And in the other new thread about this, there's a statement from a Logitech rep that XMPP access will be maintained going forward.
Here's that link, in case people see this thread before the other one.
https://community.logitech.com/s/question/0D55A00008OsX3CSAV
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
