Get openHAB item values down to esphome devices via mqtt_subscribe sensor

Good afternoon (o;

Still in the process of migrating away from homeassistant to openHAB…so far ZigBee, Homematic, BLE (after reboot) and esphome devices work via MQTT binding.

Now as I’m totally unfamiliar with MQTT…do I need additional setups to be able to use the esphome mqtt_susbcribe sensor to get sensor values and switch states from openHAB?

This is the last piece of puzzle as I have several e-ink based dashboards running esphome for displaying weather station infos.

thanks in advance

The basic model is that an MQTT broker sits in the middle.
Any client can publish messages to a named topic.
Any client can subscribe to a named topic (others may or may not be publishing to this topic) to be copied in on messages, by the broker.

There is no means for one client to interrogate another, you can only choose to listen to what the broker offers.

openHAB publishes nothing to the broker by default, so yes.

Okay…right…just installed MQTT explorer…seems to be a nice tool…and I see the topics curretnly my esphome devices publish to openHAB.

Okay…if I understand correctly this is where the Generic MQTT Thingie comes into play…
so add a channel there a link to the item…right?

Remember that anyone can subscribe to those messages, multiple anyones. You don’t need openHAB to sit in the middle. The MQTT broker is a service completely independent of openHAB.

You’d generally only need to publish from openHAB stuff wholly generated within openHAB - instructions like “turn on”, or some calculated value, etc.
If your dashboards or whatever can get the message straight from the horse’s mouth, do it.
openHAB can listen in as well of course, but doesn’t need to re-publish it.

Internally to openHAB, the general model is that an Item represents some device.
It’ll have a state, a condition (typically messages from a real device will be processed by an OH binding, like MQTT or zwave, into Item state updates).
Rules or users at the GUI can issue commands, “do something” instructions, to Items, and a binding can process those into external messages (like MQTT)

As you can see, there is no path for OH Item states to be reported to external devices/services.

That’s okay, openHAB allows all sorts of customizations so that there are several ways to get an Item state reported out to MQTT. Which is the most appropriate way depends - what is the original source of the data? How many are involved? Does the raw data need massaging or conversion before publishing? etc.

At the simplest, there are features that can attach to an incoming sensor report from say zwave device, and auto-route that to MQTT to be treated as though it were a command i.e. trigger a publish message.

At the more complex, people with multiple openHAB installs (home/office etc.) sometimes mirror some or all Item states between them, using either an automated rules-based system or a custom binding to communicate the states using MQTT. If you had lots to do, that might be adaptable.

Okay…works now…used an example code from another thread.

Downside is that when a new MQTT subscriber connects the topic is unavailable until openHAB publishes again when a value/state changed…so for a switch state this can be a very long time.

The esphome topics are availabe immediately upon connect…

I assume this is the fault of the mosquitto daemon?

I don’t know. I don’t really understand what problem you are describing. Break it down step by step.

I think you may be misunderstanding how MQTT works. When you subscribe to a topic, the broker will feed you new messages that arrive on that topic, when they arrive.
So when you subscribe, you get no message until someone publishes a message.
That’s exactly how MQTT is designed to work.

If you weren’t listening when the last message was published, too bad.
MQTT has an extra feature, “retained”.
When one publishes to a topic, you can mark that message to be “retained”.
The broker remembers it now.
When someone new comes along and subscribes, they will get fed the remembered message. And of course, any messages on that topic that come along later.

It sounds like that’s what you want to happen, openHAB publishing some/all messages as “retained”. There’s a channel setting for that.

That was it…great…thanks :slight_smile: