Yea great question. The bulbs were provisioned via an iOS app and there was a Wifi bulb sold that had a speaker in it (part of our pivot towards more marketable products)
The bulbs could have been updated either by A) having a wifi bulb that then synchronized each other node via a low power mesh network, or B) by opening the app and connecting to the network.
We effectively used the BLE radio to make a mesh network and a BLE device (phone) could connect and send and receive over the mesh.
This is exactly a product idea I had and a product I have been desperate to find and buy. Included the "no cloud connection or hub needed" being a desired feature.
Instead I now have a crappy overly complex setup that involves a bunch of lifx bulbs, a flic hub and buttons and a synology NAS running some python scripts from task scheduler every few minutes to set the desired temperature at certain time ranges (hard coded).
That Twist idea sound(ed) perfect. What a bummer that it didnt work out.
I kinda wish industry would converge on one standard for the devices themselves and compete on "IOT cloud/hub controller" instead of trying to build tiny closed ecosystems around eachother.
MQTT + some schema for typical devices would be a dream. Maybe have some of those devices be able to act as hub themselves with option to connect to "bigger" controller (whether cloud or on premise) but still be able to handle basic functions when say internet is down
That kind of already exists with Home Assistant. Granted, it often feels like a thin wrapper around lots of tiny closed ecosystems, but the fact that most things interoperate well enough means I can recommend it.
Matter/Thread exist as well, and some smart device makers claim to already have adopted it, so we'll see how that all goes.
I used it few years ago and it had problem of occasionally disconnecting from MQ (I was using external one) and just... not reconnecting.
> Matter/Thread exist as well, and some smart device makers claim to already have adopted it, so we'll see how that all goes.
I'm kinda worried it will be the usual bloated standard by comitee result; tho I guess even if that happens it would still be better to have to implement one bloated standard instead of dozen incompatible ones.
Also at least wikipedia page says its "Proprietary, by certification" so eh, I'm worried
You're kind of describing home assistant. It integrates with all the various non interoperable standards and gives them the same interface. (In the ui sense, but also in the sense that you can write scripts that cross manufacturer boundaries.)
I know, but I'd prefer if it came that way from manufacturer instead of hacking at it away.
Like, I converted one of (sadly out of production) mpower pro power strips (it was great, cheap 6 socket with power measurement per socket) to talk to it but it wasn't exactly great experience.
The config of IoT devices should be just "start an app, point it to your (or cloud) controller, done", not "browse compatibility list and hope HASS supports it and the manufacturer won't break that support on update".
The bulbs could have been updated either by A) having a wifi bulb that then synchronized each other node via a low power mesh network, or B) by opening the app and connecting to the network.
We effectively used the BLE radio to make a mesh network and a BLE device (phone) could connect and send and receive over the mesh.