As part of playing with troubleshooting a Zigbee oddness, it occured to me that I have few XBee modules lying around - so I joined one of them to the Hub. I tried this years ago and it was a pain, but this time it was surprisingly easy
Obviously since I have no code attached to it at the moment, it does not do much, although I can map out some of the Zigbee network - but I was curious as to what I can do with this. Ideally it would be nice to use this as a platform to link some non-connecter or TCP/IP connected devices to ST with more reliable, and more importantly local comms - for example, my tcp based alarm bridge tends to break a lot due to sheer number of intermediary components - I could shortcut this with a direct connection, making my XBee act like a bunch of switches and sensors
With that in mind, I have a few questions (if anyone has answers)
1 - I have not messed with drivers in a while, but last I did, you could not write a local comms driver (something that talks without need for internet) - only Samsung was allowed to do that - is that still the case? I have v2 hub, if that matters
2 - Assuming #1 is true, are there any known local zigbee device drivers I can emulate on my end where and if so, what are the most capable ones? Are there any links to protocol definitions?
3 - Does every zigbee device/driver use custom data protocol, or is there a common one for HA devices?
The whole point of having a protocol, such as HA 1.2, is that it is using a common definition of clusters. So Iâm having a little difficulty understanding what youâre asking.
In order to use a protocol like HA 1.2 or ZLL 3.0, your device must have that stack loaded. The manufacturer of the Zigbee chip you were using should have instructions on how to utilize their available stack libraries.
It is correct at the present time all custom code cannot be loaded to the hub. It either has to run in the Samsung smartthings cloud if itâs written in groovy (although this option will be going away sometime this year) or you have to host it yourself using the new API.
When you were asking about definitions for protocols Iâm unclear whether you were asking about zigbee or whether you are asking about Smartthings platform or whether you are asking about the new API. But hopefully others will be able to go further into this with you.
only Samsung provided Device Type Handlers that are specifically marked and loaded on the hub with the hub firmware are capable of running locally, period.
theres a ton to unwind about this question. Best thing i can suggest is undersand what DTHs are local first so you can see what your selection is. Funny this comes up today as the recent hub firmware beta 35.x will unlock local builtin automations but onky if all devices involved run locally (see item 1)
So that means youâre about to see a ton of people suddenly very interested in which device handler are local capable.
refer to the smartthings developer portal about âhub connected devicesâ (thabks for the correction JD) youll find the current documentation for building a Zigbee DTH.
So, #1 is answered clearly - it is still only built-in/Samsung provided DTHâs that are allowed to run locally - which has been the case since v2 came out - I was hoping for a change, but not so much.
As for #2 - Since I cannot write a local DTH, I was curious if there are decent Samsung provided DTHs I can co-opt for my device - i.e. use the âlocalâ DTH provided by Samsung and then emulate that device in my code on my end. The zigbee protocol is build into the hardware, so the only things I would need to do is emulate the driver/device specific protocols (and my question #3 was if said protocols are standard or per-device)
You can copy one, but it still wonât run locally on the hub if thatâs what youâre asking. You can select one of the DTHs which is downloaded into the firmware of the hub and assign that to your Device, but the minute you make any changes to it it becomes custom code that will run in the cloud. As a customer, You donât have permission to modify code that runs on the hub and have it still run on the hub.
As far as âstandard or per deviceâ thatâs not how zigbee (or zwave) works. Devices have a Device class and that class has certain characteristics. So there are standard generic DTHs provided for specific kinds of devices. Like a zigbee motion sensor, or a Zigbee Dimmer. But you canât use the DTH for a motion sensor for a device that is a dimmer or vice versa.
So you can select one of the existing local DTHs for a specific device class and use it with your device as long as it is the same class. That will still run locally.
Or you can take one of the existing local DTHs for a specific device class, modify it, and publish it to your account, but then itâs going to run in the cloud like all the other custom code.
To be clear, I do not intend to change the DTH side of them - just adapt my device to respond same as the intended device would. Do if it is a switch, I would return state of it, and process commands for on and off, etc
Thats nice as a high level concept, but probably has less to do with the protocol running on top of Zigbee, and more to do with capabilities DTH expose to the Hub. Since I am not messing with DTH - I have no way to changing any of that - so I am limited to whatever DTH supports.
Under the hood, however, DTH has to come up with a a small set of bytes that define requests for the device and understand small set of bytes that constitute a response for a specific device (aka âprotocolâ) That is the whole purpose for a DTH. That is the protocol I am interested in as I would need to understand it/speak it on my end. Now that I am writing this out, the fact that DTHâs exist at all is a clear sign that these are custom protocols
How do I know which devices are local and which are cloud? I picked a few at random and they all said Cloud so far
Actually, after playing with several DTHs - some of them are local, but it occurs to me that I would probably want more complex devices and anything with any sort of complexity would require multiple capabilities, and I would not be able to do that (for example, an Alarm system would be a collection of 64 sensors and a number of switches (armed/disarmed/etc) - I most likely would be forced to write a DTH, so local is not going to be an option
Or is it possible to have multple devices share same Zigbee endpoint (i.e. create contact sensors AND switches and have them all talk to same device on Zigbee Network?
