[SOLVED] Zigbee: Update Light item status when bulb is offline (no powered)

I am using Openhab 2.5.0 with Zigbee binding and it works great!

In PaperUI the Zigbee bulb is shown as “offline” some minutes after switching off from the wall switch (as expected).
What I am wondering is if it is any way to know in the sitemap/rules when a Zigbee bulb has been switched off/no power (from the wall switch).

I want to know is if the bulb is switched off, either from openhab or from the “realworld” (wall switch).


PaperUI is for configuration of OH not control. Create a sitemap and use something like BasicUI for control.

Can’t think of a quick solution for this, a rule and proxy item maybe?

Yes, I have a sitemap for control (obviously). I just wanted to state that in PaperUI the bulb appears as offline so openhab knows that it is not communicating (it could be because it is not powered or a communication failure, but for me I will interpretate it as switched off from the wall switch)

Do you know how I can get this “offline” status of the bulb (that is being shown in PaperUI) from a rule?


The offline status is showing when looking at the Things or where in PaperUI?

Yes, in the Configuration->Things section in PaperUI.

Use a proxy (dummy switch) item to represent the offline status.

rule "offline"
    Item Your_Zigbee_Item changed 
    if(Your_Zigbee_Item.state == whatever log indicates as offline)

Its a rough rule to get you started but need to open a browser and use frontail log and see the log for what is shown when you switch the light off. Post the log here and I will try to help finish the rule.

The thing goes offline, so you’ll need to write a rule to do something based off of that:

From memory…

rule "Zigbee Bulb offline"
  Thing "zigbee:device:abcd1234:edcb4321" changed to OFFLINE
  # Do something, such as set a string item.

Alternatively you can get the status of any Thing (such as “OFFLINE”) using:


where thingname is the full name of your Thing e.g. zigbee:device:abcd1234:edcb4321. Then you can trigger your rule when it changes to any status.


Yes! That will do the trick.

I have implemented it this way (ZB_Sofa is the item linked to the Zigbee bulb Thing refered in the rule condition):

rule "ZB_Sofa"
	Thing "zigbee:device:4b531422:7cb03eaa0a05ce9b:7CB03EAA0A05CE9B_3_dimmer" changed to OFFLINE

Now when the bulb is offline the sitemap shows that the bulb is off.

The situation now is that I have like 20 bulbs. Any suggestion on how to make a general rule for all of them and avoid creating a copy of this rule 20 times?

For anyone interested, I finally update the status to UNDEF instead of OFF when the Thing goes offline (more adequate)

rule "ZB_Sofa"
	Thing "zigbee:device:4b531422:7cb03eaa0a05ce9b:7CB03EAA0A05CE9B_3_dimmer" changed to OFFLINE

When the bulb is energized again and communicates with the Zigbee controller, the binding updates the Item is instantly and shows the bulb as ON, so now is working as expected.

I think that this should be implemented in the binding itself, that is why i have open an issue in the repository:

Thanks to all of you for your help!

1 Like

I disagree with this. To me, the binding should simply set the thing OFFLINE (which it does). It should not have to go through and set all channels on that thing to be UNDEF state. If this is what should be done, then it should be done in the CORE so that it is consistent for every binding and not having to duplicate this, and implement this code in dozens of places, in hundreds of bindings.

I already suggested that you open an issue for this, but I guess that you disagree with this architecture?

No, I do not disagree, I am still trying to understand how the Zigbee binding and the CORE works in order to do a proper request.

On the other hand, I am also thinking about the general approach you propose, as what would happen for Zigbee sensors (temperature, humidity, luminance…), maybe in that case I would prefer to keep the last state (value) even if the Thing is offline, but for bulbs not (as their “real state” will be often modified from the wall switch). Maybe this should be done in the binding itself as it knows what type of devices are communicating with and can decide what to do (last state/UNDEF)? (I am just guessing, please do not be hard on me :sweat_smile: )

I think if we want consistent application of these sort of “policies”, then they need to be implemented in a single place. Otherwise you end up with what we have now - some bindings do one thing, and other bindings do another thing. Every binding does something different, and the user then has to work out what each binding does, and this is bad (IMHO). Rules will not work consistently - they will do different things depending on if the item is from one binding or another. These sorts of “high level” things should be implemented in a common way so that the user experience is as consistent as possible.

My personal view is that bindings should not implement these sort of things, and by doing so, they may be improving things for their binding, but at system level they are making the overall system less consistent and making the users experience worse (although this is only true if the user has more than 1 technology). Instead, binding authors should submit these sorts of things into the core to ensure the standard experience.

I’m a system engineer by trade - these sorts of design decisions are what system engineering is all about, and to ensure the system is a real system, and not a mix-mash of different ideas and implementations they should be properly considered in the system architecture. Unfortunately we don’t really do this in OH and we continually have these discussions around adding features into bindings.

