v0.1.20210725 Improved log.debug handling v0.1.20210702 Added Presence Capability to indicate whether or not the connection to the Harmony Hub is 'present' or 'not present' v0.1.20210425 Corrected data type of custom attributes v0.1.20201228 Fixed Null division issue caused in the 11-23-2020 release v0.1.20201123 Added custom level attributes for Home Control Buttons. Thanks @fabien.giuliano and @abuttino. v0.1.20200920 Use 'pushed' and 'held' events for 'Home Control Buttons' v0.1.20200918 Added support for Home Control Buttons for Harmony remotes that support these buttons - Thanks @abuttino! PLEASE READ THE README section regarding these buttons! v0.1.20200301 Added Left, Right, Up, Down and OK commands - Requires the device ID - Thank you @rebecca (Rebecca Ellenby) v0.1.20200114 Added Switch Capability and Default Activity user preference to Parent Device. If the Parent switch is turned on, the default activity is turned on. If the Parent switch is turned off, the current Activity is turned off. v0.1.20191231 improved volume control logic and robustness. fixed small bug preventing volume changes. v0.1.20190723 adds Actuator Capability to allow use in RM's Custom Actions v0.1.20190715 adds support to the Parent Device for VolumeUp, VolumeDown, Mute, ChannelUp, and ChannelDown custom commands for those Harmony Activities which support Volume and/or Channel control. Thank you @aaron for you insight and motivation to bring these features to fruition!** Simply update your Parent driver and then click REFRESH on the Parent Device. Update: You can now add a Volume Tile to the Dashboard for the Parent Device to bump the volume level up or down (but you cannot set a specific volume level as the Harmony Hub cannot set the level, it can only adjust the volume up and down.)
Note: Logitech changed the webSockets interface slightly in v4.15.250 of the Harmony Hub firmware. @corerootedxb was able to come up with a fix to the driver to make it work with the new 4.15.250 firmware. This issue only affects new instances of the Logitech Harmony Hub virtual device. Existing users are not impacted. v0.1.20190220 of this driver is designed to work specifically with Harmony Hub v4.15.250. Existing user may upgrade as well, as long as their harmony hubs are also at 4.15.250. Thank you @corerootedxb for the quick solution!
I am pleased to announce a Release of my new Logitech Harmony Hub Driver. This driver communicates directly to your Harmony Hub over your LAN. It will create a child switch device for each of your Harmony Activities, and will keep them all up to date with instant status updates from the Harmony Hub. No polling required!
This integration requires new LAN connectivity features only available in the recent Hubitat Elevation Firmware version 2.0.3. and newer
The instructions for using this driver are available in my GitHub repository within the ReadMe for this driver. I expect users will want enhancements. I encourage GitHub Pull Requests as I welcome community support of this integration!
STOP - PLEASE ONLY PROCEED WITH THE FOLLOWING instructions AFTER you have completed the steps above in the ReadMe....and even then, only if you have a strong desire to try and use the "Home Control" buttons found on some Harmony physical remote controls.
[UPDATE: September 27, 2020]
I would like to thank @abuttino for the recent help in adding some limited support for using the 4 Harmony Home Control buttons found on some Harmony remote controls. Below are some instructions written by @abuttino to help users utilize this remote control buttons within Hubitat.
Note: Once the four buttons are configured in the User Preferences of the Parent Device, the Parent device will then become a 4-button Button Controller that can be used in any App that supports 'pushed' and 'held' button events (e.g. Button Controllers, Advanced Button Controller, Rule Machine, webCoRE, etc...)
I finished removing my caseta bridge from harmony setup so I'm guessing the warnings will go away. Just giving feedback as I'm sure other configurations will also show these warnings if the driver isn't expecting them.
Thanks again for your work on this! I hope Santa hooks you up with some well deserved goodies since this driver should definitely qualify you for his "nice" list!
Its amazing how well the websocket solution works for controlling the activitys. 100% local and no need to fight with any keys for authentication and its really fast. I guess this is a security issue on your local network but this would be the least of my worries on my local network.
I hope they don't take away the websocket implementation.
Very Nice! I'm excited to see development towards a Harmony solution.
Right now, this isn't quite a solution for me - but I'm hoping it will become one. I was wondering if there were plans to send commands to specific devices? All of my "activities" are handled within HE - they are really more of traditional macros as I no longer use my harmony remote. If an activity requires an IR device, HE sends the command to tasker on a separate android machine and then it is routed to my harmony hub. It's all local, and works well - but I'd love to get the bridging android device out of the equation.
I saw the same thing going from the first beta to the second beta with this driver. Not sure what is going on. Might be something in the new webSockets API. Or it could be in my code. Pressing REFRESH also seems to bring it back to life.
I think its because it doesn't reconnect the websocket after the reboot.
Clicking refresh will send a websocket command which should fail because its not connected, however should be caught by the websocketstatus and issue the reconnect command which calls initialize and it kicks back in.
One thing you can do is create a smart app that manages the devices and subscribes to the hub reboot event. Then after any reboot it can kick off a reconnect and refresh to update any switches for scene's that may be out of sync.
Its more complicated but I only think you can subscribe to that event in the app. I don't think there is any way to issue a command after a reboot with a driver.
You can also add it to a rule that maybe calls refresh on it every x minutes. This way it will eventually kick back in.
I could be wrong, but this is what I could see by scanning through the code.
I think you're correct as well. Since this issue would plague any device driver that uses webSockets, it probably makes sense to have @chuck.schwer take a look at the new webSockets API to see if there is a race condition or something happening during startup of the hub.
I just updated my DEV hub to 22.214.171.124 and had to click SAVE on the Parent Device as well to restore the webSocket connection. Earlier, during my testing, the driver's Refresh call used to perform the same action as saving the device. I think I changed it in the last release to try to clean up the code a little.
This issue actually plagues any driver that does some kind of function that kicked off when its installed. I think it was telnet I was playing with that I also saw this. I get around it by creating parent apps to manage them.
You could also create a schedule to run a connect method every X minutes. If its already connected it will just close the connection and create a new one. But at least after a reboot it will eventually reconnect and continue functioning. I don't know if there is a way to tell if its already connected before trying to reconnect other than sending a random message and getting an error.