Connected Zigbee Bulbs connection checks

is there a way to check a connected bulb on/off status? Actually I need to know if it is off. I have GE Link bulbs. When I turn on the switch the bulb reports to smart things that it is on. But when I manually turn them off. SmartThings says its still on. Can I create a App to check its status based on a action?

Smart bulbs expect to always have current. If you’re turning them off with a dumb switch, you’re taking them off the network so status can’t be tracked.

The easiest thing from a daily living standpoint is to add a smart switch. That way you can turn them off at the switch but still keep them on the network.

See:

And this one for discussion of some different types of add on switches:

Yea, I know there is no way to check the status of the bulb when its off. So maybe if a app does not get the status then its considered off after X try’s?

That makes sense for a bulb connected via a star network, like a LifX or Striimlight, both of which use WiFi.

GE, Hue, Cree, and Osram, though, are zigbee mesh. The whole point of mesh is to keep the network cheap in terms of dollars and energy draw, and to keep it resilient in terms of individual devices going on and off the network.

The hub isn’t supposed to be concerned if any individual device disappears from a mesh network for awhile. It might just be getting its batteries changed or being moved to a new location. The whole concept of mesh is that messages will be routed around any missing node until it returns.

For either continuous real-time monitoring, or the kind of status checks you’re talking about, you’d generally go to a star network. But it costs more.

So if you want to use $15 networked smart bulbs, you’re almost certainly using mesh, and that means you should make sure the bulbs always have current.

I’m really happy with the Amazon echo as a control mechanism for smart bulbs. We’ve added nine more GE’s since we got the echo. No switch issues, everybody just uses voice. :blush:

The Echo does look cool. My problem is I live in an Apartment and my wife and kids like to flip the switch. I guess ill just wait till I buy a house so I can do switches.

@relenger,
If these are ZigBee bulbs the answer is you bet you can. For example with a Hue bulb (that is directly connected to the SmartThings hub) you can query the bulb and get it’s current On/Off state, current level setting (brightness), and its current xY color setting. You can also read things like the firmware version, model number, manufacture name, supported clusters, supported end points. These are all ZigBee commands you can send from SmartThings with a custom device type.

AS JD points out the bulb has to be powered on to get this information. Just an FYI:: One thing that is cool is when a bulb is powered on (Hue bulb) it does a ZigBee device announce to the SmartThings hub. I have often thought about taking the time to see if I could capture that device announce look up that bulbs color setting and reset the bulb to the correct color and brightness once it has been switched on. If you did that you would be a very popular guy!! Well with me anyway.

Anyway your talking about some fairly low level code to make this happen but it is doable. If your comfortable with JAVA I would be happy to help with pointing you in the right direction for the ZigBee commands.

Good luck!

1 Like

@JohnR ,

You can, but how much traffic are you adding to the network to get that information?

I’ve seen some SmartThings mesh networks where literally over 90% of the traffic was polling just to get the tile status “right.”

If you poll a bulb almost 100 times a day just to see if somebody turned it off at the switch you’re tossing out a lot of your energy savings. (And that’s just polling every 15 minutes.)

Again, just seems like a better match for a star network.

DOOOHHH - been waiting for this and missed it. So this requires Hue Starter or other hub to implement? like
http://www.amazon.com/Philips-452714-60-Watt-Connected-Frustration/dp/B00ME9CDQE
I rue another hub but would bite for this function.

I tried some weak searching, is this the most descriptive thread:

Is there another thread that discusses Echo command to change ST-Mode?

I was only going to check status on a bulb when there is some action(Maybe motion in that room or something) So it would not be going all the time. I guess ill go play with this and see what I can do.

The short answer is there are 4 options:

  1. run Echo and SmartThings in parallel, both talking to the same Hue Bridge. Works very well, but you only have Echo control of those bulbs.

  2. do 1) above but also use the Big Switch for Hello Home Actions (a smartapp) to give you voice control of Hello Home Phrases. Works ok, sometimes lags.

  3. wait for official integration, which several people are working on and could be out by the fall

  4. if you’re comfortable with ruby, Python, etc and setting up your own server you can create your own extensive integration. See the technical interface topic.

More discussion of all of these options here:

1 Like

Normal you don’t poll a device. That is what ZigBee reporting and device bind is all about. So if you have a ZigBee device and you want to know when its status changes you can bind it’s cluster to the hub and a report will be sent whenever a change is noted. You can even configure the reporting and set the device to report its status every 15 minutes or when a change occurs or both. This is all part of the ZigBee protocol and and large number of devices support it.

However, the Hue bulbs don’t support binding. The only way to find out what state your bulb is in for sure is to query it. You can query it with a uni-cast message or a broadcast. If you want to get the status of all your bulbs send a broadcast query (that is one packet to all the bulbs) and they will respond with a single packet back. In a well designed ZigBee network this is nothing.

Now for SmartThings I would bet if your seeing people sending polling traffic they are sending it as uni-cast to each bulb and that right there would double the traffic.

I couldn’t agree more that polling is a bad thing but in some cases its your only choice.

Curious how this works. More to the point, how you set this up. The Echo is in the living room for instance, does this limit it use to that room and immediate surrounding area??? My devices such as Wermo, GE link bulbs, are spread throughout my house (Basement Family room, office, sunroom etc). In such environment how useful can this Echo be? Do I need multiple echos??

