Struggling linking two channels to an item

I have a normal MQTT channel for a light, with an item link to the channel.

UID: mqtt:topic:mqtt_broker:movie_room_lights
label: Movie Rooms Lights
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:mqtt_broker
  - id: movie_room_lights
    channelTypeUID: mqtt:switch
    label: Movie Room Lights
    description: ""
      commandTopic: cmnd/movie-room-lights/POWER
      stateTopic: stat/movie-room-lights/POWER

The item linked to this works fine.

I also have another channel on a different thing linked to a virtual button on the NS panel

- id: nxpanel_movie_light
    channelTypeUID: mqtt:switch
    label: Movie Light - 10:1
    description: ""
      commandTopic: cmnd/nspanel/nxpanel
      formatBeforePublish: '{"sync":{"pid":10,"bid":1,"state":%s}}'
      transformationPattern: 'REGEX:(.*\"pid\": 10.*\"bid\":
      stateTopic: tele/nspanel/RESULT
      off: "0"
      on: "1"

If I link an item to this channel. it works fine. The vitual button on the NS panel toggles the OH button and activing the OH button changed the vitual button on panel.

All good to here.

But at this point, I’d like to add the second channel to the item on the first channel so everything is in sync. However, when I go there to do that;

and link a channel

If I pick the thing that has the send channel. I dont see it to choose?

How do I link these two channels to be in sync?

I figured it. you can’t to it what way around. you need to link the item from the second channel, then when you go back into the item, both are there. and it works perfectly!

I don’t see how, there is no stateTopic on that nxpanel MQTT channel.

It works, I think it’s just coming over tele not stat, which is prob my fault;

12:37:29.056 NXP: Received Raw = bytes('7B22627574746F6E223A207B22706964223A2031302C2022626964223A20322C...')
12:37:29.085 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 2, "state": 1, "next": 0}} 
12:37:29.465 NXP: Received Raw = bytes('7B22627574746F6E223A207B22706964223A2031302C2022626964223A20322C...')
12:37:29.495 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 2, "state": 0, "next": 0}} 
12:37:29.749 NXP: Received Raw = bytes('7B22627574746F6E223A207B22706964223A2031302C2022626964223A20322C...')
12:37:29.776 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 2, "state": 1, "next": 0}} 
12:37:30.077 NXP: Received Raw = bytes('7B22627574746F6E223A207B22706964223A2031302C2022626964223A20322C...')
12:37:30.106 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 2, "state": 0, "next": 0}} 
12:37:30.263 NXP: Received Raw = bytes('7B22627574746F6E223A207B22706964223A2031302C2022626964223A20322C...')
12:37:30.293 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 2, "state": 1, "next": 0}} 
12:37:30.344 BRY: GC from 41222 to 20956 bytes, objects freed 428/353 (in 25 ms)
12:37:30.573 NXP: Received Raw = bytes('7B22627574746F6E223A207B22706964223A2031302C2022626964223A20322C...')

I send the event from my berry here;

 elif msg[0]==0x7B # JSON, starting with "{"
   var jm = string.format("%s",msg[0..-1].asstring())
   tasmota.publish_result(jm, "RESULT")        

I don’t actually say there if it’s stat or tele, yet the publish seems to go out as tele. Maybe I should be doing something else to publish it as stat? I wasn’t really sure the different. If I listen on the tele, it all works. But maybe to be more tidy and following conversion I should make it go out on stat?

@rossko57, it’s not obvious how to sent it as stat. The publish_result command of tasmota uses topic “tele/xxxx”. There is a publish method where you could build the whole topic from scratch, but I can’t see anywhere in berry to get the xxxx in stat/xxxx/RESULT. I thought there might be a property you have access to with it in, but I don’t see anything.

I couldn’t tell you how to set up your tasmota.

What are you trying to achieve?
The nxpanel_movie_light channel cannot update your Item, as it has no stateTopic defined - it’s a write-only channel.
That’s okay, you have another channel movie_room_lights now linked to the same Item, that presumably does update it.
What do you want your Item state to represent?

I think it does have a topic, just not shown very clearly. I think the markup was drowning in quotes! :slight_smile:

Both channels have a command and state topic, both can change an item and and both get item update back. I wanted the two be in sync though, so firstly I removed the item linked to the 2nd channel and then tired to add the unlinked channel to the first item. This didn’t work as you couldn’t see the channel to select (after picking the thing having the channel) as an option then adding the second channel to the item. So, secondly, I when into the 2nd channel and linked it to the first item there, this worked. now when I go into the first item, i see two channels link to it. toggling the OH switch toggles the virtual switch, and toggling the virtual one, does the same to the OH one. working well.

Just odd that you can’t seem to add the channel from the link channel option on the item, as it’s a valid thing to do, because you can do it by adding the item from the channel.

I’d have expect both to work. as it’s just two ways to do the same thing.

Oh yes! Looked twice and still missed it. :crazy_face:

You have to define this closely. Two different devices out there, what does “in synch” mean?
Looks like one device is a lighting control, the other is a control panel.
I think you want the lights to work in the ordinary way - OH commands get sent to it, and it reports its status back as Item updates.
If there is some manual action at the lights, that gets reported to OH Item state too, all good so far.

But I think you want your control panel to work in the opposite sense - like an OH GUI, when you poke it you will want command to arrive at the OH Item (and so get passed along to lights device). And when the lights state changes, that to be reported to the panel, which does not usually happen.

