433mhz, infrared IR to and from MQTT on ESP8266

Third party integrations
122

I included your examples into the wiki thanks!

123

@1technophile thanks for sharing this and all the effort you put into this. This has some advantages over the rpi_rf that I was using as it running on a ESP8266 instead of a PI. The advantage is that I can have multiple gateways through my house (each floor) as I have some issues getting through the 60 cm walls with just one PI :slight_smile: I just need to make sure that the topics per floor are different

Now with some testing I found that your code doesnā€™t update the state topic subject433toMQTT ā€œhome/433toMQTTā€ when sending a command to a switch which give some issues in some of my test cases.

I understand that this is mainly caused by the fact that Iā€™m using the setting ā€œoptimistic: falseā€ instead of ā€œtrueā€. However currently the state topic is only providing a state based on receiving a signal and not after sending a signal which makes it useless in most cases.

Anyway I added the following lines to your sketch after line 330 and it is all working perfectly for my now :

// Update default state topic with the latest status = command 
String subject = String(subject433toMQTT);
String value = String(data);
trc(F("Updating default state topic in MQTT"));
trc(subject);
trc(value);
boolean resultUpdateST1 = client.publish((char *)subject.c_str(),(char *)value.c_str());
if (resultUpdateST1)trc(F("Update default state topic published"));

Now this only solves it for the 433toMQTT state topic not for any IR but you get the idea behind it.

Now as this state topic is overwritten as soon as a new command is given or received I also added an extra flag in the command topic that allows me to define a special state topic:

// MQTT state topic - This is the name of the state topic if a subject contains the StateTopicKey followed by the name of the state topic
#define StateTopicKey ā€œST_ā€ // The state topic will be the value of subject433toMQTT and combined with the string after ā€œST_ā€
#define StateTopicEnd ā€œ$ā€ // State Topic end key

The code for this is (also after line 330):

// Check for special state topic
//We look into the subject to see if a special state topic is defined
int posstart = topic.lastIndexOf(StateTopicKey); 
int posend = topic.lastIndexOf(StateTopicEnd); 
if (posstart != -1){ // State topic defined in subject
  posstart = posstart + +strlen(StateTopicKey);
  String StateTopic = (topic.substring(posstart,posend));
  trc(F("State Topic defined:"));
  trc(StateTopic);
  String subject = String(subject433toMQTT) + "/" + String(StateTopic);
  String value = String(data);
  trc(F("Updating special state topic in MQTT"));
  trc(subject);
  trc(value);
  boolean resultUpdateST2 = client.publish((char *)subject.c_str(),(char *)value.c_str());
  if (resultUpdateST2)trc(F("Update special state topic published"));
}

in my hass config the switch config looks like:

  • platform: mqtt
    name: ā€œREV 1ā€
    state_topic: ā€œhome/433toMQTT/REV_1ā€
    command_topic: ā€œhome/commands/MQTTto433/433_1/PLSL_282/ST_REV_1$ā€
    payload_on: ā€œ14013452ā€
    payload_off: ā€œ14013443ā€
    optimistic: false
    qos: 0
    retain: true

This avoids copying the status to another sensor via automation and makes it a bit cleanerā€¦ bear in mind thought that if a RF remote is used the state will not be updated in that case so you could end up out of sync. I never use remotes though.

Hope this helps to give you some ideas :slight_smile:

124

Hello,

Thanks for the feedback!

I will take a look to your idea of updating the state topic when sending data to the gateway.

Regarding your multiple gateway installation could you point me out how it works exactly, you said that youā€™ve changed the topic, are you talking about in and out topic or only in?

125

easy by changing state topic subject433toMQTT from ā€œhome/433toMQTTā€ to ā€œbasement/433toMQTTā€ for the gateway in the basement, to ā€œdownstairs/433toMQTTā€ for downstais gateway, etc for first and second floor.

In HASS the sensors and switches etcā€¦ will look at state topic of the gateway per floor and also put the commands in the resp. gateway.

sure the gateway will pickup signals from RF remotes on the various floors and create MQTT signals but as the HASS sensors etc are only looking at the floor gateway these will not impact the behavior.

Hope this explains it

126

Great timing, I have just been looking into how to trigger state changes from MQTT messages to indicate to HA whether a device has been turned on / off. Iā€™ll adapt this for my IR codes. Cheers

127

Hmmmm with the IR Codes iā€™m using the same code to basically toggle on/off, so I wont have separate payload values to define an on state and an off state.

So I will need to somehow keep track of the relative state in the arduino code to pass back to HA to acknowledge the state in HA.

Just wondering if anyone has done anything similar already? @ronvl @1technophile

128

Interesting no havenā€™t come across this yet
What I would do is add something to the RF code like _on and _off and strip this off the code in sketch before calling the RF function.

When you update the state topic you use the full code with the on and off.

@1technophile this you could also add to your sketch so other user will benefit from this as well

129

