Sometimes you can’t do anything about cpe bugs, asking help to the vendor is not an option. I haven’t found anything in genieacs that enabled dealing with cpe faults, so I made my own provision function to do this.
This function prevents a fault from being recorded and messing up with the channels. It’s called expectFault, it takes 2 arguments the first being the fault_code and the second a function for the faulty command(s) you are trying to run.
Exemple usage:
expectFault('session_terminated', () => {
log('Enabling IPV6')
declare("InternetGatewayDevice.WANDevice.1.WANConnectionDevice.*.WANPPPConnection.1.X_HW_IPv6Enable", {path: now, value: now}, {value: true});
});
The fault will still appear in the logs with an “Expected fault” message.
Is there any interest in adding this function to the main release?
I know it’s not the same thing you are talking about but we handle faults externally. I have a single bash task querying the ACS ever few minutes for faults via API (among other things). If there’s at least one, it clear the faults, extract the devid from the list obtained from the first query then do a Connection Request directly to the CPE. If it’s offline it’s OK (probably there’s a tech on site working on it). If it’s not the it has the chance to complete whatever is left to do at the provision level.
I have the OK from my boss to share anything related to the ACS, so later I will make a thread about the subject in case someone finds it useful.
I just let the faults stay. They usually clear up automatically when the CPE next informs. Has that not been your experience?
(sry for the offtopic)
Honestly I haven’t tested specifically that. What I saw at the time (ver 1.2.4) was the fact that some CPE could not get the provision and clearing the faults was the way to fix it. My criteria is to have periodic inform disabled. If I need a CPE I call it. Reason behind this: customer support does not like to wait, same for customer on the phone.