Our Echo is usable for most of the first floor. It’s in the living room, it controls lights in the living room, entry, kitchen, family room, study, guest room, master, bathroom, and second bedroom. With doors closed. The far field recognition on this thing is amazing. You do have to raise your voice a bit to be heard from the distant rooms, but way below shouting level. Just a normal attention getting voice.

It also comes with one remote, but you have to hold down a button to use that. My housemate has the remote in his room for quiet voice control.

We have two Echos (we each got one). We didn’t even set up the second one for about a month, but eventually added it in my room to give me quiet voice control from there.

Both Echos can control any of the lights on the same Hue bridge.

I’m sure it depends on local architecture as far as coverage range but most people seem to get at least 3 room coverage from it.

3 Likes

That is a great example of when to query a device. In your example you could make a quick call to a bulb to get its current state (color and brightness) and then tell it to go red and vary the level up and down sever times to simulate a flashing red light. Once your done with the notification return the bulb back to its original state based on the information you got on the first call.

@JohnR ,

Sorry, I’m confused.

The OP wants to catch status when a device is powered off by a dumb wall switch. There’s no event to report and no way to report it (the bulb is powered off).

So in your example you request a report every 15 minutes. Setting aside the question of false nonreports, and even setting aside broadcast vs unicast, let’s just look at the number of packets on the network.

Typically a residential light gets turned on and off 3 times a day. (Obviously that varies.) If those are all network requests, that’s 6 events.

If I request a report every 15 minutes, that’s another 96 packets coming back.

96/102 = .96

96% of the network traffic for that device is to update status.

Maybe the network can handle it, maybe there are collisions, but there’s definitely a cost.

I’m sure there are people willing to pay that cost in residential automation, but it’s not what mesh is intended for.

Obviously limiting the status checks to when motion is in the room would help.

And I know many people will consider this a completely trivial concern. They don’t want to even think about message volume unless they’re seeing QOS issues.

For me it’s “a stitch in time” issue. Capturing a real event with a smart switch fits mesh better than an arbitrary status update every 15 minutes. Plus it leaves the bulb available for networked “on” commands. But I know other people will have other priorities.

I think with @JohnR is referring to is something I’ve been trying to capture as well. If the bulb is turned off, there is no way to distinguish this from a bulb that fell off the network…

However, there is a Join packet that is sent when the bulb comes back on the network, either via power on, or mesh is reachable again.

This join packet, should be parsed by ST to then send a query to get status of bulb and then could be used as a subscribed event “Joined” to most likely restore last known state by the system.

That way, if a bulb is dropped from mesh, or switch turned off and back on, the bulb would be on for only a few seconds until the hub would parse the join event, and restore last state.

All doable today, only if ST would link up the Join packet with the device ID and allow it to be parsed.

Still not ideal, but better then nothing.

1 Like

@JDRoberts, I was simply answering his question as to if you can tell if a ZigBee bulb is on or off. And the answer is yes you can. Remember a bulb can have power to it but still be off. I then gave him a little more information on how he could do it. I also said the bulb has to be on to communicate with it. So I think we are on the same page here but if not I will be happy to debate it more.

I don’t see how this is a mesh network issue. I would like to understand your concern here!

In his scenario, the bulb is turned off at a dumb switch. So no power, not just “off” as it would be with a network command.

I don’t see any issue if he wanted notification of an off event from a network command, but my understanding is that is not what he was asking for.

As to mesh, the guidelines I worked with professionally were that status checks should be limited to no more than 5% of traffic on a mesh network. If you needed more than that, you looked at other topologies.

It’s the old adage that mesh gets stronger as you add more devices. That’s only true if you limit status checks. Otherwise you can end up with “virtual orphans,” devices that can’t get their messages because their parent is too busy handling status check traffic. That doesn’t happen in a star network. The whole network may bog down, but new messages don’t overwrite the buffer.

But I know many people don’t worry about this stuff for residential automation in their own homes unless they see actual problems occurring. I’m sure I’m overly conservative on this, just old habits. :sunglasses:

Ahh I get ya now on the Mesh concern there may be a twist here to think about for your guidelines.

With a ZigBee network you have a few ways to route traffic the most common is AODV (Ad-hoc On-demand Distance
Vector routing) “Mesh routing” and it is generally used for small networks 20 to 30 or so nodes. For lager networks the ZigBee hub often uses Many-to-One routing or a star typology. This is how the current SmartThings hub routes traffic. I know this because of a conversation I had with Urman before he went to Google and the fact that the hub sends out many-to-one route broadcast all the freaking time. These broadcast are how you setup a Many-To-One routed ZigBee network.

Just an FYI not saying your guideline applies here or not but I can say for a fact my SmartThings hub is dong Many-To-One routing (Star Configuration) over ZigBee I see the Many-To-One route packets everyday in my device’s log files.

I understand the confusion because we are deeeep into technicalities here, but zigbee many to one is not a star network. It’s a route optimization method for a mesh network.

Zigbee can be configured as a star, but then by definition each node is only one hop from the controller. No parents and children, no relaying of messages, no buffering for later transmission.

In contrast, many to one is just a way for the controller to continually force calculation of currently reliable routes across the mesh. Lots of hops, parents and children, message buffering.

https://www.digi.com/wiki/developer/index.php/Large_ZigBee_Networks_and_Source_Routing

.
http://www.jennic.com/elearning/zigbee/files/html/module2/module2-4.htm

.

Many to one routing messages aren’t needed in a star network because there are no alternate routes to worry about anyway, each node has a direct one hop connection to the coordinator.