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!