This sounds like it could be useful if you want to have a bunch of IoT devices (possibly on the same network) which interact with each other directly without going through a central server.<p>In most cases though, your IoT devices do need to interact with a central authority (not just with each other). For example, if you have a web-based dashboard which displays the devices' state, it means that the devices will need to send that state to a central authority from time to time (in order to keep the web-based dashboard updated). Also, if you want users to interact with these devices from that dashboard, then the devices will need to receive commands from that central authority too.<p>What I'm getting at here is that in many cases, it's more practical to make all your IoT devices talk to each other through remote servers than directly with each other because usually there is an element of 'monitoring and coordination' which means that you need one or more remote servers to act as a central authority for the IoT network.<p>It may be more efficient to just make all the devices talk to each other through pub/sub hosted by a central authority than directly with each other... Unless your IoT devices are fully autonomous and that data doesn't need to be aggregated (which, to be fair, may cover some use cases).<p>Or maybe also this could be useful if this network of devices works in isolation - For example, the dashboard connects directly with your devices without needing to coordinate with external data from devices owned by other users.
> the basic functionality is simple enough to run on tiny IoT-devices<p>But it seems to be written in Python... Why do all of these IoT platforms forget that most things will be running on a Cortex M3 with 32 kB of RAM?<p>Or am I missing what this is? Their explanation is kind of buzzwordy.