esprfid / esp-rfid

ESP8266 RFID (RC522, PN532, Wiegand, RDM6300) Access Control system featuring WebSocket, JSON, NTP Client, Javascript, SPIFFS
MIT License
1.34k stars 422 forks source link

Publish mqtt availability topic of esp-rfid #103

Closed rradar closed 6 years ago

rradar commented 6 years ago

Would be really nice to see esp-rfid publishing it's availability topic.

For home assistant this information is really nice! Could be something like this (ha yaml code entry):

availability_topic: 'esp-rfid/status'
payload_available: 'online'
payload_not_available: 'offline'

When the device is offline (network wise) I could see this information in home assistant :+1: as well when it's online/available :+1:

magic-tune commented 6 years ago

How should that work? When the device is offline it can`t publish anything. You could use home assistant ping sensor for that.

quikote commented 6 years ago

+1 I would also like to see this feature called LWT (Last Will and Testament) implemented in esp-rfid. In this way we will see in the controller (Home Assistant for example) if the device is online or not. I usually use it with every MQTT client connected to HA.

The Last Will and Testament (LWT) feature is used in MQTT to notify other clients about an ungracefully disconnected client. Each client can specify its last will message (a normal MQTT message with topic, retained flag, QoS and payload) when connecting to a broker. The broker will store the message until it detects that the client has disconnected ungracefully. If the client disconnect abruptly, the broker sends the message to all subscribed clients on the topic, which was specified in the last will message. The stored LWT message will be discarded if a client disconnects gracefully by sending a DISCONNECT message.

rradar commented 6 years ago

@magic-tune -> A picture says more than thousand words:

image

All sensor are offline. Just the upper one (Multisensor) supports the 'availability' topic. The lower one just shows the last values ever published. These could be a year old (because the device could offline since a year...)

magic-tune commented 6 years ago

Ah ok. I did'n know about this testament thing. So when the esp-rfid connects, it say to the broker: “hey when i die, push this message to my friends.“ When the broker realized that esp-rfid is died, then a message will be pushed to all subscribers “esp-rfid is death! You can't enter your home any more“. What happens when the broker goes down? Why not to use the ping-plugin for that ? Asynchron mqtt supports this testament messages. But I do not see the advantage of this in esp-rfid. Maybe when you hook up some 24/7 sensors? What does a rfid cardreader do all day long? Right 99,9% nothing. So why it should be connected to wifi and consume power all day long? I hooked my to a pir like this. So when there is movement, esp-rfid gets power, connects to wifi/broker (by the way this happens very fast. I test it for a week now with no issues at all) and when the right card is present it activates the relay, push a mqtt message. When there is no movement for 2 minutes, the pir cuts the power. For now this is the best solution 4 me. Dont know if the powercuts effects the esp health? I will see. Maybe connecting a pir to gpio and using deepsleep is a better option for the future?

cheers magic-tune

pidiet commented 6 years ago

@magic-tune for your environment the LWT gives you even more information than for someone who has esp-rfid running as a 24-7 always-on node. But even with 24-7 the information of a disconnected device is really helpful and makes debugging much easer!

This for example would be a 24-7 always-on node OR your esp-rfid which just comes online when needed

image shows always the last uid (No matter if online or offline)

This one could be your esp-rfid LWT. Actually you can utilized your information (online/offline) from your esp and create a binary-sensor out of it. So even you PIR is not even connected to your home assistant it can receive the information of motion (little bit of topic so)... Anyway you could see with LWT in the history when esp-rfid was active (online) in your case which is when the pir activated the device. Also the time frame when the tag was used is visible (missing right now in the screen up because the last uid is 'always' shown.

image shows the last uid (on the little green field) and online (on) or offline (off) state

And pinging is not a good idea btw. Needs more energy (on two devices!) and flooding the network with unnecessary traffic. It's also more dumb (just hitting every n seconds/minutes with the hammer) and not smart like LWT. And it's all about smart things nowadays - isn't it?

Pablo2048 commented 6 years ago

And pinging is not a good idea btw. Needs more energy (on two devices!) and flooding the network with unnecessary traffic. It's also more dumb (just hitting every n seconds/minutes with the hammer) and not smart like LWT.

Sorry, but this is definitely not true - how do you think MQTT knows when client die? By using keep-alive packets, so there is always some traffic and the two devices have to be online...

pidiet commented 6 years ago

Sorry, but this is definitely not true - how do you think MQTT knows when client die? By using keep-alive packets, so there is always some traffic and the two devices have to be online...

If it's inside or part of the mqtt protocol it should be good without any downsides (it's by design a low traffic protocol/architecture). I thought more about using nmap and scanning your network at given time intervals for certain targets (because there exists plugins for home assistant). If you will test it on battery powered nodes/devices you will see a heavy increase of battery usage on these devices. You can test it easily with your phone and look in the battery stats afterwards - deep sleep will permanently be interrupted.

So my last will and testament: we all need LWT for esp-rfid :+1:

Pablo2048 commented 6 years ago

Yes I'm also for LWT, but this need ESTABLISHED TCP connection so I did not see any battery saving...

quikote commented 6 years ago

I agree. It would be great to have LWT in esp-rfid.

And also (sorry for the repeated wish) a bidirectional MQTT communication to send commands from the smart controller to the relay, for example, in a easy and integrated way.

omersiar commented 6 years ago

WebSocket messages can be used out of the box. You will need to wait for MQTT support.

For LWT just tell which message to publish.

Also I think Async MQTT Library is not as stable as PubSubClient.

omersiar commented 6 years ago

@quikote Can you please share LWT message example?

quikote commented 6 years ago

Normally my sensors sent a "Online" or "Offline" message as LWT. I just have to listen to a topic, as for example 'stat//LWT' for "Offline" or "Online" message.

rradar commented 6 years ago

I think this one here could be used as a starter:

/*
  Function called to connect/reconnect to the MQTT broker
*/
void connectToMQTT() {
  if (!mqttClient.connected()) {
    if (lastMQTTConnection < millis()) {
      if (mqttClient.connect(MQTT_CLIENT_ID, MQTT_USERNAME, MQTT_PASSWORD, MQTT_AVAILABILITY_TOPIC, 0, 1, "offline")) {
        DEBUG_PRINTLN(F("INFO: The client is successfully connected to the MQTT broker"));
        publishToMQTT(MQTT_AVAILABILITY_TOPIC, "online");

Source: https://github.com/mertenats/Open-Home-Automation/blob/master/ha_mqtt_multisensor/ha_mqtt_multisensor.ino

omersiar commented 6 years ago

https://github.com/marvinroger/async-mqtt-client/blob/master/docs/2.-API-reference.md#asyncmqttclient-setwillconst-char-topic-uint8_t-qos-bool-retain-const-char-payload--nullptr-size_t-length--0

omersiar commented 6 years ago

There will be LWT on next release, closing it now, track it on #125