[App_rpt-users] Access Command Mode With A Macro
Robert Garcia
robert at n5qm.com
Thu Aug 1 15:40:14 UTC 2013
Ken,
Agreed. Using the commands I posted would only get you the digits
that caused the script to run, but nothing after it unfortunately.
Robert
N5QM
On Thu, Aug 1, 2013 at 10:09 AM, Ken <ke2n at cs.com> wrote:
> of course ... that will return the DTMF code that executed the OS script. I
> think what is wanted are the digits that come afterwards (so that you can
> punch in any number not just a fixed menu of numbers).
>
> Oh well, I am sure a smart person can figure this out ;-P
>
> Ken
>
>
> -----Original Message-----
> From: Robert Garcia <robert at n5qm.com>
> To: Ken <ke2n at cs.com>
> Cc: app_rpt mailing list <app_rpt-users at ohnosec.org>
> Sent: Thu, Aug 1, 2013 9:29 am
> Subject: Re: [App_rpt-users] Access Command Mode With A Macro
>
> Or even better...
>
> asterisk -rx "rpt stats 29820" | grep executed
> Last DTMF command executed.......................: 329829
>
> asterisk -rx "rpt stats 29820" | grep executed | cut -c52-
> 329829
>
> Robert
> N5QM
>
> On Thu, Aug 1, 2013 at 8:23 AM, Robert Garcia <robert at n5qm.com> wrote:
>> Ken,
>>
>> Your idea lead me to this.. The shell script could parse that out
>> rather easily and act upon it.
>>
>> asterisk -rx "rpt stats 29820" | grep executed
>> Last DTMF command executed.......................: 329829
>>
>> Robert
>> N5QM
>>
>> On Thu, Aug 1, 2013 at 4:10 AM, Ken <ke2n at cs.com> wrote:
>>> No but that is an interesting idea
>>>
>>> The DTMF decodes are in the log file. If your script is smart it might be
>>> able to find and parse them
>>>
>>> /var/log/asterisk/messages
>>> ...
>>> Sep 24 12:58:34] NOTICE[2672] chan_usbradio.c: Got DTMF char * duration
>>> 210
>>> ms
>>> [Sep 24 12:58:35] NOTICE[2672] chan_usbradio.c: Got DTMF char 9 duration
>>> 82
>>> ms
>>> [Sep 24 12:58:35] NOTICE[2672] chan_usbradio.c: Got DTMF char 9 duration
>>> 191
>>> ms
>>> [Sep 24 12:58:36] NOTICE[2672] chan_usbradio.c: Got DTMF char 5 duration
>>> 150
>>> ms
>>> [Sep 24 12:58:37] NOTICE[2672] chan_usbradio.c: Got DTMF char 2 duration
>>> 170
>>> ms
>>> ...
>>>
>>> GL
>>> Ken
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Robert Garcia [mailto:robert at n5qm.com]
>>>> Sent: Wednesday, July 31, 2013 9:37 PM
>>>> To: Ken
>>>> Cc: app_rpt mailing list
>>>> Subject: Re: [App_rpt-users] Access Command Mode With A Macro
>>>>
>>>> Guys,
>>>>
>>>> This is an excellent thread with great ideas. By chance does the cmd
>>> function
>>>> pass the entered DTMF sequence to the shell script?
>>>>
>>>> Robert
>>>> N5QM
>>>>
>>>> On Wed, Jul 31, 2013 at 6:10 PM, Ken <ke2n at cs.com> wrote:
>>>> > Very nice - I do something quite similar.
>>>> >
>>>> >
>>>> >
>>>> > I note that you can define a function to tell Allison to "be quiet"
>>>> > for example
>>>> >
>>>> >
>>>> >
>>>> > 9940=cop,34 ; local telemtry off
>>>> >
>>>> >
>>>> >
>>>> > I execute *9940 at the start of my multi step script and it helps keep
>>>> > things a bit more quiet.
>>>> >
>>>> >
>>>> >
>>>> > At the end, I turn it back on with cop,33.
>>>> >
>>>> >
>>>> >
>>>> > Of course, this only does the local node. I suppose you could execute
>>>> > such a function on the remote node to turn off announcements (after
>>>> > the first one).
>>>> >
>>>> >
>>>> >
>>>> > I have a DSTAR machine at the same site and it sends commands to the
>>>> > asterisk machine, in some cases, using OS scripts like this.
>>>> >
>>>> >
>>>> >
>>>> > 73
>>>> >
>>>> > Ken
>>>> >
>>>> >
>>>> >
>>>> > From: Michael Hebert [mailto:mhebert1975 at gmail.com]
>>>> > Sent: Wednesday, July 31, 2013 3:21 PM
>>>> > To: Bryan D. Boyle
>>>> > Cc: app_rpt mailing list
>>>> > Subject: Re: [App_rpt-users] Access Command Mode With A Macro
>>>> >
>>>> >
>>>> >
>>>> > Brilliantly written Bryan! Kudos
>>>> >
>>>> >
>>>> >
>>>> > Mike - KD5DFB
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Jul 31, 2013 at 2:14 PM, Bryan D. Boyle <bdboyle at bdboyle.com>
>>>> wrote:
>>>> >
>>>> > On 7/31/13 2:38 PM, Johnny Keeker wrote:
>>>> >
>>>> > The question is, can a macro be created to connect to a node and then
>>>> > put it in the command mode? I've tried creating the usual macro
>>> example.
>>>> > [macro]
>>>> > 1=*325555*425555#
>>>> > *51 only calls the 25555 node yet it does not take into account the
>>>> > *425555
>>>> >
>>>> >
>>>> > Colin Chapman, founder of Lotus, had a favorite saying: "Simplify and
>>>> > add lightness".
>>>> >
>>>> > When you get into complex command strings and trying to make the
>>>> > machines jump through hoops, brew coffee, and change the baby at the
>>>> > same time, it's easy to forget that there is more than one way to
>>>> > accomplish what you are trying to do or gore an ox or stuff a ballot
>>>> > box
>>> (if
>>>> you're in Chicago).
>>>> >
>>>> > Ever thought of writing an OS shell script? There you now have
>>>> > somewhat more programmatic control over HOW and IN WHAT sequence
>>>> > commands are executed, can pause in between commands to allow them
>>>> to
>>>> > run to completion, do variable substitution so that the same shell,
>>>> > with different values passed to it, can be used for multiple
>>>> > functions.
>>>> >
>>>> > In short, to me, it makes more sense.
>>>> >
>>>> > Here, is an example of a useful Macro tied to a schedule:
>>>> >
>>>> > [macro27XXX]
>>>> > 09=*81#
>>>> >
>>>> > [schedule27XXX]
>>>> > 09 = 00 * * * *
>>>> >
>>>> > Which plays the time at the top of every hour. Clean. Neat. Simple.
>>>> > Brilliant. No pillocks here....
>>>> >
>>>> > But, what if you want to unlink two hub nodes, link another node
>>>> > through a secondary hub (because your brother ops object to the other
>>>> > node because it's a 2-meter link radio?) and tell everyone that it's
>>>> > done? Wow. Tell me the command string for that.
>>>> >
>>>> > I do not see that as a macro job.
>>>> >
>>>> > How about a script to do it:
>>>> >
>>>> > Call this script linkconnect.sh. Put it in a scripts directory
>>>> > somewhere, like /etc/asterisk/scripts, strangely enough...
>>>> >
>>>> > Call it from rpt.conf:
>>>> > 9XX=cmd,/etc/asterisk/scripts/linkconnect.sh
>>>> >
>>>> > --
>>>> > # Call a shell, no error checking, WYSIWYG, down and dirty #!/bin/bash
>>>> >
>>>> > #Send Asterisk a function message to unlink the two hubs
>>>> > /usr/sbin/asterisk -rx "rpt fun 27123 *127234#"
>>>> >
>>>> > #wait for all the gyrations and Allison to shut up sleep 5
>>>> >
>>>> > #Now, send a message to the second hub in the network to link #to the
>>>> > link radio node 27999 /usr/sbin/asterisk -rx "rpt fun 27123
>>>> > *428999*327999#"
>>>> >
>>>> > #Wait for it....
>>>> > sleep 2
>>>> >
>>>> > #Now, play an announcement that the new configuration is up and going.
>>>> > /etc/asterisk/scripts/w3skconnect
>>>> > --
>>>> >
>>>> >
>>>> > (obviously not the real node numbers, apologies to the holders of
>>>> > those numbers if they're in live use.)
>>>> >
>>>> > Now, you can define a 'macro' as, say, 10=*9xx# ;call the function
>>>> > numbered 9XX
>>>> >
>>>> > This gives you added flexibility and the ability to either call, using
>>>> > the internal schedule, on a fixed value, the shell you wrote, or using
>>>> > the OS cron facility, from a cronjob, or, even just run from the
>>>> > shell.
>>>> >
>>>> > Don't fixate on one solution as being better...sometimes imagination
>>>> > is the key to creativity and indecision is the key to flexibility.
>>>> >
>>>> >
>>>> > --
>>>> > Bryan
>>>> > In this world, you must be oh so smart or oh so pleasant.
>>>> > Well, for years I was smart. I recommend pleasant.
>>>> > You may quote me.
>>>> >
>>>> > Sent from my MacBook Pro.
>>>> > _______________________________________________
>>>> > App_rpt-users mailing list
>>>> > App_rpt-users at ohnosec.org
>>>> > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > App_rpt-users mailing list
>>>> > App_rpt-users at ohnosec.org
>>>> > http://ohnosec.org/cgi-bin/mailman/listinfo/app_rpt-users
>>>> >
>>>
>>>
More information about the App_rpt-users
mailing list