Hello everyone. After upgrading to klipper (from marlin+octoprint) i was needed to manually send MQTT commands to my esp8266 connected to cheap relay in order to turn on and off my printer. I was trying to make it work several times, but no luck whatsoever. I yse custom firmware that is having commands simillar to tasmota protocol.
ON/OFF to switch the relay state (alternatively on/off lowercase)
? to actively query for state. The response is ON or OFF.
Other than that, my printer works amazing, cannot wait to use it fully.
(Also, my log file was way too large and i wrote a python script that cut the simillar lines automatically.)
Always provide a full and unmodified log. If too large, compress it as zip or (preferably) delete the old log, restart Klipper and produce a log that only contains the issue in question.
Moonraker supports mqtt client connections. In addition it has support for configuring power switches over mqtt. When a power device is configured it can be toggled in Mainsail.
If you use Mainsail then you have Moonraker installed on your host system.
[mqtt]
address: localhost
# Address of the Broker. This may be a hostname or IP Address. This
# parameter must be provided.
port: 1883
# Port the Broker is listening on. Default is 1883.
username: moonraker
# An optional username used to log in to the Broker. This option accepts
# Jinja2 Templates, see the [secrets] section for details. The default is
# no username (an anonymous login will be attempted).
password:
# An optional password used to log in to the Broker. This option accepts
# Jinja2 Templates, see the [secrets] section for details. The default is
# no password.
mqtt_protocol: v3.1.1
# The protocol to use when connecting to the Broker. May be v3.1,
# v3.1.1, and v5. The default is v3.1.1
enable_moonraker_api: True
# If set to true the MQTT client will subscribe to API topic, ie:
# {instance_name}/moonraker/api/request
# This can be set to False if the user does not wish to allow API
# requests over MQTT. The default is True.
instance_name: kobra2
# An identifier used to create unique API topics for each instance of
# Moonraker on network. This name cannot contain wildcards (+ or #).
# For example, if the instance name is set to my_printer, Moonraker
# will subscribe to the following topic for API requests:
# my_printer/moonraker/api/request
# Responses will be published to the following topic:
# my_printer/moonraker/api/response
# The default is the machine's hostname.
status_objects:
# A newline separated list of Klipper objects whose state will be
# published. There are two different ways to publish the states - you
# can use either or both depending on your need. See the
# "publish_split_status" options for details.
#
# For example, this option could be set as follows:
#
# status_objects:
# webhooks
# toolhead=position,print_time,homed_axes
# extruder=temperature
#
# In the example above, all fields of the "webhooks" object will be tracked
# and changes will be published. Only the "position", "print_time", and
# "homed_axes" fields of the "toolhead" will be tracked. Likewise, only the
# "temperature" field of the extruder will be tracked. See the
# "Printer Objects" section of the documentation for an overview of the most
# common objects available.
#
# Note that Klipper will only push an update to an object/field if the field
# has changed. An object with no fields that have changed will not be part
# of the payload. Object state is checked and published roughly every 250 ms.
#
# If not configured then no objects will be tracked and published to
# the klipper/status topic.
publish_split_status: False
# Configures how to publish status updates to MQTT.
#
# When set to False (default), all Klipper object state updates will be
# published to a single mqtt state with the following topic:
# {instance_name}/klipper/status
#
# When set to True, all Klipper object state updates will be published to
# separate mqtt topics derived from the object and item in the following
# format:
# {instance_name}/klipper/state/{objectname}/{statename}
#
# The actual value of the state is published as "value" to the topic above.
# For example, if the heater_bed temperature was 24.0, this is the payload:
# {"eventtime": {timestamp}, "value": 24.0}
# It would be published to this topic:
# {instance_name}/klipper/state/heater_bed/temperature
default_qos: 0
# The default QOS level used when publishing or subscribing to topics.
# Must be an integer value from 0 to 2. The default is 0.
api_qos: 0
# The QOS level to use for the API topics. If not provided, the
# value specified by "default_qos" will be used.
[power mqtt_plug]
type: mqtt
command_topic: wifi-relay
# Tasmota uses "on" and "off" as the payload, so our template simply renders
# the command
command_payload:
{command}
# There is no need to set the retain flag for Tasmota devices. Moonraker
# will use the query topic to initialize the device. Tasmota will publish
# all changes in state to the state topic.
retain_command_state: False
# To query a tasmota device we send the command topic without a payload.
# Optionally we could send a "?" as the payload.
query_topic: wifi-relay
# query_payload: ?
state_topic: wifi-relay-state
# The response is either "ON" or "OFF". Moonraker will handle converting to
# lower case.
state_response_template:
{payload}
# Tasmota updates the state topic when the device state changes, so it is not
# not necessary to query after a command
query_after_command: False