Zigbee Integration

Devices & Integrations
1

Is there a document that specifies the integration with Zigbee?

The main question I’m interested in is:

When a Zigbee device joins a Smartthings hub, does all messaging go through the hub?

For example, if I have a up/down dimmer positioned next to a light (both Zigbee) and they both join Smartthings hub, I can set up an automation to assign the up/down buttons to on/off on the light. However, the response time is really slow (a second). Furthermore, it doesn’t seem to support hold-down dimming (This might be an API limitation).

On the other hand if the button and the bulb are paired directly with each other (they are both IKEA, but I assume they using Zigbee NWK to some extent), then the response is very quick.

This led me to find out more about the nature of the Zigbee integration. As far as I know Zigbee supports peer-peer messaging. That the response time is so slow, suggests to me that the Smartthings topology enforces a round trip from the button to the hub and back to the light. Does Smartthings support the ability to configure Zigbee pairing of devices so that they can talk directly to each other?

2

I’ve never looked, but I suspect it would be found in ST’s developer documentation for directly connected devices, similar to his:

https://smartthings.developer.samsung.com/docs/platform-basics.html

That doesn’t sound normal for the platform (for zigbee devices at least). I have a very large Zigbee mesh with all kinds of devices that constantly hammer the mesh with all sorts of data coming from them, and response times are practically instant. This is regardless if it’s a switch or sensor, or what ever Automations or SmartApps I have controlling/monitoring those devices.

I just used a zigbee dimmer switch to press and hold down/up levels and watched the app (Classic) report level changes immediately. My device also logged these events. Response times between the device and seeing it in the app were practically instantaneous, but never slow from my perspective
image
2020-06-12 7:23:40.402 AM EDT (level 87)
2020-06-12 7:23:42.159 AM EDT (level 100)
2020-06-12 7:23:45.983 AM EDT (level 78)
2020-06-12 7:23:47.068 AM EDT (level 65)

Those response times were from holding down to set the level up/down, so however fast the device sent the level value is how fast ST handled it. I could see the lights step up/down and at the same time watch the app change. The key takeaway here is however fast the device sent the value. I can’t adjust the step values or rate on this dimmer (unlike on some zwave devices from the same manufacturer), but what ever the defaults are were more than acceptable in my opinion.

I’m not sure if it’s correct to say that ST forces messaging, but more like ST implements the Zigbee spec as designed. More info on Zigbee standards can be found here (if you haven’t seen that yet) :https://zigbeealliance.org/

My response times are so fast in my zigbee mesh (I have over 250 zigbee devices), and do not see any slow response times. On a couple rare occasions I have see odd things happen, and in every case it was either a device failure, a repeater being unplugged, or interference.

I’m just sharing this info to give you another data point on Zigbee behavior on the ST platform. Perhaps your response times may be influenced by something else?

3

You are asking about “multicast binding.”

It exists, and can be done. For example, it’s the usual way of using a Hue dimmer switch as a parallel means of control for directly connected bulbs. You add the Hue switch and the bulbs to the smartthings Network. Then you individually bind the bulbs to the Hue switch. Now the hue switch will groupcast directly to those bulbs without going through the hub.

It’s also commonly done for the IKEA handheld remotes.

That said, smartthings doesn’t tend to maintain these connections very well, and it’s pretty common for the remote to end up stealing the bulbs from the network so they are no longer usable from the smartthings app or automations. So you end up having to redo the connections every so often.

There’s quite a bit of existing discussion on the practical methods for doing this for individual devices, so just search the forum for the specific device you were interested in.

In all cases all the devices have to be added to the SmartThings network first. Then you set up the multicast binding, typically with physical manipulation of the remote when it is physically close to a bulb.

On the other hand, as @johnconstantelo said, messaging through the hub should be very quick, nowhere near one second. So it sounds like something else is going on with your setup.

1 Like
4

I didn’t measure it, so it may well have been much less than 1 sec. In any case it was noticeably slower. It was the difference that that put it into my head to ask if it was going a different route.

But thanks @johnconstantelo too, for the data! I would say that the delay when going via the hub was not so slow as to be unacceptable, but after getting used to the response using the direct pairing, I felt I had lost something.

5

What devices are you using?

