Skip to content
ggodart edited this page Aug 25, 2023 · 5 revisions

mqtt items

Awaiting contributions

SYNOPSIS

An MQTT Items module for Misterhouse. Uses existing interface class in mqtt.pm. It does not use the mqtt_Item class in mqtt.pm.

Can be used together with mqtt_discovery.pm to publish and process Home Assistant format discovery messages.

DESCRIPTION

This is a misterhouse style items interface for MQTT devices

MQTT Items (mqtt_items.pm)

There are several MQTT item types implemented in this module (see below).

Each item can handle both commands and state messages to/from MQTT devices. LWT messages can also be handled for remote items.

There are several classes implemented in mqtt_items.pm:

mqtt_BaseItem: - is the base class.

mqtt_LocalItem: - implements an mqtt mh item that is tied to a local item - when the local item changes state, this mqtt item will send mqtt state_topic messages - it will also listen for mqtt command_topic messages and set the state of the local item, if the set of the local item is successful, the mqtt item will send out the state_topic message - a LocalItem can be associated with a specific broker, in which case it will listen only to that broker for commands and will send state messages only to that broker - if there is no broker specified, then the LocalItem will listen to all brokers for command messages, and broadcast state messages to all brokers - can publish HA discovery info -- a fairly simple discovery language is used that is based on the insteon-mqtt project

mqtt_BaseRemoteItem: - implements a base class mh item that both sends commands to and receives state messages from a remote device that directly sends mqtt messages - a BaseRemoteItem is always associated with a specific mqtt broker - when set is called, will send command_topic messages to change the state of a device - local state will not change until state_topic message is received unless the item is marked as optimistic or does not have a state_topic - will listen for state_topic messages with stata changes - will also listen for last will and testiment (LWT) messages reporting when a device goes offline

mqtt_RemoteItem - implements a statically defined mh item for mqtt devices - it is intended to work with Tasmota, IOT4 and ESPurna devices, BUT, I have a very limited set of devices to test with - currently implements switch, light, sensor, binary-sensor - I only have Tasmota switches, and with tuya convert broken, I am not able to setup other Tasmota devices (not into soldering at this point) - Remote devices can also be discovered using the gear in mqtt_discovery.pm eliminating the need to statically define them, but you need to turn discovery on on your device (eg. Tasmota: SetOption19 1) -- note that the Tasmota discovery gear is not being developed anymore... - can publish HA discovery info -- a simpler discovery message than the discontinued Tasmota discovery mentioned above

mqtt_InstMqttItem - implements a statically defined mh item for Insteon devices managed by insteon-mqtt - see https://github.com/TD22057/insteon-mqtt - can pulish HA discovery info, as insteon-mqtt does not implement discovery yet

Discovery (mqtt_discovery.pm):

This module implements MQTT discovery. Both publishing discovery information for locally defined devices, as well as receiving discovery information from mqtt devices.

The discovery definitions are based on the Home Assistant Discovery info: https://www.home-assistant.io/docs/mqtt/discovery

There are several uses for mqtt discovery in MH: - discover mqtt devices without having to statically define them in .mht files - publish discovery information for locally defined devices. This has multiple uses as well: - share device information with another MH instance - publish device information to Home Assistant. This could be for environments where both are running, or used when transitioning one way or the other.

There are 2 classes implemented in mqtt_discovery.pm:

mqtt_DiscoveredItem: - implements an mh item from a mqtt discovery message - this class extends the mqtt_BaseRemoteItem class - it has been built to handle 2 types of discovery messages: 1. discovery messages as published by the below discovery class primarily for mqtt_LocalItems, but discovery info for RemoteItems and InstMqttItems can also be published. This allows easy sharing of device definitions between MH instances, and also allows Home Assistant to know about MH items. 2. discovery messages published by remote devices. It handles some Tasmota, IOT4 discovery messages published when Tasmota SetOption19 is set to 1, or HASS discovery turned on on the IOT4 device. I don't have any ESPurna devices so I don't know about discovery for those devices. - it handles switch, light, sensor and binary-sensor - so far the handling of discovery messages is somewhat limited due to my very limited set of these devices - I have implemented these devices based on HomeAssistant documentation for discovery and information on blakaddr.com - In order to implement this properly, we would need a templating engine in perl

mqtt_Discovery: - is a class that listens for mqtt discovery messages based on an mqtt wildcard - creates mqtt_DiscoveredItems based on the published discovery information - you can then write out these items to a .mht file using the write_discovered_items method - note that the discovered items will not appear as fully referencable MH items until you restart MH once. - this class will also publish discovery information for mqtt_LocalItems and even for any of the mqtt_BaseRemoteItems if they are created with the discovery flag set

