search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
22.12k stars 4.79k forks source link

Support for webread and MQTT read #3924

Closed qingz2004 closed 6 years ago

qingz2004 commented 6 years ago

Have you look for this feature in other issues and in the wiki? Yes.

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Try to get a sensor value from other device/MQTT topic.

Describe the solution you'd like A clear and concise description of what you want to happen. Like websend or publish to send a command to other device, I'd like to have a webread or mqttread to get a status/sensor value from other device/topic and use them in a rule.

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. We can use websend or publish to push the data from other device to this one, but it's not a good idea if there are a lot of devices need the data from the same device.

Additional context Add any other context or screenshots about the feature request here.

(Please, remember to close the issue when the problem has been addressed)

ascillato commented 6 years ago

You can use KNX for sending sensor values to several devices at once.

qingz2004 commented 6 years ago

I'm not using KNX. Don't know anything about it. And you may not know which device needs it. Better just let the device who needs it to fetch the data.

ascillato commented 6 years ago

By KNX you broadcast the data and only the devices that you want to listen, will use the data

ascillato commented 6 years ago

Thinking on your request on mqtt, you will need a command to ask for the value and another that will be triggered when the value is received. So, the timing and messages send/received will be the same than using rules, right?

Also, remember that for very complex things you will need to use a home automation software like node-red, home assistant, openhab, domoticz, etc.

qingz2004 commented 6 years ago

As for MQTT, can I trigger on the message was received by the server? Or just get the retained the message. If they are in the same LAN, I prefer to use something like webread, so no MQTT involved at all. I do have an openhab server, but just want it to be as simple as possible. For KNX, there will be a lot of reading. I may eventually use it, but not now. Thanks!

andrethomas commented 6 years ago

You can trigger something on a different device via mqtt using rules... check this for example https://github.com/arendst/Sonoff-Tasmota/wiki/Rules#2-execute-any-mqtt-message-when-a-button-is-pressed

qingz2004 commented 6 years ago

@andrethomas Thanks, but that is not what I want. Publish is used to send a command, it will not return anything. I need to read status/sensor value from a remote device.

ascillato commented 6 years ago

If they are in the same LAN, I prefer to use something like webread, so no MQTT involved at all.

well, the same as I was trying to explain.

device 1: send the webread request to device 2 device 1: need to wait for the request to be processed device 2: receive the webread and send data device 1: receive the answer from device 2

All that will be the exact same time than:

device 1: websend ip_device2/cmnd/event webread device 2: rule on event#webread do websend cmnd/device1topic/event webread_answer=%var1% device 1: rule on event#webread_answer do my_stuff %value%

Frogmore42 commented 6 years ago

If you want to be successful in home automation, a LOT of reading will be required. While you are always free to do what you believe is best, I find it useful to see what others have done and understand why they did it that way. Many times I find I can save a lot of time following along. Once I have done that I can have a better understanding of the trade-offs before discounting the solutions others have proposed.

I doubt that just because you think webread is a great idea, anybody else will drop what they are doing and go implement it right now, but I could be (and have been) wrong about that. That leaves you with a choice.

You can wait till webread happens. You can implement webread yourself. You can learn about the 7 different ways you could achieve your goals using tools that are available already.

I like to remind myself that just because I know how to use a hammer and like using a hammer, it doesn't mean every problem is a nail.

ascillato commented 6 years ago

But again, if you want to send a sensor value to several devices, by KNX you just need to set a KNX group address using the knx webmenu of tasmota and send data to that address. the config is very straight forward. In the wiki is explained with screenshoots.

KNX is a protocol, does not require any aditional hardware if using between Tasmotas. Only it needs your wifi router obviously.

The communication is a direct device to devices. It uses multicast protocol. So all devices receive all the data, but only the ones that are configured to a KNX group address will take the data into account.

Using the previous schema, using knx will be:

device 2: publish on a KNX group address the sensor data every teleperiod device 1: receive the data and do things with that (using a rule) device 3: receive the data and do things with that (using a rule)

ascillato commented 6 years ago

@qingz2004

I think that if you use the following schema (by HTTP, by MQTT or by KNX) is going to do what you want.

