Tasmota: Fallback topic detection generates false positives

[tari]

When the MQTT client ID and topic are set to the same value, received messages are treated as coming in on the fallback topic, rather than the regular topic. For instance, if both are set to sonoff-0000 and the topic is %topic%/%prefix%/, then commands received on the regular topic sonoff-0000/cmnd/ are responded to on the fallback topic cmnd/sonoff-0000/.

While the fallback topic is a useful feature to have (eg #1528, #4190, probably others), the value of fallback_topic_flag in MqttDataHandler depends only on finding the client ID in the topic, rather than it actually being the fallback topic:

 fallback_topic_flag = (strstr(topicBuf, mqtt_client) != NULL);

Since this logical shortcut has bitten multiple users in the past, I think it should be changed to check that the topic is actually the fallback topic (match the beginning against the command prefix); this doesn't break the fallback, but does prevent confusion when users want to make the default topic contain the client ID (which is particularly useful when setting pattern ACLs in mosquitto).

[wongnam]

the sonoff-xxxx is a default topic, i thinks it's not a FallbackTopic.
You can get FallbackTopic on tele/sonoff/INFO1 and that topic is generated base on the last 3 digit of its MAC address.
example:

07:32:01 MQT: tele/smartplug/INFO1 = {"Module":"Sonoff TH","Version":"6.4.0(sonoff)","FallbackTopic":"DVES_0F86C9","GroupTopic":"sonoffs"}
07:32:01 MQT: tele/smartplug/INFO2 = {"WebServerMode":"Admin","Hostname":"smartplug-1737","IPAddress":"192.168.12.111"}

Update: I usually used this kind of FallbackTopic for my new Sonoff devices to Auto Initial Configuration(Provisioning) for the first time its connect to my system.

[tari]

The fallback topic is the MQTT client ID, so in your example you have the default client ID set.

I usually used this kind of FallbackTopic for my new Sonoff devices to Auto Initial Configuration(Provisioning) for the first time its connect to my system.

Which is fine; the change I propose doesn't stop that from working, it just means that a regular topic that also includes the client ID in it isn't incorrectly treated as the fallback topic (as I saw in #4683).

[wongnam]

Maybe you mention about the "feedback" topic right? you want TASMOTA send feedback of devices state as cmnd/sonoff-xxxx/POWER instead of stat/sonoff-xxxx/POWER.

[tari]

No, the bug is that a command on the regular topic is treated as coming in on the fallback topic, so the response is sent on the fallback instead. For instance:

-> sonoff-xxxx/cmnd/POWER ON
<- stat/sonoff-xxxx/POWER ON

The response is on the wrong topic because the check I noted originally sees the client ID is present in the topic and sets the fallback_topic_flag, when in fact the command was not on the fallback topic. The correct behavior is

-> sonoff-xxxx/cmnd/POWER ON
<- sonoff-xxxx/stat/POWER ON

(Or whatever the actual messages are- the important part here is the topic, not the message.)

[wongnam]

I am not sure i understand your mean, but i am trying to replicate it.
as i found that Tasmota Sonoff Basic can perform the mqtt command and stat as you expect.
here is my weblog 3 FYR:

00:00:08 WIF: Connected
00:00:08 DNS: Initialized
00:00:08 HTP: Web server active on sonoff-1234-6529.local with IP address 192.168.12.106
00:00:08 APP: (UTC) Sat Dec 22 02:35:42 2018, (DST) Sun Mar 25 02:00:00 2018, (STD) Sun Oct 28 03:00:00 2018
09:35:43 HTP: Main Menu
09:35:44 MQT: Attempting connection...
09:35:44 MQT: Connected
09:35:44 MQT: sonoff-1234/tele/LWT = Online (retained)
09:35:44 MQT: sonoff-1234/cmnd/POWER = 
09:35:44 MQT: Subscribe to sonoff-1234/cmnd/#
09:35:44 MQT: Subscribe to sonoffs/cmnd/#
09:35:44 MQT: Subscribe to cmnd/DVES_7C7981/#
09:35:44 MQT: sonoff-1234/tele/INFO1 = {"Module":"Sonoff Basic","Version":"6.4.0(sonoff)","FallbackTopic":"DVES_7C7981","GroupTopic":"sonoffs"}
09:35:44 MQT: sonoff-1234/tele/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff-1234-6529","IPAddress":"192.168.12.106"}
09:35:44 MQT: sonoff-1234/tele/INFO3 = {"RestartReason":"Software/System restart"}
09:35:44 MQT: sonoff-1234/stat/RESULT = {"POWER":"OFF"}
09:35:44 MQT: sonoff-1234/stat/POWER = OFF
09:35:44 APP: Boot Count 10
09:35:44 SRC: MQTT
09:35:44 RSL: Group 0, Index 1, Command POWER, Data OFF
09:35:44 MQT: sonoff-1234/stat/RESULT = {"POWER":"OFF"}
09:35:44 MQT: sonoff-1234/stat/POWER = OFF
09:35:44 CFG: Saved to flash at F9, Count 75, Bytes 3584
09:35:45 HTP: Console
09:35:52 MQT: sonoff-1234/tele/STATE = {"Time":"2018-12-22T09:35:52","Uptime":"0T00:00:18","Vcc":3.390,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Wifi":{"AP":1,"SSId":"iot-2","BSSId":"38:17:C3:F1:90:01","Channel":1,"RSSI":68}}
09:35:53 SRC: MQTT
09:35:53 RSL: Group 0, Index 1, Command POWER, Data ON
09:35:53 MQT: sonoff-1234/stat/RESULT = {"POWER":"ON"}
09:35:53 MQT: sonoff-1234/stat/POWER = ON
09:35:54 CFG: Saved to flash at F8, Count 76, Bytes 3584
09:35:56 SRC: MQTT
09:35:56 RSL: Group 0, Index 1, Command POWER, Data OFF
09:35:56 MQT: sonoff-1234/stat/RESULT = {"POWER":"OFF"}
09:35:56 MQT: sonoff-1234/stat/POWER = OFF
09:35:56 CFG: Saved to flash at F7, Count 77, Bytes 3584
09:36:57 HTP: Main Menu
09:37:10 HTP: Console

[tari]

The client ID needs to be present in the full topic; per your screenshot if you change the client field to "sonoff-1234" (it's not pictured so I assume it's set to the default) you should be able to replicate the bug.

[arendst]

I'll change the test to include the full fallback topic of "cmnd/fallback" so including the fixed string "cmnd/".

[wongnam]

@tari I can replicate the issue as you said.

00:00:26 DNS: Initialized
00:00:26 HTP: Web server active on sonoff-1234-6529.local with IP address 192.168.12.106
21:55:54 MQT: Attempting connection...
21:55:54 MQT: Connected
21:55:54 MQT: sonoff-1234/tele/LWT = Online (retained)
21:55:54 MQT: sonoff-1234/cmnd/POWER = 
21:55:54 MQT: sonoff-1234/tele/INFO1 = {"Module":"Sonoff Basic","Version":"6.4.0(sonoff)","FallbackTopic":"sonoff-1234","GroupTopic":"sonoffs"}
21:55:54 MQT: sonoff-1234/tele/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff-1234-6529","IPAddress":"192.168.12.106"}
21:55:54 MQT: sonoff-1234/tele/INFO3 = {"RestartReason":"Software/System restart"}
21:55:54 MQT: sonoff-1234/stat/RESULT = {"POWER":"OFF"}
21:55:54 MQT: sonoff-1234/stat/POWER = OFF
21:55:54 MQT: stat/sonoff-1234/RESULT = {"POWER":"OFF"}
21:55:54 MQT: stat/sonoff-1234/POWER = OFF

[ascillato2]

Fixed. Thanks everyone for reporting and testing :+1:

[BostonMikeGetHub]

I’m a newbie with Hass.io. I’m been trying to get mqtt discovery working and I found this thread.
Anyway, I using 6.4.1(sonoff) and I notice the order of the full topic and the fallback topic are different and it always seems to be using the fallback topic. Is this a reason for my mqtt not discovery working?