Discrete on/off IR commands

[prl]

I'm shelving contemplating work on this until an agreed and clear description of requirements appears in the issue tracker.

It would need to describe the required settings, and the actions for long- and short-POWER on both the remote and front panel in standby and running mode, the actions of other codes, and make clear the differences in behaviour between power-toggle mode and discrete POWER modes.

It would also need to accommodate the fact that long-POWER can't be generated on the front panel on either the T2 or T3.

[MrQuade]

Can we just make this as simple as ignoring the front panel button enhancements for now and continuing on the original track.
I really feel that those changes are unrelated to this feature and only serve to add confusion. There is nothing stopping us from tackling those issues later in another thread.

It seems clear now that the "wake only" approach proposed in the change request is not workable, so we need to add a single new setting to be able to toggle discrete IR mode on and off.
I had initially thought that the "wake only" option would be the less intrusive approach, and would not require a new setting to be added, but it is the front panel complication makes it unworkable.

Description of the new setting is as-per this post from earlier in the thread:
viewtopic.php?f=54&t=9955&start=100#p136685

This solution is simple and doesn't change the behaviour of any existing functionality, other than disabling the POWER button on the remote when the PVR is running.

My apologies to all for my part in the earlier distractions, I just hate seeing these new features spiral off into oblivion due to scope creep.

[prl]

Can we just make this as simple as ignoring the front panel button enhancements for now and continuing on the original track.
...

Changes in how the front panel button works are entailed in the changes proposed for "Wake only", whether the action function(s) for POWER return(s) False or True when the POWER action is set to "Wake only".

[MrQuade]

Changes in how the front panel button works are entailed in the changes proposed for "Wake only", whether the action function(s) for POWER return(s) False or True when the POWER action is set to "Wake only".

That's why I am saying to not using the "Wake only" approach.
If that approach is not taken, then the operation of the front panel need not functionally change at all. It will simply continue to operate according to the existing short-press POWER action as it does now.
The addition of the new "Discrete mode" setting means that we never have to set "Wake only" as the short-press action.

[prl]

... The addition of the new "Discrete mode" setting means that we never have to set "Wake only" as the short-press action.

I can't see how that can be done without changing how front panel POWER is handled, either.

It's also not clear to me how that setting would interact with the Action on short POWER setting.

[MrQuade]

I can't see how that can be done without changing how front panel POWER is handled, either.

It's also not clear to me how that setting would interact with the Action on short POWER setting.

The new discrete mode setting is a binary On/Off. When on, it will prevent the POWER button on the IR remote from operating while the PVR is in the on state.

In the current firmware, the front panel POWER button simply performs whatever action that the short-POWER button is configured for.

When the discrete mode is activated, the front panel POWER button will simply ignore the "discrete mode on/off" setting, and just does whatever the short-press POWER action is already configured to do.

[prl]

I can't see how that can be done without changing how front panel POWER is handled, either.

....

... When the discrete mode is activated, the front panel POWER button will simply ignore the "discrete mode on/off" setting, and just does whatever the short-press POWER action is already configured to do.

Yes, precisely what I said. It would mean changes to the way the front panel POWER button is handled.

[MrQuade]

Yes, precisely what I said. It would mean changes to the way the front panel POWER button is handled.

I see, but I believe that this has already been solved. I see that as just an implementation detail that was already discussed here:
viewtopic.php?f=54&t=9955&start=100#p136654

You just create a new instance of power_up and power_down, called for the sake of discussion NEWpower_up and NEWpower_down.

NEWpower_up and NEWpower_down will check for discrete mode being enabled and simply exit if it is enabled.

If discrete mode is not enabled, then it just calls the original power_up or power_down.

Front panel will always call the original power_up or power_down and hence be unaffected by the new setting.

[prl]

I'll wait for an implementable set of requirements in the issue tracker, then.

[MrQuade]

Ok, I'll put a revised description in the issue tracker later tonight.
My apologies for the misunderstanding of your request. I was thinking entirely in terms of function and not in terms of implementation. I was honestly trying to avoid proposing detailed implementation information, since I am completely ignorant of the code and coding standards that exist below the level of the keymap.xml file. I figured that was best left in your capable hands.

[prl]