zigbee devices that use local device handlers are very fast, but if the handlers are not local, you need to make a round trip to the cloud, which will be a noticable delay

6

Way too many to list, but most handlers are local. The cloud DTH’s I have are for my Aqara double rockets and Xiaomi Mi LUX sensors, Pearl thermostats, and Halo smoke detectors (ST’s still run in the cloud). Even with the cloud DTH’s in the mix, performance is extremely fast (way less than a second). My new Aqara double rockers perform as if there was a direct connection. It would literally have to be measured in 1/4 seconds they are that fast. Here’s a quick video. Remember, the DTH is in the cloud and I’m using the new app:

ALL my devices work this fast.

1 Like
7

I can appreciate that the response times can be fast even if a round trip over broadband is needed. It’s been discussed already, but for me it’s the notion that it even requires a round trip is a problem. I understand it’s a legacy issue.

The cloud is about bringing stuff (whether it be docs, apps, services, functions) TO the client, not to force the client to go out to the internet. It’s about making distance disappear, not to insert it artificially.

Speed is not an issue when things are fine. But many people don’t have reliable broadband (otherwise why would it be in political party manifestos), and it does suffer outages, peak loads, etc, etc. Sure it’s perfectly good for most of the time, but we never thought we would be banned from going to the pub for 2 months did we?

One of the things that attracted my interest to Smartthings was the device type handler concept as a way of abstracting the interface to various manufacturers implementations, and then wifi/Zigbee/Zwave/cloud connections. Perhaps I am naive, but I expected that DTHs for Zigbee devices would already be exploiting peer-peer capabilities, as appropriate according to the nature of the “Automation” being set up. i.e. that the encapsulation would hide details of whether it was a simple on/off message, requires some role of the hub, or requires something from the cloud. It seems that the DTH is fixed to either being locally (i.e. hub) executed or cloud regardless of complexity of the automation.

8

That’s fair. You probably should have dived into ST’s architectural materials, and then compared that to something like Hubitat.

1 Like
9

Essentially, that’s what I’m still in the process of doing: getting to understand the Smartthings environment. But as you say I think my best option is to study the Home Assistant and Hubitat route. Thanks for the reference.

I installed Home Assistant last week, followed the Getting Started instructions and in 2 hours (1 hour downloading and watching Netflix) I was all set up! One small error, they didn’t point out to ignore the console login prompt when the RPi boots up!

On the other hand, anyone who has been on this for more than a few years should try role-playing as a Smartthings newbie and following the Getting Started documentation. It takes you down a very tight closed loop of links which involve 2 samples, neither would work if you didn’t already have a coloured light or didn’t know what LIFX was. Remember you’re supposed to be a newbie - not just to Smartthings, but to Home Automation in general - I only had a hub and two mono light bulbs, a button, a motion sensor. You don’t often get to choose what’s in the Xmas stocking, and I didn’t want to spend money I wasn’t going to get back if I wasn’t happy with my experiment.

Then, if you want to skip the samples (because although you already knew what a webhook was, you didn’t really want to know if ngrok was the only way or just one way, or was it also glitch, or why don’t they just say up front, you need a http endpoint with a public certificate - as prominently documented on Home Assistant), you look for tutorials. Besides, I didn’t want to open yet another account I was never going to use again, this time on WeatherAPI. The tutorials link takes you back to the two samples, or you can go straight to the documentation. There is no tutorial! (There are pictures, with terms that are not consistent with the documentation)

So you start looking at the documentation, and you find errors that are probably long standing but still haven’t been fixed. And on it goes, you end up getting the impression that despite the brand and the promotions, there isn’t actually an awful lot of effort being put in in terms of quality.

So you query some design decisions:

  • why are the permissions/token rules inconsistent between /schedules and /subscriptions? No answer. (There may well be a perfectly good answer. But I get no answer)
  • why do /subscriptions have to be done in the context of a fully fledged SmartApp? No answer. (And I find, as I suspected I would, that Home Assistant is forced into going down this route in order to integrate with Smartthings. Result: I’m probably just going to ditch the hub - yet another one for eBay - and fall back on Zigbee)
  • and of course, the issue on this topic, about why so much needs to go back to the cloud (The answer to that appears to be: Oh that’ll be changed, Oh no it won’t! Oh yes it will!..doublespeak)

