Brand new first-time user of OH here, just set up an instance on a RP3 today with a simple connection to my old Hager Tebis EIB installation. Surprisingly, it works - I can see when a light is turned on and off, and I can turn it on and off via OH. Yay
Unfortunately the implementation is quite odd (old??). Instead of using DPT 1.001 to turn the light on & off, the switch sends a one-byte binary value (0x32 for ON, 0x30 for off) to the GA. So to get this to work I had to use 18.001 to interpret this as scene selection as follows:
So, in the UI I now see the light with two buttons, one for ‘off’ and one for ‘on’. And, as I said, it works as expected both for a physical switch being hit (and reported) and for switching via the UI.
But what I’m trying to do is work out how to get OH to recognise that 48 is an off state, and 50 is an on state, for a normal light switch so that OH ‘understands’ this is an on/off light & I get the little slider switch in the UI (and the icon changes automatically) instead (and other standard switch on/off semantics work by default).
I feel like I need to translate or map the values somehow to tell OH that this device is just an ordinary switch and to treat the nominated values simply as ‘on’ or ‘off’ (sort of how the MIOS binding does for z-wave stuff).
Well, Tebis is… sorry… sort of shit . Luckily, I rejected to use this and decided to use ETS from the very beginning (July 2005).
Now, what you could do, is to use some unbound items for UI and define rules to “translate”:
Switch mySwitch "my Switch is [%s]" //will use the default dynamic icon for switches
Number mySwitch_knx {knx="..."}
rule "translate knx"
when
Item mySwitch_knx received command
then
if(receivedCommand == 48)
mySwitch.postUpdate(OFF)
else if(receivedCommand == 50)
mySwitch.postUpdate(ON)
end
rule "translate mySwitch"
when
Item mySwitch received command // switched from UI
then
if(receivedCommand == OFF)
mySwitch_knx.sendCommand(48)
else if(receivedCommand == ON)
mySwitch_knx.sendCommand(50)
end
Of course doing that with more switches would be a mess… you probably would want to use groups to build a more general rule for all switches.
I totally agree, Tebis is indeed a POS Unfortunately I didn’t know anything about KNX at the time and believed the salesman when I put this in about 13 years ago… One thing in its favour - it has been totally reliable up to now!
Re the code - took me a while to realise there was a minor issue with your suggestion (needs “Item” in the when clause) but, once that was sorted, it worked perfectly. Thanks so much!!
Just a pity that this amount of code is necessary - had hoped to just shim a translate in at the binding or item layer…
Next challenge - I have 23 different lights to manage. Which means I need 46 mappings (knx->OH and OH->knx). I’d rather not write individual code for each!!!
I note you suggest using groups to build a more general rule… would you be able to elaborate a bit please?
I’ve spent about a day googling away, but am sort of stuck. The closest I come is using a Lambda to manage the code, with maybe two hashmaps to manage the translations in either direction, but working out which device triggered & hence managing the corresponding switch is still escaping me…
. Luckily, I rejected to use this and decided to use ETS from the very beginning (July 2005).
Unfortunately I didn’t know anything about KNX at the time and believed the salesman when I put this in about 13 years ago… One thing in its favour - it has been totally reliable up to now!