I have battery Zigbee products that are reporting are second floor wireless contact sensors (all others are wired with Konnected). I also have three dead bolts and not one of them has failed to communicate, whether via routine script or manual trigger from Hubitat. The dead bolts have been installed for about three years and the contact sensors (16) for a little over a year. These were previously connected via Wink and 3rd Reality hub and did not "sleep" on them.
Please explain what happens when you see one "sleeping" and how you get it to reconnect. If mine are "sleeping", they must wake up immediately upon command.
BTW: Batteries last about 4 months in the door locks and 16 months for the contacts.
It seems you are using "sleepy" to describe a device that has lost connection and not communicating with the hub anymore. That's not what this means.
A sleepy device is one that only turns on its radio only if it has something to say due to an event on the sensor side. You can't poll it from the hub because it isn't listening. However, if the contact opens, or if you push a button, or it is configured to report battery every 4 hours and that time is up, then the device knows it has something to say and says it.
A "sleepy" device isn't broken. It is working perfectly as designed to prolong battery life.
Yes, that is what I thought the term was used for. As an IT guy, I am familiar with devices that have issues when they "sleep" and won't wake up, unless rebooted.
Thread is 100% local, it would be up to the border router (such as an apple homepod or lets say an echo with thread enabled which apple uses mostly thread) to keep it out of the cloud. Lets say that Hubitat had a thread enabled radio (essentially another zigbee radio in order not to time slice a single radio), hubitat could control that thread device (lets say an outlet) with no cloud involvement what so ever. Thread is a pretty mature protocol and the specs for it and open and laid out pretty clearly. Matter on the other hand? You will need a matter enabled unit to make the primary connection, but again, lets say that you use an Echo to connect it to matter and Hubitat is matter compliant, then once the device is available to the matter mesh, you can remove control and communication to the echo device and no cloud is needed as matter would be running over thread. Again though I'm sure that amazon, google, etc will try to monetize the data but in the end, it doesn't have to be cloud based.
The key word you used here is Hubitat. Without it, none of that works. I've tried to ask Alexa to do complex routines and it cannot. So once again, we're not fixing a current problem we're just adding more to an already muddy water, because Hubitat can already manage what you have locally. If they do improve Hubitat to support Thread and Matter devices, no one will purchase devices that cost 3x the current technology with it being able to fix a current need. By the time China is producing cheap knockoffs, those big three will be charging for "cloud" services or they will have left the game. They're in this to make a profit and they wouldn't invest in it if they didn't feel there was a large opportunity to do so. Charging for "cloud" services is their only hope. I work for large corporations and are projects designed to increase the bottom line, while looking like they are helping a greater cause.
From my limited understanding, it answers a need for separation of concerns (network stack / application layers). Need being expressed by chip manufacturers, among others. Irrespective of any differences between them at the network level, ZigBee appears to try to "do it all". Thread/Matter seems like a cleaner/useful split.
This kind of thing has been litigated to no end for multiplayer games (a low latency network application with exacting users). One of the problems is how do you migrate any state info when you elect a new leader. I won't bore people here with all the scenarios. A "single-point of failure" can also be a "single point of success". There are many tradeoffs. Very curious to see where the chips will fall in practice.
As @HAL9000 noted, the sleep state is fundamental to how all battery operated IoT devices work.
Typical design point for an SoC in a Zigbee (or Thread) end device like a contact sensor is to target 'sleep' mode 99.99% of the time. The chip does include an 'always on' portion of the core logic which is capable of ultra low power consumption (typically less than 1.5uA) yet capable of responding to external events (like a contact closure or real-time clock interrupt) that enable it to wake up the rest of the system, enable the radio, transmit & receive as necessary and then return to sleep.
Zigbee (and Thread) devices like pushbuttons and contact sensors could theoretically remain sleep forever unless wakened by an external event, but this isn't how they are designed. They need to remain logically joined to a parent router in order to be capable of transmitting or receiving messages (all data transmitted or sent to a sleepy Zigbee or Thread device is queued in message buffers in the parent router); that parent device needs to receive a periodic poll from its sleepy child devices within a defined timeout interval or it will assume they've left the network and free up their message buffers for future use.
Depending on the device (and profile in use), that poll interval could be several seconds or an hour or more. I've timed the poll interval of my Zigbee lock at roughly 3 seconds which means it's essentially dead to the outside world aside from a few milliseconds 20 times every minute. So depending on when the 'unlock' command hits my Kwikset lock's always-on parent router, it could take up to 3 seconds for its Zigbee chip to wake up, initiate a check-in with its parent and determine if an 'unlock' command has been sent for it to execute.
Sleep mode power savings make it possible for the battery life of sensor type devices to approach years rather than weeks while using a small battery; other optimizations like shortening message frames (by associating 64 bit MAC addresses with 16 bit device ID's) minimize the radio-on time, saving considerable power (a Zigbee SoC's current consumption while transmitting is several thousand times more than while sleeping). Zigbee Green Power truncates message frames even more, making batteryless operation possible (nanojoules per bit add up, especially when you're harvesting the kinetic energy of a button press in order to power the radio).
Previous post have shown that I have misunderstood information provided, so please feel free to redirect me if the information below is not what you were speaking of.
Thread uses all stack protocol layers, just as Zigbee.
Example application layer protocols that Thread uses:
3.5 ICMP
Thread devices support the Internet Control Message Protocol version 6 (ICMPv6) protocol as defined in RFC 4443, Internet Control
Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. They also support the echo request and echo reply
messages.
3.6 UDP
The Thread stack supports User Datagram Protocol (UDP) as defined in RFC 768, User Datagram Protocol.
3.7 TCP
The Thread stack supports a Transport Control Protocol (TCP) variant called âTCPlp" (TCP Low Power) (See usenix-NSDI20). A
Thread-compliant device implements the TCP initiator and listener roles as described in:
⢠RFC 793, Transmission Control Protocol
⢠RFC 1122, Requirements for Internet Hosts
⢠Thread Specification 1.3.0: Existing TCP implementations are typically not tuned to work optimally over wireless mesh networks and
with the limited 802.15.4 frame sizes. Therefore, the specification defines those elements and parameter values required for an efficient TCP implementation over Thread Networks (see Thread Specification 1.3.0, section 6.2 TCP).
UG103.11: Thread Fundamentals
IP Stack Fundamentals silabs.com | Building a more connected world. Rev. 1.4 | 10
3.8 SRP
Service Registration Protocol (SRP) as defined in Service Registration Protocol for DNS-Based Service Discovery is utilized on Thread
devices as of Thread Specification 1.3.0. There must exist a Service Registry, maintained by a border router. SRP clients on the mesh
network can register to offer various services. An SRP server accepts DNS-based discovery queries and additionally offers public key
cryptography for security, along with other minor enhancements to better support constrained clients.
Yes, but my understanding is Zigbee goes much further up into the app layer, with the ZCL defining interfaces for end user devices like thermostats and window coverings.
A standard definition of an application layer is an âabstraction layer that specifies the shared protocols and interface methods used by hosts in a communications networkâ (Application layer - Wikipedia). Put more simply, an application layer is the âlan- guage of devices,â for example, how a switch talks to a light bulb. Using these definitions, an application layer does not exist in Thread.
My understanding is that Matter goes above the dotted line, where Zigbee ventures and Thread does not.
You need to be careful with this statement, Some battery operated devices don't sleep and can receive commands all the time like the Smartthings multi-sensors and a few others that I don't have in mind right now (I think the Hue motion sensors also never sleep but not 100% sure). So although most do sleep not all go to sleep and this can be important for some setups.
Thread Partitions allow devices to maintain communication with other devices in the same Thread Partition but not with Thread Devices in other partitions.
Periodic polling (during wake intervals) is how Zigbee/Thread battery operated end devices normally receive commands; polling happens frequently enough that the device may appear to be 'always on' (it will accept configuration commands, refresh commands, etc. within a few seconds) but it doesn't remain fully powered all the time. There are also specific poll intervals; a device will temporarily go into 'fast poll mode' to fetch a message if its 'slow' polling interval indicates that it has buffered data waiting, but it is still periodically waking and sleeping. Zigbee design specs recommend wakeup intervals no more frequent than 7.5 seconds (aside from 'fast poll'); obviously locks are different and poll more frequently (they also have big batteries).
According to SiLabs:
In their normal operating state, ZigBee end devices shall poll no more frequently than once every 7.5 seconds except where this specification indicates otherwise for a particular device description, or under the following conditions.
â˘ZigBee end devices may operate with a higher polling rate during commissioning, network maintenance, alarm states, and for short periods after transmitting a message to allow for acknowledgments and or responses to be received quickly, but they must return to the standard rate indicated previously during normal operation.
â˘It is recommended that ZigBee end devices poll much less frequently than once per 7.5 seconds, especially when the device normally only communicates due to user interaction. To further clarify, except for one condition in the Simple Metering cluster (refer to DD.3.3), all cluster interactions that read or write attributes, or cause command exchanges should limit transactions to once every 30 seconds.
There's no reason (or any practical way if you're powering the thing with a wafer cell and want it to operate for more than a few weeks) to keep the radio and chip fully powered all the time.
Zigbee SED polling isn't to be confused with how sleepy Z-Wave devices work--that scheme is different; a Z-Wave sleepy device's wakeup time is configurable and can be several hours; if you want to do anything to change a Z-Wave sensor's configuration parameters you either wait for hours or physically 'wake up' the device by hitting its button. It will then wakeup for a certain amount of time (during which you get a shot at sending it configuration data), then go back to sleep for hours again.
Have you tried secure pairing in Z-wave? I would have rejoiced if it was only a 20% failure as I was getting my locks and secure devices into Hubitat! And let's not even start about all the work needed to remove the "ghost" devices left behind by Z-wave pairing failures.
So it still appears to me that the video is complaining about imperfect early/first end-device implementations, where we already have and accept greater long-term, nobody is doing much about it (and I'm pointing to silicon labs here), imperfections in how smarthomes already work.
Though this is definitely all in the "the next year will tell" category as devices come out and the true test of interoperability is seen!
(Zigbee, on the other hand, seems to pair right just about every time)
My personal experience was closer to 90% success rate and I only created a ghost once. That was due to a really crazy coincidence (vehicle hit a pole up the road causing a power at the house - hub ran fine on battery. But the switch on the wall did not) while I was trying to include.
There's no internet required for functional Thread usage. Apple Home has no problem working without an internet connection. The only thing that won't work without internet are some Siri commands and control from outside of the house. In fact there's not even a controller/hub required for Thread devices. Probably the oldest consumer implementation of Thread are the Nest Protect smoke detectors. They work great and only require internet for the phone app to work outside of the home.
Thread can communicate outside a local network, but it is not required.
Any internet requirements is based on the device manufacturer's implementation including Matter. Not the radio.
The Apple Home implementation of Matter/Thread is all local (Thread support requires a recent Apple HomePod or AppleTV with a Thread radio.) Just like HomeKit, Apple's implementation is pretty much all local, including the processing for automations, with the exception of voice processing and controlling your home when away (as mentioned by @bill.d above.) Apple is also the one major company that actually puts privacy of its end users' data as a high priority.
