Time Condition: "Current: Unknown State"

FreePBX Configuration
1

We have set up a time group and time condition and can’t get it to trigger correctly.
The Time Condition shows “Current: Unknown State” when I edit the time condition.
I have attempted to create a new time group and new time condition and it behaves the same.
I time has been set correctly and even changed the time zone, rebooted, put it back and rebooted but it still stays in Unknown State.
I am able to manually set the state to override, but it won’t ever trigger on it’s own.

Any ideas where to start looking at what I might have misconfigured?

2

Make sure asterisk isn’t running as root.

That data comes from astdb so it can’t access it or there is bad data.

You can run

asterisik -r

freepbx*CLI> database show

I believe the entries will be /TC/{id}

Relevant code…

if ($itemid && $thisItem['tcstate'] !== false) {
	$tcstate = $thisItem['tcstate'] == '' ? 'auto' : $thisItem['tcstate'];
	switch ($tcstate) {
		case 'auto':
			$state_msg = _('No Override');
		break;
		case 'true':
			$state_msg = _('Temporary Override matching state');
		break;
		case 'true_sticky':
			$state_msg = _('Permanent Override matching state');
		break;
		case 'false':
			$state_msg = _('Temporary Override unmatching state');
		break;
		case 'false_sticky':
			$state_msg = _('Permanent Override unmatching state');
		break;
		default:
			$state_msg = _('Unknown State');
		break;
	}
}else{
	$state_msg = _('Unknown State');
}
3

Thank you for your response. I think I have pulled the correct data but not 100% sure what I am looking for.

It looks like it runs safe_asterisk as root and asterisk is running as asterisk.

root 2069 0.0 0.0 115404 784 ? S Nov19 0:00 /bin/sh /usr/sbin/safe_asterisk -U asterisk -G asterisk
asterisk 2072 1.0 2.2 1738136 87124 ? Sl Nov19 75:21 /usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c

/TC/1 :
/TC/1/INUSESTATE : INUSE
/TC/1/NOT_INUSESTATE : NOT_INUSE
/TC/2 :
/TC/2/INUSESTATE : INUSE
/TC/2/NOT_INUSESTATE : NOT_INUSE

I am not sure if the above info helps.

4

I looked at a FreePBX 14, I see the same behavior. It only says something if the TC is overridden.

This is a bug.

5

Is there any known way around the bug?

6

You can use a BLF.

You may report the bug: issues.freepbx.org

If you create one, please link it here.

7

We experience exactly the same issue after we’ve upgraded from FreePBX 13 to 15 by installing a fresh machine and restoring the back-up.

I‘ll try to do some debugging.

8

I have updated “Time Conditions” from 15.0.15.3 to 15.0.15.4 but the problem is still there.
So what happens?

The manual override works indeed.

When the trigger has passed (for example 1 minute after closing time) and you test it, the condition is not met (so in this example the working hours are not over yet).
Then a manual “Permanently unmatched” override, sets the right condition.
But! When switching back with “Reset Override” the right condition stays in place (only after “apply config”) button in the right top corner (reset asterisk).

After that i thought lest test it by only applying the “Reset Override” when the trigger is not working.
After applying config (right top corner), the desired state is applied.

After that i tested only the “apply config” button (resetting asterisk). And that allso works.
So the trigger is “triggered” only on a asterisk reset.

This does the asterisk log say when reloading.

image
image1557×579 112 KB

Than i notices something strange. The time of the logging of some TC’s is 1 hour off.

Maybe this helps a bit, for searching the solution. We need help with this as well.

9

If it’s any help, I’ve noticed this and not given it much thought since timeconditions was introduced. I’m pretty sure it’s a cosmetic problem, but you might want to consider submitting a JIRA ticket so it can get some attention.

10

Good to know: After recreating the time conditions (manualy), the automatic switch, does work.
It looks like the Time Conditions, who have been restored from back-up do not switch automaticaly.

1 Like
11

Just thought I would give a quick update.
We tried re-creating the time condition and the time groups and never got it to work. What did work for us was moving to a Calendar for the time condition.

thank you,
Cliff

1 Like
12

Thank you cliffo80. When writing my previous post, it was the lunch time condition, that worked for us. But at the end of the day, the time condition for closing times, did not apply automatically unfortunately.
So i’m gonna try your Calander option.

13

With the Calendar option, everything works as expected.
So the issue could be related to the Time Groups.

Thank you cliffo80!

14

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.