Controlling rf433 bridge via MQTT brocker

[OrientST]

Thank you very match for excellent espurna firmware. I use it to control Sonoff Basic and Sonoff Pow devices. I need some help with Sonoff rf433 bridge firmware.

My Sonoff rf433 bridge works well. Remote control keys (A,B,C,D), door, and PIR sensors, switches submit rf433 commands,

witch are executed adequately. Switches statuses are controlled and depicted correctly in ESPURNA web interface (see appended file). Bridge regularly provides MQTT information about its state: {"app":"ESPURNA","version":"1.12.6","board":"ITEAD_SONOFF_RFBRIDGE",….}

However, I have problems controlling switches with MQTT broker.
When I press remote control key A (via rf433, code ID: 23640122037AA7C984) I receive a MQTT message:

RF433/data {"rfin":"23640122037AA7C984","relay/2":"1","time":"2018-06-02 11:37:16","mac":"DC:4F:22:CA:CE:06","host":"RF433","ip":"192.168.1.113","id":32028}

But when I send a message via MQTT

mosquitto_pub -t RF433/rfout/set -m "23640122037AA7C984,1"

nothing happens. The message is published, I see it in mosquitto terminal as

RF433/rfout/set 23640122037AA7C984,1

but command is totally ignored by the bridge, its status does not change. Nothing happens in Debug Log

ID code 23640122037AA7C984 corresponds to remote control key A for switch#2 – see the attached file. I have the impression that the bridge is not subscribed to the topic (see my rf bridge MQTT settings and Espurna firmware ver in the appended file). Reboot bridge does not help.

Second problem: Quite often ID codes of the remote control keys (A,B,C,D), door, and PIR sensors change in time to time, mostly in the first 2 bytes ("sync length") but not only. The distance between bridge and keys is about 1 or 2 meters. Тhis phenomenon will prevent me to control my devices - I would not be able to know which ID code to send to switch.

Mosquito is OK
Rf bridge and remote control are OK
I do not think you “forgot” to subscribe firmware to {hostname}/rfout

What do you think?
And the last – pls give an example how to use bridge http api in case I will not be able to control it by MQTT

[wildwiz]

have you tried to send simply to "RF433/rfout" (without /set) ?
one topic sends the relay status, and that is <root>/relay/x/set (0 off 1 on 2 toggle)
the other sends raw rf codes to the transmitter and that is <root>/rfout. These codes, if learned, are tracked by internal representation of relay too.

[OrientST]

After your answer I guessed to restart mosquitto broker and after that everything with sending messages to rf433 bridge is OK. Strange thing – my local mosquito server is working for a long time (more than 10 days). I permanently watch its terminal log and did not notice any signs of misbehavior. Anyway, I remembered the old maximum – “if something goes wrong - always restart”.

RF433/rfout “without /set” is not working either before or after mosquito restarting.

What about phenomena of ID codes changing. See an example – after several key presses the same button I received the following codes:
"236E01180384A7C988"
"23640122037AA7C988"
"236E0122037AA7C988"

[wildwiz]

About the changing IDs the pending pr #913 might help for your case too.

[mcspr]

@wildwiz Isn't it expected that timings may vary a little? Data part stays the same, from the example above:

"236E 0118 0384 A7C988"
"2364 0122 037A A7C988"
"236E 0122 037A A7C988"

[OrientST]

You were absolutely right that timing is not so important for me. I didn't know that above 3 codes are absolutely identical when sending MQTT messages to the firmware because their device code (last 3 bytes) is the same.
Тhank you for your attention.

[wildwiz]

@mcspr the point there is that the data part stays the same, but the overall string changes. This means that the mqtt consumer has to enter on the merit of how the code is structured, rather than just match it. While this is unavoidable for non learned codes, on a learned code we can emit a 'canonical' form, i.e. the one we stored and ease a bit the usage downstream (In my nodered I don't break down the codes, I rely on espurna learned ones to have consistent ones).

[mcspr]

@wildwiz Ok, fair enough. :) I do now realise that the workflow is to learn the code in webui and then to copy that value into the automation trigger.

Slightly OT I actually don't use rfbridge codes-as-relays learn/send/etc. feature at all and rely on parsing it like you describe to track buttons / door sensors. Now I got an idea - what about mapping these to dummy buttons so this would avoid code parsing part (and fixed timings problem goes away)? Sort-of related to #391