Is MQTTbox processing the incoming JSON payload before it displays it or is the payload simply 0.73? If it’s simply 0.73, and not in JSON format, then use what tom_I recommended but replace value_json.value with value.
Hey @123 and @tom_l you are both absolutely right. I didn’t notice that it returns a number, and not a json, and then the conversion to float first made it all work.
Thankyou very much both of you. I haven’t tried the MQTTbox that much before, but it seems like a simple and effective tool.
I dont know yet what this is for, so not sure if it should be a binary_sensor or not, but for now, I’d just like it to display the actual state. because it doesnt:
Nice, since up to mow, I always use the payload version for these binaries, didnt realize we could also use the template version. TIL, yet again
Still, since I am not sure of that functionality just yet, I feel I should be able to have the frontend show 'yes and ‘no’ in the state, and haven’t yet found a way to have that literal string displayed…
ok, that’s a nice ‘hack’. It still doesn’t simply show the actual state doesnt it? And of course it’s still a binary sensor.
I mean what if the state would be a more elaborated text. this seems to be only an issue because of the use of the reserved words. We should be able to do that, and ‘un-boolean’ yes/no
maybe:
value_template: >
{% if value == 'yes' %} 'yes'
{% elif value == 'no' %} 'no'
{% else %} value
{% endif %}
An MQTT Sensor will report unknown when there’s no payload.
For example, if you publish a payload to the topic, but it’s not a retained message, anything that subscribes to the topic afterwards will not receive the previously published payload. They will receive the next published payload. In the case of an MQTT Sensor, it will report the payload verbatim unless a value_template dictates otherwise.
An MQTT Binary Sensor, by default, expects to receive a payload of ON or OFF unless payload_on/payload_off or value_template dictate something different.
EDIT
More likely due to a misunderstanding of how retained/un-retained messages affect the value of an MQTT Sensor and MQTT Binary Sensor.
retained: dont believe they are, mqtt explorer doesnt show the yellow retained box.
so Taras, I guess you’re right there. Though I did restart the watermeter, so it published all once more, and still the sensor would show unknown.
though we can not set a retain flag in the sensor config, there is this expire_after:MQTT Sensor - Home Assistant
defaults to 0, which I did expect to mean ‘doesnt expire’
will contact the dev once again, because I discussed retain with him before, and I believe he updated the firmware to use that. Upon inspection now, I see none of the entities use retain…
and still they all are showing a correct state, except this ‘no’ state sensor.
Which means when Home Assistant is restarted, it will reconnect to the MQTT broker, subscribe to various topics, and for each topic that doesn’t have a retained message, the corresponding MQTT Sensor entity will report unknown. It will report a value only when the next one is published to the topic.
If the firmware developer doesn’t provide a means to publish retained messages, you can create an automation in Home Assistant to re-publish them as retained messages.
Basically, it subscribes to one topic and re-publishes received payloads to another topic (as a retained message). The MQTT Sensor is subscribed to this new topic. A single automation can be created to monitor multiple topics.
Untested but should give you an idea of what I am talking about: