If I write something to the topic using mosquitto_pub the switch changes from off to on or from on to off --> great
But if I press the switch within my sitemap the topic is set to “ON” --> not so great, I assumed that it should be 2 (based on the map file)
In the log file I get the following messages:
2020-01-19 13:22:26.185 [ome.event.ItemCommandEvent] - Item 'KG_Wohnraum_StarPower' received command OFF
2020-01-19 13:22:26.188 [nt.ItemStatePredictedEvent] - KG_Wohnraum_StarPower predicted to become OFF
2020-01-19 13:22:26.197 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Incoming payload 'ON' not supported by type 'NumberValue'
2020-01-19 13:22:26.197 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '2' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.
2020-01-19 13:22:26.212 [vent.ItemStateChangedEvent] - KG_Wohnraum_StarPower changed from ON to OFF
That’s exactly what it should do when you specify on=“ON”
(In case it’s not clear, the on= off = gets used both for inbound and outbound)
So, you need to remove that instruction.
Having done so, I would advise a binding restart to make sure it has picked up minor edits.
Then you can show us the current config and current problem, if any.
I removed the on/off parameter and performed a complete openhab restart (not just the binding).
If the current topic value is 2 and I press the switch I get the following log message:
2020-01-19 16:27:24.002 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command ‘2’ not supported by type ‘OnOffValue’: No enum constant org.eclipse.smarthome.core.library.
2020-01-19 16:27:24.015 [vent.ItemStateChangedEvent] - KG_Wohnraum_StarPowerTest changed from ON to OFF
I’m not sure what that means. You mean the last message payload on the topic was 2? From earlier comment, that has been correctly mapped to your openHAB Item having state ON,yes?
Which switch pressing are we talking about, something at the device or OH UI?
I assume you’ve installed MAP transformation service, I’s expect to see a more meaningful log if not.
Your “bidirectional” map file looks reasonable to me.
That part’s easy ;you have subscribed stateTopic to the same topic as commandTopic, so everything you command in openHAB is immediately (attempted to be) reflected back in the channel state, even if it doesn’t fit.
That will happen regardless of any remote device also subscribing to or publishing to the topic.
When you poke an openHAB UI it sends a command to an Item. Commands are very distinct from Item states - although for a Switch they happen to have the same names.
UI “button” sends command to OH Item.
Any binding channels linked to that Item get the command
(In general, but there are exceptional ways to configure some back to front)
The MQTT binding processes this command through transformationPatternOut then publishes to commandTopic
That’s the end of that, assuming all works. Note the Item state never changed.
So here, with OFF command we should get MAPped payload 255?
But meantime, OH’s autoupdate feature may kick in (it’s active by default)
This is like a dummy binding listening for commands and making predictions about the likely resulting state. You’ll see these predictions in your events.log.
Why? Because if you poke the UI you expect a response, not a long delay while messages are exchanged with some remote device. So it’s just guesswork for the sake of speed-up appearance. Doesn’t involve MQTT at all.
Likely, your Item gets a fairly quick state update here, a guessed OFF.
Independently of all that, this channel of your happens to be subscribed to the identical topic by stateTopic. “Someone” just published to that topic (you) so the broker will send the subscribed Thing a copy of your recent message.
Now the inbound transformationPattern will be used to process the payload into something hopefully suitable for a Switch type channel i.e. ON or OFF.
Here we’d expect to get 255 and MAP/convert to OFF, probably to no real effect if autoupdate has already updated Item state to OFF
So the flow and interaction with parameters is rather different, but so far as I can see your current config should work in practice.
To help diagnosis, you might temporarily change your commandTopic to something else to break the chain and figure whether the outbound or inbound leg is at issue.
Outbound MQTT transformation was pretty broken before 2.5, but you say you have that version.
I note you’ve marked the topic to be retained at the broker, but I don’t think this plays into this sequence? It might, if the remote device is also publishing to the same topic with or without retained. Who wins there, I wonder.
2020-01-19 18:48:41.353 [ome.event.ItemCommandEvent] - Item 'KG_Wohnraum_StarPowerTest' received command ON
2020-01-19 18:48:41.365 [nt.ItemStatePredictedEvent] - KG_Wohnraum_StarPowerTest predicted to become ON
2020-01-19 18:48:41.398 [vent.ItemStateChangedEvent] - KG_Wohnraum_StarPowerTest changed from OFF to ON
The animation_out topic is ALWAY “ON”, even if the sent command is OFF.
If I publish anything to animation_in (using mosquito_pub) openhab reacts as expected: 255 = OFF, every other number = ON.
The following output shows the list of installed mqtt components:
openhab> bundle:list | grep MQTT
223 x Active x 80 x 1.14.0 x openHAB MQTT Binding
232 x Active x 80 x 1.14.0 x openHAB MQTT Transport Bundle
251 x Active x 80 x 2.5.1 x openHAB Add-ons :: Bundles :: MQTT Broker Binding
252 x Active x 81 x 2.5.1 x openHAB Add-ons :: Bundles :: MQTT Things and Channels
253 x Active x 82 x 2.5.1 x openHAB Add-ons :: Bundles :: MQTT HomeAssistant Convention
254 x Active x 82 x 2.5.1 x openHAB Add-ons :: Bundles :: MQTT Homie Convention
255 x Active x 80 x 2.5.0 x openHAB Core :: Bundles :: MQTT Transport
"Stern Status Test"
Toggled the switch in the UI:
2020-01-19 22:07:35.785 [ome.event.ItemCommandEvent] - Item 'KG_Wohnraum_StarPowerTest' received command ON
2020-01-19 22:07:35.800 [nt.ItemStatePredictedEvent] - KG_Wohnraum_StarPowerTest predicted to become ON
2020-01-19 22:07:35.869 [vent.ItemStateChangedEvent] - KG_Wohnraum_StarPowerTest changed from OFF to ON
And sadly the result is always the same… the value of the topic is just “ON”.
2020-01-19 22:25:32.154 [ome.event.ItemCommandEvent] - Item 'KG_Wohnraum_StarPowerTest' received command OFF
2020-01-19 22:25:32.166 [nt.ItemStatePredictedEvent] - KG_Wohnraum_StarPowerTest predicted to become OFF
2020-01-19 22:25:32.168 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '0' with the file 'apple.map' : Target value not found in map for '0'
2020-01-19 22:25:32.226 [vent.ItemStateChangedEvent] - KG_Wohnraum_StarPowerTest changed from ON to OFF
2020-01-19 22:25:36.807 [ome.event.ItemCommandEvent] - Item 'KG_Wohnraum_StarPowerTest' received command ON
2020-01-19 22:25:36.810 [WARN ] [rm.AbstractFileTransformationService] - Could not transform '1' with the file 'apple.map' : Target value not found in map for '1'
And now I understand it even less
Where is the 1 or 0 coming from?