Connected Zigbee Bulbs connection checks

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.

I will need a Hue Bridge to get the status correct? A hue bulb connected directly to SmartThings will not suffice? I did some light research but I donā€™t even think I can directly connect a Hue bulb anyway.

Yes to get that polling. Which isnā€™t really polling, itā€™s checking the bridge heartbeat, which is much easier on your network.

It is technically possible to connect a hue bulb directly to the SmartThings hub, but it is not recommended, because the smart things hub uses the ZHA profile instead of these ZLL profile that the hue bridge uses, and you could end up with the bulb that you would not be able to move back to the bridge without buying an additional device to reset it.

https://support.smartthings.com/hc/en-us/articles/200848024-How-to-connect-Philips-Hue-devices

Ok. I already have the presence detection via Wifi for the household cellular phones running smoothly. I may just try a wifi bulb and see what happens. If not, a craigslist hue bridge will be in my future.

1 Like

Also, Thanks.

1 Like

Sorry to beat a dead horse. After doing more reading on the Hue bulb direct connection, If I wanted to take a chance on a $15 bulb that I would need to purchase additional hardware down the line to reset, I could directly connect a hue bulb. However, it is not the hue bulb which is being ā€œpolledā€ (heartbeat check). It is the bridge which is performing this action, which means for my situation, I would need a hue bridge to monitor the bulb status, on/off/offline.

Am I understanding this correctly?

If so, do you know if I need a new Hue bridge or if the original version 1 would suffice?

Thanks

Yes.

One of the advantages of having the Hue bulbs connected to the bridge is that instead of polling each individual device frequently (which adds a huge amount of traffic to your network and can cause the bulbs to miss some commands), The bridge itsself writes to its heartbeat cache every time it sends a command to a bulb. Then when you poll this heartbeat, you are sending one LAN request to the bridge, which sends one LAN request back to the hub with the current status of all its devices. So the zigbee network itself doesnā€™t have to carry any extra traffic. :sunglasses: