MCE Controller Plugin for Keyboard and Mouse Interface

I threw together a quick and dirty plugin with the more complex WoL code:
MCEController.plugin - 2023-05-27-TEST.js.txt (20.6 KB)

If this works, I will clean it up a little and add some additional plugin settings. For now, this way you only need to copy/paste the new code in and not worry about any additional plugin setup.

To use it, your Host setting needs to be an IP address. Also, it currently doesn’t use a port by default, but if you want to force it to use port 9 (as your wolcmd takes as a parameter) you need to set the WOLPORT variable up at the top to be "9" (it might work if it’s the number 9, but it is intended that you give it the string).

I haven’t had a chance to test this myself, but wanted to try to keep things moving for you. Please let me know what you discover and/or if you have any questions/problems.

1 Like

Tested by copy-pasting the code from this plugin and replacing my existing one. It works a treat! Thanks very much for quick fixing this - your support is amazing.

FYI, my setup was tested with the WOL port left blank and set to ‘9’ (to mimic the wolcmd wake-up). Both ways it reliably wakes the HTPC up now (tested 20-30 times with various sleep durations). :sunglasses:

It got me thinking on whether there is any way of knowing the power status of the HTPC in THR? (similar to the .Switch property on other devices) Asides being able to provide status feedback for the user, it would also be handy for other reasons (triggering events based on the HTPC on/off states.)

What do you think…is this possible?

Thanks for testing, @Shuggy and I’m glad it worked! I have updated the top post with a more polished version of the plugin. This one adds some additional Settings, so technically I think you need to delete and re-add the plugin in its entirety (otherwise the new Settings don’t get added). The defaults are set based on what you discovered (using the IP address and port 9) because, as far as I know, MCEC only runs on Windows, so those seemed like the best defaults for this plugin.

I tested it out and it seems to work for me as well, but I did rearrange the code a bit since I didn’t like where the WOL stuff was located. It should be cleaner and hopefully I didn’t break anything in the process :slight_smile: As always, please let me know if you have any problems.

Regarding knowing the power status of the HTPC, I think the answer is no. There’s nothing magical about the Switch Attribute–the value for it just gets set based on feedback from the device in the plugins/built-in devices that support it. But if the HTPC is off, there’s no way to query that (you might be able to infer it based on a connection timeout, but that is pretty clunky because THR doesn’t provide reliable timeouts on connection attempts, as I recall, and it takes a long time).

I think some home automation hubs may have a little better support for tracking the state of a PC device (using pings or something), but I’ve never played around with those–I got into THR to control my home theater setup and not for more general home automation. That might be your best avenue, at least for triggering events, I’d think.

All of that said, in other plugins I have added some internal psuedo-power state tracking, just to reduce trying to connect to a device that I don’t know whether it is on yet not, so it avoid some timeout-type behavior which is annoying. That might be possible here, but I’m not sure it really makes sense–there’s no harm in sending WOL when it’s already on, so the assumption is that it is always on, and the internal power state tracking adds some complexity.

1 Like

Yeah, that’s fair enough - it was just a ‘wish list’ kind of thing for completeness. I too am only really interested in controlling my AV setup (and a few lights/cameras) so I want to avoid adding extra devices, controllers and complexity into it all for negligible benefit.

Excellent! Great work :+1:
I’ll give the new version above another test. I was about to edit my post above (before I saw you had replied) because I noticed this morning that the HTPC did not power on with the WOL. :confused:
Even though I did multiple tests with it over the weekend, the longest I left it to test the wakeup was probably half an hour or so. It seems that leaving the unit overnight, the WOL no longer works. No idea what could be happening there - but I’ll try the new version (fully removing the plugin and re-adding it) and maybe that will work.

I’ll give the new version a test overnight and let you know if it powers on or not in the morning. Thanks!

I’m concerned to hear that the WOL didn’t work after an overnight sleep. Not sure what would be the issue there–maybe Windows goes into a deeper power-save mode after some amount of time? I haven’t tested such a scenario myself, but like your prior tests, it did wake up after some shorter-period tests. One thing I did notice is that it takes 10-15 seconds for Windows to wake back up after sending the PowerOff (MCEC standby), which was surprisingly longer than I’d expected. Anxious to hear what you discover.