Ok, I'll put a revised description in the issue tracker later tonight.
My apologies for the misunderstanding of your request. I was thinking entirely in terms of function and not in terms of implementation. I was honestly trying to avoid proposing detailed implementation information, since I am completely ignorant of the code and coding standards that exist below the level of the keymap.xml file. I figured that was best left in your capable hands.

Adding new keymap action names directly implies changes to the code if they are to be implemented.

[MrQuade]

Adding new keymap action names directly implies changes to the code if they are to be implemented.

Which is why I was loathe to delve into that detail and specify HOW you would implement changes to the keymap.xml to deal with the front panel. My proposals are offered as suggestions only.
As I said before, if you can think of a cleaner way of doing this, then by all means do so. I am primarily interested in the end result, which is the visible appearance of the GUI and the resulting functionality.

[Gully]

I don't believe there is anything heated going on here. We are just too-ing and fro-ing or work shopping ideas.

I was concerned about some usability aspects of parts of the proposal and felt some discussion may highlight my concerns and allow for a better alternative to be found. We are, after all, in the Developers Community area of the forum where this sort of discussion could be expected.

Not to get in the way if discussion is progressing constructively, I never said it was heated just that I wanted to check if it was progressing for Peter (prl)'s work and that we lose some of the you cannot change your mind, I have a right to post here parts which were not helping that process.

Anyway, Peter has posted what he needs now so happy to leave you all to it.

[peteru]

long-POWER can't be generated on the front panel on either the T2 or T3.

That should probably be considered a bug. If it's in the issue tracker, it may get fixed one day.

It may not be possible to program the T2 front panel to cause a board power cycle on the T2, but maybe a long press could be caught in the driver and cause a reboot. Not a bullet proof solution, but a step in the right direction.

Either way, both of these "forced restart" features are just a blue-sky features right now. No commitment.

[prl]

...
It may not be possible to program the T2 front panel to cause a board power cycle on the T2, but maybe a long press could be caught in the driver and cause a reboot. Not a bullet proof solution, but a step in the right direction. ....

I'm not sure how that would be done. The enigma2 app gets a "make" and a "break" POWER keypress event immediately on "make" of the front panel switch, and no other keypress events, no matter how long the power button is held down for.

That looks like front panel behaviour to me, but I have no way to be sure.

[peteru]

The driver talks to the IC in the front panel and generates events. Clearly the T2 event generation would need a revamp to correctly handle the button presses. As long as the front panel IC can actually report the key down and up states correctly, the changes may be in the "lot of work for minimal benefit" category, but not in the "impossible" category.

[MrQuade]

The issue has been updated.

Implementation details such as function names, setting names and descriptions are up to prl to decide based on his judgement.

[kidhazy]

My T4 will hopefully arrive this week, and I'm keen on the use of discrete commands for my Harmony remote.

Am I correct that the only implementation available at the moment is the customisations that Mr Quade points to in his first post until we get something in an updated firmware?

And I don't believe the codes have been requested to Logitech to load on the Harmony website (or at least I don't see them when I add a Beyonwiz T4 device)?

Are these two points correct?

Thanks.

[MrQuade]

Am I correct that the only implementation available at the moment is the customisations that Mr Quade points to in his first post until we get something in an updated firmware?

Correct. The firmware enhancements got a bit bogged down, but there is now an updated set of requirements in the bug tracker for work to proceed when time is available.

And I don't believe the codes have been requested to Logitech to load on the Harmony website (or at least I don't see them when I add a Beyonwiz T4 device)?

The new codes have not been added to the standard Harmony database yet, so in the meantime you will need some other means of generating the codes to allow your own Harmony to learn them. I did post a link to an open source Harmony database editor that might be of some use, and prl was using an Android application that was able to drive the IR port on his phone. I personally use a Philips Pronto remote to teach my Harmony units.

When the feature is properly implemented in the firmware, then we get Logitech to add the new discrete codes and clean up their database with all available remote types.

[kidhazy]

The new codes have not been added to the standard Harmony database yet, so in the meantime you will need some other means of generating the codes to allow your own Harmony to learn them. I did post a link to an open source Harmony database editor that might be of some use, and prl was using an Android application that was able to drive the IR port on his phone. I personally use a Philips Pronto remote to teach my Harmony units.

When the feature is properly implemented in the firmware, then we get Logitech to add the new discrete codes and clean up their database with all available remote types.

