Hi @JDRoberts, I don’t know if you were on the developers call yesterday… There was a lot of talk about reliability…There is a lot of devices out there that are not z-wave or zigbee. In fact, I think that a lot of the upcoming devices will be wi-fi or bluetooth or some kind of variation in the near future.
The developers of those devices need to be able to implement them with performance and reliability characteristics built-in, and not rely on their network protocols to do so.
This approach would allow the ST platform to achieve a good user experience from beginning to end…
i’m sure you’re right: apple’s HomeKit is going to greatly increase the number of home automation devices with Bluetooth.
However–the most recent Bluetooth standard approved Bluetooth
Mesh. The good news is that means range longer than 50 feet. The bad news is that means it’s no longer point to point, no guaranteed command sequencing.
My personal guess is that a lot of Bluetooth home automation installs will rely on Bluetooth mesh for all the same cost control and network resiliency reasons as zigbee and zwave. So I don’t think Bluetooth will necessarily solve the problem.
As for wifi, three issues there, which is why WeMo doesn’t already own the home automation market.
power consumption is higher (this is why WeMo’s own bulbs use zigbee, not wifi)
each device requires its own IP address
number one complaint about wifi devices in home automation is that the network is not self healing. When a device drops off for any reason, you often have to reinclude it. Look at the complaints people have about WeMo devices needing to be reset every few weeks.
Yes, you can harden the network with a lot more money. But–it’s a lot more money.
So I agree we’re going to see more Bluetooth devices next year. But if they’re Bluetooth mesh, it’s still mesh.
@JDRoberts Also, I’d say that some of my z-wave devices (locks and thermostats for example) would also benefit from non functional capabilities… I don’t know why exactly there are so much performance lags, but I think that just relying on the 4 OSI layers (up to transport) for performance improvement is not enough.
I found a potential name for the non functional capabilities that I suggested…
We could call them device type annotations (loosely derived from EJB annotations) if we want to distinguish them from functional capabilities in the device type category…
Like I said in earlier threads, they would give additional information to the hub or to the cloud container(s) for handling a device type in order to ensure high throughput, reliability, security, etc.