My question is more of a generic architecture approach than a specific implementation issue. I just don’t see quite how the components all fit toghether. I come from a computer science background, so I’m pretty keen on coding things myself (but also having maximum flexibility) and don’t mind a more complicated setup.
So I’m building a simple setup with Raspberri Pi 3b. For now just a few components for a personal project - half a dozen smart things connected with a smartphone app as well (made myself, not the openhab configuration ui).
So I see that MQTT is a useful part for linking the smart devices toghether with the openhab software, and openHab will run on the raspberri pi and in a sense act as my “server”. However for my application I would also like to have a more involved server application (likely in Python, probably a Cherry Py server). I will eventually have a database and I would like to be able to make api calls to this server through my app (some REST api structure).
But… when I look online, all that seems to be included in the architecture are openHab, MQTT (as a lib/component loaded in openHab) running on the raspberri pi.
Am I wrong to try to include in there some REST api built in raspberri pi? Or could openHab allow me to do all of this, including the DB management and handling api calls from my smartphone app as well?
I don’t get your question.
You can have all those things running on a raspberry, I have mosquitto for MQTT, openHAB and RaumServer, which is a RestAPI Server for Teufel Raumfeld speakers on one piece of hardware. I also do logging with rrj4d database.
For the DB, I would prefer a different hardware, not a flash drive.
I’m software developer myself, but today it’s a lot more configuration work and when working on code (e.g. habPanel) it’s more copy&paste from online ressources. Much less old-school programming.
@FranckyVee let me see if I got your questions correct with the following description:
Think about OpenHab as a central service that can provide logic and integration to your homeautomation. OH2’s core gets and writes its information on an internal event bus. For your devices to interact with this event bus, you will need bindings, think of MQTT as just one of them, like you would need a binding for Philips Hue/Ikea’s tradfri if you were to use one of these smart lights.
Of course, these bindings may need to interact with other services, for Hue/tradfri it is a bridge, for MQTT it is a broker. So, your smart device connects to the MQTT broker (or bridge) and needs to bring the ability to do so to the table by itself (that’s the smarts in smart devices).
device <-> MQTT broker <-> MQTT binding <-> OH2 would describe this chain.
Databases and UI’s would work the same way, your OH2 needs to be configured to use the database (what needs to be stored in and retrieved from the databases). This is just an additional service that you can activate and configure with many options. This use is called persistence in OH2.
OH2 comes with more interfaces and has a built-in REST API too, that you can use as you wish (feed information to the system or get it out of the system to use as you please).
So one way, I can look at OH2, it just a the center of the wheel and all the services (most of them will need bindings and all are configurable) are the spokes. UI’s work the same way, they are just modules that interact with central OH2 system. At its core, OH2 then provides the links and logic how all these parts work together.
Where this all can become confusing is the level of choices that OH2 gives you, for all there are multiple choices and multiple solutions possible.
Maybe start trying to read again at the very first overview (https://www.openhab.org/docs/) and basics of configuration (https://www.openhab.org/docs/configuration/)
Does this help? Apologies if I am completely off the mark here…