Cheers - time to break out one of the older Harmonys - and use the old Infrared Analysis Center webpage hack to enter a Pronto code to a device ... and then use the old Harmony to teach the new one.

[prl]

I've started working on the implementation of this. I think I have it mostly written, so I should start testing fairly soon.

One curious thing I found, though: back here I found that the T4 front panel could do long-POWER, but the T2 and T3 could not. I just re-tested with firmware 2016-03-25, and now the T4 no longer does long-POWER from the front panel.

Added: I just re-tested on the T4 using firmware 2016-01-25, and I got the same result. I'm not sure what I did there.

[MrQuade]

I've started working on the implementation of this. I think I have it mostly written, so I should start testing fairly soon.

I forgot to mention, thanks for jumping back on this prl. Very much appreciated.

As for the long-power stuff, would that possibly be the result of the additions to the "dreambox front panel" section now handling the power press instead of the "GlobalActions", or are you testing on an unmodified keymap.xml?
I think that if the long-press action can't be supported by all of the T series due to hardware constraints, then perhaps it should be left unused on the T4 as well. Though given that the T4 already has a bunch of features that only it supports due to its more powerful hardware, perhaps it can get a long-press action that gets "hidden" from the T2 and T3 setup menus.

[prl]

...
As for the long-power stuff, would that possibly be the result of the additions to the "dreambox front panel" section now handling the power press instead of the "GlobalActions", or are you testing on an unmodified keymap.xml?
I think that if the long-press action can't be supported by all of the T series due to hardware constraints, then perhaps it should be left unused on the T4 as well. Though given that the T4 already has a bunch of features that only it supports due to its more powerful hardware, perhaps it can get a long-press action that gets "hidden" from the T2 and T3 setup menus.

Long-press front panel POWER doesn't generate any "long press" or "repeat" events on any T series model. I think this is happening in the kernel driver for the device. The events simply aren't being generated, it's not that they're generated and ignored.

I've also found that mappings in device-specific sections in keymap.xml are searched after generic (not in a <device/> element) mappings. This has made the code to ensure that front panel POWER has an effect when discrete codes are enabled (and remote control POWER is ignored) slightly more complicated than if device-specific mappings had priority over generic mappings.

That all means that my mapping setup is slightly different from the one you suggested in the issue tracker.

I think that mappings for long-press of front panel POWER should be retained, because peteru has suggested that long-press front panel power might be implemented at some point.

[MrQuade]

I've also found that mappings in device-specific sections in keymap.xml are searched after generic (not in a <device/> element) mappings. This has made the code to ensure that front panel POWER has an effect when discrete codes are enabled (and remote control POWER is ignored) slightly more complicated than if device-specific mappings had priority over generic mappings.

That all means that my mapping setup is slightly different from the one you suggested in the issue tracker.

Sounds like an unfortunate design decision by someone else, but good that you can work around it in this instance I can see how that would make it tricky to allow the front panel button to operate differently to the remote's power toggle button (I hadn't considered that extra feature in the request). Whatever works!

I think that mappings for long-press of front panel POWER should be retained, because peteru has suggested that long-press front panel power might be implemented at some point.

Fair comment, but keeping in mind, since the T2's panel is fixed-function, from what I understand, long-press will never work there, so you'd still need to be able to hide any new options from the menus on the T2. Though that is a topic for another day .

[prl]

I've also found that mappings in device-specific sections in keymap.xml are searched after generic (not in a <device/> element) mappings. This has made the code to ensure that front panel POWER has an effect when discrete codes are enabled (and remote control POWER is ignored) slightly more complicated than if device-specific mappings had priority over generic mappings.

That all means that my mapping setup is slightly different from the one you suggested in the issue tracker.

Sounds like an unfortunate design decision by someone else, but good that you can work around it in this instance I can see how that would make it tricky to allow the front panel button to operate differently to the remote's power toggle button (I hadn't considered that extra feature in the request). Whatever works!

I think I know how to fix it, but I hesitate to, in case the "fix" breaks something else.

I think that mappings for long-press of front panel POWER should be retained, because peteru has suggested that long-press front panel power might be implemented at some point.

Fair comment, but keeping in mind, since the T2's panel is fixed-function, from what I understand, long-press will never work there, so you'd still need to be able to hide any new options from the menus on the T2. Though that is a topic for another day .

