Re: [mh] Misterhouse and Tasmota and other MQTT/HTML devices

Hey Giles,

I have done qutie a bit of work on the MH mqtt support over the last few
weeks.  It was in a different vein from what you are doing.  I have
implemented support for mqtt items that match up with the insteon-mqtt
project mqtt message format and with home assistant.  Support for both
local MH controlled items (eg. insteon) that publish mqtt messages, as well
as mqtt items that act as control for a remote mqtt device.

I also added discovery for both types of objects to publish device
discovery information (again as HomeAssistant expects to see it) as well as
to consume discovery information.  Consumption is little tough in MH as
adding items dynamically, while it works, it is not really MH intended
use.  However, I also added a routine to write out a .mht of the discovered
items.  This seems like a pretty good alternative mechanism for having two
MH instances share device information and work together.

I haven't yet submitted this work as I was letting it stabilize and
polishing it before doing so.  I am happy to share this work if you are
interested.  I don't have any Tasmota devices at this point, but am quite
interested, and would like to see all this mqtt work combined together.
The mqtt implementation really needs a template type approach for mqtt
messages, much like the insteon-mqtt project, but that may be more than I
can invest in at the moment.

Dave

On Sun, Dec 13, 2020 at 6:15 AM Giles Godart-Brown <[email protected]>
wrote:

> Starting a new thread on this topic.
> *My Experiences to date*
>
> Here is my experience of using Misterhouse to interface with Tasmota
> devices;
> By default to turn a relay (like a sonoff S20)  on and off from
> Misterhouse you need to set it up in MH like this;
>
> $Workshop_cutout_relay = new mqtt_Item( $mqtt_1,
> "cmnd/Workshop_cutout/POWER" );
>
> The misterhouse will publish appropriate on and off commands to this
> device.
>
> There are a few wrinkles in the MQTT  implementation in MH, so here is
> what I have found works for me;
> I normally use a generic MH variable for my switches in a group called
> IPswitches, with a member change handler that sends the appropriate html (
> http://ipaddress/cm?cmnd=Power on) when MH changes its state, this is for
> historic reasons and I really should change them all to native MQTT devices
> as above (its on a very long list of things to do), but as Jeff has said
> this way you dont HAVE to have a working  MQTT broker to communicate with
> these devices.
>
> Whenever a Tasmota switch changes state (or any sensor for that matter) it
> publishes an MQTT message that changes the value of an MQTT variable in
> Misterhouse e.g.
> If I look at the console for my outside xmas tree light switch and press
> the button on it, it both toggles the lights  locally and sends this MQTT
> message;
>
> topic= stat/Outside_tree_lights/POWER  payload = ON
>
> so if you have a device set up in MH like;
>
> $Outside_tree_lights = new mqtt_Item( $mqtt_1,
> "stat/Outside_tree_lights/POWER" );
>
> The MH value will be kept in sync with the state of the switch. This is a
> bit of a kludge because the stat message is sent because the relay changed
> state, and not the switch.
>
> In another  example I use this for my doorbell switch that's connected to
> a WEMOS D1 mini running Tasmota. and is defined in MH as $Front_doorbell =
> new mqtt_Item( $mqtt_1, "stat/Front_doorbell/SWITCH" );
>
> You can also use rules in tasmota to make it publish any message  you like
> e.g.
>
> Rule1 on Switch1#state do Publish stat/MHdevicename/whatever %value%
>
> Here is the rule I use for PIRs that are connected to Wemos D1 Minis to
> change it so they turn on the local LED and send motion and still instead
> of on and off
> Rule1
> on Switch1#state=1 do Backlog LedPower1 1; Publish stat/%topic%/PIR1
> motion endon
> on Switch1#state=0 do Backlog LedPower1 0; Publish stat/%topic%/PIR1 still
> endon
>
> If its more complex, e.g. 1-wire temp sensors then by default Tasmota
> sends a JSON encoded message e.g.
>
> tele/Roof_1_temperatures/SENSOR =
> {"Time":"2020-12-12T23:26:03","DS18S20-1":{"Id":"0008019F913C","Temperature":18.5},"DS18S20-2":{"Id":"0008019FAADB","Temperature":21.1},"DS18S20-3":{"Id":"000801B89032","Temperature":19.5},"DS18S20-4":{"Id":"000801F5AF58","Temperature":48.0},"DS18B20-5":{"Id":"0000026B4C3F","Temperature":19.8},"DS18B20-6":{"Id":"000002E07AEE","Temperature":14.6},"TempUnit":"C"}
>
> However I've found that MH filters out commands that start tele so I have
> a small listener process that subscribes to all tele/+/SENSOR topics and
> when it gets a message and  re publishes it as stat/+/SENSOR then I have in
> MH an item
>
> $MQTT_Roof_1_temperatures =  new mqtt_Item( $mqtt_1,
> "stat/Roof_1_temperatures/SENSOR" );
>
> I then use an on change handler for the  MH MQTT object
> Roof_1_temperatures to use JSON decode to translate the serial numbers into
> Room names and set up the temperatures.
>
> As an aside, I  use the same listener to subscribe to tele/+/LWT and look
> for mqtt Last will and testament offline and online messages then email me
> when devices go on or off line. With the default settings it detects
> Tasmota devices within 15 seconds of them being disconnected.
> *Propsed actions*
>
> Jeff is working on a Table_A implementation to support Tasmota devices via
> http, I'd like to help by adding MQTT native support, I suggest something
> like;
>
> MQTT_GATEWAY, name_of_gateway, LWT_topic e.g. MQTT_GATEWAY,
> mqtt1,tele/Misterhousemaster/LWT
>
> Then for the device;
>
> MQTT_DEVICE, name_of_device, name_of_gateway, topic, groups e.g.
> MQTT_DEVICE, Kitchen_lamp, mqtt1, cmnd/Workshop_cutout/POWER, Lamps|Kitchen
>
> I'm assuming the ip address,port,  id and password etc.of the MQTT broker
> will be .ini parameters.
>
> It would be really helpful if mqtt.pl could subscribe to more than one
> topic because Tasmotas default way of communicating sensor changes is via a
> tele rather than stat topic and it would  save users from having to create
> rules on their devices for communicating with MH. I'd like to be able to
> have a .ini parameter like  mqtt_topic=stat/#,tele/# and have the
> appropriate devices receive the messages but I'm blowed if I can see where
> to make the change, can someone please help?
>
> It would also be great to incorporate the LWT proposal above to regularly
> ping the broker so that external systems can verify that misterhouse is
> still up.
>
> As we make progress I will  update the wiki with this and my notes about
> the Tasmota environment (like Tazmotizer, TDM , MQTTfx etc)
>
> Regards
>
> Giles
> ________________________________________________________
> To unsubscribe from this list, go to:
> https://lists.sourceforge.net/lists/listinfo/misterhouse-users
>
>

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users