xoseperez / espurna

Home automation firmware for ESP8266-based devices
http://tinkerman.cat
GNU General Public License v3.0
3k stars 636 forks source link

Please report state change source if available #1937

Open giddyhup opened 5 years ago

giddyhup commented 5 years ago

Is your feature request related to a problem? Please describe. Knowing what triggered a relay change helps in further processing.

Describe the solution you'd like I'd like to be able to know if an Alexa command has been received and acted upon or if it was an MQTT command or a button event. Adding a "source" : "alexa" value to the status message object would help. Perhaps this is also useful for other sources (e.g. Homeassistant).

Describe alternatives you've considered Currently I can differentiate (in Node-RED) if the light was switched on by a button press or via MQTT by looking at the state object (the relay value is changed and a button value appears if the event came from the button). I cannot see if the relay change was triggered via Alexa or via MQTT.

Additional context When the light was turned on triggered by a motion sensor (MQTT message) it gets turned off after a time of no motion (another MQTT message). If the light was turned on via the button I consider it 'forced on/latched' and it stays on. By setting a flow variable (in Node-RED) I can also set the forced state and the first motion event turns the light on and it stays on. I would like to have the same behavior when the light was turned on via voice command but I cannot differentiate between a motion triggered event and one triggered by Alexa.

mcspr commented 5 years ago

Perhaps a topic could change instead of the message? If this is strictly for MQTT reporting <root>/relay/<some-string>/0 or <root>/<some-string>/relay/0/ etc.

giddyhup commented 5 years ago

I'm more a JSON person. I'd like to see it as TOPIC: home/espurna/03/data PAYLOAD: {"relay/0":1,"source":"alexa","time":"2019-10-12 10:23:55","mac":"80:7D:3A:68:12:FF","host":"ESPURNA-03","ip":"192.168.1.61","id":1246383032} but there would of course also be a way to attack this for people who prefer topic-based information.

mcspr commented 5 years ago

It might be a separate entity, but consider this situation when using more than one relay:

set relaySync 3
+OK
reload
[127594] +OK
relay 0 1
[129348] [RELAY] #1 scheduled ON in 0 ms
[129348] [RELAY] #2 scheduled ON in 0 ms
[129348] [RELAY] #3 scheduled ON in 0 ms
[129349] [RELAY] #0 scheduled ON in 0 ms
[129351] Status: true
[129353] +OK
[129357] [RELAY] #0 set to ON
[129358] [RELAY] #1 set to ON
[129362] [RELAY] #2 set to ON
[129363] [RELAY] #3 set to ON
[129468] [MQTT] Sending ESPURNA-35A259/data => {"relay/0":1,"relay/1":1,"relay/2":1,"relay/3":1,"time":"...","mac":"...","host":"...","ip":"...","id":1} (PID 1)

You could end up with something like source/N, but now we have a payload that increases in size for no reason. Not to hijack the issue, but something similar was already noticed in the https://github.com/xoseperez/espurna/issues/1546 - we might want to always send all of relay statuses at once. In this case, there could be a "source":["alexa", ...] that describes the last known event source