My recollection is that peteru was of the opinion that repeat- and long-POWER could be implemented on the T2. It's not code I've even looked at.

[prl]

There's also a bit of a wrinkle in peteru's otherwise nice and concise state machine:

• KEY_POWER2 (aka power off key)
  ON -> OFF
  OFF -> OFF
  STANDBY -> OFF

may not do quite what's wanted if the recorder is in standby to do a recording. I've currently implemented:

• KEY_POWER2 (aka power off key)
  ON -> OFF
  OFF -> OFF
  STANDBY -> OFF if (no recordings running or coming up soon) else STANDBY

Should it do something else?

[MrQuade]

• KEY_POWER2 (aka power off key)
  ON -> OFF
  OFF -> OFF
  STANDBY -> OFF if (no recordings running or coming up soon) else STANDBY

Is there a way to configure it so that it tells the PVR to power off after the timer(s) have completed? And by extension, will a subsequent KEY_POWER wake the PVR and cancel the post-timer shutdown? Sounding too complicated?

If that starts getting too elaborate, then yes, staying in Standby looks fine. It is likely that anyone who is recording in Standby, will already have their PVR set to shut down post-recording if that's the way they wanted it to work.

[prl]

• KEY_POWER2 (aka power off key)
  ON -> OFF
  OFF -> OFF
  STANDBY -> OFF if (no recordings running or coming up soon) else STANDBY

Is there a way to configure it so that it tells the PVR to power off after the timer(s) have completed? And by extension, will a subsequent KEY_POWER wake the PVR and cancel the post-timer shutdown? Sounding too complicated?

That the PVR would continue to obey the current rules when there are active recordings and a shutdown is requested as a button action is assumed. The shutdown code changes all "after events" for running and later contiguous recordings to "shutdown" (I still need to test that for timer recordings started from shutdown).

Further POWER2 presses will have no further effect.

The code also turns on the video while the

PowerOff while Recording in progress!
Entering standby, after recording the box will shutdown.

message is displayed, so that it's seen on the TV if the TV is on at the time. The message also displays on the T4 front panel display.

If that starts getting too elaborate, ...

I think it's already pretty much that elaborate.

[MrQuade]

Fair enough I am more than happy with it continuing to operate the way it already does then.
KEY_POWER2 from standby should act exactly the same as KEY_POWER does when KEY_POWER is configured as "Deep standby".

[prl]

Discrete ON/OFF/STANDBY/WAKEUP IR command implementation

Enabled by MENU>Setup>System>Button settings>Use discrete power codes. The option only appears when GUI Settings>Setup mode is set to "Expert".

The state transition table is expanded from peteru's original to show some of the relevant transitions due to recordings starting and ending. It doesn't show all transitions, and assumes that the "After event" for timers is "auto".

It doesn't reflect some of the anomalous behaviour of the recording state transitions, like:
ON_REC - [STANDBY] -> STANDBY_REC
sets running timers' "After event" to "go to deep standby", but
STANDBY_REC - [WAKEUP or POWER] -> ON_REC
does not set the timers back to "auto", and that
OFF - [(timer) recording(s) start] -> STANDBY_REC -> [WAKEUP or POWER] -> ON_REC
does
ON_REC - [recordings (all) end] -> OFF (though with a popup question)
rather than the transition diagram's
ON_REC - [recordings (all) end] -> ON

However, the intention is that it should work sensibly with all the states and with all the timer "After event" settings, so if you find something that's not in the transition diagram that doesn't seem to be the sensible thing to do, let me know.

If you think the state machine can be improved, let me know.

If you have suggestions for improving the description text for the Use discrete power codes setting, remember that the description box is nearly full already

The current text is:

Enable the use of the WAKEUP (wake from standby), SUSPEND (go to standby) and POWER2 (shutdown) codes from the remote, and prevent the POWER code from powering the Beyonwiz TN off.
Only enable this if you have a programmable remote set up to use the discrete power codes.

• [KEY_POWER] ("power on" key for short press when in discrete codes mode)
  OFF -> ON
  STANDBY -> ON
  STANDBY_REC -> ON_REC
  ON -> ON
  ON_REC -> ON_REC
