Hello OpenHAB Community,
I’m currently engaged in a project within a home automation company where we’ve been managing device control through a proprietary mobile app and IR remote. Our system architecture involves various devices that communicate wirelessly within a home network. To advance our system’s capabilities and embrace open standards, we’re looking to transition to OpenHAB for device management and control.
Goal:
We aim to integrate OpenHAB to control our devices, leveraging our own MQTT broker. The plan involves deploying a Raspberry Pi board in each home to act as a local server, which would then interface with our mobile app. This setup is intended to manage all wirelessly connected devices within the home through OpenHAB, utilizing MQTT for communication.
Requirements:
Custom MQTT Broker Integration: We have our own MQTT broker that we intend to use. We need guidance or a method to integrate this broker with OpenHAB effectively, ensuring smooth communication between the OpenHAB instance on the Raspberry Pi and our devices.
Raspberry Pi as Local Server: Each Raspberry Pi will act as a local server in homes, running OpenHAB. We seek advice on the best practices for this setup, especially concerning secure communication between the mobile app and the Raspberry Pi/OpenHAB server.
Mobile App Communication: Our proprietary mobile app is designed to control devices directly. We want to shift this control to communicate with the OpenHAB server on the Raspberry Pi instead. Insights on how to facilitate this shift, particularly in terms of API use or other integration points with OpenHAB, would be invaluable.
Challenges Faced:
Lack of detailed documentation or examples for integrating a custom MQTT broker with OpenHAB.
Ensuring secure and reliable communication between the mobile app and the Raspberry Pi running OpenHAB.
Adapting our current device control protocols to be compatible with OpenHAB’s command structure.
I would greatly appreciate any guidance, documentation references, or insights from the community on how to best achieve this integration. Any examples of similar setups or advice on best practices would be incredibly helpful as we navigate this transition.
Thank you for your support and looking forward to your responses!
What do you mean with integrating a custom MQTT broker ?
MQTT Binding connects to a standard broker, just enter its network address in the thing config.
What is missing ?
Thank you for your response and for pointing out the capability of the MQTT Binding in OpenHAB to connect to a standard broker by configuring its network address in the thing config. I understand the flexibility that OpenHAB offers in this regard.
To clarify, our current home automation system incorporates IoT devices (chips) that directly connect to a Wi-Fi router. These devices are managed through a custom Android app, communicating via our own MQTT broker. Our primary concern has been the significant load on the Wi-Fi router due to multiple IoT devices connecting simultaneously. To alleviate this, we aim to introduce a central device (server) within each home network. This server would manage communications between the IoT devices and our MQTT broker, essentially serving as a middleware that reduces direct traffic on the Wi-Fi router.
Here’s the envisioned workflow:
IoT devices connect to the central server instead of directly connecting to the Wi-Fi router.
This server handles all device communications and then connects to the Wi-Fi router itself.
The MQTT broker is connected to this server, allowing for efficient data passage between our devices and the broker.
We see OpenHAB as a potential solution to act as this central server in our system due to its extensive support for home automation. However, we’re uncertain about the best way to integrate OpenHAB into this architecture. Specifically, we’re looking for insights on:
How to configure OpenHAB to act as an intermediary between IoT devices and our MQTT broker.
Best practices for managing device connections through OpenHAB to ensure efficient and reliable communication.
Any additional configuration or setup considerations to effectively use OpenHAB in this role.
We appreciate the OpenHAB community’s expertise and are hopeful for guidance on integrating OpenHAB into our system to enhance its efficiency and scalability. Any help or pointers in this direction would be greatly appreciated.
If you IoT devices connect to a WiFi network, you need access points to connect them. They than can talk to your MQTT broker if it is reachable from your WiFi networks.
openHAB is no access point.
Still not getting your full picture, might be good if you could provide a drawing of the topology you would like to build.
Thank you for your patience and for trying to understand our complex setup. Let me clarify our current product setup and how we intend to integrate OpenHAB into our system.
Current Product Setup:
We manufacture touch switches with a Wi-Fi chip integrated into the back of the touch plate.
When a button on the touch plate is pressed, it sends a signal to the Wi-Fi chip, and also activates the corresponding relay.
The Wi-Fi chip is connected to a Wi-Fi router, which facilitates communication with our MQTT . And from MQTT server we updates our custom mobile app with the status of the switch, and vice versa (the mobile app can also control the switch through the MQTT).
Desired Integration with OpenHAB:
Gateway Creation with OpenHAB:
Our goal is to use OpenHAB as a gateway through which all our Wi-Fi-enabled touch switches connect.
This OpenHAB gateway would manage communication between the switches and our MQTT server, effectively centralizing device management and reducing direct traffic on the Wi-Fi router.
The gateway would relay commands and status updates between the switches and the MQTT server, ensuring our mobile app is synchronized with the devices’ states.
Support for Multiple Device Types:
We’re also looking to expand our product line to include devices that use Bluetooth Low Energy (BLE), Zigbee, Z-Wave, and Matter, in addition to Wi-Fi.
We’re interested in knowing if OpenHAB can serve as a central hub that supports these various communication protocols, allowing all device types to be controlled through our custom mobile app via the OpenHAB gateway and MQTT server.
Questions:
Given this setup, is it possible to configure OpenHAB to act as the central gateway for managing communications between our Wi-Fi switches and the MQTT server?
Can OpenHAB support the integration and control of devices across Wi-Fi, BLE, Zigbee, Z-Wave, and Matter protocols, facilitating a unified control point for these devices through our MQTT server and update our mobile app also?
I hope this clarifies our intentions and the topology we aim to build. I understand OpenHAB is not an access point itself, but we’re looking to leverage it for its potential as a central communication hub that interfaces with our MQTT broker and manages various types of IoT devices. Any guidance or insights on achieving this setup would be greatly appreciated.
Sorry, but from what I understand, the setup does not make sense to me.
What would be the benefit of openHAB, if your devices should communicate with your MQTT broker, which updates your mobile clients.
I read it counter way - from my understanding wifi routers have limited resources dedicated to work with network level operations. They rarely bother about application protocols, as their main duty is to receive packet and forward it to valid destination. Running a MQTT broker forces router to bother about application, takes its resources to retain state etc…
All except Matter is supported. Recently there was a shift from zigbee to zigbee-js which runs within container, hence sentiment is a bit split nowadays. Matter is not yet covered in official distribution.
MQTT is supported in several flavors - generic one forces you to configure command/state topics, however there is also support for homie convention which assumes communication using specific payloads and structures.
I’m confused too because while this is absolutely true, how does running openHAB address this? The MQTt Broker is still needed. No mention is made in how the wall switches will communicate with openHAB except through MQTT in which case, all OH is doing is doubling the MQTT traffic.
Not using MQTT between the switches and openHAB. You’ll need to use something else to communicate between OH and the switches. From there OH can indeed convert the commands and updates to MQTT messages. If you stay using MQTT for the communication between OH and the switches all you’ve done is double the MQTT message traffic. OH adds nothing.
However, either way you’ve doubled your message traffic because now every message has two hops instead of just the one. On between the switch and OH and another between OH and MQTT. And since each message uses WiFi you’ve only increased the data flowing across the WiFi router.
I don’t see any way OH does anything here except make the situation worse.
OP already mentioned RPi, meaning there will be other server than router to take this load. It is there in first or second post.
What OP asks is perfectly ok. There is plenty of people within community who use shellys and other relays connected through MQTT broker.
I don’t really get why overall message in this topic is that there is nothing about openHAB in here, especially that OP posts mention other protocols which are supported by project and can be bridged at software level.
I guess because we don’t understand. If the goal is to reduce the load on the WiFi router, increasing the message traffic by making them go through openHAB first isn’t going to improve the situation.
Sure, we don’t know protocol between switches and app, so its a big question mark. Amount of mqtt traffic will be the same with OH if broker is co-hosted on rpi. Battle is about introducing server other than router device.
But OP already stated that “their” devices will talk to MQTT broker and mobile App will also read data from this broker. So apart from possibility to integrate other devices/protocols, I don’t see any benfit from using openHAB in this szenario.
That’s why I asked for simple drawing to better understand the topology.
