RF sending: few different consecutive commands lead to weird/unpredictable results

[akasma74]

Describe the bug If you sent few different mqtt commands with little delay between them to OMG, its behaviour is unpredictable and status messages are incorrect.

To Reproduce

1. Subscribe to all mqtt topics to see messages in both command (MQTTto433) and state (433toMQTT) topics and their arrival times.
2. Publish messages like {"value":12001361} and {"value":12001360} to the command topic with no delay between them (for example, from an automation or a script).
3. See in the mqtt log 2 consecutive messages in command (MQTTto433) and then 2 consecutive messages in state (433toMQTT) topic.
4. The appliance that supposed to be turned OFF remains ON.

Expected behavior Few different consecutive commands must result in OMG generating a designated RF signal for each command.

Screenshots

Environment (please complete the following information): OMG v0.9.1beta (master?) Arduino UNO with w5100 Ethernet shield

Additional context Here is a complete description:

I have a RF wall switch I control from HA via OMG v 0.9.1beta. My automation sends 2 mqtt commands to OMG with a very small interval between them.

Turn on the switch

home/OpenMQTTGateway/commands/MQTTto433 {"value":12001361} Turn off the switch home/OpenMQTTGateway/commands/MQTTto433 {"value":12001360}

The wall switch turns on and remains on.

In mqtt log I have this

home/OpenMQTTGateway/commands/MQTTto433 {“value”:12001361} home/OpenMQTTGateway/commands/MQTTto433 {“value”:12001360} home/OpenMQTTGateway/433toMQTT {“value”:12001361} home/OpenMQTTGateway/433toMQTT {“value”:12001360}

and in Serial Monitor

Hey I got a callback 11:57:34.324 -> MQTTtoRF json MQTTtoRF OK 11:57:35.193 -> Pub json into: 11:57:35.193 -> home/OpenMQTTGateway/433toMQTT 11:57:35.193 -> {“value”:12001361} 11:57:35.193 -> Hey I got a callback 11:57:35.193 -> MQTTtoRF json MQTTtoRF OK 11:57:36.104 -> Pub json into: 11:57:36.104 -> home/OpenMQTTGateway/433toMQTT 11:57:36.104 -> {“value”:12001360} 11:57:36.104 -> Hey I got a callback 11:57:36.104 -> Store signal 11:57:36.104 -> Json buf. 11:57:36.104 -> Min ind: 11:57:36.104 -> 0 11:57:36.104 -> store code : 11:57:36.104 -> 12001361/76872 11:57:36.104 -> Col: val/timestamp 11:57:36.104 -> 0:12001361/76872 11:57:36.104 -> 1:13916622/64536 11:57:36.104 -> 2:75/74694 11:57:36.104 -> 3:75/74710 11:57:36.104 -> Data JSON stored 11:57:36.104 -> Hey I got a callback 11:57:36.208 -> Store signal 11:57:36.208 -> Json buf. 11:57:36.208 -> Min ind: 11:57:36.208 -> 0 11:57:36.208 -> store code : 11:57:36.208 -> 12001360/76892 11:57:36.208 -> Col: val/timestamp 11:57:36.208 -> 0:12001360/76892 11:57:36.208 -> 1:13916622/64536 11:57:36.208 -> 2:75/74694 11:57:36.208 -> 3:75/74710 11:57:36.208 -> Data JSON stored

I wonder why the switch turns on but then does not turn off? And what is the right way to get it work properly?