• [KEY_POWER2] ("power off" key)
  OFF -> OFF
  STANDBY -> OFF
  STANDBY_REC -> STANDBY_REC
  ON -> OFF
  ON_REC -> STANDBY_REC
• [KEY_SUSPEND] ("standby" key)
  OFF -> OFF
  STANDBY -> STANDBY
  STANDBY_REC -> STANDBY_REC
  ON -> STANDBY
  ON_REC -> STANDBY_REC
• [KEY_WAKEUP] ("wake from standby" key)
  OFF -> OFF
  STANDBY -> ON
  STANDBY_REC -> ON_REC
  ON -> ON
  ON_REC -> ON_REC
• [(timer) recording(s) start]
  OFF -> STANDBY_REC
  STANDBY -> STANDBY_REC
  STANDBY_REC -> STANDBY_REC
  ON -> ON_REC
  ON_REC -> ON_REC
• [recordings (all) end]
  {OFF -> OFF} (unreachable transition)
  {STANDBY -> STANDBY} (unreachable transition)
  STANDBY_REC -> OFF
  {ON -> ON} (unreachable transition)
  ON_REC -> ON

Release alpha2

• Leaves the POWER2, STANDBY and WAKEUP codes permanently enabled.
• Corresponding changes to the settings texts as discussed in the topic.

Installing the patch

This patch has been tested only on 2016-0325 14:30 firmware, though I'd expect it to work on any recent version. This is code under development. I suggest you don't test it while your favourite program is recording.

To apply the patches, download the attached .ZIP file, and extract it. It will create a new directory/folder called discrete-installer, which contains two files, installer and uninstaller.

Copy the two files somewhere convenient on a T series box (like /home/root), then log into the box using telnet or ssh, change directory to the place you put the installer/uninstaller files. If you put the files in /home/root you'll be in the right place as soon as you log in.

To install the patches run:

sh installer

and restart the GUI (or reboot).

To uninstall the patches, log in and go to the directory as you did to install, and run

sh uninstaller

Make sure you uninstall before doing an online upgrade. Don't run the installer if you've already installed & don't run the uninstaller if you've already uninstalled.

You can check whether the patches are installed by logging in and running this on the box:

find /usr/lib/enigma2 /usr/share/enigma2 -name \*.bak

It should print nothing if the patch isn't installed, and it should print

/usr/lib/enigma2/python/Components/UsageConfig.pyo.bak
/usr/lib/enigma2/python/Screens/Standby.pyo.bak
/usr/lib/enigma2/python/Tools/KeyBindings.pyo.bak
/usr/lib/enigma2/python/mytest.pyo.bak
/usr/share/enigma2/setup.xml.bak
/usr/share/enigma2/keymap.xml.bak

if the patch is installed.

[MrQuade]

Sweet! I'll undo my changes, and try this one out when I am able.

Quick question though.

Enable the use of the WAKEUP (wake from standby), SUSPEND (go to standby) and POWER2 (shutdown) codes from the remote, and prevent the POWER code from powering the Beyonwiz TN off.
Only enable this if you have a programmable remote set up to use the discrete power codes.

So the WAKEUP, SUSPEND and POWER2 codes only get activated when "MENU>Setup>System>Button settings>Use discrete power codes" is enabled?
Was there a reason for that? I would have thought that having them active at all times would not cause any dramas. When the option is enabled, all it should do is inhibit the POWER from operating when in the "On" state.

[prl]

...
So the WAKEUP, SUSPEND and POWER2 codes only get activated when "MENU>Setup>System>Button settings>Use discrete power codes" is enabled?

Yes.

Was there a reason for that? ...

I thought that was what was intended. Perhaps not. I don't mind much either way. It's easy to change.

[IanSav]

Hi Prl,

The current text is:

Enable the use of the WAKEUP (wake from standby), SUSPEND (go to standby) and POWER2 (shutdown) codes from the remote, and prevent the POWER code from powering the Beyonwiz TN off.
Only enable this if you have a programmable remote set up to use the discrete power codes.

Would this text be a more concise:

Enable the WAKEUP (STANDBY -> ON), SUSPEND (ON -> STANDBY) and POWER2 (ON / STANDBY -> SHUTDOWN) discrete remote control codes. Limit the POWER code to only power on the Beyonwiz. Only enable this option if you have a remote control programmed with all these discrete codes.