INHERITS

INI PARAMETERS

Items.mht

MQTT_BROKER, name, subscribe topic, host/ip, port, user, pwd, keepalive MQTT_BROKER, mqtt_1, , localhost, 1883, , , 121

# Used to define mqtt items as published by insteon-mqtt project
# TopicPattern should be of the form "<realm>/<mqtt name>/+". 
# MQTT_INSTMQTT,    name,		groups,		broker, type,		topicpattern,				    discoverable    Friendly Name
MQTT_INSTMQTT,	    bootroom_switch,	Lights,		mqtt_1, switch,		insteon/bootroom/+,			    1,		    Bootroom Light

# Define a Tasmota item.  Note that the topicpattern must be in the order that the device will
# send.  This is configured in the Tasmota MQTT configuration. 
# MQTT_REMOTEITEM,  name,		groups,		broker, type,		topicpattern,				    discoverable    Friendly Name
MQTT_REMOTEITEM,    tas_outdoor_plug,	,		mqtt_1, switch,		tasmota_outdoor_plug/+/+,		    0,		    Tasmota Outdoor Plug


    # Say you have a local INSTEON item  (could be any kind of misterhouse item)
INSTEON_SWITCHLINC, 52.9E.DD,		shed_light,	Lights|Outside
#
    # Then you can create an mqtt item to publish its state and receive mqtt commands
# TopicPattern should be of the form "<realm>/<mqtt name>/+". 
# MQTT_LOCALITEM,   name,		local item,	broker, type,		topicpattern,				    discoverable    Friendly Name
MQTT_LOCALITEM,	    bootroom_switch,	shed_light,	mqtt_1, switch,		insteon/bootroom/+,			    1,		    Bootroom Light
#


###################################################
# Use of Discovery functionality is optional
###################################################

# MQTT_DISCOVERY,   obj name,		discovery topic prefix, broker
MQTT_DISCOVERY,	    mqtt_discovery1,	homeassistant,		mqtt_1

.mht generated file:

# Discovery items are generated by the write_discovered_items function
# You would not normally code these by hand
# MQTT_DISCOVEREDITEM,	name,			    discovery_obj,	discovery_topic,			    discovery_message
MQTT_DISCOVEREDITEM,	mqtt_tasmota_outdoor_plug,  mqtt_discovery,	 homeassistant/switch/877407_RL_1/config,   {"name":"Tasmota Outside Plug","cmd_t":"~cmnd/POWER","stat_t":"~tele/STATE","val_tpl":"{{value_json.POWER}}","pl_off":"OFF","pl_on":"ON","avty_t":"~tele/LWT","pl_avail":"Online","pl_not_avail":"Offline","uniq_id":"877407_RL_1","device":{"identifiers":["877407"],"connections":[["mac","D8:F1:5B:87:74:07"]]},"~":"tasmota_outdoor_plug/"}


and misterhouse user code:

    #
if( $bootroom_switch->{state_now} ) {
    &print_log( "Bootroom light set " . $bootroom_switch->state );
}

#
if( new_minute(10) ) {
    # this will turn on the light by sending an mqtt command
    $bootroom_switch->set( 'toggle' );

    # as the insteon light is toggled with this command, an mqtt state message will be published
    $shed_light->set( 'toggle' );

}

# this will publish mqtt discovery messages for all discoverable items
$mqtt_discovery1->publish_discovery_data();

# this will write a .mht file with data for all discovered items
&mqtt_Discovery::write_discovered_items( "mqtt_discovered_items.mht" );

CLI generation of a command to the CR_Temp

NOTES

I believe most people using MQTT are running their own mqtt server. Typically mosquitto.

If you are using a higher traffic mosquitto server, then you
will want to qualify topics more.  That would require configuring
your Tasmota devices to have a qualified prefix.

Discovery: For discovery, there are a lot of devices types out there and a lot of different discovery message formats. I have handled common device types in this code, but it can be extended to handle many more. I have only been able to implement Tasmota switches and a rough implementation of Tasmota Dimmers based on zapping a device I have to think that it is a dimmer.

METHODS

AUTHOR

Dave Neudoerffer <dave@neudoerffer.com>

SEE ALSO

TODO

find a command that works to turn on the $shed_light mosquitto_pub -d -h test.mosquitto.org -q 0 -t test.mosquitto.org/test/x10/1 -m "Off" There is a lack of error checking and connectivity checks and restoration. I'm sure there are a huge number of features that need to be added.

Clone this wiki locally