Just to clarify - I meant that only the first wake-up didn’t work after the overnight sleep. After I had woken up the HTPC by pressing the power button, the WOL does work as before (for shorter-term sleeps.)

I was worried there may be inconsistencies in the sleep mode, hardware and general setup of PCs that might affect how they behave with the MCEC controller and WOL. Hopefully we will get a positive result when I test it again tomorrow morning and I’ll be able to avoid troubleshooting every power setting known to man. :crossed_fingers:

Hmmm…I don’t experience that. If my HTPC wakes up, it triggers pretty much instantly and I just have to wait a few seconds for the TV display to show the desktop. The reason I can say this with confidence is because whenever my HTPC starts ups or comes out of sleep, the CPU fan audibly whirs up - something that I never thought would come in handy but it helps determine when a WOL occurs in this instance.

Anyway - I’ll let you know what happens in the morning with the new WOL.

@hotelfoxtrotnovember Reporting in!
The WOL did not work again this morning - the activity button turns on the TV, etc but not the HTPC. With the HTPC still in sleep I then ran the wolcmd script on another network PC and it woke up the HTPC immediately.

So I realised (in a rare moment of clarity) that the issue occurs because the THR app is closed (or I turn off my tablet) and the app connection to the MCEC controller on the HTPC is severed. Upon re-opening the app to run the WOL cmd it obviously cannot reconnect to the HTPC because it is sleeping. I’m assuming that if the app is left idle for long enough the connection may also timeout.

To test this, I added single-command buttons to my setup (HTPC “PowerOff” & HTPC “PowerOn”). It took me 10 seconds to reproduce by simply sleeping the HTPC and then minimising the THR app on the tablet (the app was still running in the background, I just returned to the desktop.) That alone was enough to kill the connection - when I maximised the THR app, the WOL button did nothing. I’m sure you’ll be able to replicate this by doing the same thing on your ipad.

What I find strange here is that the HTPC does not wake up, but once manually powered on, the rest of the activity commands are executed (as previously discussed.)

Currently I have my HTPC sitting in the open to test, so it’s not a big deal to power on manually. But it will eventually be hidden away in a wall cabinet so it won’t be easy/practical to keep manually powering it on (especially for the rest of the family). Is there any way at all you can see this WOL working?

Thanks for your patience and support as always!

I think you are right about what is happening: when you put the HTPC to sleep and then close THR, THR drops/closes the connection (from its perspective) with the HTPC. Consequently, when you restart, the plugin’s onConnect() is called, it attempts to establish a connection the MCEC, and that hangs waiting for a timeout. I’m actually a little (but not a lot) surprised that pressing the button that sends the PowerOn doesn’t go through anyway, since I have observed that THR will interrupt onPoll() when a button push comes in. Apparently that isn’t happening so the button push is getting ignored at least until the connection timeout happens.

Regardless, I think it’s a simple fix. Go into onConnect() and just delete/comment out these last few lines:

    // connect to the MCEC server
    debugLog("  connecting...");
    mcecConnect();
    debugLog("  connected");

It shouldn’t break anything because mcecSend() checks that the connection is established before trying to send and the code now handles the WOL stuff before it even gets that far, so that should go just fine. Basically it just defers the connection to MCEC until the first command actually needs to be sent. That has the downside of introducing a slight delay for that first command, but I don’t think there’s another option since the timeouts can’t be controlled within THR.

Sorry for the somewhat rambling reply–I happened to check the forum for new messages shortly after you posted so I took a quick stab at what was wrong.

1 Like

Thanks for the quick response - especially trying to resolve it on the fly. At first attempt this fix didn’t work, but I’d only commented the code in my project plugin. So I removed the plugin completely from the project and re-added the new one with the code change. Works every time now, whether the app is minimised, closed or the tablet is turned off/on before WOL. The longest HTPC sleep I have tried so far is ~2 hours and it woke up immediately on the WOL button so it’s pretty much a certainty that it will work overnight (or indeed after days/weeks.)

