Manually defined mqtt:trigger channel not recognized as a trigger channel by the UI for rules

Hi Team,
great work on the OpenHab 3. Discovered small issue with the fact that when I define manually the channel in the mqtt generic binding as a triggered I can’t then use it in the rules UI - it is just not visible on the list of available trigger channels. However I can, without any issues, use it in rules defined directly in .rules files.

I have the following Thing defined:

UID: mqtt:topic:autoPogoNAS:9F306C
label: tasmotaSonoffDualV2_02 manual
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/tasmota/SW/9F306C/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:autoPogoNAS
channels:
  - id: Button1
    channelTypeUID: mqtt:trigger
    label: Buttons trigger
    description: ""
    configuration:
      stateTopic: stat/tasmota/SW/9F306C/BUTTON1T
      transformationPattern: JSONPATH:$.TRIG

So when I try to choose a Channel for “a trigger channel fires” Add Trigger dialog:

image

This empty list appears:

image

As mentioned in the same time manual rule works perfectly fine:

rule "React on single button trigger from mqtt tasmota 9F306C device"
when
    Channel "mqtt:topic:autoPogoNAS:9F306C:Button1" triggered SINGLE
then
    logWarn("ButtonLog: ", "SINGLE")
end

Not only it works but also appears fine in rules UI (just cannot be edited):

image

  • Platform information:
    • Hardware: RaspberryPi 3b
    • OS: openHABian 5.4.83-v7+ #1379
    • Java Runtime Environment: openjdk 11.0.9 2020-10-20 LTS
    • openHAB version: 3.0.0

Can you edit the rule’s YAML and define the mqtt trigger that way?

I’m not sure how that list gets populated but it sounds like a bug and an issue should be filed on the openhab-webui repo.

Yes, I can.
By creating a garbage rule and then overwriting it with the proper YAML code:

triggers:
  - id: "1"
    configuration:
      event: SINGLE
      channelUID: mqtt:topic:autoPogoNAS:9F306C:Button1
    type: core.ChannelEventTrigger
conditions: []
actions:
  - inputs: {}
    id: script
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: |
        // context: mqtt-1
        logWarn("ButtonLog: ", "SINGLE")
    type: script.ScriptAction

I’m able to achieve expected results in the Design UI:

Which is editable (of course I still cannot pick trigger channel from the list).

The list seems to be populated in trigger-module-wizard.vue:

  <f7-list-input
    v-if="thingEventType === 'triggerChannelFired'"
    label="Event"
    name="triggerChannelEvent"
    type="text"
    placeholder="Any"
    :value="currentModule.configuration.event"
    @blur="(evt) => $set(currentModule.configuration, 'event', evt.target.value)"
    />
</f7-list>

But how to check if the mqtt:trigger has the “thingEventType” set properly to “triggerChannelFired” is beyond me.

Can confirm this happens here as well.

For the Time being i created items from the things and react on state changes.

Can we go back a step, and ask how you are doing that exactly? The MQTT binding documents applying a “trigger=true” parameter to an otherwise ordinary channel. Are you using UI or xxx.things file?

I’ve no idea if the binding then creates a trigger channel alongside an ordinary channel (maybe of similar name) but there might be scope for confusion there.

Hi Rossko,

You are right, I have not specified it, sorry for that. I’m creating the Thing with a trigger channel in UI:

And choosing Trigger as a Channel type:

Which results in the following situation:
image

As you can see, already here this is unexpected situation as the trigger channel allows to add a link, which should not be a situation for properly defined trigger, I assume. For example this is an Astro Thing trigger channel in UI (expected behavior):

mm, I don’t know enough about the JSON channel description, but as MQTT binding was an “early adopter” of configure-your-own-trigger I wonder if its missing something. I’ll bet the answer is in the JSON you already showed - comparison to a working trigger may be revealing.

It might be deliberate, an assumption we could make from binding docs is that a channel can fire triggers from stateTopic but still transmit commands via commandTopic, a sort of dual nature. I don’t know if that is practical.

yes, I’ve already did this comparison in the bug report. for readers benefit:
When adding mqtt.generic Thing as a trigger channel the following definition is produced (copied from org.openhab.core.thing.Thing.json):

 {
          "acceptedItemType": "Trigger",
          "kind": "STATE",
          "uid": {
            "segments": [
              "mqtt",
              "topic",
              "autoPogoNAS",
              "9F306C",
              "button1"
            ],
            "uid": "mqtt:topic:autoPogoNAS:9F306C:button1"
          },
          "channelTypeUID": {
            "segments": [
              "mqtt",
              "trigger"
            ],
            "uid": "mqtt:trigger"
          },
          "label": "Wyzwalacz przycisku",
          "configuration": {
            "properties": {
              "stateTopic": "stat/tasmota/SW/9F306C/BUTTON1T",
              "transformationPattern": "JSONPATH:$.TRIG"
            }
          },
          "properties": {},
          "defaultTags": [],
          "autoUpdatePolicy": "DEFAULT"
        }

When adding mqtt.generic Thing trigger channel it should have “kind”: “TRIGGER”, as it can be observed for the Astro binding event triggers (that works properly):

        {
      "kind": "TRIGGER",
      "uid": {
        "segments": [
          "astro",
          "sun",
          "local",
          "rise#event"
        ],
        "uid": "astro:sun:local:rise#event"
      },
      "channelTypeUID": {
        "segments": [
          "astro",
          "rangeEvent"
        ],
        "uid": "astro:rangeEvent"
      },
      "label": "Range Event",
      "description": "Range event",
      "configuration": {
        "properties": {
          "offset": 0
        }
      },
      "properties": {},
      "defaultTags": [],
      "autoUpdatePolicy": "DEFAULT"
    }