Now I have disabled auto update in the item An tried to change the slider from 17 to 14.
the openHAB log reflects the change:
Item ‘tempObjRadiadorSalaJuegos’ received command 14
But no mqtt command is sent.
After a while it returns to 17 (may be due to the poll that sends each minute or so tasmota with state updates).
No, only if Tasmota published the message again would it receive the message.
Then go back to the above and continue along the path.
The Item is being commanded: check
Is the Item linked to the right Channel?
Is the command topic in the Channel configured correctly?
Is the binding triggering?
Well you just sort of explained it yourself.
Tasmota polls the devices from time to time and updates the state topics
When Tasmota updates the state topics, OH gets the message and updates the Item.
If the command to change it never went out (I thought you had confirmed that it was being published) then of course, the next time Tasmota polls and updates the topics the Item will revert to the old value since the device was never commanded to change state.
But wait, i have seen right now that the channel has disapeared.
May be I have deleted it inadvertedly in the las changes.
Let me a minute to recreate it and test again.
Well I had to recreate it.
When I tried to recreate the channel, and save it, the channel had disapeared again. There was no channel in the thing.
But the item had a link to a channel to that thing that did not exst.
I had to remove the item too, and then it let me recreate the channel and the thing.
But the behaviour continues the same: with autupdate the value changes back and forht and only sends a message with the last change (returning it to the original value).
without autoupdate, the mqtt message is never changed.
Well, I will let it be for now.
I need a pause and come tomorrow with new ideas.
Thank you very much both for all your help and time, a I owe you a beer.
Anyway I have learned a lot of things this afternoon.
Well I have made a last test.
I just edited the channel of the thing and changed from mqtt:number to mqtt:string, and deleted formatBeforePublsh and now all works correctly.
It works in autoupdate and without autoupdate (in this case the slider takes a second to be updated, when the updated msg message is received).
I can see the MQTT messages for command going out.
If I use mqtt:number it does not work and messages are not sent out.
In order to discard it could be a problem with slider, I have created an input card component with the same item and problem is the same.
Here is the complete thing definition (the offending channel is the last) with the channel as string that works:
UID: mqtt:topic:58b244c706:radiadorSalaJuegos
label: Radiador Sala de Juegos
thingTypeUID: mqtt:topic
configuration:
payloadNotAvailable: Offline
availabilityTopic: tele/tasmotaSalaJuegos/LWT
payloadAvailable: Online
bridgeUID: mqtt:broker:58b244c706
location: salaJuegos
channels:
- id: modoRadiadorSalaJuegos
channelTypeUID: mqtt:string
label: Mode funcionamiento Radiador sala de juegos
description: ""
configuration:
commandTopic: cmnd/tasmotaSalaJuegos/EQ3/radiadorSalaJuegos/mode
allowedStates: auto,manual
postCommand: false
retained: false
stateTopic: stat/EQ3/radiadorSalaJuegos
transformationPattern: JSONPATH:$.mode
- id: aperturaRadiadorSalaJuegos
channelTypeUID: mqtt:dimmer
label: Apertura válvula Radiador sala de juegos
description: ""
configuration:
min: 0
stateTopic: stat/EQ3/radiadorSalaJuegos
transformationPattern: JSONPATH:$.posn
max: 100
on: "100"
- id: tempObjetivoRadiadorSalaJuegos
channelTypeUID: mqtt:string
label: Temperatura objetivo Radiador Sala de juegos
description: ""
configuration:
commandTopic: cmnd/tasmotaSalaJuegos/EQ3/radiadorSalaJuegos/settemp
step: 0.5
min: 5
stateTopic: stat/EQ3/radiadorSalaJuegos
transformationPattern: JSONPATH:$.temp
max: 30
And this is the previous definition which does not wor (MQTT command messages not going out).
UID: mqtt:topic:58b244c706:radiadorSalaJuegos
label: Radiador Sala de Juegos
thingTypeUID: mqtt:topic
configuration:
payloadNotAvailable: Offline
availabilityTopic: tele/tasmotaSalaJuegos/LWT
payloadAvailable: Online
bridgeUID: mqtt:broker:58b244c706
location: salaJuegos
channels:
- id: modoRadiadorSalaJuegos
channelTypeUID: mqtt:string
label: Mode funcionamiento Radiador sala de juegos
description: ""
configuration:
commandTopic: cmnd/tasmotaSalaJuegos/EQ3/radiadorSalaJuegos/mode
allowedStates: auto,manual
postCommand: false
retained: false
stateTopic: stat/EQ3/radiadorSalaJuegos
transformationPattern: JSONPATH:$.mode
- id: aperturaRadiadorSalaJuegos
channelTypeUID: mqtt:dimmer
label: Apertura válvula Radiador sala de juegos
description: ""
configuration:
min: 0
stateTopic: stat/EQ3/radiadorSalaJuegos
transformationPattern: JSONPATH:$.posn
max: 100
on: "100"
- id: tempObjetivoRadiadorSalaJuegos
channelTypeUID: mqtt:number
label: Temperatura objetivo Radiador Sala de juegos
description: ""
configuration:
commandTopic: cmnd/tasmotaSalaJuegos/EQ3/radiadorSalaJuegos/settemp
step: 0.5
min: 5
stateTopic: stat/EQ3/radiadorSalaJuegos
transformationPattern: JSONPATH:$.temp
max: 30
formatBeforePublish: "%.1f"
```
It is quite strange, seems that there is some king of problem with this binding and number channels.Things, Items, and Links are stored and handled separately. If the Thing or Channel for a Thing disappears without removing the Link problems like this can occur because the Link makes OH think the Thing still exists. The same can happen with Items.
OH is often pretty good about cleaning this stuff up but there are still ways you can leave orphaned Links hanging around.
OK, so that may be what happened, that for some reason after removing the channel the link was not removed, and the item was linked to an inexisting channel.
As a user (using the UI, at least) you don’t have direct access to links, you create them through the item or the channel.
But removing the item an recreating channel and item solved the problem.
I have it working now, but I have to keep the settemp channel as a string for it to work.
If I convert it to number (as it should be as it is a temperature) the mqtt command is not sent and the value is reset back to the old value soon after you have tried to change it.
May be I can try to reproduce it in a clean openHAB install and without a real connection to an external device, just creating the MQTT status and command and creating responses manually to see if it is a bug.
Do you think that could help? How should I report it and document it in a way it can be reproduced?
You can reproduce on your existing set up, just use new unique names alongside your existing topic Thing - channel - Item. You don’t need a responsive target device to publsh test MQTT messages, just the broker and a tool like mqtt.fx to monitor them.
I don’t know how to command an item and send a new settemp value, for example without using an interface component.
I can monitor and send MQTT messages using MQTT explorer.
If for some reason you don’t want to click the UI, you can issue commands to Items from a rule. But then you have to think about when you want the rule to run, i.e. what to trigger it from.
No, just to be sure the problem does not reside in the interface component (slider)
You can see exactly what the slider sends as commands to your Item in your events.log - take care to observe if it is 17 or 17 ºC etc.
You did that before -
and that’s the end of the slider’s involvement - it sends the Item a command.
Well, I have reproduced it manually witout valves nor other things.
I created a generic MQTT thing, with two channels, one defined as number (temp) and other as text (txt) and wit corresponding status and command messages to send them manually from MQTT Explorer.
Then created two items of type number:temperature linked with each channel.
And two sliders one for the text channel and the other for the number channel.
Both sliders receive status messages correcty and display the temperature.
The text slider also sends the command correctly and modifies the temperature (I manually send back a status message with the updated temperature). The number slider does not send the command.
If autoupdate is active, it sends and command with the incorrect temperature, the previous temperature and not the new set temperature.
I don’t know exactly were is the problem but it seems a bug.
I would thank to try to reproduce it to see if it happens to others as well.
Here are the thing definicion:
UID: mqtt:topic:58b244c706:ded331510d
label: testThing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:58b244c706
channels:
- id: txtTest
channelTypeUID: mqtt:string
label: Text test channel
description: ""
configuration:
commandTopic: cmnd/testThing/TRV/valve1/settxt
stateTopic: stat/TRV/valve1/state
transformationPattern: JSONPATH:$.txt
- id: tempTest
channelTypeUID: mqtt:number
label: Temperature test (number)
description: ""
configuration:
commandTopic: cmnd/testThing/TRV/valve1/settemp
min: 5
formatBeforePublish: "%.1f"
stateTopic: stat/TRV/valve1/state
transformationPattern: JSONPATH:$.temp
max: 35
And the items:Boths are number:temperature type and one linked to one channel the other to the other channel, but boths equal (I cannot get the code from UI, so I show the capture of screen:
The txtItem
The number channel:
And this the definition of the page with the sliders:
config:
label: testing
layoutType: responsive
blocks:
- component: oh-block
config: {}
slots:
default:
- component: oh-grid-cells
config: {}
slots:
default: []
- component: oh-grid-row
config: {}
slots:
default:
- component: oh-grid-col
config: {}
slots:
default:
- component: oh-slider-card
config:
item: txtTestItem
releaseOnly: true
unit: ºC
scaleSubSteps: 5
scaleSteps: 5
scale: true
label: true
max: 30
min: 5
step: 0.5
title: Text
commandInterval: 1000
- component: oh-grid-col
config: {}
slots:
default:
- component: oh-slider-card
config:
title: Number
item: tempTestItem
min: 5
max: 30
step: 0.5
label: true
scale: true
scaleSteps: 5
scaleSubSteps: 5
unit: ºC
releaseOnly: true
commandInterval: 1000
masonry: null
grid: []
There are no text type channels. It’s a string type. None of this works without accuracy, it is very difficult to understand without accuracy.
Autoupdate never sends commands.
It’s probably best if you also show your actual events.log to avoid these confusions.
I don’t actually see any bug here.
If you command a Number:Temperature type Item with a valid command for that type, like 17 ºC, then the (plain) number MQTT channel will ignore it. It’s not a valid numeric command. You asked for formatBeforePublish: “%.1f” which only works with numerics. It won’t work with 17 ºC,
Try a plain ordinary Number Item.
If you are happy that works, but you still want to use a Number:Temperature type - and there might be good reasons to do that - then you will have to change your number channel.
formatBeforePublish: "%s"
will publish the whole 17 ºC to your MQTT payload.
If you want just the 17 published, you’ll need to use a commandTransformation, probably a little JS script to split on the space and only return the unit.
OK. As you can see in the definition, it is declared as mqtt:string.
It does not send commands, it sends the MQTT comand message configured cmnd/testThing/TRV/valve1/settemp for the number channel and settxt for the text channel.
But the problem is that the sent value by the number item is wrong, it does not send the new value that you changed, but the previous value (correclty formatted with no ºC).
The valves don’t include the ºC in the message.
There is no problem with formating or units with any of them.
This are the commands they generate, correctly formatted:
cmnd/testThing/TRV/valve1/settemp 20.0
Wich is what the valve accepts.
And this the status message that valves generate:
{
"txt": 25,
"temp": 25
}
The txt channel works correctly and sends the modified value as command topic to MQTT.
Have you tried it?
Tried what? I don’t have your Tasmota and TRVs.
This is very difficult to follow. You send an MQTT “20.0” to the Tasmota, get an answer “25” and say it is correct? I thought that was your whole problem, that is not correct?
Now we are getting to see real payloads I think there is one potential problem - does the Tasmota accept decimal numbers like 20.0, or is it just ignoring them?
No, that were only examples of the format of status JSON messages from valve (no ºC) in it. And the command topic to set the value.
And this is not from the valve. I have made them manually with the same format, for anybody be able to reproduce the problem with no valve.
If you have read my previous messages, the problem is only when you create a number channel, which does not send the command topic correctly: it does not send the new value you have selected in the slider component, but the previous value.
That is why it was changing it and returning back to the previous value.
Is you change the channel for a string channel it works as expected and everything is OK.
As not everybody has a TRV, and the problem does not have anything to do with the valve itself, I have put in the previous message an example to reproduce it: create one thing with a generic MQTT thing and two channels, one string and the other number, and two items linked to them and sliders to interact with them (you will have to use a MQTT explorer to see the generated topics and generate responses).
The string channel works as expected, the number channel does not, it when you change from say 25 (previous state) to 15, in the logs it says that the item has changed from 25 to 15, but the command it sends is cmnd/testThing/TRV/valve1/settemp 25.0 (the previous value, not the new one).
That is why it was not working and the slider returned to the previous value (even when you disabled autoupdate, as the valve generated a status with the update of its state with the value it had been commanded: 25, not 15 and the slider was updated).
So no problem with tasmota or the valve here (in the test there is no valve, just MQTT and you), or formats. The problem is with the channed when you select number (at least with the configuration I have used may be there is something wrong in the configuration).
The thing is, sending numbers works for everyone else. Let’s find out your unique problem and fix it.
Yes, you keep saying that, but we haven’t seen that. Looking at the closest thing to evidence shown so far, that shows a command posted towards the device of 20.0, and a response from the device of 25. That would be the device ignoring the command, and staying the way it is, not sending old values. It’s just about interpretation.
Please show us exactly the payload that the string channel sends when it works.
Compare weith the payload the number channel sends.
None of that is interesting here. It’s the Item command that counts here.
This is the only thing that results in MQTT messages being sent from openHAB
That is why I have uploaded a test configuration (as you told me) with the thing with the number channel and the text channel and the items and the sliders.
It reproduces exactly what I am telling, with no tasmota or valve involved (as others don’t have it).
Other people may be using other options or there is something wrong (probably) in the config of the number channel I am using and posted here.
Let me try to simplify and clarify the most.
Using MQTT explorer I send this JSON topic message (to initialize the values as if the valve would have sent its current state).
stat/TRV/valve1/state
{
"txt": 25.0,
"temp": 25.0
}
That would inform the current temp as 25 degrees.
The two sliders (Text and Number) in the test page I have put here show correctly 25 ºC.
Now I change the Text slider from 25 to 20 ºC.
The openHAB log shows
Item 'txtTestItem' changed from 25 °C to 20 °C
And in MQTT explorer I can see a topic update in the cmd topic assign to the txtTest channel (of type string) asking for 20.0
cmnd/testThing/TRV/valve1/settxt 20.0 ºC
All correct (except that the command should not output the units ºC as the valve does not expect it, but it works any way as TASMOTA gateway only reads the number 20.0 and ignores the rest).
Now I do the same with the slider Number associated with the channel of type number.
I change the slider from 25 to 20.
The log of openHAB shows:
Item 'tempTestItem' received command 20
But when I use MQTT explorer to see the command topic it has send it shows:
cmnd/testThing/TRV/valve1/settemp 25.0
Wrong value. That is not the new value set (20) but the original value (25) and different behaviour from what you get when the only change is setting the channel to string (and deleting the formatBeforePublish).
Yes, Despite its name, your txtTestItem is actually a Number:Temperature type Item, so I would expect commands to include a unit. That’s exactly how it is supposed to work.
Yes. You can link a a Number:Temperature type Item to a string type MQTT channel. The channel will pass along the string version of the Number:Temperature command, so you’ll see payload 20.0 ºC
This is working exactly as intended.
It’s doing what you told it to do.
It is possible to apply transformation to alter the command before putting it in the topic.
Your tempTestItem is also a Number:Temperature type Item,
Technically, command 20 is faulty for this Item type - a unit is required.
I’m honestly not sure how you managed to load the Item state with 25 without units to begin with - a system default unit should appear - but that would be why the slider generates commands without.
Anyway, this Item state deals in “quantities”, numbers with units - so it will pass “20 + blank unit” to the MQTT channel.
This time the channel is a number type, it is going to try to process that quantity, not convert it to a string first.
What is also different about it is the parameter
formatBeforePublish: "%.1f"
As we discussed already, I would definitely expect that to choke and fail with a quantity like “20 °C” with proper units.
I really wouldn’t like to predict what happens here though - technically “20 + blank unit” is a valid quantity (just not for a temperature). It means 20-to-1 ratio, or 2000%. Quite how this is going to interact with your max and min values I have no idea.
I’m going to guess commanding 20 gets added to min, giving 25? (and so nothing to do with old value) Try it, command 15.
The point of all this, is that this is all broken. Not because of bugs but because of bad data to begin with. You can’t just hook up a Number:Temperature Item to a number channel without doing something about units.
So, what do you really need here?
Great. Simplify.
Never mention units in your MQTT channel, or you will get them in published messages.
Get rid of max and min in the channel. These are about scaling, not limit restraints. The device will tell you what it wants to tell you in inbound messages. If you want to limit the commands that you publish, this should be done at source - the UI slider or rule generating the commands.
So that leaves -
- id: tempTest
channelTypeUID: mqtt:number
label: Temperature test (number)
description: ""
configuration:
commandTopic: cmnd/testThing/TRV/valve1/settemp
stateTopic: stat/TRV/valve1/state
transformationPattern: JSONPATH:$.temp
For the simple solution, link that to a Number type Item. Not a Number:Temperature.
Try it.
The more elegant solution would be to use the number channel with a Number:Temperature Item, but that will require more effort to add/remove units along the way. Satisfy yourself that a plain Number works first.