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.
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.”
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.
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.
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.
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?
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.
