[arm-allstar] Help with RXKEYED and TXKEYED events

Tue Jan 5 11:38:50 EST 2021

Correct; when there are back-to-back keyup/unkeys, very occasionally, the
call to my python script for the unkey will complete before the keyup
script.   The events in the Asterisk CLI are in the correct order, but, I
assume,  due to a race condition the scripts that publish to the MQTT
server complete out of order.

Same script is called for both, passing a '0' or '1' for the event.

python2 /usr/local/sbin/on_air.py 1 = s|t|RPT_RXKEYED
python2 /usr/local/sbin/on_air.py 0 = s|f|RPT_RXKEYED

So, with an unkey-keyup-unkey, I can end up with
0
0
1
flow through my MQTT server.

If I could include a epoch time or Asterisk event number in that payload,
0 1609863700
0 1609863900
1 1609863800
I could turn off my sign on the first 0, on the second 0, the sign would
remain off, and the 1 would be ignored because it had an epoch time before
the previous 0.

This is only a problem when the key-unkey are nearly simultaneous.

On Tue, Jan 5, 2021 at 7:59 AM David McGough <kb4fxc at inttek.net> wrote:

>
> Hi Kevin,
>
> I guess the problem you're having is that the on_air sign will sometimes
> be off, when it should be on. Or, vice-versa?
>
>
>
> 73, David KB4FXC
>
>
>
>
>
>
> On Mon, 4 Jan 2021, Kevin Davis wrote:
>
> > I’m still trying to figure a way to avoid these race conditions. Is
> there a way to include an epoch time or a chronological asterisk event
> number of some sort in the call to my Python script?  I could the publish
> this as a part of my MQTT payload, and have my client ignore payloads with
> a epoch or event number lower than a saved maximum.
> >
> >
> >
> > > On Dec 27, 2020, at 1:41 PM, Kevin Davis <blu666z at gmail.com> wrote:
> > >
> > > 
> > > Occasionally, when there are near instantaneous t|RX_KEYED and
> f|RX_KEYED events, I think I'm running into a race condition where my MQTT
> payloads of "1" for t|RX_KEYED and "off" for f|RX_KEYED arrive at the
> broker out of sequence.
> > >
> > > python2 /usr/local/sbin/on_air.py 1 = s|t|RPT_RXKEYED
> > > python2 /usr/local/sbin/on_air.py 0 = s|f|RPT_RXKEYED
> > >
> > >
> > > Am I correct in thinking that based on threading, the python script
> that was called on f|RX_KEYED could complete before the initial t|RX_KEYED
> script, thus making the MQTT payloads out of order?
> > >
> > >
> > >
> > >> On Sun, Dec 20, 2020 at 8:10 AM David McGough <kb4fxc at inttek.net>
> wrote:
> > >>
> > >> Yes, I believe just using TXKEYED should work satisfactorily.
> > >>
> > >> 73, David KB4FXC
> > >>
> > >> On Sun, 20 Dec 2020, "Kevin Davis via ARM-allstar" wrote:
> > >>
> > >> > Thanks David.
> > >> >
> > >> > I answered my own question as I was typing up the email(funny how
> that
> > >> > happens), but decided to still send it for confirmation.
> > >> >
> > >> > I guess in this case, I'll use only the TXKEYED event since it
> covers both
> > >> > scenarios I want my sign lit; I'm TXing or RXing from the reflector.
> > >> >
> > >> > On Sun, Dec 20, 2020 at 7:58 AM David McGough <kb4fxc at inttek.net>
> wrote:
> > >> >
> > >> > >
> > >> > > You're correct. In duplex=2 or duplex=3, and RPT_RXKEYED event
> will
> > >> > > immediately have a following RPT_TXKEYED event.
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Sun, 20 Dec 2020, "Kevin Davis via ARM-allstar" wrote:
> > >> > >
> > >> > > > Morning all.
> > >> > > >
> > >> > > > I'm working on controlling an "On-Air" sign using RPT events
> and MQTT.
> > >> > > I'm
> > >> > > > trying to understand why, when I key up my node, both the
> RXKEYED and
> > >> > > > TXKEYED events are both triggered.  Is it because I'm on a
> radioless node
> > >> > > > running full duplex?
> > >> > > >
> > >> > > >
> > >> > > > ***** RPT.CONF *****
> > >> > > > python2 /usr/local/sbin/on_air.py 1 = s|t|RPT_RXKEYED
> > >> > > > python2 /usr/local/sbin/on_air.py 1 = s|t|RPT_TXKEYED
> > >> > > > python2 /usr/local/sbin/on_air.py 0 = s|f|RPT_RXKEYED
> > >> > > > python2 /usr/local/sbin/on_air.py 0 = s|f|RPT_TXKEYED
> > >> > > >
> > >> > > >
> > >> > > > ***** Asterisk Log *****
> > >> > > > -- Event on node 507410 doing shell command python2
> > >> > > > /usr/local/sbin/on_air.py 1 for condition s|t|RPT_RXKEYED
> > >> > > > -- Event on node 507410 doing shell command python2
> > >> > > > /usr/local/sbin/on_air.py 1 for condition s|t|RPT_TXKEYED
> > >> > > > -- Event on node 507410 doing shell command python2
> > >> > > > /usr/local/sbin/on_air.py 0 for condition s|f|RPT_RXKEYED
> > >> > > > -- Hungup 'DAHDI/pseudo-1027201242'
> > >> > > > -- Event on node 507410 doing shell command python2
> > >> > > > /usr/local/sbin/on_air.py 0 for condition s|f|RPT_TXKEYED
> > >> > > >
> > >> > > >
> > >> > > > ***** Python Script *****
> > >> > > > import paho.mqtt.publish as publish
> > >> > > > import sys
> > >> > > > from datetime import datetime
> > >> > > >
> > >> > > > if sys.argv[1] == '1':
> > >> > > >         payload = 'ON'
> > >> > > > else:
> > >> > > >         payload = 'OFF'
> > >> > > >
> > >> > > > payload += ' ' + str(datetime.now())
> > >> > > > publish.single(topic="ke7k/on_air/status", payload=payload,
> retain=True,
> > >> > > > hostname="192.168.1.3")
> > >> > > >
> > >> > > >
> > >> > > > ***** MQTT Payload Published *****
> > >> > > > ON 2020-12-20 07:22:32.323583
> > >> > > > ON 2020-12-20 07:22:32.395017
> > >> > > > OFF 2020-12-20 07:22:34.326844
> > >> > > > OFF 2020-12-20 07:22:35.624007
> > >> > > > _______________________________________________
> > >> > > >
> > >> > > > ARM-allstar mailing list
> > >> > > > ARM-allstar at hamvoip.org
> > >> > > > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > >> > > >
> > >> > > > Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> > >> > > >
> > >> > >
> > >> > >
> > >> > _______________________________________________
> > >> >
> > >> > ARM-allstar mailing list
> > >> > ARM-allstar at hamvoip.org
> > >> > http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar
> > >> >
> > >> > Visit the BBB and RPi2/3/4 web page - http://hamvoip.org
> > >> >
> > >>
> >
>
>