Apply a follow profile to the the Item-panel channel link only. This reverses the usual flow.
MQTT incoming to the channel stateTopic get passed to the Item as commands. The lights channel will pass those on. Item state updates will be passed to the panel channel commandTopic, so the panel gets told and can display remote device state.

Your Item state will mirror the lights device state only.

Yes. The MainUI GUI is young; maybe no-one has asked for that facility.

@rossko57 still no right,

I have a physical switch (sonoff mini) on a light
I have a mqtt channel for that, call it C1
I have panel with virtual button on
I have an mqtt channel for that, called C2
I have an OH item, just one, call it item 1

I have linked both channels to the item.

I can try varies options of follow and not, none work correctly. I’ll start here though…

C1 - follow, C2 - default
If I have the Panel as default, and the switch as follow, this works best from a UI point.
I can press the button on either the panel or the UI item and the light turns on/off the both panel and OH UI keep in sync. However, if I turn off at the switch, neither of the UI’s turn off.

C1 - defaut, C2 - follow
This way, the OH UI works turning light on/off, the panel keeps in sync, the switch itself (obv turn lights on/off) and both GUI’s work, but now, turning the light on/off via the panel has no effect.

C1 follow, c2 follow
OH UI turns light on/off, panel does not. turning physical light, updates panel UI, not OH item

c1- default, c2 - default
panel sync with OH item, oH item turn light on/off and panel show. real switch show on OH UI, but not panel and panel does control light.

Seems no combination where I can press on/off on either the OH button, the panel or the phyical swich and both GUIs (panel and OH Item) keep in sync!!!

Don’t try random combinations. I don’t think the profiles respond well to in-flight editing. Set up your best guess, reboot.

What actually happens when you use the remote panel? You’re listening to topic tele/nspanel/RESULT for button presses, is that what it sends?

My panel sends this as you press the button on/off

15:29:33.015 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 1, "state": 0, "next": 0}} 
15:29:34.114 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 1, "state": 1, "next": 0}} 
15:29:35.342 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 1, "state": 0, "next": 0}} 
15:29:36.493 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 1, "state": 1, "next": 0}} 
15:29:37.403 MQT: tele/nspanel/RESULT = {"button": {"pid": 10, "bid": 1, "state": 0, "next": 0}} 

The pid represent the page and the bid the button on the page, state is 1/0

My channel extracts it like this;

REGEX:(.*\"pid\": 10.*\"bid\": 1.*)∩JSONPATH:$.button.[?(].[?(].state

outward it send



If create a new item for this channel it works perfectly. The item controls the panel the panel controls the item. perfect.

It’s just when I try a link it to the real item that is the light itself that i get the trouble.

I could forget about linking them and just use rules that have loads of ifs or cases statements and reflect the changes that way. but the felt pretty nasty. seemed much nicer to link a channel to a specific button and use OH at that level, so OH was aware of the button. That felt the correct way. But it just seems it can;t

You need to understand the events here. The standard setup for an MQTT channel is that incoming messages on stateTopic get turned into state updates on the Item.
That’s a Good Thing normally.

But if you want that passed out to some other channel it needs to be in the form of a command, not a state update.
Furthermore, you want state updates to get passed out to your panel for indication. So you want the whole panel channel working in reverse-flow to normal.

I told a lie, misleading you. I always trip up on these follow profiles. It pays to re-read the docs :crazy_face:

So in truth the follow profile reverses half the flow - Item state updates get passed to the channel as though they were commands. Hurrah, that deals with your panel indication need.
But it blocks altogether incoming state updates from the panel channel, the ones we want to treat as commands.

Luckily the MQTT binding has a magic trick - the channel has a postCommand parameter. When true, incoming messages get passed to Item as Item commnds. Hurrah, you want that (so that it gets passed along to the target light)

So -
Panel MQTT channel settings, add postCommand=true.
Link panel channel to Item using follow profile, this will cause Item updates to be sent out on commandTopic.
I think the incoming command will bypass the follow profile, I’ve never tried it. If this works, the commands will show up in your events.log just like they do for UI clicks.

If it doesn’t work (follow profile may block that too), you’ll have to split the MQTT channels.
Keep the original panel channel with commandTopic and follow profile, but remove stateTopic. This is just for outgoing.
Make new channel with stateTopic and postCommand=true, and ordinary link to same Item (making three links), this is just for incoming.

We got there in the end, it seems to be working, after trying all the combinations.

Main channel, normal config. Panel channel, follow profile with Is Command turned on. The shortness of that sentence belies the effort geting there!! :slight_smile:

Thanks for you help again @rossko57, glad could achieve in OH standard config without yet more rules to support panel.

1 Like

Okeydoke, good the full ‘reverse flow’ effect works.

I don’t know why people are so keen to avoid rules though, it doesn’t cost anything.

other people will use the nxpanel and because there are a few different ways to script it, people want to do it different ways. it just gets tricky to keep track with different comps and different scripts. so it’s easier for me if I can say a standard way that works for all. I like rules myself, but I use groovy, others don’t. If it was just me using my panel code, I’d prob just have done it in groovy.

One opportunity you might have here is to create one or more rule templates, depending on what all these rules and “not rules” all need to do. It’s a whole lot easier to install and configure a template than it is to write a rule usually.