But why? If we are saying the device is OFFLINE, then we are saying there is no communication. In this case, how do you know it’s still 21 degrees outside as reported by the last report on your sensor 3 hours ago, and not 10 degrees?

Bindings should avoid setting things OFFLINE too rapidly. In ZigBee, we know when we expect a device to send a report - if we miss two reports in a row, then we say it is OFFLINE since we are no longer communicating (ZWave does a similar thing). This is clearly the responsibility of the binding - it knows how to handle the thing, but IMHO, once it’s OFFLINE, it is no longer functioning and cannot be relied upon, so the state should probably be UNDEF, and I would suggest that this should be applied consistently for all bindings - therefore, it can only be done by the core.

I’m happy to be convinced there’s a better way, but really it should be consistent - either way.

This is what tools like the expire binding are for - user configurable, not dependent on binding author’s whim, or on the particular behaviour of the technology involved.

I think the difficulty applying it consistently is that the bindings are inherently inconsistent (because of underlying technologies).
Some actively poll devices, you might declare a failure if no timely response comes.
Some incorporate retry mechanisms - should we declare data invalid at first failure, or Nth?
Some sit passively. You might recognise a failure if no update comes in a certain time. But perhaps updates only come when something actually changes.
openHAB supports shouting into the void model too - issuing commands where no response is expected No fault detection is possible.

So yes … each binding (should) know how to deal with the quirks of their “own” Things.

Issuing UNDEF to data channels is bit different, though. It’s tempting in simple cases - but becomes a nuisance in complex set ups.
Items may be bound to multiple channels, there’s no voting or priority about who gets to declare the shared data invalid. (not there is about “ordinary” updates either of course.)
Users could choose to deal with failures in their own way, using persistence say.

We had a fair debate about this in connection with Modbus binding - where data is usually polled, so failure to read is easily detected. However, Modbus also makes allowances for unreliable comms … failure can be acceptable, there’ll be another poll in a moment.
A) The v1.x binding had an option postundefinedonreaderror - we could choose to have read errors set UNDEF to Items.
B) The v2.x binding however we did away with that option. in the case of read errors there is simply no update. Users can choose to ‘expire’ stale data of course with added tools. But one of the key factors in enabling that no-update decision is that the binding also publishes a lastReadError channel (as a DateTime). Users can choose to watch for an update to that, and then take whatever action they desire.
I think both those approaches are valid.

I guess I’m saying, give the user the choice! It is true that bindings can provide features to help the user here.

Well, hopefully it’s not the authors “whim” - hopefully there’s some sound basis for setting a device offline. I think what I do in ZigBee makes a lot of sense - if it doesn’t check in twice in a row, then we mark it offline.

Of course, the expire binding also fine - but it’s not really the topic.

That should be irrelevant. The point is that a binding should mark a device OFFLINE (or not), and it should do this on some basis. If the binding marks the device OFFLINE, then that means it cannot be communicated with. Underlying technology is not relevant - the binding is there to provide the abstraction between the technology and openHAB concepts.


The ZWave binding uses combinations of all of these, but that’s up to the binding. The bottom line is (as I said already) the binding should find a way to decide that it cannot communicate with a devce, and then set it offline. It does not matter at all if that is through polling, reporting, smoke signals or anything else - that’s the bindings business. Presenting this to the user is the frameworks business.

All technologies should do this - again though, this is a binding feature.

I’m not really sure what you are suggesting?

We also need to be very careful about “giving the user choice”. Yes, everyone loves to have a dozen ways to do things, but that also means added complexity, confusion and some unhappy users. I know a lot of people here love that choice - they are technology enthusiasts, and it’s fun to configure things many different ways.

However, these options add confusion to a different type of user and having lots of ways to do the same thing is therefore (IMHO) not a good idea. It also means a lack of consistency in the framework - as I said above - we end up with different bindings doing things differently, and users getting confused when a rule works for one binding, and not another. In an ideal world, all items etc that the user interacts with would be the same no matter what binding they came from - presenting a consistent user experience in a totally technology agnostic way. If that’s what we want (and it is openHABs stated goal) then leaving this to hundreds of different implementation will not achieve he goal.

I should clarify - my remarks were about a binding updating Items to UNDEF state.

Things OFFLINE is, as you say, very binding specific business.

I like the expire binding idea, in fact I am using it for other situation but it did not come to my mind for my Zigbee bulbs. Just one question, When is updated the state of the Item, each time the state changes (command) or each time is it polled (and gets a reply from the Item with the state)? If it is when polled the expire binding will work as expected, If it is update only when the state changes not.

I will answer to myself, the Item state is being updated each 10 minutes (aprox) so the expire binding will work. This 10 minutes poll is always the same for all things? Is it configurable?

Thanks to both of you!