device 1: websend ip_device2/cmnd/event webread device 2: rule on event#webread do websend cmnd/device1topic/event webread_answer=%var1% device 1: rule on event#webread_answer do my_stuff %value%

If we add a new command like (websend) you WILL NEED to configure what is going to answer the device 2. So, you will need to configure several things in order to make it work.

So, I think that using rules will be the best option due to you can configure the behaviour you want and make Tasmota stay general and flexible with that.

qingz2004 commented 6 years ago

@Frogmore42 I am using websend and publish from other device for now. It works well for me at the moment. I request the feature just I think probably it is useful to others too. I do like to know what others have done. Thanks!

@ascillato Thanks! Didn't know I can use KNX that a simple way. Will try that.

qingz2004 commented 6 years ago

@ascillato Yes. A websent with a return is a good idea, and very useful. Thanks!

ascillato commented 6 years ago

@qingz2004

If you have a setup that is working, can you share that as an example for the wiki?

ascillato commented 6 years ago

@qingz2004

For example, I have a moisture and a Temp/hum sensor attached to a nodemcu that also controls some solenoids for watering my backyard. That moisture and temperature values are being sent by MQTT to my home automation software, but also those are being sent by KNX every teleperiod to a sonoff dual. That Dual controls other solenoids but from my front garden watering. So, as the garden does not have a temp sensor (*), I use the value sent by KNX to make the dual not to open solenoids if the temperature is close to zero celsius degree (freezing water) in order to prevent solenoids to brake.

So, backyard is sending temp every teleperiod, garden is receiving it and running a rule to store it in a VAR. The timers for watering the garden trigger a rule, the rule triggers a comparison with the VAR to know if it is ok to use solenoids. If Ok, turn them on, If not, do nothing.

What is your use case?

(*) No sensors due to in the front of the house is more likely to be vandalized. So everything need to be hidden below ground or with a very strong case, so as not to be broken or stolen.

ascillato commented 6 years ago

@qingz2004

So, coming back to the issue:

Are you ok on using the following schema (by HTTP, by MQTT or by KNX) using rules and events?

device 1: websend ip_device2/cmnd/event webread device 2: rule on event#webread do websend cmnd/device1topic/event webread_answer=%var1% device 1: rule on event#webread_answer do my_stuff %value%

ascillato2 commented 6 years ago

If you have further questions, ideas or suggestions, please, just ask to reopen this issue. Thanks everyone for sharing your ideas.

qingz2004 commented 6 years ago

@ascillato

Are you ok on using the following schema (by HTTP, by MQTT or by KNX) using rules and events?

device 1: websend ip_device2/cmnd/event webread device 2: rule on event#webread do websend cmnd/device1topic/event webread_answer=%var1% device 1: rule on event#webread_answer do my_stuff %value%

Yes, use websend with webread arg is perfect for this situation.

Here is my work around without webread. Remote device(outdoor): setup a rule to use websend to assign variables in local device(indoor) with the outdoor sensors' values. Local device(indoor): setup a rule to display both local sensor and remote sensor on OLED. Here is what I achieved. Thanks! screenshot_2

qingz2004 commented 6 years ago

Can't we get the return with websend immediately, like we browse the web site of the device? If I open a browser with this URL http://sonoff/cm?cmnd=Var2 I got this return on the page. screenshot_3

ascillato commented 6 years ago

You see that inmediatelly, but it is not instantly. There is a lot of time between your browser that asks and the return. So, for implementing that, you will have all the time the:

device 1 ask data device 2 catch the request device 2 process and send answer device 1 receive data

So, in the device 1, it is going to be 2 different steps, so will be 2 different events. So, you will fall again in the schema for rules.

You will need again an event for reception, and again, by rules you can set the behaviour you want. With an specific command, we will shrink the possibilities to only some cases. Like it is now, it is more general and can be used in a wide range of cases.

qingz2004 commented 6 years ago

Ok. I understand. There are two packets transmitted between these two devices. First packet to send the request from device 1 to 2 and second packet to send the answer from device 2 to 1. The process which issue the websend in device 1 can not wait for the second packet to receive and process the data.