…and it goes on, you can be a perfectly qualified developer, but if you don’t have experience in the home automation world, you are just there to read and learn. “Not Invented Here” seems to be the pattern of behaviour.

…then if you experiment (which I believe is the honest approach if you lose faith in the written word) you are accused of (to paraphrase and misquote) sitting backwards on a (as it turns out) two-headed horse!

It’s disappointing, because the whole platform looked excellent on paper, but it seems to fail on implementation, on quality and on support.

10

SmartThings staff have said multiple times in this forum that their typical customer has less than 15 devices and never uses any custom code. They don’t know what a webhook is. They don’t know what Ifttt is. They aren’t looking for the kind of documentation that you were looking for as someone with a strong technical background and an interest in developing.

Their typical newbie customer buys a device which says that it works with smartthings (hopefully out of the box). They open the app and fumble around with creating an automation and end up with something that turns the light on 15 minutes before sunset. And they think it’s really cool. :sunglasses:

No question, there are all kinds of gaps and confusing places in the SmartThings “developer documentation.“ That’s been true since the beginning, mostly because it’s never been a big part of the target market. And it’s definitely frustrating if you are coming at it from a different angle.

I just think there are other platforms which are a much better fit for the goals that you’ve described. As I mentioned previously, Home Assistant, Hubitat, and Insteon are all aimed at technical users. I think you would just find your frustration levels much lower with any of those.

I had a strong technical background (I was a network engineer) before buying smartthings for my own home, but at the point of purchase I was physically very limited and I was looking for a simple plug and play system that could handle Zigbee sensors and a Z wave smart lock. And eventually probably some zwave light switch is (although I ended up going with Lutron). I also needed an app that supported voice control.

Smartthings was a pretty good match for that, although if you see any of my earliest posts you’ll see that I was incredibly frustrated that it didn’t handle Zwave local scene controllers (and still doesn’t). Over the years that became less significant because the Z wave specification itself introduced central scene controllers, which are easier to integrate with smartthings. But it still annoys me that you have to use custom code just to set the associations for a virtual three-way switch setup.

Anyway, you definitely have my sympathy, and I’m not disagreeing with you at all regarding the quality of the documentation for developers at the present time. I just personally, in your situation, wouldn’t waste the energy wondering why smartthings doesn’t do a better job of that, or expecting it to change Any time soon. I’d move On to something which was a better fit. But that’s just me.

11

That point has been made several times, but I never thought why it was relevant. Windows, IOS and Android typical customers do not write programs, but there are developers who do. They did not need to publish an SDK for the sake of it, but having done so, you expect it to be properly supported. Smartthings did not need to publish an SDK, and could instead have relied on proprietary app development. The simple fact that they chose to is enough to expect a better level of support than we currently get. That the choice might be based on improving the level of adoption of the platform (by increasing integration possibilities, and creating application universe) is even more important - because it benefits Smartthings!

That point has also reinforced the two-headed horse image: I first asked why there are only 8 publicly available SmartApps, to which the answer was ultimately there are thousands of them if only you will look, but they are all cut and past scripts! Is it a consumer and a developer platform at the same time? (Well actually, I think the answer is yes, in the same way as Windows, IOS and Android are both. So that’s why I don’t think the point is relevant.)

Even if the API/SDK is not meant to be a fully fledged development environment, isn’t there an engineering principle that with a quality product you should be able to slice it open in any number of ways and it would still look well engineered. (For example, if I were to start dismantling a Mercedes, would I start to see bits of random shim and manual filing in places where it didn’t quite fit right?)

I said up front that my criticism would sound harsh. It seems to have been responded to in a number of ways, including:

  • It’s not a developer platform
  • looking at it through the lens of the past (ironic considering what Wikipedia says was the event that motivated the founder to create Smartthings - a power cut!)
  • that’s something for another thread
  • that’s a future thing (without specifics)

What I find more disappointing than everything else added together is the response that should be at the top of this list is: the no response. It’s as though the attitude is of “using the past as an excuse for the present”, rather than “using the present, to determine what we will do in the future”.

