When i use the switch in paperUI both channels are being triggered.
Nikobus binding is turning on the light and the state is correctlty published on MQTT.
When I publish the correct command to the MQTT broker, the Item switches on in paperUI and the Nikobus binding is turning on the light.
However when the light is switched on via physical buttons, the Nikobus binding is correclty updating the the switch in paperUI, but the state is not being published to the broker.
So both channels work fine individually, but when the first one (nikobus) is triggering the Item change, the state change doesn’t seem to trigger the second channel.
This can be a workaround indeed. But again this is not supposed to work that way and I would like to know the root cause.
Why if channel1 is updating an Item state, the state change is not being picked up by channel2?
But the other way around works. (channel2 is updating an item state and the state change is picked up by channel1 correctly)
Stop OH and clean the cache as there may be something lingering around that’s causing the issue. Other than that maybe try adding DEBUG or TRACE to the logs for both mqtt and nikobus binding to help get an idea with what the root cause is.
Bindings normally pass only commands to real devices, and convert incoming data to state updates.
It has to be that way or it’d all collapse in a screaming loop.
So if you want something incoming to prompt a binding, then you need to make it into a command; this is what the follow profile is for.
MQTT binding is an odbball in this use because you can actually configure non-standard response events to internal state changes and incoming data.