-
Notifications
You must be signed in to change notification settings - Fork 130
New_Items mqtt
ggodart edited this page Aug 25, 2023
·
5 revisions
Awaiting contributions
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.
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
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
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.
Dave Neudoerffer <[email protected]>
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.