MQTT2 (Homie Convention) - Thing goes offline permanently

Add-ons Bindings
3

Hi @David_Graeff -
Thanks for chiming in (as always) and your contributions to Openhab.

In this particular case I am not sending any $stats objects at all. I just double checked the broker and non are set. From what I can, there is only one location in the code that would have the “No connection or readOnly channel!” error. Which is line 324 of src/main/java/org/eclipse/smarthome/binding/mqtt/generic/internal/generic/ChannelState.java

it looks like that is only thrown if the connection is null or the channel is readOnly. Would a heartbeat timeout trigger either of those?

4

Hm. No. So that’s an other issue then.

5

hi, I’m using openhabian2.4 and homie convention+esp32 ,now i’m able to set auto discovery for my esp devices in openhab but i want to control my devices from Alexa, so for that i have to set tags ( [ “Lighting” ], [ “Switchable” ]…) but i don’t know how to set tags through homie convention ??

The following topics are published as retained messages to the broker (from esp):

  homie / device123 / $homie → 3.0
  homie / device123 / $name → My device
  homie / device123 / $state → ready
  homie / device123 / $extensions → ''
  homie / device123 / $nodes → my_thermostat

  homie / device123 / my_thermostat / $name → My thermostat
  homie / device123 / my_thermostat / $properties → temperature

  homie / device123 / my_thermostat / temperature → 22 
  homie / device123 / my_thermostat / temperature / $name → Temperature
  homie / device123 / my_thermostat / temperature / $unit → °C
  homie / device123 / my_thermostat / temperature / $datatype → integer
6

Homie has no means to express openHAB tags. But homie supports extensions. We could assemble a quick one for a $tags attribute.

1 Like
8

I think you don’t understand ^^.

For now you need to tag your Items yourself. This is not yet possible with paperUI, you need to define Tags in an ancient .items file instead.

For the future I imagine that you can just publish

homie / device123 / $extensions → 'org.openhab.tags'
homie / device123 / my_thermostat / temperature / $tags → Lighting

But code need to be written to support that first.

9

Can you help me out with a sample extension, so that i can try writing the extension myself. or if there is any other way to make Alexa detect my devices other than rest API.?

10

Can u suggest me any links/documents to learn homie convention for openhab , i want to know about all currently supporting homie topics in openhab

11

There is no “Homie convention for openHAB” :wink:

Please read homieiot.github.io for an idea what Homie is.

tl;dr: Homie is vendor neutral. openHAB renders everything according to Homie 3.0/4.0.

12

For managed items (these created with PaperUI), you can add tags on console.

Start with openhab-cli console and use the smarthome:items addTag command:

openhab> smarthome:items addTag Lab_Sensor_Temperatur Temperature
Successfully changed tag Temperature on item Lab_Sensor_Temperatur
13

@David_Graeff Can you explain section 5 of the Homie 3 spec a little more…

> ## Timings
> 
> As soon as a device starts to publish any Homie related topic, it MUST finish with all topics within a timeframe of 500ms. Controllers should assume the default for topic values not received within this timeframe.

Does this mean that all nodes must supply all their details within that 500ms of the device starting up or the defaults will be applied ? This could be hundreds of nodes potentially.

I’m looking at an app that is sending a lot of nodes (50+) and it does not manage to complete the sending of that information in that time - in fact its an order of magnitude adrift based on the cpu power it has. Is there a way around this as I’m thinking it’s just not possible in this case ?

What I am seeing is the device comes online but fairly quickly goes offline on a timeout but the stats are being provided bang on the interval set. OH shows a device did not send heartbeat in time’ error, maybe I should increase the expected interval to less than the stats.

Also when trying to control a node I am getting a topic is read only which I think results from a default $settable being applied. MQTT shows the correct ‘true’ value in $settable. All nodes do appear in discovery.

Lastly … is a topic allowed to contain a whitespace character which is valid in MQTT but is not specifically mentioned in the Homie 3 spec ?

14

Whitespace is not allowed per the homie spec: https://homieiot.github.io/specification/#topic-ids

We have a discussion about the timing, but no solution yet, here: https://github.com/homieiot/convention/issues/90

15

Yes it doesn’t mention whitespace specifically but I was guessing that - unfortunate - not sure why it’s not allowable.

I’ll look at that other github timing issue post…

It seems it has some ambiguity … David commented …
“Doesn’t the section say half a second without any input? As long as you keep sending data, everything is alright.”

…not sure what the outcome is … but I know this device is taking nearly 10 secs. But it doesn’t look like that is the reason for going offline. Maybe I’m breaking things with some topics having whitespace in them. I’ll try eliminating that first.

16

The mqtt binding (home controller) requires a timeout. Otherwise if the device dies on the other end, we would have a dangling Thread that is never forcefully killed. That’s the reason why I convinced the Homie community to add a timing paragraph.

But yeah, it doesn’t work for slow devices that well. I guess, I should rely on $state and have a very generous timeout in the binding instead.

Edit: Have created a PR:

17

So the integration with Homie 3 that this guy has tried to implement (one of the first I believe outside of esp8266) can’t be done until 2.50 or is this retrospective to people adding/updating the MQTT 2.4 binding ?

I don’t understand if this is a change to the spec or a change to the plugin code ? Looks like the former so why is this failing currently ? stats are updated within 50s against an interval of 60s and yet it times out on a missed heartbeat.

18

The heartbeat mechanism has been removed for OH 2.4M1 and OH 2.5.

See here: smarthome/extensions/binding/org.eclipse.smarthome.binding.mqtt.generic/src/main/java/org/eclipse/smarthome/binding/mqtt/generic/internal/MqttThingHandlerFactory.java at 2239635027bf1e809b97dc3292f6da982e5daa0e · eclipse-archived/smarthome · GitHub

There is a fixed timeout of 1.5 seconds for the entire Homie tree and a 200ms timeout for a single property sub-tree. Those timeouts are quite low for slow devices.

19

So if I’m getting timeouts from heartbeats in OH 2.4 release (which is later than M1?) where should I look ?

20

Oh I’m sorry I mean OH 2.5M1 or OH2.5 snapshots.

21

The homie tree takes over 10 secs to populate into MQTT - am I still stuffed ? (There are no long pause between nodes - just a lot of them). It comes from trying to expose one controller with all it’s devices to another.

22

Actually I made an implementation mistake. Your device is apparently slow, but your MQTT broker is not, I guess.

Per specification I should honor homie/device123/$state, but I don’t. I’ll fix that and make the timeouts configurable. Probably not this week though.

23

Yes the broker is pretty fast - it’s the device that has limitations. I think you will find this with a lot of multi node controllers that expose everything using homie3 / mqtt. I’ll watch for the update.