Re: [mh] Adding Tasmota HTTP support

Yeah, this is kind of pushing my capabilities. That's why I was so happy 
to see the work you guys have done. I think you have given me enough to 
get the mqtt working though.

Thanks again for all your work on this.

Paul

On 12/28/20 1:46 AM, Giles Godart-Brown wrote:
>
> FYI - Attached is the report I run based on MQTT lwt and other tasmota 
> status messages
>
> Gies
>
> On 28/12/2020 07:05, Giles Godart-Brown wrote:
>>
>> Paul
>>
>> In my earlier (far less elegant) implementation, I overload the 
>> device with its on and off commands from a small config file e.g. 
>> $Tasmota_device->{on_command} = "cm?cmnd=Power On" and use this to 
>> build up the HTML call. This would solve your problem, however Jeff 
>> and I did discuss this but decided it was over complicating it at the 
>> moment and better to walk before we run.
>>
>> Of course you could do this with mqtt with no extra code;
>>
>> 1) install mosquitto - this is easy (e.g. for pi see 
>> https://randomnerdtutorials.com/how-to-install-mosquitto-broker-on-raspberry-pi/) 
>> and add its coordinates to mh.ini
>>
>> 2) make sure you have the latest read_table_A.pl as described in the 
>> wiki (you should already have this as its part of the pull that Jeff 
>> created for http)
>>
>> 3) configure your devices in items.mht as
>>
>> MQTT_DEVICE, my_relay_1 , my_grouplist, mqtt_1, 
>> cmnd/my_tasmota_device/POWER1
>>
>> MQTT_DEVICE, my_relay_2 , my_grouplist, mqtt_1, 
>> cmnd/my_tasmota_device/POWER2
>>
>> etc.
>>
>> This technique would also work with any of the huge array of 
>> pre-defined sensors you attached to the gpio port (e.g.1-wire 
>> temperature) viz;
>>
>> MQTT_DEVICE, my_temperatures, , mqtt_1, tele/my_tasmota_device/SENSOR
>>
>> You'd also benefit from the last will and testament that MQTT uses to 
>> tell you if a device is not working.
>>
>> Giles
>>
>>
>> On 28/12/2020 05:53, Paul Onley wrote:
>>> Jeff,
>>> Many of the tasmana modules have the ability through external 
>>> additional gpios to add additional options would it be possible to 
>>> address specific channels with your tasmana module? For example 
>>> using a  sonoff mini in a ceiling fan one could add an additional 
>>> output relay so that one mini and one IP address could control both 
>>> fan and light. This however would require that your module will be 
>>> able to send to a specific output channel on the sonoff or tasmota 
>>> device.
>>>
>>> Again thanks for your work on this
>>> Paul
>>> Get BlueMail for Android <http://www.bluemail.me/r?b=16117>
>>> On Dec 15, 2020, at 1:51 PM, Jeff Siddall via misterhouse-users 
>>> <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>>
>>>     A couple of people have asked about detecting offline devices or
>>>     transmission failures.  My general response is that I would prefer to
>>>     make WiFi reliable enough that there is no need to keep tabs on
>>>     individual devices.
>>>
>>>     Having said that, I understand stuff still happens (and I would be the
>>>     first to tell you the best WiFi is _far_ from wired reliability) so
>>>     there are a couple of other options.
>>>
>>>     One of the great things about standard IP/web devices is there are a
>>>     _lot_ of existing tools, like monit
>>>     (https://en.wikipedia.org/wiki/Monit  <https://en.wikipedia.org/wiki/Monit>), to do network monitoring. These
>>>     are already readily available, well established and well supported so
>>>     that would be an easy solution.
>>>
>>>     In addition, I have now added an HTTP timeout setting to the
>>>     Tasmota_HTTP::Item module.  The default setting allows for the initial
>>>     request, plus 2 re-transmissions.  That should take care of any
>>>     individual packet loss without causing long pauses.
>>>
>>>     As part of that improvement, I also added the last request status line,
>>>     coincidentally stored in the item variable "last_http_status" to help
>>>     with monitoring items.  This is in addition to the ack tracking that I
>>>     added yesterday.  It's probably best to start looking at ack, since
>>>     ack=1 means you can be sure the last set was successful.  However, if
>>>     ack is 0 then you can start digging into last_http_status.
>>>
>>>     Further, if any web request to an item comes back as anything but
>>>     successful, a print log error message is generated so the issues is
>>>     recorded and can be further analyzed.
>>>
>>>     Let me know if that makes sense to everyone.  Of course, anyone can add
>>>     new code to do whatever other cool things they want if existing options
>>>     don't meet everyone's needs.  I hope to have the code committed shortly
>>>     and update the wiki accordingly so people can test this out.
>>>
>>>
>>>
>>>     ------------------------------------------------------------------------
>>>
>>>     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
>>>

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