I integrated both ways (sensor starts connection/server starts connection), but i am not sure which one is better.
Both have pros/cons.
Version 1
Sensor (eg Tasmota) does not know anything about OpenHAB.
So the “brain” knows where to look for data and so on.
pro no special setting needed to install the sensor.
con if the sensor changes (eg. breaks down, new MAC) OpenHAB needs to know about the changes.
Version 2
the sensor knows about the “brain” eg the MQTT server.
pro if the sensor changes, only the sensor config needs to be reinstalled and the system is up and running.
con: the info is not centralized.
which is the preferred way to go? are there any best practices?
another thought i had on this:
if the sensor is like a base config, with the setup it can broadcast the net, and OpenHAB offers all “Slaves/Clients” it has, and their configs/images.
Would that be possible to have an OTA update for a device replacement? could be a nice feature.
If that is already out there, i might be looking for the wrong wording. Any hint is welcome.
In general a push is better than a pull. The sensor detects a new temperature (for example) and pushes the new temperature.
Both HTTP or MQTT can be used by the sensor to push the data.
Given that, your Version 1 is already less good than Version 2.
Unless Tasmota is changed to make HTTP calls to OH to publish sensor readings as needed.
You will have to configure the sensor itself though. Adding in an IP and username/password (in the case of MQTT) isn’t that much of a burden.
Unless the sensor calls OH instead of OH polling the sensor.
OH is the brain. The MQTT Broker is aptly named. It’s a go-between publishers and subscribers so that the publishers and subscribers do not necessarily need to know anything about each other. They just need to know the names and meanings of the topics and what sorts of messages to expect to be published there.
One huge advantage of having this broker in place is you can change out the sensors or OH (e.g. replace it with HA) without needing to change anything else. The sensors don’t know or care that it’s OH or HA reading the sensor readings. OH doesn’t know or care that the sensor is running Tasmota or ESPHome or ESPEasy or whatever.
I don’t understand this statement. The info is centralized in the MQTT Broker.
MQTT has additional benefits over HTTP such as the LWT which will cause the MQTT Broker to publish a message to a topic when the Broker detects that the client has gone offline. There’s QOS which can be used to guarantee messages are delivered exactly once (QOS 2) or lower the overhead and just attempt to deliver the message once and if it fails drop it (QOS 0).
That;s basically what you get with MQTT. So long as the new sensor publishes the same messages to the same topics as the old one, OH doesn’t know nor care that the sensor changed.
That’s outside the scope of what OH would do I think, but there are tools for centrally administrating and configuring devices running Tasmota. ESPHome and ESPEasy might have something like that too.
If the devices are publishing MQTT information following one of the supported standards (HA, Homie, etc.) OH can automatically discover the devices and create the Things for you.
thank you for the reply.
I guess my wording did its part for some confusion
You are absolutely right: push vs pull should have been my question!
but regarding
not really. the sensor data is centralized, but the configuration is decentralized. every sensor needs to know the MQTT Broker.
with the pull aproach the sensor just needs to have the same ip, and everything is done.
anyways! Thank you again. that shed some light in my thoughts…
esphome and espeasy sounds like the other topic i was looking for.
maybe the combination of the two will solve my where is what info/config stored and maintained.
I dont think they aim for sth i look for.
Kind of like a DHCP Server that provides the IP Address. This setup would provide the binary and config for devices.
Situation:
Sensor broke down. I want to replace it. I tell the device its “name” (must be unique in this setup, and best case, written on it) then the device boots… broadcasts… gets its firmware and configuration >> restored.
No need to know about where the CCU is, how its called, how it works.
So i was aiming for the maintenance scenario. Even with the Sensor connection MQTT vs URL.
What is easier to maintain… bring back to life. Best practice.
Right now all those home automations are basically working because the admin is living there It is not a level like an electician can come in, and knows how to restore this or that device.
Maybe i am reaching too far. but i see that this community (and tasmota/ESPHome/ESPEasy/…) are doing such a great job, that i think in a near future this can be possible.
I’ve been running 35 Tasmota-flashed Shellys (1PM, 2PM as relays, 2PM as shutter controllers, Pro3 as Relay, 10V dimmers, and RGBW) over MQTT for almost two years. The initial MQTT setup was the easiest part of the project (the hardest part was fitting the Shellys behind the existing wall switches).
Setup: Shelly (MQTT) → LAN (Router) → mosquitto on Raspberry Pi → openHAB
I can really recommend this reliable setup.
On the topic of centralization: you really only need to establish a network and MQTT connection, and then you can configure most Tasmota settings centrally from the server command line or via specially configured openHAB channels.