Thanks so much for your efforts. This plugin and your fixes have made a huge difference to my setup. :+1:

I’m moving onto to fully testing my tweaked keyboard setup, browser buttons and shortcuts/scripts I’ve setup per activity so I’ll let you know if there are any issues with anything.

1 Like

Glad to hear it! I’ll hold off a few days on updating the plugin again just in case you find anything else that needs to be tweaked :slight_smile:

1 Like

Cool. I have only found one issue so far with media/shortcut buttons not working on a particular website - but they work on all others I have tested, so it’s likely the website/player that is the issue.

If I get the time at the weekend I’ll piece together what is going on, but it’s unlikely that it’s a THR/plugin issue as I say.

Thanks,
Shuggs

Hey! @hotelfoxtrotnovember
Life and holidays have got in the way of continuing my remote setup recently but I’ve managed to get back into it and do some pretty thorough testing on the MCEC plugin, keyboard and mouse. Here’s what I have found…

1. WOL has worked flawlessly, even when I returned after a week away and the HTPC had been physically unplugged. Works a treat!

2. Touchpad selection. As we previously discussed, this refers to holding the mouse down and drag-selecting text/areas/items. Refer to previous post passage…

This is working, with one caveat - it feels like it is overly sensitive and I (and more so my partner) find a lot of the time we’re simply trying to accurately focus the cursor on a certain area/button it often triggers the drag-select mode instead. I feel like this may be much less intrusive with a longer delay on the drag mode being enabled - maybe 0.75 > 1 second. At least this way, we’d know to trigger the drag-mode that we very deliberately need to hold down for x time.
To avoid any wasted time/effort up front on your behalf, is there any way this can be altered or even exposed on a variable much like the other mouse-related variables in the index.html??

3. As mentioned in my last post, various browsers/players do not work with keyboard shortcuts. It seems that sites like YouTube work correctly because they use native keyboard commands. However, some of the subscription/TV sites obviously use third party media players and UI so the key shortcuts do not work or function incorrectly.

Here is a good example for you (although if you’re in the US you will be unable to test this out). Using the BBC iplayer, the following shortcut keys will trigger these commands:
- Back 20s (LetterJ / DirectionLeft)
- Skip 20s (LetterL / DirectionRight)
- Play/Pause (LetterK)
- Fullscreen (LetterF)
- Subtitles (LetterS)

If I use a physical keyboard all of the above commands work perfectly. Using the THR remote, if any of these keys are pressed, they only force the player overlay to appear - none of the actions (skip forward, pause, fullscreen, etc) are actually performed. I’ve tested this in Chrome, Opera & Vivaldi browsers with the same results. There are other sites/players I have seen similar behaviour.
Interestingly, my Logitech Harmony remote does work with the iplayer and other sites - and looking at the key assignment in the Harmony app, it uses the exact same commands (DirectionLeft, ‘F’ key, etc).
As I am a dunce when it comes to the code side, keystroke sending/commands, etc I wondered if you had any inkling on how to get this to work?
Is this related to your very first post where you mention the way the keys are sent/registered in MCEC?

As always, thanks for your help!

Apologies for the delay, I was out of town and just saw your post. Glad to hear WOL is working!

Regarding the dragging mode, the MouseHelper uses hammer's default press detection, which according to the docs here is 251 ms, if I’m reading it correctly. You should be able to modify this line in the index.html:

pressRecognizer = new Hammer.Press();

to be something like:

pressRecognizer = new Hammer.Press({
    time: 750,
});

I don’t have time to test this right now so I’m going off the syntax for configuring some of the other recognizers already in that file, but I’m fairly sure that should work. If that works for you, please let me know and I can add it to the main configuration section.

Regarding the last point, I only use Plex on my HTPC and, on occasion, use the keyboard for general Windows configuration/maintenance, so I can’t say I’ve encountered those specific issues. But, as you note, it may be related to the way MCEC sends keystrokes/its virtual keyboard–I don’t think this is a THR/plugin issue. I wonder if the Harmony remote uses a different keyboard-type interface/mechanism to send those commands? The creator of MCEC was fairly helpful when I reported a number of bugs/inconsistencies (not related to this), so it might be worth trying to open a ticket with him to see if he has ideas on MCEC's interaction with such third-party media players. Sorry I can’t be more help with that one, but there are aspects of MCEC that still baffle me somewhat :slight_smile:

