433mhz, infrared IR to and from MQTT on ESP8266

[1technophile]

@thundergreen

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?

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

[thundergreen]

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

[1technophile]

@thundergreen I made a fork with the modification

1technophile/Arduino-IRremote

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

[ronvl (Ron)]

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.

[1technophile]

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?

[ronvl (Ron)]

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 …

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.).

[1technophile]

Thanks for this explanation,

You are right if we use the ack current functionnality you will have to choose into HA config between ack topic and 433tomqtt topic.

If I sum up HA can have 2 kind of data from the gateway:
-feedback when sensing a command to the gateway that indicates that the gateway received it
-data coming from signals published to mqtt

And it should be the same topic to be able to update HA switches when pressing a button from a remote or the HA command.
You could use optimistic: true but you prefer that the gateway says that it received the message so as to update the switch.

Am I right?

One other track; is it not the goal of MQTT QOS level 1 to handle that ?

[ronvl (Ron)]

You are right

Yes you could use optimistic: true but basically you than ignoring the state topic i.e. you could even leave it out of the config.

MQTT QOS is quality of service on protocol level and you don’t really want to use it as you can end up with resend of packages. The ACK we are talking about here is on service/application level.

But in principle we are only confirming that the gateway has received a command and successfully transmitted it via RF… this doesn’t mean that the switch has received it and turned itself on or off… however it is just nice to have the interface updated either way

[1technophile]

Ok clear to me, i will update the code and the wiki with this function, thanks for your participation

[1technophile]

@ronvl @craigcarps
I have made the modification to send back the payload here if you have some time to test don’t hesitate

[1technophile]

@ekim

Optional: I like to keep my networked devices on a fixed IP address for future trouble shooting. For that reason, I added static IP address capability, to OpenMQTTGateway.ini, as well as Serial Monitor IP address reporting. I did this by replacing the #ifdef statement in the setup() section of the code with the following:

Thanks for the idea, added to the code

[thundergreen]

I am scared now to update as i had problems to upload the sketch… i used the webbrowser arduino to upload and it worked but as i am not that familiar with all of this i might want to let it as it is till someone would provide a step by step tutorial for this Thanks anyway for your efforts

[craigcarps (Craig)]

Cheers, I’ll take a look tonight

[ronvl (Ron)]

Thanks, will try it next week

[thundergreen]

You might want to make a short how to? I’m really not that familiar with arduino. Got it working but not sure what and how I did it

[craigcarps (Craig)]

Hi

I’ve grabbed the new code and had a look. The “home/sensors/ir” MQTT feed now relays the transmitted IR code which is great. However when I used this feed as my state loop my switch seems to turn off for a second and then bounce back to on. I suspect this is due to both states (on/off) being triggered by the same payload value (the same IR code).

I might try using a if then else statement to publish back either a On or Off to designate the two states.
e.g.
if (signalSent == true && String(state) == “Off”){
char state[] = “On”;
trc("State changed to " + String(state));
boolean result = client.publish(subjectGTWIRtoMQTT, state); //datacallback);
if (result)trc(F(“Acknowedgement of reception published”));
} else if (signalSent == true && String(state) == “On”){
char state[] = “Off”;
trc("State changed to " + String(state));
boolean result = client.publish(subjectGTWIRtoMQTT, state); //datacallback);
if (result)trc(F(“Acknowedgement of reception published”));
}else{
trc(“State un-changed”);
trc(state);
}
if (result)trc(F(“Acknowedgement of reception published”));
}

Unfortunately my state variable stays as a constant and never changes (char state[] = ‘Off’), I think its cause the PubSub library publish function wants a constant char value as the message.

[1technophile]

Hello,

Have you seen this wiki?

1technophile/OpenMQTTGateway

[1technophile]

Hello,

Indeed as it is the same code for on and off i’m not sure this new acknowledgement function is usefull in this case, optimistic : true could be a bypass before finding another way.

[thundergreen]

i saw this wiki but couldnt figure out exactly how to change the files . a step by step would be great though …

[1technophile]

Hello,

I have a request on the openmqttgateway github.
Asking to be compatible with homie convention

homieiot/convention

I’m investigating time on this but before going further i would like to know the degree of compatibility with home assistant.
My main concern is about the fact that several mqtt payload must be sent in case one needs to send a rf signal with some particular parameters.

Currently if you want to send a signal with a special protocol or pulselength you set it into the topic:
home/MQTTto433/433_1/PLSL_360 123456
In one mqtt message we are able to send 123456 and other parameters.

With the homie convention we will have to publish 3 messages:
homie/openmqttgateway/rf-send/plsl/set 360
homie/openmqttgateway/rf-send/protocol/set 1
homie/openmqttgateway/rf-send/set 123456

I would like to have your thoughts on that, can this example be implemented easily into home assistant ?