OpenHAB3 with ESPEasy running Homie MQTT Thing Config?

Setup, Configuration and Use Beginners
, ,
1
  • Platform information: Raspberry Pi 3 Model B Rev 1.2
    • OS: what OS is used and which version Raspbian GNU/Linux 10 (buster)
    • openHAB version: 3.0.1 - Release Build
  • Issue of the topic: please be detailed explaining your issue
    I’m attempting to Migrate from my 2.5 Openhab setup to OH3 but I’m completely redoing my setup so I didn’t post this in migration.
    I’ve updated my ESPEasy devices to use the Homie convention and have confirmed via MQTT.fx they are sending LWT and device updates via MQTT.
    image
    image956×379 14.6 KB

    The first problem I’m seeing is they are not auto-discovered but I can live with that if I can get them working correctly.

The second problem is OH3 doesn’t even show my device Online even after manually creating a homie MQTT thing. Here is my thing code does anyone know what I’m doing wrong?

UID: mqtt:homie300:516b378e:ESP_B11D69_2
label: DoorSensor2
thingTypeUID: mqtt:homie300
configuration:
  deviceid: ESP_B11D69_2
  removetopics: true
  basetopic: homie
bridgeUID: mqtt:broker:516b378e
location: Basement Door

According to MQTT.fx the QoS is 0 but the OH log is showing this.

2021-04-21 10:01:16.524 [WARN ] [e.internal.handler.HomieThingHandler] - Homie devices require QoS 1 but Qos 0/2 is configured. Using override. Please check the configuration

I’m not sure what configuration it wants me to check.
Does anyone have auto-discovery working with the ESPEasy firmware?

2

Don’t manually create a Homie Thing. Create Generic MQTT Things if you must manually create them. I can’t speak to why it’s not automatically discovered. There might be a conflict in Homie versions between what OH supports and ESPEasy implements.

As for the QOS, it’s important to understand that QOS is not end to end, it’s only between the client and broker. It’s definitely possible to have a client publish a message at QOS 0 and another subscriber subscribe and receive the message with QOS 2. With a Generic MQTT Thing you can set the QOS at the broker level or on an individual Thing or Channel (I think). Anyway, the error is telling me you need to change your MQTT thing to subscribe with QOS 1 or 2.

Beyond that I don’t know. I’m running a really old version of ESPEasy and haven’t upgraded nor tried the Homie support yet.

3

I think the ESPEasy developers believe auto-discover should work in OH3 according to this.
But it does look like it’s still in testing.
https://espeasy.readthedocs.io/en/latest/Controller/C014.html?highlight=homie#setup

image
image1731×280 55.7 KB

1 Like
4

The versions talked about there are very old. We are over a year past OH 2.4 and 2.5M1. It says recent snapshots should work which implies that any version since OH 2.5M2 should work as well.

Moquette, the MQTT broker that used to be embedded in OH 2 is no longer supported in OH 3. So you are most likely using Mosquitto which should behave correctly when it receives the QOS=0 but retained=true message.

5

To check: do you have the JSONPATH and JINJA Transformation Services installed in your openHAB? I think you need them for auto discovery.

2 Likes
6

I didn’t have JINJA transformation installed but I have installed it now and even clicking scan doesn’t find my devices. But I do see the state being published by the device using MQTT.fx
I also see the LWT was published also and showing ready.

7

What is the difference in creating a MQTT system broker via the settings page seen here.

image
image773×627 35.3 KB

VS Manually adding a thing that is a Broker
image
image747×323 15.9 KB

Should I be using System Broker for the locally installed Mosquitto server?
I attempted to disable the broker I created under things and create a system broker with the same settings but it’s trying to use Port 8883 even if I set the port to 1883.

8

No, definitely not. Only use a Thing Broker as shown in the tutorials.