1 Like

Thanks for the quick fix - that code replacement in the index.html is spot on. After some tweaking we’re now finding it much easier using a longer delay of ~700 which pretty much eliminates the accidental drag-select triggering. Much happier to have the drag-select as a more deliberate action, so thanks for making it happen!

I managed to find a workaround to get the iplayer media keys working - by creating scripts in Autohotkey. I’ve been using Autohotkey scripts for various shortcuts and maintenance tasks but realised I could just setup THR to use simple Autohotkey scripts that trigger the keys locally on the HTPC itself. The direction keys worked straight away, but I found that the letter keys (s,f,k, etc) only work if they are lower case so there must be some case-sensitive shenanigans under the iplayer bonnet.

FYI, even though the autohotkey scripts are basic, if anyone is interested here is an example of the ‘s’ key which toggles the subtitles in iplayer:

#NoEnv
SetWorkingDir %A_ScriptDir%

; Send the ‘s’ key (case sensitive for iplayer)
Send {s}

Exit

I haven’t had a chance to test the other media players yet - if I have any issues that Autohotkey can’t fix, I’ll contact the MCEC guy as you suggested. Thanks for the tip!

This plugin & MCEC has really transformed our home AV setup in general. Even my partner now prefers using THR on a tablet, to the point where she can’t go back to the handheld remotes because they lack the speed and functionality. :smile: :+1:

1 Like

I’ve updated the index.html file in the main MouseHelper post so that this is now easier for others to change the minimum press time configuration. Thanks again for your help with this, @Shuggy!

1 Like

No problem! @hotelfoxtrotnovember It’s all you man - your support and work on this is incredible, so thanks again. :index_pointing_at_the_viewer: :+1:

I’ve been tinkering with my layout (changed to UK spec, moved some keys around, removed redundant stuff, etc) and started building a UI that I can patch into my activity pages. The idea is that the keyboard is clean and compact - as I use it in portrait mode. I’ve removed the arrow keys and will add a d-pad, zoom controls and windows shortcuts underneath.

The mousepad is anchored at the top, below is a scrolling panel which contains the activity-specific controls, media player panels, keyboard, etc - so the mousepad is always present, but you can scroll through the controls below.

Here’s a quick (compressed) gif of the current setup using image buttons (this took a lot of time rebuilding the buttons to swap images and avoid the android ripple anim on my tablet). :sweat:

Shug_Keyboard1

1 Like

Hey @hotelfoxtrotnovember
Just a quick question regarding the touchpad/scrollbar: Is there any way of triggering feedback when the touchpad or scrollbar are pressed?

As the touchpad is done on the MCEC side I’m not sure if there’s any way THR can know when it has been pressed. I tried adding an event trigger to the WebBrowser element, but THR just threw an error when the page was loaded.

Cheers!
Shuggs

I’m not sure. What kind of feedback did you have in mind?

Image, text, anything really. Currently, I trigger ‘IsPressed’ images for buttons - so I already do this for the left and right mouse click.
Something similar for interacting with the touchpad (and ideally the scrollbar separately) would be nice.

THR WebBrowser elements do not seem to have any trigger functionality other than Loaded/Unloaded though. So it feels like there would need to be a change on the THR side with WebBrowser interactions (even if there was something to track/monitor on the MCEC/mousehelper end).

Just thought I’d ask in case I’d missed something blindingly obvious.

This is a good news, bad news, situation, I think.

The good news is I think what you want to do can be done. In the index.html file, I think in the various hammer.on() handlers, that’s where the feedback effects should be added. If I’m remembering how this all works correctly, those fire every time an event trips. In addition, the scroll region has a separate scrollHammer.on() handler, so those should be able to be handled separately.

The bad news is I have no idea how to actually provide the feedback. My knowledge of html/javascript in this context is paper thin, unfortunately. Maybe someone with more skills than I in that department can help out?

1 Like