sames here, it seems the EVT_MINUS_BREAK is not properly handled. Any value changed with the minus button on a X9D+ (not 2019) has the effect when release the minus button the value returns the previous without any effect.

step to reproduce:
select a value, change it with minus , release minus button , see value change back to what is was at first

nothing happend till now

referencing to OTX: opentx/opentx#6852 (comment)

betaflight event.lua has the following:

dial = {
    left = EVT_ROT_LEFT or EVT_UP_BREAK,
    right = EVT_ROT_RIGHT or EVT_DOWN_BREAK
}

removing the OR condition make script to work properly.

maybe the Horus or Taranis 2019 wheel commands are mixed up with the old button commands the wrong way...?

can you please test if this in the events.lua fix the issue ?

dial = {
left = EVT_ROT_LEFT ,
right = EVT_ROT_RIGHT
}

This code was added in #135 by @raphaelcoeffic. Maybe he has got an idea what needs to be done here?
As it is now with these scripts, we are supporting a number of different hardware types with different switches / toggles / wheels, so we need to thread carefully and do thorough testing to make sure we don't just shift the breakage to different hardware.

Yes, it does (I first kept the wrong half of the expression, thinking the ROT_ identifiers were supposed to fit the Taranis 2019 with ROTation wheel... :-))

So dropping the EVT_UP_BREAK, EVT_DOWN_BREAK parts of the OR expression does the trick on my Taranis 2013 X9D+

Ok, good.

Maybe the Taranis 2019 identifiers are pre-initialized to values which make the OR expression go wrong for a Taranis 2013?

well it seems like opentx 2.3 has wrongly EVT_DOWN_BREAK assigned to minus

As it is now with these scripts, we are supporting a number of different hardware types with different switches / toggles / wheels, so we need to thread carefully and do thorough testing to make sure we don't just shift the breakage to different hardware.

We have discussed this internally with the other opentx devs and it seems that some events have been broken for LUA since 2.3. We will need to look into it.

However, it should be time to think about moving to the new virtual events, which should normally bring compatibility with all radios with minimum effort.

@raphaelcoeffic: You seem to be in the loop on OpenTX development, would you be able to propose a change to move to virtual events?

Yes, That’s the plan. I don’t have much hardware to test on, but I guess a lot of people are eager to test ;-)

@raphaelcoeffic: Well, the hope would is that if we move to virtual events that are then mapped to hardware switches / wheels by OpenTX then the mapping to the different hardware types would have been done in OpenTX when they were added. 😉

@mikeller that’s the idea, yes. The feature is already in OpenTx, so we need to adapt the key mapping, and that’s it.

I just reviewed the virtual events to make a difference between INC/DEC for changing value, and PREV/NEXT for navigating the UI, since x9d(+) has those reversed. Should be merged shortly

And yes @mikeller , thats exactly why those virtual events where created, so that LUA developper don't have to worry about that mess :)

@3djc: I like that. Can you alert us / propose a change when the fix for X9D+ has been merged - I think a considerable part of our users are using this hardware.

@mikeller @raphaelcoeffic Here it is: opentx/opentx#6890 (thank you @3djc !) :-)

first PoC for the virtual events: #250

@raphaelcoeffic, @3djc: Any chance that this is fixed in 2.3.1?
If so I think the right thing to do is to release a version of the lua scripts that include the changes needed for Betaflight 4.1 now, and tell users to update to OpenTX 2.3.1.
This will then allow us to give the 'virtual events' changes in #250 some weeks time for thorough testing / feedback, and after that we can do another release that includes them.
Thoughts?

@mikeller Just added #251 for this purpose, let's see if that works better. It does for me on the simulator, but I don't have any X9D+ for testing in real...

no, not resolved yet on X9D+ ... #255