Hipath4000(v6) Some analog extension ports will make a beep around 1-3 am 1

Maybe it's being reset or there could be a voicemail sending out a message notification ?
Have a look at the history
STA-HISTA:SEARCH;

Hello, sbcsu.
Thank you very much for your response. The attached information is about sta-hista:search. The system encountered many F4066&F4057 error messages. The customer reported that extension 8812 experienced this phenomenon in the early morning of February 26, 2024.
I wonder if the system performs some board or port self-tests in the early morning, causing pulse voltages on some ports. This is just my guess. But I can't confirm what causes it
thanks again!
<DIS-SIGNL:SYSTEM;
DIS-SIGNL:SYSTEM;
H500: AMO SIGNL STARTED

+------------------------------------------------------------------------------+
| SYSTEM STATE TABLE |
+----------+-------------------------+-----------------------------------------+
| UNIT | STATE | ADDITIONAL INFORMATION |
+----------+-------------------------+-----------------------------------------+
| CC-A | ACTIVE | POWER ON FROM 11-09-04 14:25:19 |
| CC-B | NOT AVAILABLE | ---- - - : : | ( CCB not installed)
| ADS | IN SERVICE | POWER ON FROM 11-09-04 14:25:03 |
| REF CLOCK| AUTONOMOUS CLOCK | |
| | (NO CLOCK REFERENCE) | |
| TFAILTR | TRUNK FAIL TRANSFER OFF | |
| ALARM | DEVICE ALARM | ---- ---- |
| | MINOR ALARM | ---- ---- |
| | MAJOR ALARM | ---- IN ADS |
+----------+-------------------------+-----------------------------------------+

ADD-SCSU:8812,1-1-4-19,ANATE,0,0,10,10,1,1,1,1,,,0,0,0,,,DTMF,LEDSIGN,,,ENGLISH,YES,,ONLYEXT,,,,0,DIR,YES,NO,0,YES;

OK so it's send F4057 DBAR errors
DBAR are normally serious.
I've looked up that error (F4057) and I attach the info below:
It would seem that the system is not correctly 'patched up' to date