In your message, you have pretty much implied agreement with my assessment that the platform is disappointing from the developer perspective (because you only offered an excuse, rather than a rebuttal). When I raised change request to fix the inconsistency in permissions model between different parts of the API - no response. When I suggested we should have more natural support for states rather than events - no response. And on it goes. It’s not that I’m claiming I’m right, I’m just amazed that there is no willingness at all to engage in a discussion! I’m perfectly prepared to be wrong - (I’m educated as a scientist, so being wrong makes me happy because I’m learning something). So I don’t get why, whenever a criticism is made, it’s met with an excuse, a vague promise it’s being worked on, or silence. Does this mean that the criticism is valid, despite the harsh way in which it is expressed?

1 Like
12

CONSISTENCY

You’ve mixed together my response with responses from multiple other people, which gets confusing.

Remember, this is not an official support channel. This forum was set up many years ago so the customers could help other customers and share ideas.

So the responses you get are not necessarily going to be consistent, they are just the ideas and opinions of multiple other customers, mostly. There are a few staff members who participate on their own time, and their responses should be consistent with each other, but again not necessarily with those of the individual customers discussing the same topic.

MY MOST RECENT REPLY

The response of mine that you quoted was in direct reply to this comment of yours:

Remember you’re supposed to be a newbie - not just to Smartthings, but to Home Automation in general

I’m sorry if I wasn’t clear, my point was that your definition of “newbie” and your concerns about the lack of documentation for yourself and other newbies like you was that smartthings’ definition of newbie is very different than the one you presented.

Their target market just isn’t going to be looking for the same kind of documentation that you are. In fact, they probably aren’t going to be looking for any documentation at all.

WHERE WE AGREE

I agree absolutely that if smartthings is going to offer A platform that developers can use it would be great if they documented the features of that platform in a clear and easily findable way. But so far they haven’t.

So I don’t disagree at all with any of the pieces that you’ve identified as being missing. It would be fantastic if those gaps were filled in.

GOING FORWARD

But honestly, I’m tired of being criticized for just contributing to a conversation. I’m just another customer. If you think smartthings is a good fit for what you want to do, I’m happy for you. If you want to spend time in this forum complaining about the lack of developer documentation while you work with it, that’s your privilege. There are people who enjoy those kinds of conversations.

For myself, my energy is limited and my ability to use the forum is also limited as I rely on text to speech software. I enjoy hearing about new devices, and I enjoy helping people solve practical problems if I can. And I enjoy reading about the practical creative solutions that other people have come up with.

I’m not a developer, so I can’t comment on the details of those issues once they go beyond protocol specifications and device class features.

and personally I’m just not interested in arguing about why somebody did or did not reply to a particular post in a peer support forum.

But I’m sure there will be other people who do enjoy those kinds of discussions. Just don’t take my absence for anything other than what it is: exhaustion. :sunglasses:

Carry on.

3 Likes
13

@JDRoberts First of all I should make clear that I’m not directing my messages specifically to you! That goes especially for the criticisms! When I write a message, its in response to the thread, so sometimes it will be in direct response to a message that you might have sent, but most of the criticisms I have made historically have not been directed at you or anything you have said.

But you obviously feel that they have from reading this:

So please accept that I make criticisms of behaviours and ideas, and they are not purposely targetted at individuals. In fact, I think you have been a star on these forums and I dread to think what Smartthings would do without you! As I said, the most disappointing failure has been the lack of engagement from Smartthings staff, and you certainly cannot be accused of that. Without your contributions, the silence from Smartthings would be truly deafening! Or just plain dodgy…

NEWBIES

(Newbie/Experienced), (Developer/Consumer) - These are two orthogonal axes aren’t they? My use of “newbie” was intended to mean Newbie Developer. So in that sense, and given that there IS an API/SDK, I think I’m right in expecting Smartthings to deliver on my expectations.

So, going forward, I’m not surprised you feel exhausted if you feel that you have to respond to everything I write. I was recommended to contribute here by Tech Support, and since Tech Support don’t seem to feel the need to confirm with a fact that simple features of their system do in fact work, it seems my opportunities to gather information are somewhat limited. If the Smartthings staff had some sense of the service you give the forum, you would expect them to show some engagement. And if criticisms are made of the platform, I would expect Smartthings staff to either acknowledge it or to defend it and put me right. I wouldn’t expect that to be your job, since it sounds like you don’t have any disagreement with the objection basis of what I’ve said.

1 Like