Tahoma Binding: Problem with temporarily not available plug in receivers

Hi all,

I have a problem with the display of temporarily not available plug in receivers.
I’m using OH3 with the Tahoma binding. The the plug in receivers are working fine as long a nobody plugged them out. The problem is now, if they are plugged out I would like to hide them in the basicUI. But the behavior is as follows:

  • on the things configuration page I see them with status “ERROR:COM”
  • the item itself (which is a switch) is shown with the status “OFF”
  • if I try to switch this respective switch on it directly goes back to status “OFF” again.
  • in the log I see that the item received the command to switch ON, next line is that the item is predicted to become OFF

Is there any possibility in the sitemap definition that I can use the things state “ERROR:COM” for the visibility of the switch item?
On second thought, is there any possibility to see the things state at the item’s state? How does the item know that it is OFF when there is no communication in the parent thing?

Any help is very appreciated and thanks a lot in advance.


This is autoupdate feature at work; it tries to guess the likely outcome of your command, but allows the binding to have a say, which presumably vetoes an update because the device/Thing/channel is broke.

No. But you might be able to copy the state of your Thing into an Item by rule. Then you can use that Item in your sitemap for visibility control.

It is possible for bindings to set channel/Item state UNDEF in the case of comms failure. That’s not always the smart thing to do, but it would sound appropriate here. For example, persistence does not record UNDEF so you don’t get fake records.
That depends on the binding author making it so. You might request an enhancement, but of course that won’t happen overnight, if at all.

A rule detecting Thing state could also set your Item to UNDEF, that might be more convenient than an extra Item.
Then you can use the Item’s own state to control visibility, or map to a useful message like “unplugged”

Hi rossko57,

that was a fast answer. Thanks a lot.

A rule detecting Thing state could also set your Item to UNDEF, that might be more convenient than an extra Item.
Then you can use the Item’s own state to control visibility, or map to a useful message like “unplugged”

I will give this suggestion a try and will report about the result.

Thanks again,

Hi together,

after the hint from @rossko57 I created the following rule:

// rule for checking state of somfy plug receiver
rule "check somfy plugs"
    Time cron "0 0/5 * ? * * *" or                   // every 5 minutes, just for in case
    Member of g_Switch changed from UNDEF to OFF     // if any of the plugs items received an update
    // SSWFlurOGFensterSwitch
    var status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:412c0373-66d6-4678-b019-27761fc823b4").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWFlurOGFensterSwitch", "UNDEF")

    // SSWGZFensterSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:07e384d5-dff8-4619-b874-3d920aa51d19").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWGZFensterSwitch", "UNDEF")

    // SSWLenyaFensterSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:8075f3b2-25af-4665-9df7-1a2463eff965").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWLenyaFensterSwitch", "UNDEF")

    // SSWLionFensterSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:1f5181df-c4cc-4d94-bd7d-026468aa03b5").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWLionFensterSwitch", "UNDEF")

    // SSWSchlafzimmerFensterSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:09f430bd-acd6-4f80-a7a1-ff14388d292f").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWSchlafzimmerFensterSwitch", "UNDEF")
    // SSWWZBelFensterDSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:4f478480-0d04-4cb1-8ab4-008c61309ab2").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWWZBelFensterDSwitch", "UNDEF")

    // SSWWZBelOberschrankSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:a147e8b0-1aff-42d6-bfb9-8ccf5a1d977a").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWWZBelOberschrankSwitch", "UNDEF")

    // SSWWZBelSchrankwandSwitch
    status_str = getThingStatusInfo("somfytahoma:onoff:4b1097d5b2:ba7c291d-d15a-4521-a47a-cea8254d642f").getStatus()
    if( status_str.toString == 'OFFLINE' ) {
        postUpdate("SSWWZBelSchrankwandSwitch", "UNDEF")

This works for me and I mark the plugs in the plugs overview with a red labelcolor. In the rooms view I hide these plugs.
Later on I will create an icon for the UNDEF state.

Thanks again to @rossko57 for the fast answer.


It’s a weird rule trigger, but I guess you face the problem that the binding comes along and re-posts OFF to the Item at each periodic device retry.
I think you could still lodge an enhancement request on github for this binding to post UNDEF - posting OFF is a fib really, in the case of lost comms.

Setting the items to UNDEF when the thing is OFFLINE makes sense.
As I am currently extending this binding, I will implement this feature. I believe it should be very easy.

1 Like

That sounds great. Is there a possibility to get a message when it is implemented?
If I could make another suggestion which is that if the thing is OFFLINE or the state of the item is UNDEF it would be great if the item is not operable. I don’t know how difficult that is therefore it is just a suggestion/wish from me.

Yes, if the thing is OFFLINE, commands should be ignored

Depends what you mean here.

So far as the general openHAB framework goes, you can command or update any UNDEF Item just like any other Item, this will not and should not block such activity.
(You might be linked to multiple channels/bindings, each makes its own decision what to do with commands.)

Beware the effects of autoupdate here - if autoupdate is enabled on the Item, it may do its usual thing of predicting a new state and carry out an update to something other than UNDEF.
In your particular case, I think we’ve already seen that the broken channel/Thing blocks this. But that may not be the case for every binding/fault situation.

Guessing what you really want is to disable UI controls, that’s a presentation issue you can sort out with UI controls e.g. for a sitemap use visibility= and state UNDEF to present a Text widget instead of a Switch widget.

Any automation rules can of course check for state UNDEF before doing whatever, and choose what to do if found.

I see I still need to learn a lot about openHAB framework.
I will play around with it and read some documentations. I hope that will help.

I will try that to see if this fits my needs.