1technophile / OpenMQTTGateway

MQTT gateway for ESP8266 or ESP32 with bidirectional 433mhz/315mhz/868mhz, Infrared communications, BLE, Bluetooth, beacons detection, mi flora, mi jia, LYWSD02, LYWSD03MMC, Mi Scale, TPMS, BBQ thermometer compatibility & LoRa.
https://docs.openmqttgateway.com
GNU General Public License v3.0
3.57k stars 786 forks source link

Feature: Send on MQTT topic specific to RF payload #170

Closed danobot closed 5 years ago

danobot commented 6 years ago

It would be useful for home automation integration to have separate topics for different RF codes. home/433toMQTT/111111 and home/433toMQTT/222222 for two different motion sensors which send RF code "111111" and "222222" respectively.

Problem that made me think of this feature: This enables easy set up of sensors based on those MQTT topics. Attempting to set up a sensor on a single topic means the sensor with payload "111111" will get triggered when payload is "111111". This is as expected. however, when a different sensor with rf payload "222222" is triggered, then the first sensor's condition evaluates to false (because "111111" does not equal "222222"). Having separate topics means I can assign one topic per sensor and there are no conflicts in the payloads.

1technophile commented 6 years ago

Hello,

We could do that, but this enter in conflict with the requests of replacing standard payload by json ones. Does Json publishing could help you ?

danobot commented 6 years ago

THe problem persists because the messages are sent on /MQTTtoRF. Sensor 1 condition: json.rf_code == 111111 Sensor 2 condition: json.rf_code == 222222 Receiving 111111 makes Sensor 1 true (correct) but the state of binary sensor 2 is also affected. Now you could add additional metadata to the json payload but that would involve modelling the RF devices on the gateway and mapping RF code to some kind of device identifier. Simply sending a message on a dedicated topic such as /MQTTtoRF/111111 means the home automation hub can correctly interpret the message for different sensors and the gateway doesn't have to understand where RF codes are coming from. I hope that makes sense

1technophile commented 6 years ago

some infos that is related to this request: https://community.home-assistant.io/t/mqtt-py-log-warning-no-matching-payload-found-for-entity/42995/5

liwenyip commented 6 years ago

I've done something like this on my own fork by splitting the RF codeword into its address and data parts, and sending three additional MQTT messages like this (look at the last three lines):

home/433toMQTT/protocol 1
home/433toMQTT/bits 24
home/433toMQTT/length 288
home/433toMQTT 2971624
home/433toMQTT/address 2971616
home/433toMQTT/data 8
home/433toMQTT/2971616 8

See https://github.com/liwenyip/OpenMQTTGateway/commit/9032c91fd7f2f0635134a190aa07ff6f4218f1d4

Do you think this would be a useful feature to incorporate into the main fork? (Let me know and I'll submit a PR)

danobot commented 6 years ago

This is exactly what Im looking for! please PR and merge ;)

1technophile commented 6 years ago

Hello, Thanks for proposing. It is interesting. Indeed we have several ways to satisfy that: Sending the complete code as the last part of the topic: home/433toMQTT/2971624 1

or

Sending the adress like you propose and the data: home/433toMQTT/2971616 8

or

And keeping in mind that the next version will include json format we could imagine something like that: home/433toMQTT/2971616 {"protocol":1,"bits ":24,"length ":288,"data":8}

or

home/433toMQTT/2971624 {"protocol":1,"bits ":24,"length ":288}

Your opinions?

danobot commented 6 years ago

All my use case requires is distinct topics for each received RF code. All examples satisfy that condition.

graphite-elegance commented 6 years ago

Danobot, If you define a dummy payload for false or "off" for each of your motion sensors, any of the other payloads will be ignored. How are you currently turning your motion sensors off? I use a common off payload for all the motion sensors and have and automation rule that sends the common "off" payload after 5 seconds of any of them being activated. I don't believe the flexibility of the MQTT commands is being fully utilized by forcing complete subjects. I believe the payload solution is a much more elegant use of the system!!

danobot commented 6 years ago

Can you share your automation to set the binary_sensor to off after 5 seconds. According to a few posts on the HA community there is no way to manually set sensor values in automations.

graphite-elegance commented 6 years ago

The example motion sensor config

  • platform: mqtt name: BedroomMotion state_topic: "home/433toMQTT" payload_on: '12129369' payload_off: '11111111' sensor_class: motion

Automation to turn off sensor, I deleted some of the triggers to shorten the code, but I use the same automation for all of my binary sensors and some switches that I need to be momentary like my front gate.

  • id: MotionOff alias: MotionOff trigger:
  • platform: state entity_id: binary_sensor.troom_motion to: 'on' for: seconds: 5
  • platform: state entity_id: binary_sensor.BedroomMotion to: 'on' for: seconds: 5
  • platform: state entity_id: switch.front_gate to: 'on' for: seconds: 3
  • platform: state entity_id: binary_sensor.GateBell to: 'on' for: seconds: 8
  • platform: state entity_id: binary_sensor.GarageMotion to: 'on' for: seconds: 4
  • platform: state entity_id: binary_sensor.FamilyMotion to: 'on' for: seconds: 4
  • platform: state entity_id: binary_sensor.remote1off to: 'on' for: seconds: 4 action: service: mqtt.publish data: topic: 'home/433toMQTT' payload: '11111111'

Automation to turn off the light

  • id: BedroomMotionOff alias: BedroomMotionOff trigger: platform: state entity_id: binary_sensor.BedroomMotion to: 'off' for: minutes: 5 action:
  • service: homeassistant.turn_off entity_id: light.Bedroom

This is all working well for me for a few months now.

danobot commented 6 years ago

Ok, you are setting the value by sending an MQTT message. Yes this works. Thanks.

1technophile commented 5 years ago

see #298, you can add to the subject the value received by uncommenting the macro: //#define valueAsASubject true