I was not talking about the items. Items are both of type Number:Temperature.
I was talking about the channels: one is of type mqtt:string and the other (the want thas does not work as expected) is of type mqtt:number. Both are linked to Items of type Number:Temperature (as you can see in the provided test).
The only difference between the channels is that and that the mqtt:number channel has FormatBeforePublish:%.1f just to send the output to the devices with one decimal channel, as the devices temp increment is just 0,5ÂșC.
I will take out the min and max from the channel definition to see if it makes some difference.
As you can see too, in the test example, there is no unit in the channel definitions, neither of them.
The only place were units are used is in the slider, as I want the temperature shown as ÂșC.
The output of 20.0 ÂșC in the textchannel has to come from the slider.
The devices does not send (in the state topic) nor interpret the unit you put in the command topic. Anyway it works (in the string version) because the device ignores anything beyond the separating space.
May be it can be solved eliminating the ÂșC but it would be better to have the channel working as mqtt:number (that is what really the devices writes to the topic, a number, not a string).
I will try what you say, eliminating min and max and changing the type of the Items to Number instead Number:Temperature.
I donât know the difference, but as I saw that there were a more specific type (the channel is a temperature) I used that type.
But the Items matter too. There is something wrong between the slider and the MQTT message being sent. Items are among the things between those two points.
And by using a Number:Temperature you are bringing in all sorts of complexity and nuance that you want to eliminate when debugging a problem.
Give up on that temporarily and lets get it to work with just a plain old number. Once that works we can mess with the added complexity introduced by units and limits and all the rest.
Agreed, so simplify until we can get it to work and then add stuff back in. We need to eat the elephant here and you are trying to do it all in one bite.
It is absolutely critical to post what you see in events.log as well as what you see on the topic.
No, rossko57, I am not ignoring you, of course not.
I DO thank you for all your help.
Donât take me wrong, please. It is difficult for me to explain what I want to say in english. So may be sometimes my words may sound rude or as if I was not taking your words into account, but that is only because I did not fully understand what you say, not ignoring them.
Simply I am trying to understand and am not understanding well what you are trying to tell me.
Because you told me:
And I was just trying to say that there is not a unit configured in the thing channels.
Thas was clear previously for the responses from you or rlkoshak.
From what you and rlkoshak told me, using Number:Temperature for the items is a complexity that is not needed, so I have changed it to Number.
I have deleted min and max from channel definition, and am testing to see if that solves the problem.
But I have now a problem with the MQTT broker, and to test it need to put it to work again (the configuration of the broker has been lost in an upgrade of openWRT).
As soon as I can get it back working I will test with that changes.
Excellent. When you are happy that works, then weâll help you use a Number:Temperature if you want. This is worth doing for consistency if you have other sensors using Number:Temperature, but it not ânativeâ to MQTT and requires careful work.
You donât need to use a use a Number:Temperature just to get a ÂșC displayed in the GUI, that is just a presentation issue. Keywords - metadata, pattern.
Where can I find more info about transformations and all the path that follows a message from receiving it via mqtt till it is display in the UI?
And all the way back.
mqtt message â associated thing channel (with info about how transformation and interpretation is done) â linked item (and if it does transformation to set its state) â ui element display.
UI -> Command on Item -> Link -> Channel -> Binding -> MQTT Message
A transformation can take place at the Channel or on the UI in either direction. In the incoming direction a transformation can occur also at the Link via a transform Profile.
The Display State metadata is defined on the Item but itâs not actually performed until itâs displayed on the UI. However, the Display State is used in all sorts of other ways too which can cause some problems.
When something isnât working, we need to eliminate as much of that path that we can until it works and then gradually add it back once we get it to work as simply as possible.
