At integration loading (restart HA) the integration sometimes pulls 0.0 for rx_bytes sensors (and corresponding data_usage sensors)

[Shariner]

At integration loading (e.g. restart HA) the integration sometimes pulls 0.0 for rx_bytes sensors (and corresponding data_usage sensors)

This issue is addressed in the next pull request.

To fix these statistic data issues for the past you have to repair the database.

For example mariadb:

UPDATE states
SET state = 'unavailable'
WHERE state = '0.0'
  AND metadata_id IN (
    SELECT metadata_id
    FROM states_meta
    WHERE entity_id IN ('sensor.monthly_rx_gb', 'sensor.monthly_tx_gb', 'sensor.monthly_usage')
  );

SQL command tested.

[Shariner]

Ah: After the next pull request, the data_left sensor will not having these spikes to the set up data contigent anymore, but you also need to fix the database, just change the corresponding sql command. You can work this out for yourself, you just need to set all values to unavailable which have your "max data" value. at my case: 200GB

[MiG-41]

This is probably general problem with connection or read data , since all sensors are not updated sometimes. Here is examples from 4 entities from 1h , black spaces means that it was no data read ,and it correspond to 0.0 read from i.e. Monthly TX GB:

So it should be some verification/ reapeated read or whatever ,before updating entities , instead @Shariner is making some workorounds for onlt few entities....

[Shariner]

This is probably general problem with connection or read data , since all sensors are not updated sometimes. Here is examples from 4 entities from 1h , black spaces means that it was no data read ,and it correspond to 0.0 read from i.e. Monthly TX GB:

So it should be some verification/ reapeated read or whatever ,before updating entities , instead @Shariner is making some workorounds for onlt few entities....

Everyone can participate in this project, feel free. I am aware of this but couldn't find the correct entry point for this yet, because the sensors are created all in the same way by directly linking the read data to the sensor. The custom sensore offer more options.

As i needed the correct data i made a quick solution for this and also the correct commands to fix the database later, if alle issues are corrected.

[Kajkac]

I will look at it, i did some fixes before for this part and its mainly coz sometimes script dont get data or python comand to get data failed(its not perfect solution) but thats on zte coz it doesnt have proper api, so need to see how to preserve state and implement retry and not read 0, currently i am litle busy at work so i didnt have time to look at it, but i will try to implement some workarounds on integration itself

[Kajkac]

I push out new release which includes retry for getting the sensor data, in my debug logs i see often that on restart or sometimes script failed to get data, so i implement 3 times retry, i hope this can solve intermitent data on sensors. I will leave it for today to see if sensors get any 0.00 data.

[MiG-41]

Still noticing "gaps"

EDIT.... But this retry implementation do also some job , since in logs i can see "Attempt 1 failed with error: Command '['python3', '/config/custom_components/zte_router/mc.py', '192.168.24.1', '*****', '7']' returned non-zero exit status 1.. Retrying in 2 seconds..." , and it is apeard 79 times within 2,5h work.... "Attempt 2 ..." i don't have.

So looks like there is still something more , that even login is ok , read can be fail.

[MiG-41]

On 1.0.17 similar , random gaps:

[Kajkac]

Can you try with version 18, i think situation is much better at least on my router

Update: i cant see any gaps for now

[MiG-41]

Yes , now it is ok.