tdm fails when MQTT topic is %hostname%

[sfromis]

Testing tdm (including the most recent download) I got a window with mostly blank fields, even if it was able to locate the devices. Looking around, I found that %hostname% was used in places where the topic was expected.

During an exercise to make Tasmota config as similar as possible across devices, I found that Topic %hostname% allowed me to avoid customizing this field per device. Could be a fortunate side effect, as the Tasmota code builds fulltopic by substituting %hostname% after substituting %topic%.

However, this does not work with tdm, leading to my experience of a badly broken tool. While not a major issue (after having found the trigger), I'd expect the tool to support what works in Tasmota itself.

[jziolkowski]

This works in Tasmota because it knows its hostname when running. TDM has no way of getting that value from anywhere. It won't work in TDM because you're using what is basically a hack and not something that is even recommended in Tasmota's MQTT documents.

Can you enable debug in TDM and paste the log file here? I need to see exactly the chatter.

[sfromis]

Here's the log from a cold start of tdm:

2020-02-25 14:09:46 [INFO] ### TDM START ###
2020-02-25 14:09:54 [DEBUG] MQTT: Subscribed to tele/#, stat/#, cmnd/#, +/tele/#, +/stat/#, +/cmnd/#
2020-02-25 14:09:54 [INFO] DISCOVERY: LWT from an unknown device sonoff05/tele/LWT
2020-02-25 14:09:54 [DEBUG] DISCOVERY: Asking an unknown device for FullTopic at sonoff05/cmnd/FullTopic
2020-02-25 14:09:54 [INFO] DISCOVERY: LWT from an unknown device sonoff30/tele/LWT
2020-02-25 14:09:54 [DEBUG] DISCOVERY: Asking an unknown device for FullTopic at sonoff30/cmnd/FullTopic
... repetitive lines trimmed
2020-02-25 14:09:54 [DEBUG] DISCOVERY: topic sonoff03/stat/RESULT is matched by fulltopic %topic%/%prefix%/
2020-02-25 14:09:54 [INFO] DISCOVERY: Discovered topic=sonoff03 with fulltopic=%topic%/%prefix%/
2020-02-25 14:09:54 [DEBUG] DISCOVERY: Sending initial query to topic sonoff03
2020-02-25 14:09:54 [DEBUG] DISCOVERY: topic nodemcu4/stat/RESULT is matched by fulltopic %topic%/%prefix%/
2020-02-25 14:09:54 [INFO] DISCOVERY: Discovered topic=nodemcu4 with fulltopic=%topic%/%prefix%/
2020-02-25 14:09:54 [DEBUG] DISCOVERY: Sending initial query to topic nodemcu4
... repetitive lines trimmed

As it does get the topics already, it would not seem to be necessary to use the Topic setting at all for succeeding operations. The pause after start is due to manual MQTT connect.

[jziolkowski]

So can you see these two devices in TDM? Discovery looks healthy

[sfromis]

Thats about the only thing that looks healthy. Typical Next start of the tool, the affected devices are not even on the screen, not saved in devices.cfg. The single one looking ok was my test case changing from %hostname% to a text string.

[sfromis]

Checking my MQTT log, I see these commands, for each device, with the expected responses:

nodemcu6/cmnd/FullTopic
nodemcu6/cmnd/template
nodemcu6/cmnd/gpio
nodemcu6/cmnd/buttondebounce
nodemcu6/cmnd/interlock
nodemcu6/cmnd/blinkcount
nodemcu6/cmnd/pulsetime1
nodemcu6/cmnd/pulsetime3
nodemcu6/cmnd/pulsetime5
nodemcu6/cmnd/pulsetime7
nodemcu6/cmnd/modules
nodemcu6/cmnd/switchdebounce
nodemcu6/cmnd/mqttlog
nodemcu6/cmnd/pulsetime4
nodemcu6/cmnd/pulsetime8
nodemcu6/cmnd/gpios 255
nodemcu6/cmnd/pulsetime2
nodemcu6/cmnd/blinktime
nodemcu6/cmnd/status 0
nodemcu6/cmnd/pulsetime6

Obviously, it did catch on to the working topic at this early stage.

[jziolkowski]

Ok, I'll have to test this over the weekend

[sfromis]

A possibly interesting detail is that the opening screen, after discovery, has Module (as the only field) detected for 1/3 of the devices, but a different set if starting again after deleting devices.cfg. The ordering looks random (different 2nd time), could just be unsorted discovery order.