CP
DBAR
Type:
Diagnosis-specific (several formats apply)
Short text:
Implausible data
Cause:
Implausible data for DataBase Access Routine.
Action:
Save error message data and contact your Next level of support. For
initial diagnosis, display the patch list with DIS-PATCH:SYS;. Check
P31003-H3100-S104-28-7620, 08/08/2022
242 OpenScape 4000, Troubleshooting - AlFe, User GuideError messages
the installed patches against the PRB list / latest Service Infos. Check
that no invalid or canceled patches are active in the system.
For Trace stop use e.g.:
selmsg,stop,g1,cd1,dest,40; /* FM in FA
selmsg,stop,g1,cd2,ev,26; /* DB_QF_E_CP
selmsg,stop,g1,cd3,sevt,1D; /* DB_TX_SPE_DBAR
selmsg,stop,g1,cd4,byte,11,DD /* UA Offset LowByte (e.g.UA:AABB:CCDD)
selmsg,stop,g1,cd5,byte,12,CC; /* UA Offset HighByte
selmsg,stop,g1,cd6,byte,13,BB; /* UA Selector LowByte
selmsg,stop,g1,cd7,byte,14,AA; /* UA Selector HighByte

Hi Dear sbcsu ,
Thank you very much for providing the solution.Your response has helped me gain new knowledge. I will contact the customer to arrange a time for the aforementioned actions. I sincerely appreciate your patient response.

I think possibly the DBARs are caused by missing VFGR configuration. Maybe.
I think the early morning bell chirp is caused by the RTO making routine tests, it should not be noticeable by the end devices but it does cause a change in line condition. The RTO is not tunable apart from speed it up, slow it down, turn it off. None of those would be recommended. You might try a different SLMA card maybe, and make sure you are on the latest loadware for the SLMA, but that's all you can do from 4K side.

Hi,Moriendi
Yes, I have checked the H4K system config and indeed the vfgr and acsu settings are missing. The customer does not have any ACWINIP attandant, so they removed the related configuration. As you mentioned, this could be one of the reasons for the DBARs error. I will try restoring the vfgr-related settings to see if the alarm disappears.
You Also mentioned that “RTO can speed it up, slow it down, or turn it off”. Could you please let me know how to achieve this?
I remember encountering this issue occasionally with other customers as well, and sometimes simply changing the telephone terminal resolved it. I feel that during RTO testing, there may be changes in the line voltage status, resulting in a voltage pulse. Some telephones terminal maybe have a low or sensitive ringing voltage threshold, causing a bell chirp. So I would like to try slowing down or turning off RTO to see if it can solve this problem, but I don't have much experience with RTO settings, so could you please guide me?
Thank you very much!

You don't need ACSU but you do need VFGR. VFGR configures the intercept destination for the ITR groups, if there is no ACSU it will just send to the night destination. Even if you set NAVAR to NONE, it is still configured. So add NAVAR for a night station, preferably a STN but NONE if you have to, then add VFGR with that NAVAR entry.

I think the problem with the bell chirp is more an issue with the terminal than the RTO. If only one or a few phones do it, I would change the phones. FUNSU AMO allows you to control the RTO but changing it can cause other problems. If you turn off a test than another problem may not be detected, and then you have different problems which are harder to find because you turned off the RTO. I would just change the phone.

Hello Moriendi,
Thank you very much for your patient response and guidance. The Customer feedback said that the guest room extensions would have the above faults erratically and there was no fixed extension. The customer has encountered this issue with more than 10 different extensions. If it were a few specific extensions, I would follow your advice and replace the telephones. However, I am concerned that if I replace these extensions, the same issue may occur with other extensions. Therefore, if it is possible to reduce or eliminate the recurrence of this issue by modifying RTO or if it provides a potential solution, I would like to try that. If modifying RTO does not lead to any serious faults, I am interested in attempting this approach. Could you please provide detailed instructions on how to modify RTO for testing purposes? I would greatly appreciate it!

Yes - Moriendi is correct - the missing VFGR will case issues -
Here are some 'UA's from my older notes
UA:A618:2E39 HV2.0
UA:A318:212F HV3.0
UA:A330:B124 HV4 R1
UA:A340:B516 HV5
UA:BAE8:C3D1 OS4KV7R2
VFGR is missing on the system and needs to be added!

And indeed the Routine Tests could be causing the bip - RTO

Thanks sbcsu, I had check the system and The system is indeed missing vfgr config,I will add it later.
the current challenging issue is the problem of room extensions bip in the early morning, as this can disrupt guests' sleep and lead to complaints.
therefore, I would like to attempt testing by modifying RTO to see if it can resolve this issue.However, I lack experience in modifying RTO, so I would appreciate it if some experts like you and Mr.Moriendi give specific guidance to provide me with guidance on how to proceed.

thanks!

I have referred to the documents, and based on my understanding, the configuration should be set as follows:

SET-FUNSU:UNIT=GP1A&GP1B&BPA&BPB,COMPLEX=RJGRP,RJGRP=RJP2,STARTAUT=Y,RJSTART=16,RJSTOP=17,RJPAUSE=3600;

Using the command above, modify the RTO of the room extensions to only execute between 16:00 and 17:00 in order to avoid disruptions to guests caused by its execution in the early morning？

I don't know if my idea is correct？

DISPLAY-FUNSU:UNIT=BPA&BPB&CC&LTG&SWU&GP1A&GP1B,COMPLEX=RJGRP,RJGRP=RJP2,
OUTPUT=ALL;
H500: AMO FUNSU STARTED
+------------------------------------------------------------------------------+
| UNIT : BPA |
+------------------------------------------------------------------------------+
| RJ GROUP: RJP2 START AUTH.(AM): Y STATUS (RTO): NOT ALLOWED |
| PAUSE (S): 3600 START (HH) : 16 STOP (HH) : 17 |
+----------------------------------+-------------------------------------------+
| ROUTINE JOB | START FREQUENCY |
+----------------------------------+-------------------------------------------+
| CIRA | 2 |
| CIRAENDA | 2 |
+----------------------------------+-------------------------------------------+
+------------------------------------------------------------------------------+
| UNIT : BPB |
+------------------------------------------------------------------------------+
| RJ GROUP: RJP2 START AUTH.(AM): Y STATUS (RTO): NDEF |
| PAUSE (S): 3600 START (HH) : 16 STOP (HH) : 17 |
+----------------------------------+-------------------------------------------+
| ROUTINE JOB | START FREQUENCY |
+----------------------------------+-------------------------------------------+
| CIRA | 2 |
| CIRAENDA | 2 |
+----------------------------------+-------------------------------------------+
+------------------------------------------------------------------------------+
| UNIT : GP1A |
+------------------------------------------------------------------------------+
| RJ GROUP: RJP2 START AUTH.(AM): Y STATUS (RTO): NDEF |
| PAUSE (S): 3600 START (HH) : 16 STOP (HH) : 17 |
+----------------------------------+-------------------------------------------+
| ROUTINE JOB | START FREQUENCY |
+----------------------------------+-------------------------------------------+
| CIRA | 2 |
| CIRAENDA | 2 |
+----------------------------------+-------------------------------------------+
+------------------------------------------------------------------------------+
| UNIT : GP1B |
+------------------------------------------------------------------------------+
| RJ GROUP: RJP2 START AUTH.(AM): Y STATUS (RTO): NDEF |
| PAUSE (S): 3600 START (HH) : 16 STOP (HH) : 17 |
+----------------------------------+-------------------------------------------+
| ROUTINE JOB | START FREQUENCY |
+----------------------------------+-------------------------------------------+
| CIRA | 2 |
| CIRAENDA | 2 |
+----------------------------------+-------------------------------------------+

AMO-FUNSU-111 SYSTEM SWITCHES OF SWU
DISPLAY COMPLETED;
<

<DISPLAY-FUNSU:UNIT=BPA&BPB&CC&LTG&SWU&GP1A&GP1B,COMPLEX=RJGRP,RJGRP=RJP2;
DISPLAY-FUNSU:UNIT=BPA&BPB&CC&LTG&SWU&GP1A&GP1B,COMPLEX=RJGRP,RJGRP=RJP2;
H500: AMO FUNSU STARTED
+---------+-------------+----------+-------------+
| | | | |
| UNIT | RJ GROUP |START AUTH| STATUS |
| | | (AM) | (RTO) |
+---------+-------------+----------+-------------+
| BPA | RJP2 | Y | NOT ALLOWED |
+---------+-------------+----------+-------------+
| BPB | RJP2 | Y | NDEF |
+---------+-------------+----------+-------------+
| GP1A | RJP2 | Y | NDEF |
+---------+-------------+----------+-------------+
| GP1B | RJP2 | Y | NDEF |
+---------+-------------+----------+-------------+

AMO-FUNSU-111 SYSTEM SWITCHES OF SWU
DISPLAY COMPLETED;

Hopefully it'll work out for you (and the hotel guests !) - let us know how you get on

I think that looks OK. For UNIT you could specify SWU, but RJP2 is the right group, I think it will be CIRA causing your problem. Default is 0:00-4:00am though, 4 hours, and you have dropped it to 1 hour, but better than turning it off I suppose.

Thanks sbcsu and Moriendi for affirming my ideas and giving me confidence in resolving this issue. I will coordinate with the customer to schedule a suitable time for the modifications and observe if they are effective. I will provide feedback on the outcome once it is addressed. Once again, I sincerely appreciate your patient guidance throughout this process.

You will need exec-funsu:swu; after the change to have the task read the new values. It does not cause an outage.

Hi，Moriendi
Thank you for the reminder. Otherwise, I wouldn't have known about executing this command either.