@ronvl @craigcarps Just to understand your needs, is the goal to have a kind of acknowledgement coming from the gateway saying that the signal has been sent?

130

Got my senderā€™s successfully added to home assistant.works like a charm so far. Just a question or two: is it somehow possible to increase distance and make it reacting faster
?

And I still see ir codes without having ir attached to the arduino.wondering which codes those are. Is it possible to completely deactivate this ir?

131

Hi
Thanks again to all that contributed to this project, is just amazing.
Just manage to send the codes to my plugs and all is working fine.
Thanks again

132

Hi

Ideally Iā€™m keen to use the acknowledgement payload to change the state in Home Assistant to indicate whether the switch has been turned on / off.

I might get a chance over the weekend to trial some stuff with the Arduino code

133

What do you think if we republish the payload to a subsujects like home/commands/mqttto433/ack ? In this case i have just to replace the ā€œokā€ acknwledgemeny by the sent payload .

134

Thanks for your feedback !

1 Like
135

Increase the distance it depends on what is your current setup in terms of antenna, emitter voltage and emitter type. Could you describe what are your components? I will guide you to what could be improved

136

Did you modify the irremote library finaly as pointed in th wiki?

137

I think I did but as Iā€™m totally new to thus stuff i dunno if i made it right . Could you show me how it should look like ? Donā€™t get me wrong 433 works perfectly i am just wondering how i get ir codes without ir mounted on the arduino

138

@thundergreen I made a fork with the modification

and updated the wiki, you were right it is now into IRremote/boarddefs.h

139

This will not work for HASS.
The State topic needs to have the same value as the values configured in HASS for on or off after a command has been executed.

For example my hass config looks like:

  • platform: mqtt
    name: ā€œREV 1ā€
    state_topic: ā€œhome/433toMQTTā€
    command_topic: ā€œhome/commands/MQTTto433/433_1/PLSL_282ā€
    payload_on: ā€œ14013452ā€
    payload_off: ā€œ14013443ā€
    optimistic: false
    qos: 0
    retain: true

so after i send the command 14013452 in ā€œhome/commands/MQTTto433/433_1/PLSL_282ā€ the state topic has to change to 14013452 as ack and HASS will update the interface and shows the switch is turned on.

Currently you donā€™t update the state topic when a command is send. You only update the state topic when you receive an RF command i.e. if you use an RF remote.

140

The gateway is currently able when sending an mqtt command to return an acknowledgement, example:
mosquitto_pub -t home/commands/MQTTto433/433_1/PLSL_282 -m 14013452

return to the broker:

home/commands/MQTTto433/433_1/PLSL_282/ack OK
The value returned to the subtopic ack is OK but could be easily replaced by the payload.

In the example if I replace the OK by 14013452 it should work isnā€™t it, supposing that home/commands/MQTTto433/433_1/PLSL_282/ack is your state topic?

141

I have seen that in your code and was wondering which implementation of MQTT would use this as it is not common as there are some floors in this method.

Basically the MQTT broker is working async and the responses coming back from MQTT enabled devices are random hence an ACK needs to be mapped to a command. You could argue that in your case the gateway works on a FIFO principle so the ACKs come back in the same sequence however take this example:

From my HA system I switch on a group of switches (scene) and send the following commands to the broker:

  1. home/commands/MQTTto433/433_1/PLSL_282 -m 1111111
    2 home/commands/MQTTto433/433_1/PLSL_282 -m 222222
    3 home/commands/MQTTto433/433_1/PLSL_282 -m 333333
    4 home/commands/MQTTto433/433_1/PLSL_282 -m 444444

all those 4 switches will share the same state topic: home/commands/MQTTto433/433_1/PLSL_282/ack

The result is that as soon as the gateway has processed the command for 1111111 and responded with and ACK ok all 4 switches will be updated to reflect that they are on while only the first command has been executed.

So your suggestion to replace the ok by the payload in the ACK will improve this however this means that you maintain two state topics for a switch, in this case:

  • home/commands/MQTTto433/433_1/PLSL_282/ack
    which holds the state after a command been processed coming from a broker
  • home/433toMQTT
    Which holds the state after the switch was operated via a RF remote-control

In HASS I can only declare one state topic i.e. one of the two above to have HASS determine if the switch is on or off. So as you cannot 100% determine the state topic home/commands/MQTTto433/433_1/PLSL_282/ack from a RF signal as the PLSL can vary it seems to more logical to always update home/433toMQTT if you either get a signal from a broker or from a RF signal grabbed from the air.

This is just my recommendation nothing else and mind you that this is all theoretical as even if the gateway has processed the command and acks this to the broker it doesnā€™t mean that the actual switch has received the RF signal and changed its state ā€¦ :slight_smile:

The only advantage of the method above is that in case of switches the state topics will be usable while currently the state topic doesnā€™t provide any info for switches and can only be used for Sensors that send RF signals based on a trigger (motion, open, closed etc.).