The postCommand parameter in your channel is redundant, this is only used for incoming messages and you have none here.
Tell us more about that.
It sounds like you’ve put the MAP instruction in your Item ‘pattern’ metadata?
This will do what you’ve asked it to, transform the Item state for display - without altering the actual Item state in any way.
In any case, the MQTT channel is acting on Item command not state. What commands are you posting to your Item, from UI or rule?
If it’s like “Sunny” then -
change your MQTT channel type to string, so that it matches your Item.
add transformationPatternOut using your existing MAP.
get rid of postCommand and formatBeforePublish, not needed here
My task is simple. I need to send the Number value obtained from the DarkSky binding to the broker. To do this, I created an MQTT generic thing, adding to it the channel I described above. Item DarkSkylocalweather_WeatherCondition is bound to this channel. This Item stores information obtained from the DarkSky binding channel.
I need the transformation from a string to a number due to the use of the ESP8266 with the ESPEasy firmware, which at the moment cannot accept string values via MQTT. Only numbers.
The Transformation Profile is “one way”, used with MAP it will take a state channel update from a binding and transform it, before updating the Item state.
It doesn’t affect commands in any way.
My question about your command still stands, and the fix advice remains.
From your description though, it seems you’re expecting the MQTT binding to act on the string Item state, and there is no command involved at all? It just won’t. This binding wants commands, like most bindings.
You can work round that with a rule, but as you’ve discovered profiles, use that instead.
Link your string Item to your (edited) MQTT channel using a follow profile, this does the magic of converting Item state updates into channel commands.
You’ll need a different MAP for the MQTT channel to the Darksky channel though, text->numeric and numeric->text. Thinks; in fact you could both conversions in one xxx.map file for convenience.
This all seems rather roundabout; I think I would have used a Number Item to hold the raw ConditionID from Darkshy, with a MAP pattern for human readable display.
You may need to reboot after making all the changes you want, to untangle everything.
Let me describe the problem in more detail.
I have a DarkSky binding. One of its channels (Let’s call it Ch1) is of string type.
A string item is linked to this channel (let’s call it Item1).
Now I want to publish every change of the Item1 value in the MQTT broker. One way.
But I cannot post the string. Only number. So I need a transformation before publishing.
I am a proponent of Occam’s Razor. So I don’t want to create any proxy items. Can I get what I want using only profiles? Or in the current implementation of Openhab I will not be able to do this? Perhaps I also do not understand some fundamental principles and am torturing you with my stupidity.
Thanks! It remains to wait for the change in weather conditions
Did I understand you correctly? The Follow profile generates a command, but the MAP profile does not?
In the ordinary course of things, incoming data to a binding is pushed as a channel state update towards an Item.
Data is sent to a device/service is when a channel receives a command from an Item.
Understanding command/state distinction is vital throughout openHAB. “Do something” instruction versus “Its like this” status report.
The MAP transformation profile takes whatever is fed to it by the channel state update, does its lookup, and pushes the result to the Item as a state update.
It’s one way, channel->Item, it never considers any commands, nor does it ever create commands.
The follow profile listens for state updates to the Item, and pushes to the channel as though it were a command (not visible in your events.log, because it is not a true Item command and will not affect the Item, only the channel).
It’s one way, Item->channel, it never considers any real Item commands.
I also have an inverse problem. There is a Th2 thing with a channel (let’s call it Ch2). Item2 is linked to this channel. There is also a generic mqtt thing Th3 with Ch3 channel. I would like to send commands Ch3 → Item2 without creating proxy items for Ch3. Is it possible to solve this problem with the power of profiles? Or in some other way?
I didn’t wait for the weather to change. Therefore, I continued experimenting with another channel - Sun phase name. The channel for publishing on the broker is configured as follows:
channelTypeUID: mqtt:number
label: Sun phase ID
description: ""
configuration:
transformationPatternOut: MAP:SunPhase.map
commandTopic: weather/sunphase
In the transformation file, I also tried to add a variant of writing from the log (capital letters, separated by the underscore ASTRO_DUSK). But that didn’t help me either. But the messages are not published…
It’s not clear why you think anything should be published?
State changes on an Item do not get published.
Commands get published (reason for naming commandTopic)
If you want to convert Item state changes into commands for the channel, that is a job for the follow profile we discussed already.
Having said that, clearly NAUTIC_DUSK is never going to match Nautic\ dusk=0 in your MAP file. You have to be precise with this stuff.
Then, there’s the problem that you are expecting an MQTT channel of type number to work with a string like NAUTIC_DUSK. That’s never going to happen either. You choose the channel type to suit the Item.
At the same time, the following line appeared in the logs:
Item 'SunPhaseName' changed from SUN_RISE to DAYLIGHT
How DAYLIGHT became Daylight is a huge mystery to me. And then I began to make all possible changes to the transformation file. The only thing I haven’t tried yet is escaping the _ with the backslash
Why did I remove DAYLIGHT and other states from the file? Because I saw the state of the Daylight in the item.
But nothing continues to work for me…
I did, Does it work for you?
The channel type is about matching to Items (and so also the commands coming from Item). There are after all no such thing as rollershutter type MQTT messages, for an example. Channel type is about internal openHAB business, not the type of message you want to send.
Never trust the GUI, which gives ‘helpful’ cosmetic effects. events.log tells the truth.
In this particular case, I would guess the Astro binding has assigned a set of presentation options to your Item. It’s rather like a secret map, DAYLIGHT to Daylight etc. What, why? The idea is the options are easily changed for language, DAYLIGHT to Tageslicht etc., giving a nice display, while everyone’s real state as used by rules etc. is still DAYLIGHT.
Yes it’s sneaky. You can examine your Item in the editor and see these options in metadata that you didn’t ask for.
That shouldn’t be necessary.
The transform file shown in last post looks fine.
But before anything gets transformed, it has to be passed to the channel.
While the channel is type number, you can’t pass it DAYLIGHT.
