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

More progress today, I've discovered how to make MQTT wildcards work and 
added this to the wiki (https://github.com/hollie/misterhouse/wiki/Tasmota)

My next task is to learn how to incorporate this into a pull request.

Giles

On 18/12/2020 11:19, Giles Godart-Brown wrote:
>
> All
>
> We have made good progress on this over the last few days.
>
>   * We have updated the wiki to describe how to drive these devices
>     with MQTT and HTML
>   * We have added definitions for MQTT_BROKER and MQTT_DEVICE to
>     items.mht (see
>     https://github.com/hollie/misterhouse/pull/804/files) to improve
>     native MQTT support.
>   * We have added definitions for TASMOTA_HTTP_SWITCH to items.mht
>     (see https://github.com/hollie/misterhouse/pull/803/files HTML
>     device support)
>   * We have discovered how to get MH to subscribe to all MQTT topics
>     (see the Tasmota page on the wiki) - Thanks Dave
>   * We have described how to make Misterhouse send its MQTT Last Will
>     and Testament messages in the WIki
>
> We hope these will all be incorporated into the core release in the 
> new year.
>
> Things to do;
>
>   * Dave has made a number of improvements to the MQTT support and
>     shared this with me to see how this helps with Tasmota devices. It
>     will take me a couple of days to absorb this, I will report here
>     in due course.
>   * I've been wondering if we could handle wildcard topics, this would
>     be very useful for handling closed loop feedback (e.g.
>     +/device_name/+) and LWT (e.g. tele/+/LWT). I'm thinking of
>     copying the technique in Net::MQTT::Simple where it defines a
>     subroutine to be called whenever a message matches the wildcard
>     passing it the topic and payload.  Items.mht  would look like this
>     MQTT_WILDCARD, name, wildcard_topic, subroutine_name e.g.
>     MQTT_WILDCARD, LWT handler, tele/+/LWT, handle_LWT_message(). 
>     What do people think?
>
> Special thanks to Jeff and Dave for their help in getting this done so 
> quickly
>
> Giles
>
> On 16/12/2020 14:26, Dave Neudoerffer wrote:
>> 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] <mailto:[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
>>     <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 <http://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
>>     <https://lists.sourceforge.net/lists/listinfo/misterhouse-users>
>>

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