Bug in Set device value [communication between scene and integer- an temperature-type MQTT features] (and a temporary workaround)

alpha-rd · December 21, 2023, 10:15am

There is a possible bug in the communication between scenes and MQTT. I guess this happens since the last update.

Scenes can only write calculations to integer-type MQTT-features (tested it for Counter and Unknown).

So, Simple values like “3” or “10” are not stored. The same seems to go for semi-computed values like “{{ myvalue }}”.
But calculations do work, like “3+0” or “10+0” or “{{ myvalue }} + 0”. So this is the temporary workaround.

In the french forum it is reported that this also goes for the temperature feature.

UPDATE: I can confirm the behaviour regarding the temperature-feature.
UPDATE 2: The bug seems to be in the Set device value-action in scenes. I use it to store some information in a MQTT Text-feature. But this also only works if there is some kind of a calculation involved (2+0),

alpha-rd · December 21, 2023, 12:41pm

@pierre-gilles I did some testing with the possible bug.

In MQTT I created 6 different features:

Text
Volume (Decimal)
Volume (Integer)
Switch On/Off
Light On/Off
Air Conditioning Mode

Then I tested sending value 1

Via Send MQTT Message, with the features in sensor-only mode (1)
Via Send MQTT Message, with the features in both ways mode (1)
Via Set Device Value, with the features in sensor-only mode and a simple value (1)
Via Set Device Value, with the features in sensor-only mode and a computed value (1+0)
Via Set Device Value, with the features in both ways mode and a simple value (1)
Via Set Device Value, with the features in both ways mode and a computed value (1+0)

Between tests I resetted the values to blank/0.

For each test I sent myself a Telegram-report.
These are the Telegram-reports, with my observations:

1. Via Send MQTT Message, with the features in sensor-only mode

Expectation: We can send a message to MQTT features in sensor-only mode (which distinguishes this action from Set device value)
Unexpected behaviour: We can’t send a message to the built in MQTT if it is in sensor only mode.

2. Via Send MQTT Message, with the features in both ways mode

Expectation: We can send a message to MQTT features in both ways mode (just like Set device value)
Expected behaviour: we can send messages to numeric and boolean features if they are in both ways mode.
Unexpected behabiour: The text feature didn’t work.

3. Via Set Device Value, with the features in sensor-only mode and a simple value (1)

Expectation: We cannot set values on features in sensor-only mode
Expected behaviour: We cannot set values on numeric and textual features
Unexpected behaviour: We can set values on boolean features

4. Via Set Device Value, with the features in sensor-only mode and a computed value (1+0)

Expectation: We cannot set values on features in sensor-only mode
Unexpected behaviour: We can set values on features in sensor-only mode

5. Via Set Device Value, with the features in both ways mode and a simple value (1)

Expectation: We can set values on features in both ways-mode
Expected behaviour: We can set values on the boolean features
Unexpected behaviour: We cannot set values on numeric and textual features

6. Via Set Device Value, with the features in both ways mode and a computed value (1+0)

Expectation: We can set values on features in both ways mode
Expected behaviour: We can set values on all features

CONCLUSION: there is quite a lot of unexpected behaviour at the moment.

Disclaimer: This test isn’t complete yet.

I didn’t check with computations with other devices and features
I didn’t check temperature and thermostat temperature
I didn’t check single values on the compute tab
The booleans are all checked on the simple tab.

pierre-gilles · January 5, 2024, 2:17pm

Thanks for your feedback

Can you create a Github issue ?

pierre-gilles · February 5, 2024, 5:37pm

Hi @alpha-rd !

Thanks for reporting this bug, the fix is available in the latest Gladys release :