Unable to configure MQTT when active on an interface

GeneRisi

@rechrtb Thanks for your help!

I think a small change to your config.g suggestion works slightly better. If instead, I use

if !exists(global.mqttInited)
	global mqttInited = false

then config.g can be run without a machine reset preceding it (which is possible if config.g is edited)

GeneRisi

@rechrtb Now, I get this in my trace file:

2024-05-10 21:55:14 [debug] starting mqtt.g ...
2024-05-10 21:55:14 [debug] Configuring MQTT; responder state: 0
2024-05-10 21:55:14 [debug] Configuring MQTT; responder state: 0
2024-05-10 21:55:14 [debug] Configuring MQTT; responder state: 0
2024-05-10 21:55:14 [debug] MQTT is enabled on port 1884
2024-05-10 21:55:14 [debug] Failed to publish MQTT message, client not active
2024-05-10 21:55:14 [debug] Starting MQTT on ToolChanger
2024-05-10 21:55:14 [debug] ... ending mqtt.g

from this gcode:

M929 P"eventlog.txt" S3 		; start logging warnings to file eventlog.txt
;
M111 P1 S1              ; traces turned on
M111 P2 S1
;
M118 P1 S"starting mqtt.g ..."
;
M586.4 C"ToolChanger"           ; Set client ID
M586.4 U"TC" K"wHg@tc"    	; Set authentication credentials
M586.4 S"printing3d" O2         ; Subscribe to topic
;
M586 P4 R1884 H10.0.0.103 S1    ; this should initialize the responder
;
M118 P6 S"Starting MQTT on ToolChanger" T"printing3d"   ; Publish message (See M118 for more details)
;
M118 P1 S"... ending mqtt.g"
;
M111 P1 S0                 ; traces turned off
M111 P2 S0
;
M929 S0                     ; tracing truned off
;
; finis

What does "client not active" mean in this case? Is "client" the Duet3d firmware?

Gene

GeneRisi

@rechrtb I figured it out. The port has to be activated first (using M586) and then the initialization (M586.4) steps should occur, and then a message (M118) can be sent.

droftarts

@GeneRisi could you post the commands that work for you? Is this in config.g, or using the daemon.g workaround?

Ian

rechrtb

@GeneRisi Yes, the client is the board running RRF.

Actually, configuration (M586.4) is recommended before enabling the protocol (M586). I'm guessing since M118 is immediately after M586, it is still establishing connection when the publish is attempted. The configuration in between buys enough time. However, if you had more configuration lines, the first few might succeed, but once that connection goes through - the rest will fail - hence the recommendation to do all config before M586.

You should be able to add a delay after M586 in lieu of inserting the config in between.

rechrtb

I can apply your patch and test it out in my custom firmware build.

@GeneRisi The PR to fix the issue is in: https://github.com/Duet3D/RepRapFirmware/pull/1001
I was able to test it in my own setup and I can now do MQTT on config.g, but if you're able to verify it as well on your setup that would be much appreciated.

Here is the patch file with the same changes as the PR: mqtt_config_g.txt

rechrtb opened this pull request in Duet3D/RepRapFirmware

closed Fix issue with MQTT config on config.g #1001

GeneRisi

@rechrtb First, I will try adding the delay after rearranging the gcode such that configuration happens first. I'll post what happens here. Then I will add the patch and try it out.
Gene

Adding delay between

M586.4 C"ToolChanger"           ; Set client ID
M586.4 U"TC" K"xxxxxxx"        ; Set authentication credentials
M586.4 S"printing3d" O2         ; Subscribe to topic

M586 P4 R1883 H10.0.0.103 T0 S1

and

M118 P6 S"MQTT message from ToolChanger" T"printing3d"

works !

And using the new MqttClient.cpp also works !

Thank you!

Gene

GeneRisi

@droftarts Hi Ian, the daemon.g file was just a work around because initializing MQTT in config.g doesn't work in the current release. The patch mentioned above works for my and @rechrtb systems and with the patch, it isn't necessary to use the daemon.g approach.

Gene

droftarts

@GeneRisi Great, thanks for testing. @rechrtb please can you update the documentation here, and show a config.g example? https://github.com/Duet3D/MQTT-WPA2-Enterprise-Demo
Maybe explain the daemon.g workaround? As I expect the fix won't be released before RRF 3.5.2, so for all those on earlier versions.

Ian

rechrtb

@droftarts Copy @droftarts