Is it possible to provide a mobile app to control the Z-Wave end device?

This question is not specific to SmartThings. But specific to product development for Z-Wave based end devices.
My understanding is that the end device manufacturer needs to make sure that the hardware (say a Z-Wave enabled bulb) communicates with the different HOSTS (PC Controller, like HomeSeer). The Host shall provide the UI/Dashboard/Mobile app to the user for controlling the Bulb. Am I correct? As an end-device manufacturer, is it possible for me to provide an app to control my bulb? I don’t think so because the end device is going to connect to a z-wave network and my app cannot control the whole network. Please correct me if I am wrong.

You are correct, an application alone cannot directly control Z-Wave devices, it can do so indirectly by communicating with a Z-Wave controller or hub that manages the devices.

1 Like

Thanks for the response.
Let’s forget about SmartThings for now.

  1. An end-device manufacturer cannot provide an App to DIRECTLY communicate with the end-device because an app will not have the access to the Z-Wave Network.
  2. The only way a mobile app can be used to communicate with the end-device is when it can communicate with the host or the hub that manages the devices.

Are these two statements correct?

Are there any manufacturers which provide Mobile App which can be used to communicate with the end device, irrespective of the Hub?

I know that the SmartThings provide an App, but that is because they have their own ecosystem for their products and you cannot use that App if you are not connected to SmartThings HUB.

yes, they are correct. When you are talking about Z-Wave.

No not for Z-Wave. For Wifi or directly network connected , yes.

1 Like

Zwave always requires a hub, because zwave network ids are assigned and managed by a hub. Note that in the Homeseer example you gave, it is NOT the pc itself which is controlling the Z wave end device, but rather a USB stick with a Z wave hub inside, which is connected to that PC.

It is possible to create a mobile phone app to directly control at least some devices (but not necessarily all) of the following protocols:

  1. WiFi
  2. Bluetooth

From a network engineering perspective it is also possible to set up the following protocols without a hub to manage network IDs, but they still require a specialized device to translate their messages to WiFi before they can communicate with an app on a mobile phone.

  1. Zigbee (but only some devices). The specialized device is usually called a “bridge,” like the Philips Hue Bridge.
  2. thread. The specialized device is called a “thread border router.”

In an interesting development, Apple has designed the iPhone 15 pro (but only that model) to itself be a thread border router. Meaning that at the time of this posting, that is the one and only mobile phone where you could create an app to communicate directly with thread devices, including locks and bulbs, without needing another specialized device or a hub. Many people in the industry are watching to see if this proves to have any practical value over just using the existing Wi-Fi and Bluetooth methods. Too early to tell yet, but it is something to watch in this space.

Of course, if you are only interested in developing for Z wave, none of the above will matter to you. But if you are a hardware manufacturer looking at the future of Home Automation over the next 3 to 5 years, it does feel like thread may become increasingly important, particularly if matter takes off. And it does have the long-term potential for mobile apps that can communicate directly with end devices without going through a hub. But only if the mobile phone manufacturers follow apple’s lead on the included thread border router design. Still too soon to tell on that one.

On the other hand, zwave will continue to have an advantage for fixed location devices like locks and light switches because it doesn’t have to contend with potential interference from Wi-Fi the way Zigbee, thread, and Bluetooth do. It’s one of the main reasons zwave took off in the first place. So there are certainly arguments both ways. :thinking:


As we talked about in the Matter topic, the downside to the phone being the TBR (or Matter controller) is that you would only be able to control Thread devices when you are directly connected to the Thread network. That would mean the devices could not communicate outside the Thread network if the phone were the only TBR for the network. And the phone would not be able to communicate with the devices remotely. A physical device serving as the TBR (or Matter controller) makes much more sense than the mobile device.

You could still control the thread Devices with other thread devices on the same network, even when the phone was away from home. You know my feeling on this as on most things: choice is good. :sunglasses:

Phillips Hue has already demonstrated that there is a market and use cases for devices which are only controlled locally with their Wiz Bluetooth line and their standalone dimmers. Whether it is single room lighting or something like a college student in a dorm room, some people will be just fine with only having app communication to the device when they are in fact home.

And if the devices are thread, then it’s easy enough for those people who do want away from home access to add a second thread border router, most typically a smart speaker.

So, sure, you get more functionality with a thread border router that stays in the location. But there are some people who are fine with the other configuration.


Thanks a lot for responding.

Is it possible to build a mobile app which connects to the existing hub manufacturers cloud/ server to get data of a device which is connected in the hubs network ??

The idea is our (end device manufacturer) mobile app should be able to CHANGE the parameters of our device which is connected to the user’s Z-Wave network.

I would say no for SmartThings but I’m not familiar with most of the other hub manufacturers besides Vera. I think @JDRoberts would be able to give you a more in depth answer on this one.

To get data, sure, as long as the company running the cloud service has published their API. Which SmartThings has. They provide lots of details about this in their developer documentation. You can see The end effect in some popular third-party apps which already do this for SmartThings, like sharptools and action tiles. (You can’t see their actual code as both are kept private. But you can certainly see the proof of concept.)

And here’s the official schema for how this works:

The idea is our (end device manufacturer) mobile app should be able to CHANGE the parameters of our device which is connected to the user’s Z-Wave network.

Maybe, it depends on the device, but in SmartThings this usually Requires that the Z wave device be using a custom edge driver installed on that particular hub. It’s not a general feature of the SmartThings platform. And regardless of the brand of the hub, this will probably work much better with a mains powered device. Many battery powered zwave devices will not accept a configuration change immediately, but instead queue them up and apply them once a day (to save battery life). And some Z wave devices require that you perform a specific physical action on the device, usually some kind of tap pattern, before it will accept a configuration change.

So it might be doable, but it may require additional physical actions on the part of the end user, and it’s not necessarily simple. :thinking:

If you are designing a mains powered device which needs frequent reconfiguration, I would recommend Wi-Fi instead of z wave or Zigbee.

I should note that “parameters” has a very specific meaning in Z wave and it is different from the “control“ that you were first asking about.
Take a light switch that is a dimmer.
Changing the brightness from 50% to 75% is changing the “level“ or “state” of the device. It is NOT changing the “parameters. “
Changing how quickly the light turns off when you set it to 0% brightness is changing a “parameter,“ in this case, the “fade rate.“
The brightness level is just the result of a single command sent to the Z wave device.
The fade rate is the result of a parameter value stored in the firmware of the device.
State changes should definitely be possible just using the SmartThings API.
Parameter changes require reconfiguring the device, typically a more complex process that requires a custom edge driver and may require physical manipulation of the device.
So as you are researching, be careful to check whether what you are reading is talking about changing the state or changing “parameters.” This is an important distinction in Z wave.