3 ms·

Very clever. IoT pairing is a tricky problem because phone/laptop devices give a very limited API for communicating with a new WiFi device that isn't yet on y

• iforgotpassword 3y ago
  I've seen an iot app do it via multicast - the destination MAC isn't encrypted in the wifi frames, and the last one or two bytes of them are controlled by the sending app. I figured this out when I tried to debug why the pairing didn't work from my phone, but did from an old Samsung A2: the iot device only had a 2.4ghz module, my new phone was on 5ghz...
• treyd 3y ago
  Isn't this was bluetooth was supposed to be able to help with?
  • exikyut 3y ago
    I suspect Tuya wants a solution that lets them implement a solution stack for Wi-Fi+BT and Wi-Fi-only MCUs alike. :/
• blincoln 3y ago
  All of the decent WiFi-only IoT devices I've seen bootstrap the process by acting as an access point of their own until they're configured. There are some opportunities for securing that initial connection better, like ensuring that the WPA2 key for the temporary AP mode is complex and unique to each device, but I haven't come across a fundamental flaw in the approach. Are you aware of any? I'd prefer an out-of-band option, like "physically connect the new device to the IoT hub's 'new device' port to configure it automatically before moving it to its permanent location", or "scan the QR code on the new device, which contains a public key that the IoT hub will use to broadcast the WiFi credentials over RF", but I understand that at least for mass-market residential products, that's unlikely because it generally involves more components on each device.