Schlage Sense lock BE479 + Schlage wifi adapter BR400

Right, like every Wi-Fi iot device out there provides a standard published API...
Anyway, good luck with your adventure.


The packets might be generic, but the communication and api sure as hell aren't.

1 Like

Sadly for home automation, WiFi is like buying an 18 wheeler as a family car. WiFi is great for streaming video but is far too fat for the needs of small battery powered devices sending an open or closed message. Batteries in the newest Zwave devices can last up to 10 years. WiFi devices in similar devices wouldn't last more than a few days.

1 Like

Don't confuse Wi-Fi with IP. You can do IP using other radios though it's not the norm yet. Thread is one example. It is IP-based but uses Zigbee radios (Too bad it is hobbled by a security perimeter)

Where are those devices? You may be waiting another decade. Besides, you were asking about a WiFi Lock.

There are some but that's my frustration ... but that's nothing new as when I tried to tell people about email in the 1960's.

Ha! You've brought back a bad memory.

The first IoT devices in my house were Connected by TCP bulbs that used 6loWPAN (also used by Thread). Connected by TCP bulbs were nothing short of horrible. Very high latency; commands often had to be repeated multiple times in the app to control bulbs in the same room as the gateway. These limitations led their market acceptance to be so poor that TCP pulled the Connected by TCP cloud 3 or 4 years ago.

To be honest, I remember being pissed when TCP lighting shut it down. I replaced those bulbs with zigbee GE Link and Osram Lightify bulbs, and less than a month later was relieved when my lights and lighting automation generally worked as anticipated.

1 Like

There have been problematic implementations and silly ideas like cloud dependency. But my goal is to understand why things go awry and fix them. There are some serious problems in the IP world but I also have more tools to deal with them and to extend the range. So, in the other short specialized protocols with unlimited budgets have some advantages but they also have real limits. Right now I'm trying to move away from Insteon for such reasons.

I also distinguish between issues with some of the current implementations and the very powerful idea of a common best efforts infrastructure.

Those tools also exist in the zwave and zigbee universe. Also, you have tools for 6loWPAN?

I want generic tools rather than having to maintain a network and tool set for each family. For example with IP can use VLANs when I do want to isolate traffic and share facilities.

I'm very aware of work still needed for Internet protocols and focusing on a common protocol maximized leverage.

6loWPAN does try to build on IP and it made a lot of sense 20 years ago. Today with capable devices it's not clear why we need a subset protocol.