Connected Zigbee Bulbs connection checks

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.

On Page 59 of the Digi ZigBee SMT Manual (search for 90002002_M its the first PDF that comes up in my search window) it states:

Many-to-one routing is an optimization… Rather than require each device to do its
own route discovery, a single many-to-one broadcast transmission is sent from the data collector to establish
reverse routes on all devices.

Then in the next paragraph it states:
When a device sends data to a data collector, and it finds a many-to-one route in its routing table, it will
transmit the data without performing a route discovery. The many-to-one route request should be sent
periodically to update and refresh the reverse routes in the network.

So no its not a star typology at the physical layer that’s how WiFi and standard 802.15.4 (older xBee networks) work but it has the same benefits at the routing level reducing the route discovery traffic of a mesh only network. Its the best of both worlds you don’t have the single point of failure like you do with WiFi and it vastly reduces routing traffic since the routers simply past the packet on without the discovery overhead.

On the next page they illustrate how the routing works.

I was pointing out SmartThings is not a simply Mesh Routing AODV network they use many to one routing which is more like hub and spoke routing you would see in a star network.

But it’s not hub and spoke. Hub and spoke is one central dot and then a bunch of surrounding dots, each exactly one hop away from the hub. No packets are relayed by any node except the central node. There are no alternate paths for anything. Each outer node speaks directly to the hub.

In zigbee many to one, messages are passed from node to node, multiple hops, but with the idea that each is either originating from the controller or being passed to the controller. But the mechanism of passing is totally different than hub and spoke.

What that bolded bit means is that given that the available routes in a mesh can change over time, there are two common ways to get from A to X across the mesh.

  1. AODV. X wants to send a message to A. X begins by querying its nearest neighbors, trying to find a good route. It figures out a good route, then sends the packet. That’s “route discovery.”

  2. Many to one. We know ahead of time that all the packets will be sent from the node to the controller. Not to any other nodes. (Many nodes sending to one controller.) So we have A (the controller) regularly send out messages to every node, basically asking if they’re available. Then the controller (which is normally a bigger more powerful computational device) calculates the best current route from a node to itself, and then it sends those routes to the routing nodes. So all the out nodes don’t have to do their own calculations anymore, as long as their message is destined for the controller. They just use the most recent route the controller sent them. That’s what is meant by “it will send the data without performing a route discovery.”

But–and this is the critical bit–that route can still involve multiple hops, relays, router buffers. So there is still all the usual mesh stuff regarding collisions and buffer death and potential lost messages.

So many to one takes advantage of knowing the controller will be the destination of future messages to build routes just a little in advance. Which allows for the routing to remain dynamic but still offloads the computational heavy lifting to the controller. Once the packet is released, though, it’s in the mesh. No forced sequencing.

Hub and spoke doesn’t have relays or multiple hops. The only buffering is at the destination. Packets are processed serially.

I have been looking into this as I modified a ceiling fan remote to be controlled via the ThingShield. However the wall switch (which is basically an additional in-wall remote control to the canopy of the fan) does not interact with smartthings at all. I tried installing a smart bulb so that when the wall switch is on, it will show the bulb online, and then I set a rule that turns off the switch whenever I turn off the smart bulb. This will work and I will be able to tell the fixtures status when I am not home by trying to access the bulb. It is a clunky solution, however what I propose as a possible option, if you have the appropriate router, is to purchase a wifi connected bulb and create a presence sensor. Using some of the other forums here such as DDWRT presence sensor or the Asus Wifi Presence Detection and creating a presence instance for when that bulb is on (connected to wifi) combined with some rules and virtual switches you will likely have a pretty clean solution that can tell you whether the lights are on or off and can have automate.

This assumes a few things:

  • The bulb connects automatically to Wifi when it turns on and off without any user interaction at the bulb.
  • The bulb defaults to on when power returns via the “dumb” switch.
  • There is not an extremely long connection time to connect to wifi. My current setup checks the router every 15 seconds which is likely faster than any polling system would take.

I am going to do a bit of research and see if I can find a wifi bulb that fits my needs and I will give it a go and report back. I believe the ecosmart zigbee bulbs which are sold only in canadian home depots seem to have a status change to off in SmartThings when they are powered off at the switch but I can not confirm or get a hold of any of these bulbs.

Since August 2016, SmartThings queries the hue bridge for the status of connected devices every five seconds. :sunglasses:

You might also want to look at the work that went into the “canary bulb” smart app which is used to reset all the smart bulbs in a house if the power has gone off and come back on. It works with regular zigbee bulbs. So different purpose, but I believe a similar methodology.