Skip to main content

day mode / night mode

Posted by eeman on Tue, 01/01/2008

Periodically it arrises, a customer asks for a feature to manually set daytime and after hours modes on their PBX instead of using a time based schedule. I noticed that recent versions of Thirdlane PBX have a n unused variable called OFFICE_OPEN_OVERRIDE and an example inbound route 's' to illustrate the best way to utilize it.

But what if you want the receptionist to set this variable as part of her duties. It is likely you wont want to give her administrator access to Thirdlane PBX just for this one task. I created some scripts that allow a designated extension to set and unset the OFFICE_OPEN_OVERRIDE global variable for day/night mode.

In my example I lock this privileged feature down to the defined extension OPERATOR (also defined in globals)

So if OPERATOR is set to 1206 then only that extension can execute these scripts.

Simply assign these scripts to a feature extension and dial that extension from the privileged phone.

openoffice
Script Description: Sets the global OPEN_OFFICE_OVERRIDE variable
exten => s,1,Set(MY_CHAN=${CUT(CHANNEL,/,2)})
exten => s,n,Set(MYEXTENSION=${CUT(MY_CHAN,-,1)})
exten => s,n,NoOp(${MYEXTENSION})
exten => s,n,GotoIf($["${MYEXTENSION}" != "${OPERATOR}"]?noauth)
exten => s,n,NoOp(OPEN_OFFICE_OVERRIDE = ${OPEN_OFFICE_OVERRIDE})
exten => s,n,Set(GLOBAL(OPEN_OFFICE_OVERRIDE)=1)
exten => s,n,NoOp(OPEN_OFFICE_OVERRIDE = ${OPEN_OFFICE_OVERRIDE})
exten => s,n,Answer
exten => s,n,Wait(1)
exten => s,n,Playback(ha/phone)
exten => s,n,Playback(ha/system)
exten => s,n,Playback(now)
exten => s,n,Playback(is-set-to)
exten => s,n,Playback(ha/open)
exten => s,n,Wait(2)
exten => s,n,Hangup
exten => s,n(noauth),Answer
exten => s,n,Wait(1)
exten => s,n,Playback(pbx-invalid)
exten => s,n,Wait(2)
exten => s,n,Hangup

closeoffice
Script Description: UnSets the global OPEN_OFFICE_OVERRIDE variable
exten => s,1,Set(MY_CHAN=${CUT(CHANNEL,/,2)})
exten => s,n,Set(MYEXTENSION=${CUT(MY_CHAN,-,1)})
exten => s,n,NoOp(${MYEXTENSION})
exten => s,n,GotoIf($["${MYEXTENSION}" != "${OPERATOR}"]?noauth)
exten => s,n,NoOp(OPEN_OFFICE_OVERRIDE = ${OPEN_OFFICE_OVERRIDE})
exten => s,n,Set(GLOBAL(OPEN_OFFICE_OVERRIDE)=)
exten => s,n,NoOp(OPEN_OFFICE_OVERRIDE = ${OPEN_OFFICE_OVERRIDE})
exten => s,n,Answer
exten => s,n,Wait(1)
exten => s,n,Playback(ha/phone)
exten => s,n,Playback(ha/system)
exten => s,n,Playback(now)
exten => s,n,Playback(is-set-to)
exten => s,n,Playback(tonight)
exten => s,n,Wait(2)
exten => s,n,Hangup
exten => s,n(noauth),Answer
exten => s,n,Wait(1)
exten => s,n,Playback(pbx-invalid)
exten => s,n,Wait(2)
exten => s,n,Hangup


Submitted by eeman on Tue, 05/20/2008 Permalink

it *could* with some modifications, but there is a fundamental issue with MTE that makes it difficult. Variables do not maintain themselves through restart. If you have to restart MTE for any reason, like upgrading asterisk, then suddenly all these channel variables go back to their default. I've talked with Alex in regards to using DB keys instead of 'if variable is set' as an override in the inbound routes. DB keys persist through system restarts. The same caveat exists with single tenant, the difference is a single tenant knows they need to re-set their day/night setting when they restart. Knowing how to handle 1000 tenants is quite a different problem.

Submitted by thirdlane on Sat, 05/24/2008 Permalink

I am revisiting this feature - your feedback would be helpful

1) should the dialplan code check both the variable and astdb for backward compatibility or should we abondon the global variable approach, document this and use db only? I could probably add code to read db and set the variable when the call comes in so the code in the inbound call handlers does not have to change

2) what would be a best way to report that the override is set? if it is not reported people will set it and forget that the override is on. We could have a script and a feature extension to check the status - would that be enough?

3) I think the main question is this. Should PBX Manager not allow changing the name of the variable (I would remove variable name seector from inbound routes screen replacing it with a yes/no selector or a checkmark for allowing (but not setting) the override) and just have it named internally OPEN_OFFICE_OVERRIDE?

My original idea was that you could set a dirferent variable for each action in inbound scripts (and that is why I did not provide a script for setting the variable(s), leaving it to the users). In retrospect I regret this as it makes it harder to manage and I doubt that many people use this flexibility and most will just have one variable indicating the office is open or closed. Is anyone using this beyond simple open/closed?