Regards,
Ian.

[MrQuade]

I thought that was what was intended. Perhaps not. I don't mind much either way. It's easy to change.

If you can please. If the new codes are active at all times, the end-user can choose if they want POWER masked out or not.
(eg. At one point, IanSav mentioned that he would be ok with retaining the POWER function since his remote setup was immune to lost commands)

It also reduces the length of the description text .
I suggest a variation of my earlier suggestions:
Disables the short-press action of the remote control POWER button when the Beyonwiz is on.

[IanSav]

Hi Prl,

I don't see a problem with the WAKEUP, SUSPEND and POWER2 buttons being permanently enabled. As MrQuade notes, I could add these as extra options on my remote to supplement the existing POWER code that I would use in its default (ON and OFF) mode.

Regards,
Ian.

[MrQuade]

And just to check, you haven't changed the behaviour of long-POWER in any way at all?

[IanSav]

Hi MrQuade,

And just to check, you haven't changed the behaviour of long-POWER in any way at all?

If that question is to me then I have short POWER as the "Power / Restart" menu and long POWER as shutdown.

Regards,
Ian.

[MrQuade]

No, sorry, it was in regards to prl's changes. How you configure you Wiz is none of my business

[prl]

And just to check, you haven't changed the behaviour of long-POWER in any way at all?

No. It's unchanged.

[MrQuade]

Cool. I have tested out the patch, and it appears to all be working as advertised.

Thanks for the extra effort on the POWER2 transition to shutdown from a standby recording too. It is interesting that the same scenario when in the on state was already handled though.

I was testing on my T3 rather than the T4.

[peteru]

I anticipated that the discrete codes would always be enabled and that the only thing that the UI change would do is allow a toggle switch to ignore the normal POWER key, thus preventing the system from shutting down when POWER is received.

As far as the UI description goes, it could be a lot simpler. Describe the effect, not the implementation.

Code: Select all

POWER button: ENABLE/disable

When disabled, the POWER button will not shutdown your Tx. Use a programmable remote control to send a discrete power off or standby code instead.

Obviously the default would be ENABLE.

[prl]

It shall be done.

I'll try to get another alpha out before the weekend.

[prl]

I've changed it so that SUSPEND, WAKEUP and POWER2 are always active and the "discrete codes" switch only changes the behaviour of POWER.

I've only done a small amount of testing so far, but I should be able to make it available tomorrow as a second alpha. Today is shopping day: it's seniors' 10% off day at Belconnen Markets

[prl]

...
As far as the UI description goes, it could be a lot simpler. Describe the effect, not the implementation.

Code: Select all

POWER button: ENABLE/disable

When disabled, the POWER button will not shutdown your Tx. Use a programmable remote control to send a discrete power off or standby code instead.

Obviously the default would be ENABLE.

I'm not sure about that description. The effect of ENABLE isn't to allow POWER shutdown the PVR, it's to enable the action of "Action on short POWER" on short-POWER on the remote. It doesn't affect short-POWER on the front panel.

No matter what the setting is, long-POWER will still perform the action set in "Action on long POWER".

I haven't yet written the setting label or description.

[prl]

First cut at new setting text:

Enable short POWER action for remote

Enable short POWER actions from the remote while your Beyonwiz Tx is running. The front panel POWER action is not affected.
Use a programmable remote control to send a discrete power off or standby code instead.

[MrQuade]

I've changed it so that SUSPEND, WAKEUP and POWER2 are always active and the "discrete codes" switch only changes the behaviour of POWER.

Excellent

[IanSav]

Hi Prl,

How about:

POWER button: ENABLE/disable

When disabled, the POWER button on the remote control can only be used to power on your Beyonwiz Tx. Once on the POWER button is ignored. This supports use of the discrete remote control codes to directly select the required operating, standby or shutdown mode.

Regards,
Ian.

[prl]

It doesn't disable the remote POWER entirely. It only disables short-POWER. Long-POWER isn't affected by the setting.

[IanSav]

Hi Prl,

Then how about:

POWER button: ENABLE/disable

When disabled, a short press of the POWER button on the remote control can only be used to power on your Beyonwiz Tx. Once on a short press of the POWER button is ignored. This supports use of the discrete remote control codes to directly select the required operating, standby or shutdown mode.

Regards,
Ian.