Sender Id and options for spoofing

[Skeen]

Hi,

I installed the addon, and configured a rocker switch via the discovery. I can see the state of the buttons are being picked up nicely, and everything seems to work.

Currently the rocker switch is controlling a light-bulb, and clicking the switch turns it on or off (Channel A). Changing the state in the web-interface does nothing.

I believe that I am supposed to configure the sender_id on the rocker switch, such that a unique device id can be generated, and then program this ID into my receiver / actuator, which actually controls the light bulb.

• Is my understanding on this correct? - This is the intended way to configure the system?

The reason I'm asking, is that I (perhaps wrongly) assumed that it would just work out of the box. That the USB300 would spoof / send the device id from the rocker switch, and send an identical message to the one generated by toggling the switch.

• Is there a reason why this is not the case? - Is it not technically feasible / impossible to do?

I would argue, that spoofing would be a reasonable feature (assuming it's possible), as it would remove the burden of reconfiguring / reprogramming receivers to accept the new device id.

[fruggy83]

Hi @Skeen,

Is my understanding on this correct? - This is the intended way to configure the system?

You are absolutely right. If you want to send messages to your actuator, you have to set a sender Id. This id is used to generate an unique enocean device id, which has to be taught in the actuator.

Is there a reason why this is not the case? - Is it not technically feasible / impossible to do?

There are mainly two reasons why this is actually not possible.

1. It is not the intended way to send messages with an enocean gateway like an USB300. Each device (in this case your virtual openhab rocker) must have an unique enocean device id, that has to be paired with your actuators. You could do evil things when you send messages with an id of another device, like switching the light on or off of your neighbour.
2. The main reason why I developed this binding was, that I do not want to simulate rocker switches but send directly On/Off or Up/Down/Percentage commands to my actuators. Instead of using a rocker switch thing to control your devices, you should use an A5-38 device for switching/dimming or request a new EEP for your actuator if it is not implemented yet. The rocker switch thing was initially intented just as a sensor to react to your physical rocker switches. Sending messages with rocker switches was introduced later for backward compatibility reasons (some older actuator can only handle rocker switch messages).

However when I understand the docs correctly nobody prevents sending messages with any id. So give me some time and I will see what I can do. The next two days I am quite busy, but on Wednesday I should find some time.

Best regards Daniel

[Skeen]

Hi Daniel (@fruggy83),

I accept the reasoning behind wanting a decoupled system, such that sensors and actuators aren't directly related. However this addon has several (in my honest opinion) challenges with that regard.

First off, the rocker rocker switches currently function in a toggle mode, i.e. clicking the A1 button sets the openhab widget to on, and clicking the A0 button sets the openhab widget to off.

• Is there any way to make the switches send messages instead? - Or to do as the old openhab1-addon for enocean did, simply have quick 'flick' of off-to-on-to-off.

The reason I'm asking, is that if you do indeed want to decouple the switch from the actuator as suggested (which is a fine idea), then the rocker switches should be implemented as they are; 'event devices', not toggle-able switches. - Adding the toggle-ability, should it be desired, could then be done simply using rules.

Now, I would argue with the decoupled approach, the current model isn't very purist. Say my current actuators are stupid and only accept rocker switch message (because they are old, or whatever). Now I'd configure my rocker switches as inputs, and simultaneously as outputs for my old actuators.

• This seems wrong, as the single configuration item now serves two purposes, and it defeats the initial point of the decoupling.

As such, my approach would be to configure the physical rocker switch, such that all they do is sensing and provide click-events to openhab. Then define virtual rocker switches for all my old actuators, for sending signals to my relays, and combine these using rules.

• Is this the best way I could currently implement a decoupled system?

[fruggy83]

Hi @Skeen,

you are absolutely right. The current integration of rocker switches is not well done yet. Adding the sending capabiltiy to the rocker switch sensor was just a quick and dirty approach. I also talked about this fact with @kungfoolfighting.

My approach would be the following:

• I divide the rocker switches into two entities for sensing (the physical rocker switch) and emitting (a virtual rocker switch)
• These rocker switches should not be treated as real things but as drivers for your actuators
• So you have to create a virtual item (switch, dimmer or rollershutter) and connect this item to the sensing rocker switch. This connection is done by an inbound profile, so you do not need to create a rule. The profile updates the state of the item when a trigger event occurs. Furthermore you have to connect the item with another emitting rocker switch to send a message, when you change the state of the item (outbound profile).

I do not think that you really need a rocker switch thing with this mentioned 'flick' ability, as you do not want to model a rocker switch but a light or a rollershutter. If you really have a use case for this, I can implement it later.

By the way sending an enocean message with any id is not possible with an USB300, look here . The USB300 does not send such messages. So spoofing is not possible.

Best regards Daniel

[Skeen]

Hi Daniel (@fruggy83),

I really like the idea of introducing virtual devices for decoupling sensing and emitting.

• When do you expect to be able to look into this?
• Are you welcoming pull requests?

Can you explain to me what you mean by 'inbound/outbound profile', or alternatively point me towards some relevant documentation. I'm not sure I understand your argument about these and how they handle the connection between the physical rocker switch and the virtual one.

I agree that you do not want to model rocker switches, but rather lights or roller-shutters. The argument for actually modelling your physical rocker switches would be to debug your setup, or to have low-level interactions.

The argument for the such a low-level interaction interface, including the 'flick' ability, would be modelling the physical hardware as closely as one can, the switches seem to send PRESSED / RELEASED signals, rather than ON / OFF signals.

I could imagine mapping my rocker switches using such PRESSED / RELEASED, such that timing is taken into account. Examples:

• You click the button and hold it, then after a set time you let go. The time delay can now be mapped as a number in openhab to the volume of your speaker system (using simple ON/OFF signals you wouldn't be able to derive timing).
• The light that's being controlled is already on, now you fire yet another ON event (PRESSED + RELEASED), a simple rule checks that the light is already on, and thus the behavior changes to changing the color / mode of the lights (using simple ON/OFF signals you wouldn't be able to detect further ON events, when you're already registered as ON).

Thanks for you for the link regarding the feasibility of spoofing.

[fruggy83]

Hi @Skeen,

When do you expect to be able to look into this?

I found some time yesterday to do the implementation and will do a deeper testing today. If everything works as expected (the first tests were promising), I will push the update today.

Are you welcoming pull requests?

I always welcome pull requests and such profund discussions.

The profile concept was introduced into openhab with version 2.2 (if I remeber correctly). So you will not find so much documentation about this concept yet. You can look here and here as a starting point. You can imagine these profiles as translators which sit between your things and items. A rocker switch will emit Pressed/Released events which get translated to On/Off (for example) by a profile. As these profiles are stateful you can even do some time releated translations for dimmers/volume changes. For example I link a NodOn rocker switch to a hue light bulb to dim it up/down or switch it off/on without any rule. I am using just the (system) RawRockerDimmerProfile. Furthermore I also implemented a profile to control a player item with a rocker switch (RockerSwitchToPlayPauseProfile). So these profiles are simplified translation rules which makes the interaction with rocker switches a lot easier. However you are not forced to use profiles. You can always write rules which reacts on the pressed/released events to do more complex things.

Best regards Daniel

[Skeen]

Hi Daniel (@fruggy83).

It sounds super lovely that you already had time to look into it.

• I wanted to look into your project and the code myself, but I won't be able to in the next two weeks, due to paid- and voluntary-work taking up my time.

It sounds like profiles implement exactly the transformations I'd like to do, and cover all my use-cases for the low-level / 'flick' API. - I'll have to look into those, and the two links you provided.

[fruggy83]

Hi @Skeen,

I finished my work on virtual rocker switches yesterday. I implemented the following changes:

1. Rocker Switch can only be used for sensing (represents a physical rocker switch)
2. I Introduced a virtual Rocker switch thing, which can send rocker switch messages a. It should not be used directly, but can be linked to your switch items with a profile b. It owns one (it simulates only one channel of a rocker switch) String channel to send messages (DIR1_PRESSED, DIR1_RELEASED, DIR2_PRESSED, DIR2_RELEASED) => no need to handle the 'flick', long, short, double press can be easily simulated in rules
3. Introduced a profile (RockerSwitchToOnOff) to connect your virtual and physical rocker switch to a switch item a. Profile UPDATES the STATE of item when physical rocker switch gets hit b. Profile SENDS COMMANDS (Press, Release) to virtual rocker switch thing, when item gets changed c. Profile can be configured to send toggle (upper [toggleButtonDir1] or lower button [toggleButtonDir2]) or rocker switch (On = Upper button, Off = lower button [rockerSwitch], default mode) messages. Furthermore the duration of a button press can be configured, too (default 250 ms). As this configuration is done on link level, it is possible to control two actuator with one virtual rocker in toggle mode.

Items look like Switch vLight "vLight" {channel="openocean:virtualRockerSwitch:ee492842:virtualRockerswitch" profile="openocean:rockerswitch-to-on-off",switchMode="rockerSwitch", duration=250], channel="openocean:rockerSwitch:593cf7cd:002b687e:rockerswitchB"[profile="openocean:rockerswitch-to-on-off"]} String VRS_CMD "CMD" {channel="openocean:virtualRockerSwitch:ee492842:virtualRockerswitch"}

And optional rule for debugging or advanced stuff with VRS_CMD item rule "VRS test" when Channel 'openocean:rockerSwitch:AABBCCDD:XXXXXXXX:rockerswitchA' triggered DIR2_PRESSED then VRS_CMD.sendCommand("DIR1_PRESSED") VRS_CMD.sendCommand("DIR1_RELEASED") end

What do you think about this changes? Do you need something else? Next steps: implement dimmer and rollershutter profiles.

Best regards Daniel

[martink2]

Hi @fruggy83,

I have successfully implemented the above and it is working well so far. A small suggestion/feature request if i may.

The virtual rocker currently always sends events via the A channel. To conserve sender ID's and also in my case to not relearn half of my actors I would ask to maybe change virtualRockerswitch to virtualRockerswitchA and virtualRockerswitchB to be able to send AI/AO and BI/BO via the virtual Rocker or alternatively use a channel=A/B in the profile.

What do you think about using both channels?

Thanks for your great work.

Martin

[fruggy83]

Hi @martink2,

sorry for my late answer, I should have said, that you must empty the openhab cache and restart openhab when you update this binding. Fortunately you managed it by yourself.

Feature requests are always welcome and will be considered as soon as I find time :) I will definitely implement two openhab channels for both rocker switch channels A/B as you suggested. I first wanted some more user testing and see if this virtual rocker switch concept is accepted and usable before I spend more time in new features.

Best regards Daniel

[martink2]

@fruggy83 Thanks a lot for the great support and the implementation of the B Channel in the VirtualRocker, works like a charm and lets me finally move over from fhem.