4) for MTE the variable could be named something like OPEN_OFFICE_OVERRIDE_tenant - again the will work if the name is hardwired

Best regards,

Alex

Submitted by eeman on Sun, 05/25/2008 Permalink

4) couldnt the key be something like TL/TENANT/${tenant}/office_mode ?

One could set this mode to some value. The inbound route management could look like

[checkbox] execute if office_mode key is set to [textbox]

that would allow more than a binary option.. I could have office_mode carry a few values. The most obvious that come to mind are day / night / temp.

ExecIf($["${DB(TL/TENANT/${tenant}/office_mode)}" = "day"]|from-outside-+15025551212-day,+15025551212,1)

ExecIf($["${DB(TL/TENANT/${tenant}/office_mode)}" = "night"]|from-outside-+15025551212-night,+15025551212,1)

ExecIf($["${DB(TL/TENANT/${tenant}/office_mode)}" = "temp"]|from-outside-+15025551212-temp,+15025551212,1)

Submitted by eeman on Sun, 05/25/2008 Permalink

we need an edit feature in the forum :) ...

modification to the code

ExecIf($["${DB(TL/TENANT/${tenant}/office_mode)}" = "day"]|Goto,from-outside-+15025551212-day,+15025551212,1)

Submitted by serverbeach on Mon, 09/08/2008 Permalink

Is there any new information to this post? We have a client that is looking to have a feature code to set the night service. It is a company that may need to set this during the day because they all have stepped out of the office. Our thought was a programmed key on the phone that sends a feature code. (*??) to set or unset.

It looks as if during this discussion there was progress but I am not sure how to implement this in MTE.

Regards,

Submitted by Ierlandfan on Wed, 10/08/2008 Permalink

I am looking forward to see the "temp" implemented.

Any chance for a quick hack for now?

I have a customer who wants to set the route as he pleases.

(No regular lunchtimes)

The I am able to create a feature code so he could dial say *999# and set it on or off

Ofcourse password protected.

Submitted by cbbs70a on Sun, 10/19/2008 Permalink

I'm trying to implement this so what I did is set my main inbound route with 2 actions/time-based handlers. The first says if the office is closed run script tl-menu and go to IVR "Company-Closed", except if OFFICE_OPEN_OVERRIDE is set. The second action says if the office is open, run script tl-menu and go to IVR "Company-Open". When OFFICE_OPEN_OVERRIDE IS NOT set, everything works. When it IS set, I get this error:

Timeout, but no rule 't' in context 'from-outside-redir'

It seems to me that the dialplan logic is wrong in the file inbound.include. This is what I have:

exten => 2402153479,3,GotoIf($["${OFFICE_OPEN_OVERRIDE}" != ""]?7)

...

...

exten => 2402153479,7,NoOp(${EXTEN})

exten => 2402153479,8,GotoIfTime(9:00-17:00,mon-fri,*,*?from-outside-2402153479-vbs-open-hours,${EXTEN},1)

So lets say in the case that it is a Sunday and I have OFFICE_OPEN_OVERRIDE=1, I then jump to the code above. It should fail then. Or am I wrong?

Submitted by moshe on Sat, 01/03/2009 Permalink

What would be the best way to implement such idea using a soft key on the phone if want to change day/ night/ temp status on a polycom phone basically when the assigned key is pressed it should either go to next mode if there only 2 schedules or should ask what mode u want (as call forward button it asks you always, busy, no answer, some idea like that)

I will play around with it soon just want to check if any body tried it already

Or any thoughts

Thanks

Submitted by eeman on Sun, 01/04/2009 Permalink

latest polycom firmware lets you program softkeys, you would just program the softkey to dial an extension. The admin guide doesnt correctly disclose how to do this, I had to create a ticket with polycom. Below is an example of dialing *8 for call-pickup using a softkey...

efk.version="2"

efk.efklist.1.mname="callpickup"

efk.efklist.1.status="1"

efk.efklist.1.label="Call Pickup"

efk.efklist.1.action.string="*8"

softkey.1.label="Pickup"

softkey.1.action="!callpickup"

softkey.1.enable="1"

softkey.1.precede="0"

softkey.1.use.idle="1"

softkey.1.use.hold="1"

Submitted by eeman on Wed, 04/01/2009 Permalink

wont work in MTE, because the vast likelihood a reload or restart would unset everyone's night mode, not to mention global variables are global to everyone and 1 global variable for every tenant would not scale well.

I sent Alex detailed functioning scripts and instruction on how to do it from the Inbound Routes section of PBX Manager using database keys (astdb) instead of global variables back in November. I practically wrote everything but the Perl web UI piece. I even wrote a macro IVR that has you authenticate and then choose day mode, night mode, or temp mode (like closed for emergency weather) which means you could set an inbound did to this and even set the mode from home if your snowed in and have to close the shop. Beat him up on getting this feature rolled out :) It's easy to do, we were selling PBXs (before the gui days) with this method of IVR even before we did time based handlers. Ive lost a few quotes because it was lacking this feature.

