MQTT Thing Channels not working: Channel has no type

Add-ons Bindings
, ,
1

Hello! I’m trying to add some devices using the MQTT Binding. This is my .things file:

Bridge mqtt:broker:LocalMQTTBroker [ host="localhost", secure=false] {
    Thing topic Kaffeemaschine "Kaffeemaschine" @ "Küche" {
        Channels:
            Type switch : PowerSwitch  [ stateTopic="stat/wohnung/kueche/kaffee/POWER" , commandTopic="cmnd/wohnung/kueche/kaffee/power", on="ON", off="OFF"]
    }
    
    Thing topic Temperatur_Schlafzimmer "Temperatursensor Schlafzimmer" @ "Schlafzimmer" {
        Channels:
            State Number:Temperature : Temperature "Temperatur" [stateTopic="zigbee2mqtt/0x00158d0004240688", transformationPattern="JSONPATH:$.temperature"]
            State Number:Dimensionless : Humidity "Luftfeuchtigkeit" [stateTopic="zigbee2mqtt/0x00158d0004240688", transformationPattern="JSONPATH:$.humidity"]
            State Number:Dimensionless : Battery "Batterie" [stateTopic="zigbee2mqtt/0x00158d0004240688", transformationPattern="JSONPATH:$.battery"]
            State Number : LinkQuality "Empfangsqualität" [stateTopic="zigbee2mqtt/0x00158d0004240688", transformationPattern="JSONPATH:$.linkquality"]
    }
}

The coffee maker (first thing) works just fine, but the temperature sensor (second thing) doesn’t. The Thing and all four channels do show up in Paper UI and I am able to link them to items, but those items are never updated. Currently, the temperature and battery channels are linked.

Whenever I save the .things file, this shows up in the log:

2020-05-20 16:47:01.585 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mqtt.things'
2020-05-20 16:47:02.290 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid cb72b11a-3290-4798-8519-345f60b9e7a4
2020-05-20 16:47:03.402 [WARN ] [rnal.handler.GenericMQTTThingHandler] - Channel Temperatur has no type
2020-05-20 16:47:03.408 [WARN ] [rnal.handler.GenericMQTTThingHandler] - Channel Luftfeuchtigkeit has no type
2020-05-20 16:47:03.414 [WARN ] [rnal.handler.GenericMQTTThingHandler] - Channel Batterie has no type
2020-05-20 16:47:03.423 [WARN ] [rnal.handler.GenericMQTTThingHandler] - Channel Empfangsqualität has no type
2020-05-20 16:47:03.487 [WARN ] [qtt.generic.AbstractMQTTThingHandler] - Channel mqtt:topic:LocalMQTTBroker:Temperatur_Schlafzimmer:Temperature not supported!
2020-05-20 16:47:03.490 [WARN ] [qtt.generic.AbstractMQTTThingHandler] - Channel mqtt:topic:LocalMQTTBroker:Temperatur_Schlafzimmer:Battery not supported!

The “not supported” message appears for each of the sensor’s channels that are currently linked to an item.

I am aware that the coffee maker’s channel uses Type switch and the other channels use State Number. I found both formats in different parts of the documentation. Is the latter outdated?

I fiddled around a lot and tried things like Type Number:Temperature, Type number:Temperature Type number State Number:Temperature, adding a dummy commandTopic, adding unit="°C" and many more, but they all throw syntax errors. I could just go with Type number, but apparently that leaves me unable to specify a QuantityType. If I don’t specify one, my item won’t show up in the dropdown list when linking the channel in Paper UI.

My installation is up to date (2.5.4 Release Build). I’m positive that zigbee2mqtt works without problems.

Any tips? Thanks!

2

These are valid Item types.
But you are defining channels, not Items.
Supported channel types (which depends on the binding involved) for the MQTT binding are listed here -

3

Hm, makes sense. But then, Paper UI does recognize these as valid channel types. Using Type number instead of State Number:Temperature gets rid of the error messages but leaves me unable to link my item of type Number:Temperature in Paper UI. Only plain Number type items are presented in the dropdown list.

4

Really? I only see “Number value” offered for Generic MQTT Thing types.

Yes. Not all bindings support all possible channel types to update all possible Item types.

5

I was able to work around the issue by leaving the .thing file as it is, linking all the channels, and then changing all channels to use Type number instead of State Number:Foo. The items stay linked and everything works perfectly. However, looks like I will have to temporarily revert the changes to my .things file if I ever want to link one of the channels to another item that has a quantity type.

Yes. It says Number:Temperature right below the channel id and only gives me Items of that specific type in the dropdown. Just replace Type number with State Number:Temperature on some channel and see for yourself.

6

I wonder. It’s bending the rules somewhere.

Where the devil are you? Not Configuration > Things > Generic MQTT Thing > (+) Create Channel

What you really want is QuantityType support in the MQTT binding. It’s not an unreasonable enhancement request, but practical implementation would open questions (what if I don’t want default units? how will transforms work? should units appear in outbound payloads,if so in what form?)

What I think would be generally more useful is a new profile type, operating on a channel to convert it to QuantityType for e.g. Number:Temperature Items.

7

Assuming this (invalid) .things file:

Bridge mqtt:broker:LocalMQTTBroker [host="localhost", secure=false] {
    Thing topic Test "Test" {
        State Number:Temperature : Temperature "Temperatur" [stateTopic="test/test"]
    }
}

This is what Paper UI > Configuration > Things > Test looks like:

When I click that channel in order to link an item to it, all Items that are either Number or Number:Temperature appear in the dropdown. After selecting a Number:Temperature item, I can go back to the things file and change State Number:Temperature to Type number to make the channel actually work while keeping the link intact.

Yes, that would be great, although my workaround fits all my needs for the time being.

There’s a unit parameter (e.g. unit="°C") that you can add to the channels. I don’t know about the other potential issues though. Personally, I currently only have temperature sensors and no thermostats.

8

Ah I see. Watch this -

Bridge mqtt:broker:LocalMQTTBroker [host="localhost", secure=false] {
    Thing topic Test "Test" {
        State Number:Rubbish : TemperatureX "Temperatur" [stateTopic="test/test", unit="binbags"]
    }
}

resulting
mqdemo

PaperUI further offers to link my Number:Rubbish channel to any Number type Item. I don’t expect it to work properly.
As you point out, it is possible to force invalid configurations.

9

Looks like it is. But it does, at least in my case, work without problems.

10

This is a recent addition to the binding (2.5.4 I think).

image
image1436×547 16.5 KB

I’ve not played with it yet but it’s high on my list of things to try. I’ve a number of sensors reporting with MQTT where UoM would be useful.

And I’ve no idea what the answers to those questions are. But I suspect:

  • if no unit is provided after the transformation, the default unit is assumed
  • if a unit is provided after the transformation, that unit will be used
  • I would expect the units to not appear in the outbound messages.

But I’ve not played with it yet and I’m often wrong.

But one thing I do notice is that even when I supply a UoM in the Thing config, PaperUI still lists it as a plain old Number type so I suspect there is some other way beyond Number:Temperature after the State keyword in .things files would be how it gets defined. But what that is will take research from someone who wants to support .things files.

The JSON for the Channel is:

    {
      "linkedItems": [],
      "uid": "mqtt:topic:sparethermostat:test",
      "id": "test",
      "channelTypeUID": "mqtt:number",
      "itemType": "Number",
      "kind": "STATE",
      "defaultTags": [],
      "properties": {},
      "configuration": {
        "unit": "°F"
      }
    }