For simplicity, I'll describe this using a typical smart-home setup as a reference, but nothing here is really fixed by the application. The high level topology is equally suitable for a farm monitoring application covering several kilometres with thousands or sensors, tracking parking spaces in a city, or lighting management in an office building.
I'll treat the problem approximately in layers of device hierarchy, which might correspond to increasing complexity of an installation, or pulling in specific use case scenarios. Here is my generalised diagram covering the whole network.
Node level
The individual node in my diagram is a WiFi connected lamp with a local physical override switch. The node often has both sensor and control functions, and a small amount of local compute/storage. Ideally, the node can act autonomously. The node can take control from local switches, directly over the LAN (if it has WiFi/Bluetooth), or from either the local hub or the cloud. A node will frequently maintain a persistent TCP connection with the hub or cloud.
One location typically contains several nodes, with different functions, using various connectivity options. A smart-home might collect indoor/outdoor temperature, activity and video data. Remote sensors may use disparate connections to the internet. Nodes typically use microcontrollers, often at low clock frequencies.
Hub Level In a smart home, there might be several hubs (one for each device vendor), aggregation or hierarchy. The hub can be combined in the router, or stand-alone. The hub doesn't even need to be active in the network (other than to forward packets). However, the hub might be responsible for relaying commands to a node - commands originating from either other locally connected nodes or from a remote server. The hub might implement store-forward of data, compression or filtering of data. Really, the hub is just a facilitator. Today, the hub is the first part of the network that has the ability to provide public DNS, which makes it able to publish network structure information to the full system. As described in this question a hub is often necessary to bridge between Wired/WiFi TCP-IP to a low-power radio protocol, such as zigbee or bluetooth-low-energy. Hubs are usually built around microprocessors, and are less power-constrained than nodes.
Roaming Terminals Otherwise known as your smartphone. These are often the primary point of user interaction. A simple node can present it's entire user-interface through a smartphone, once the node can establish either a direct or a mediated link with a specific device. Achieving this fundamentally requires a mechanism for establishing trust/ownership/pairing. A terminal can establish if it's own hub is on the local network, if it needs to perform all communication via an external server, or if it is able to lookup the IP address which allows direct routing to it's 'home' hub. The latter scenario usually requires that the router is configured for port forwarding.
Cloud service It is common for the cloud service to perform the majority of the work in the stack, although this is not always necessary (and not all implementations will require any cloud function). The most useful feature that an external (publicly addressed) server can provide is orchestration. Every node and intermediate element of the network is usually able to communicate over a direct channel to this server, and the server can easily pass messages from one device to the others. The server can aggregate data and present visualisations to the user. Based on the user's configuration, it can also forward information to other users (access and heating control can be granted to guests for example, flood/fire/intrusion warnings could use other network options to generate alerts). The cloud is also well placed to take in other data sources, so modifying heating profiles based on forecast and calendar information, or feeding local sensor information into local forecasting models, generating alerts for utility providers and so on.