as far as how to integrate that with the phones, you would bind the set/unset to a feature code and then have the phone use soft keys to dial that extension.

Submitted by olekaas on Tue, 04/14/2009 Permalink

So - what about it Alex? Seems like all the fun stuff has been made - you just need to do the boring stuff (code review and ui integration ;-)

This feature will off load both our sales and support. Sales can just say "Of course you can - this is a state of the art PBX!". Support don't need to help customers who can't remember the work around. Not to mention all the sobbing and whining that their old PBX could do it and it was soooo easy.

/Ole

Submitted by eeman on Tue, 04/14/2009 Permalink

i just beta tested the new featured titled 'Operator Managed Routes' so its on its way. Included is a script that you assign to a feature code to change your mode from day to night or temp.

Submitted by hostedip on Sat, 04/18/2009 Permalink

The day/night mode switch is the biggest feature customers as asking for. Was not exited about the prospect of doing it myself.

Submitted by eeman on Wed, 04/29/2009 Permalink

soon. I had to submit an emergency patch today. Recent versions of asterisk has changed the way chan_local exits a macro and re-writes macro arguements and when a call enters a hunt group, gets transferred to another extension and times out to voicemail, it was failing. I am not sure when this started happening but its definitely happening the recent versions.

Submitted by Denis Campq on Thu, 05/21/2009 Permalink

Sorry, but I am unable to find the Operator Managed script you said was in 6.0.1.72.

I have upgraded to that version and double checked for most current scrips TL said I was at running 1.1.6.5. Can someone point me to the place to get the new script.

Thanks

Submitted by Denis Campq on Thu, 05/21/2009 Permalink

OK, I see where you have added the Operator Managed feature on the Inboud Route but am unable to determin how to make it work. Where can I find some info on how to set this up.

The piece that was missing according to the previous postings was the ability to retain the option to close or open the office, basicly reroute calls to external cell phone or whatever, and have the global variable saved to db so it is retained through reloads and restarts. The new option looks interesting but need a little more guidance on how this is supposed to work.

As always, Thanks for your help.

Submitted by Denis Campq on Thu, 05/21/2009 Permalink

My Bad. Found the tl-set-daynight script right where it should be.

I will dig in and try this tonight. Thanks Erik for creating this feature.

Submitted by Denis Campq on Thu, 05/21/2009 Permalink

Found one problem and one suggestion for the Day-Night Mode feature.

The press-1,press-2,press-3 wav files are not being played and nowehere on my system that I can find, so obviously the menue choises are not played. Also, how do I use/set the "allways" mode.

Although this is great for small offices with an operator that wants to eaisly control the incomming DID. I would also like to use the route schedule I already have so my auto-attendant IVR will continue work with the incomming schedual. Is there a way.... there always is ..... of combining these two options. What I am wanting is a little of both options where the calls will follow my normal inbound route option unless the attendant that anwers the calls durring the day, wants to go to lunch or close early and can eaisly and quickly reroute the incomming DID to predefined cell phones, or whatever.

Perhaps I just need to follow your script and make the changes myself. Anyway a good start and will meet a needs of a lot of small shops.

cheers

Submitted by eeman on Thu, 05/21/2009 Permalink

make sure you have all the sound files, not just the basic ones. If compiling asterisk include the sound extras. The extra files are an absolute must for MTE, it includes all the really good carrier messages like all circuits busy etc. If you didnt compile asterisk, you can still download them and install them into /var/log/asterisk/sounds

Submitted by eeman on Thu, 05/21/2009 Permalink

the 'any' modes doesnt look for a database key. it is simply a Goto..

If database key = day , goto script X

goto script Y

in this case if the key is set to anything but day, the goto script Y kicks in

you could just use any all by itself...

goto script X

this is the same thing as setting an inbound route to tl-allhours

Submitted by eeman on Thu, 05/21/2009 Permalink

to answer your 'combined' question.. you can still use schedule based routes and use the 'unless variable set' feature and declare a global variable like 'open_office_overide' etc. Then the receptionist can set the global variable and click reload and that time based handler will be skipped and advance to the next option in the list.

Submitted by Denis Campq on Fri, 05/22/2009 Permalink

OK, but as you know in MT the global variable option has several other issues and for my application gets reset duriing reloads.

Think I will use the new tenant based DB officemode entry as the variable I can set, read and use instead of the open_office_overide global variable. I would be interested to know if this is a sound approach to my needs. I am very wet behhind the ears when it comes to scripting but creating custome solutions is the real power behind TL and the onley way to learn is to jump in.

Thanks again.

Submitted by Denis Campq on Fri, 05/22/2009 Permalink

Found one last problem with the new Operator Mode.

The inbound.include that is created is missing the } for the GoToIf day and nite check.

I manually fixed mine as shown and it worked bit I don't think I should be changing the config file as it is generated when I create the Operator Mode route.

exten => 2142722407,7,GotoIf($["${DB(TL/TENANT/Training/officemode)}" = "day"]?from-outside-2142722407-day,${EXTEN},1)