The research in [18] defined three types of BC IoT interactions. In the IoT-IoT approach only a part of IoT data is stored in the BC. End devices predominantly communicate directly (e.g., over a sensor or peer-aware network) without using the BC. This approach has lowest latency. In IoT-BC all interactions go through BC. This ensures that all interactions are traceable, but increases the bandwidth and data in the chain. In hybrid design only a part of the interactions take place in the BC and the rest are directly shared between the IoT devices. The hybrid operation leverages the benefits of BC and low-latency interactions. The fog principle in the hybrid approach can incorporate more powerful devices such as gateways, which can then be used as BC components. This enables the secure participation of constrained devices in blockchain communications. In the same study they presented a resource estimation for various BC clients, including Ethereum, running in RPi v3, but no variations in end device architecture or the impact of communication adaptation were analyzed. Running a light or full blockchain node in a constrained end device is possible, but permanent connectivity beyond low-bandwidth is required. We have various other, more efficient implementation options for the device-to-BC connection, based on remote and trusted BC nodes: (i) we can rely on \"of-the-shelf\" BC node API. This does not facilitate any application-awareness and adaptation and thus impedes further communication traffic reduction. The second option is (ii) proprietary customization of BC nodes, their APIs, and device communications. Beside the large efforts to maintain such a solution, the legacy approach increases heterogeneity and thus leads to vertical silos, and reduces the interoperability and security of the solutions. BC services can be provided via (iii) cloud APIs, for example, in Hyperledger [20]. This reduces the decentralization of the solution. Our proposed option is (iv) applying application-aware gateways to facilitate BC services for the end devices. Unlike in (iii) the end device can execute BC operations if required (e.g., create transactions, sign transactions, and receive event notifications) or delegate these functions to the gateway. Gateways can be thus fog elements that are located at the edge of the network. A context and application-aware fog smart gateway, and its role in fog computing and cloud of things, is presented in [21], but not specifically for blockchain. In [22] a LoRA implementation of BC aware GW was presented, but no real traffic measurements are given. Our study was initially motivated by our previous work with blockchain IoT systems. We were focusing on the blockchain IoT client architectures [23] and the challenge of connecting communication constrained IoT devices to the Ethereum blockchain network. To our knowledge, there has been no study of application-aware gateways for IoT and blockchain integration with measurements of real traffic in communication of BC--enabled IoT devices. For the research in this paper we designed an application-aware gateway for constrained devices and implemented its server and client part in NodeJS [24]. We soon realized that such a gateway could support other application examples apart from the blockchain. Its design therefore enables efficient extensions with other application-aware services. We tested the gateway in various application examples. Using it leads to a significant reduction in the required communication traffic to/from the IoT device. It does not aim to reduce latency. Blockchain operation is not real-time and major delays appear there because of the nature of BC transaction validation and not because of the communication or gateway processing delay. For ultralow latency applications, a hybrid approach for BC IoT interactions can be taken [18]. In the blockchain-related use case we effectively enabled decentralized applications (DApp) for the devices that without our solution could not participate in a blockchain network.