DevState for Custom extensions

Good afternoon. I initially opened this over on the Asterisk forum, and the findings there led me to open a bug, but I was asked to put the issue in these forums instead.

Here’s the deal… I’m trying to create a little demo applet that basically makes some phone BLF’s randomly show activity for a demonstration. In researching, it seems the DevState command is the way to do this (granted, I still need to figure out how to make a linux script issue those commands to asterisk).

In attempting this, I discovered only CUSTOM entities can be controlled by the DevState command, so I created 3 dummy extensions (1011, 1012, and 1013) in FPBX13 - type, Custom.

They were dialable, but DevState commands never actually changed their status - even though the Asterisk CLI said “Device x State changed to Ringing” (or whatever command I issued).

Over on the Asterisk forum, someone identified the reason the DevState wasn’t working was because it appeared the hint was improperly formatted.

I submitted the bug report over on the issues site, and was told this is assembled from the Advanced tab of the extension (the DIAL) field. I manually adjusted to be:
and sure enough, DevState now worked exactly as expected.

However, now you couldn’t call the extension, because of course dialing expects “technology/resource”. I thought I’d get crafty and put:
in the Dial field. This permitted the DevState to still work, but still couldn’t be dialed.

Its odd to me that dialing requires “technology/resource” but hints expect it with a colon (“Custom:resource”). And, unfortunately, DevState only works with Custom devices.

So, a couple questions have arisen from this little fiasco:

  1. If I manually set it in the dial string with a :, how can I still permit it to be dialed (I’m assuming some additional wizardry in the custom extensions file can achieve this)…
  2. How could I script it to auto run various DevState commands - I know how to write a linux script, but I’m unsure what linux commands I could issue which would send instructions to Asterisk specifically…
  3. Is something not quite right? - colons and slashes - is the way the hint is generated askew and does that logic need to be tweaked…


I am not sure where you came up with that but I think you need to have a long hard look at “core show hints” in the Asterisk CLI

You state that when you create a Custom Extension with a dial string of “CUSTOM/1012” that you can dial it. What have you done in order to make that work, when I dial CUSTOM/1012 I get this:

[2016-04-14 18:03:06] WARNING[21677][C-0000006a]: channel.c:6044 ast_request: No channel type registered for 'CUSTOM'

Just noticed in the ticket that this was stated:

It’s odd to me that the Dial string is based on “technology/resource”, when hints are based on “technology:resource” - Granted, that’s an Asterisk thing, but just seems odd.

This is not correct. Hints are not “technology:resource” at all. Please read more about hints:

and also looking at “core show hints” in Asterisk while using FreePBX will give you many hints as well.

I meant that in terms of dailing (to actually call the extension) - and I got this specifically from the error that then presented itself when attempted as a :.

Here’s the basics:

I’ve created custom extension 1011. FPBX auto-built the dial-string as “Custom/1011” for this. I can call that number and get voicemail as expected, but the DevState commands are essentially ignored when I issue them - it says it’s changing them, but BLFs fail to show the status changes.

Based on the Asterisk forum recommendation, I changed the Dial string to “Custom:1011”. Now my DevState commands work exactly as expected, but the extension can’t be dialed - delivering this error:
WARNING[510][C-0000000b]: app_dial.c:2353 dial_exec_full: Dial argument takes format (technology/resource)

So back to my original questions, though I’ve already addressed and tested number 2:

  1. If I manually set it in the dial string with a :, that kills the ability to call it - how can I still permit it to be dialed (I’m assuming some additional wizardry in the custom extensions file can achieve this)…
  2. Is something not quite right? - colons and slashes - is the way the hint is generated askew and does that logic need to be tweaked…

I’m not doing anything special to achieve that. That’s what dial string is auto created when I build the custom extension. I just made x1234 and this is what it populated automatically for the dial string:

Not sure why you’re being so snippy (seriously, “long hard look”?).

It was based on the fact I stated I want to do this from within the CLI for scripting purposes, so available commands needed to be limited to what I can issue in the CLI. As well as what I was told by the system itself when I first started playing with the command:
CLI> devstate change
Usage: devstate change
Change a custom device to a new state. (this is what told me I needed to make the extension CUSTOM)
The possible values for the state are:
devstate change Custom:mystate1 INUSE
devstate change Custom:mystate1 NOT_INUSE

As well as articles similar to this:

As well as:
It didn’t accept me entering SIP/1011 (or SIP:1011) when I tried it was a SIP device, which I did derive from looking at the existing hints.

If my statement was inaccurate based on the info I collected, so be it, but I’m thinking there are at least 5-6 nicer ways to say “that’s not true” - maybe even, “here’s an example of a CLI command that should work for what you’re doing”.

I gave you an example at the cli. “Core show hints” you are interpreting my response as snippy. We’ve provided plenty of help for your situation.

Basically you don’t need a custom device to use hints. If you look at core show hints you’d see all the system hints and how they are setup. Which would give you ideas for creating your own.

“Core show hints” will help you. Just look at it. I said long hard look because you simply need to read about hints and how they work from the asterisk wiki or the book.

I don’t mind using a custom extension, as its doing the trick from a lighting perspective, but in the process, I may have stumbled across an oddity, in that when the custom extension is made, its possible the hint generated is malformed (since BLF wasn’t tracking the state changes even though the CLI response was that the change was successful.