Toggle functionality for "boolean" types

[magx2]

Hey,

Writing DSL functions I found out that it would be really nice to be able to toggle types to opposite, i.e. You got command ON from item x and you want to send command OFF (opposite command) to item y:

val oppositeState = if(x.state==ON) OFF else ON
y.sendCommand(oppositeState )

vs

y.sendCommand(x.state.toggle)

WDYT?

[spacemanspiff2007]

How about a TOGGLE command which can be sent to the corresponding item type?

[magx2]

Is there a toggle command?

[spacemanspiff2007]

Currently not - I am suggesting it might make sense to implement one.

[magx2]

Currently not - I am suggesting it might make sense to implement one.

No way. I already saw long discussions about it. If you want you can do it

#947
eclipse-archived/smarthome#4638
https://community.openhab.org/t/controlling-a-dimmer-item-by-physical-buttons-various-questons-to-achieve-clean-solution/131128/15

[andrewfg]

Umm. I have an issue with your word 'toggle' .. its dictionary definition is "to switch a feature on a computer on and off by pressing the same button or key" .. in other words the 'toggle' operation executes TWO operations e.g. ON=>OFF=>ON.

So I suggest some other word like 'invert' or 'reverse' or 'flip' ..

[magx2]

@andrewfg

I think you misunderstand the Cambridge dictonary (or I did).

Look at examples of usage:

• Use this key to toggle between the two typefaces -> Use toggle method to toggle between states
• By toggling this key, you can switch the italics on and off. -> By toggling this method, you can switch the state on and off

Edit:

And definition from Google (of course without link to source...)

[mherwege]

I believe toggle is a verb in this context. It implies an action to take. This is not the case in what you coded. There is no state change involved in the original item. It shouldn't be a verb. What about something like inversed?
To be perfectly honest, I don't see the value. While it may simplify the rules code a little bit, it can also confuse, as is also apparent from the discussion on the terminology. It is not an attribute of the the original state, but rather something you want to apply to another item's (or the same item's) state. So I actually think we should not do this and keep it explicit in the rule. But that is my opinion on it.

[rkoshak]

Umm. I have an issue with your word 'toggle'

At least in American English at least, "toggle" is the correct term for something that switches the current state of a switch regardless of the state it's already in. That's the common usage for that term. I cannot speak for other English dialects.

I imagine if a way to implement a TOGGLE command in a way that doesn't require modifyinmg all the add-ons that implement Switch Channels it might be more acceptable than where the past discussions went. And most of the controversy in the ESH thread at least was around whether discussion about whether it was a good idea or not should be allowed or if the PR should just be merged without discussion.

I personally am not convinced by the arguments against a TOGGLE command. It should be up to the admin of each individual OH instance to decide whether TOGGLE is a dangerous command or not and configure their OH instance accordingly.

y.sendCommand(x.state.toggle)

You'd still need a test for NULL and UNDEF as that would obviously fail with an error. I'm not sure this approach buys us much. In fact

y.sendCommand(if(x.state == OFF) ON else OFF)

is preferable becuase if the state is NULL or UNDEF the switch will be commanded OFF instead of throwing an error.