P.S. The only way to get a correct behaviour (i.e the switch is off at the end) is to add small (1-2 seconds) delay between these 2 commands (actually, it’s just adding for: '00:00:01’ to trigger: platform: state), in which case I get

in mqtt log

home/OpenMQTTGateway/commands/MQTTto433 {“value”:12001361}

home/OpenMQTTGateway/433toMQTT {“value”:12001361}

home/OpenMQTTGateway/commands/MQTTto433 {“value”:12001360}

home/OpenMQTTGateway/433toMQTT {“value”:12001360}

in Serial Monitor

Hey I got a callback 12:15:09.941 -> MQTTtoRF json MQTTtoRF OK 12:15:10.795 -> Pub json into: 12:15:10.795 -> home/OpenMQTTGateway/433toMQTT 12:15:10.829 -> {“value”:12001361} 12:15:10.829 -> Hey I got a callback 12:15:10.829 -> Store signal 12:15:10.829 -> Json buf. 12:15:10.829 -> Min ind: 12:15:10.829 -> 0 12:15:10.829 -> store code : 12:15:10.829 -> 12001361/1125296 12:15:10.829 -> Col: val/timestamp 12:15:10.829 -> 0:12001361/1125296 12:15:10.829 -> 1:13916622/64536 12:15:10.829 -> 2:75/74694 12:15:10.829 -> 3:75/74710 12:15:10.896 -> Data JSON stored Hey I got a callback 12:15:13.328 -> MQTTtoRF json MQTTtoRF OK 12:15:14.253 -> Pub json into: 12:15:14.253 -> home/OpenMQTTGateway/433toMQTT 12:15:14.253 -> {“value”:12001360} 12:15:14.253 -> Hey I got a callback 12:15:14.253 -> Store signal 12:15:14.253 -> Json buf. 12:15:14.253 -> Min ind: 12:15:14.253 -> 0 12:15:14.253 -> store code : 12:15:14.253 -> 12001360/1128692 12:15:14.253 -> Col: val/timestamp 12:15:14.253 -> 0:12001360/1128692 12:15:14.253 -> 1:13916622/64536 12:15:14.253 -> 2:75/74694 12:15:14.253 -> 3:75/74710 12:15:14.522 -> Data JSON stored

[1technophile]

Hello,

Could you try to add the repeat key with the last code revision (it is a new function for RF), maybe the receiver doesnt' make the difference between the 2 signals as they are consecutives: home/OpenMQTTGateway/commands/MQTTto433 {"value":12001361,"repeat":5}

[akasma74]

I'm afraid it makes no difference

Hey I got a callback 17:27:47.304 -> MQTTtoRF json 17:27:47.891 -> MQTTtoRF OK 17:27:47.891 -> Pub json into: 17:27:47.891 -> home/OpenMQTTGateway/433toMQTT 17:27:47.891 -> {"value":12001361,"repeat":5} 17:27:47.891 -> Hey I got a callback 17:27:47.891 -> MQTTtoRF json 17:27:47.891 -> MQTTtoRF OK 17:27:47.891 -> Pub json into: 17:27:47.891 -> home/OpenMQTTGateway/433toMQTT 17:27:47.891 -> {"value":12001360,"repeat":5} 17:27:47.891 -> Hey I got a callback 17:27:47.891 -> Store signal 17:27:47.891 -> Json buf. 17:27:47.891 -> Min ind: 17:27:47.891 -> 0 17:27:47.891 -> store code : 17:27:47.891 -> 12001361/1017291 17:27:47.891 -> Col: val/timestamp 17:27:47.891 -> 0:12001361/1017291 17:27:47.891 -> 1:12001361/64957 17:27:47.891 -> 2:1023/65891 17:27:47.891 -> 3:1023/65907 17:27:47.891 -> Data JSON stored 17:27:47.891 -> Hey I got a callback 17:27:47.891 -> Store signal 17:27:47.891 -> Json buf. 17:27:47.891 -> Min ind: 17:27:47.891 -> 0 17:27:47.891 -> store code : 17:27:47.891 -> 12001360/1017307 17:27:47.891 -> Col: val/timestamp 17:27:47.891 -> 0:12001360/1017307 17:27:47.891 -> 1:12001361/64957 17:27:47.891 -> 2:1023/65891 17:27:47.891 -> 3:1023/65907 17:27:47.891 -> Data JSON stored

and

17:27:47: (0) home/OpenMQTTGateway/commands/MQTTto433 {"value":12001361,"repeat":5} 17:27:47: (0) home/OpenMQTTGateway/commands/MQTTto433 {"value":12001360,"repeat":5} 17:27:47: (0) home/OpenMQTTGateway/433toMQTT {"value":12001361,"repeat":5} 17:27:47: (0) home/OpenMQTTGateway/433toMQTT {"value":12001360,"repeat":5}

I also tried to add repeat only to the ON or OFF command, but it makes no difference.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[valdiks]

You could try to test commands with MQTT QoS levels, retain message and clean session.

If it is possible to send messages without delay with automation script and both commands should be executed then you should receive confirmation for each message/command that message/command was received and executed. This job has to be done by automation script but not by OMG.

[akasma74]

You could try to test commands with MQTT QoS levels, retain message and clean session.

Well, I'm not sure we can change QoS level (apart from changing it in OMG code, but that's not the way to go), I don't meed these messages to be retained and don't know what clean session means.

If it is possible to send messages without delay with automation script and both commands should be executed then you should receive confirmation for each message/command that message/command was received and executed. This job has to be done by automation script but not by OMG.

I don't quite get your point. Do you mean that my use case is invalid?

[valdiks]

I wonder why the switch turns on but then does not turn off?

You need to check what is received on receiver side. Maybe you need to use delay between transmission because of poor receiver performance or surrounding environment. You could get another RF receiver and connect it to arduino/esp/pc by wires and check what does it receive. But this does not guarantee that original receiver (switch?) is receiving the same. Or maybe you can connect to original receiver?

And what is the right way to get it work properly?

Use wire connection if you need fast performance. If not then use message delivery confirmation before sending another message or send message with delay. Try to find shortest delay between messages if possible.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 14 days since being marked as stale.