Add-on hangs Up and starts Big CPU consuption

[brubakers]

trafficstars

Add-on hangs Up every day it stops working and starts to consume 26% of muy CPU power. If i restart it, everything works ok til Next day.

[egelinotte]

I have the same issue. Even reaches 40% of CPU. And yes it stops working every day even if the service seems to be still running. @fmartinou any idea ?

[brubakers]

Take a look at tydom app. It is very possible that you have a pending update of your tydom box. It seems that i solve the problem 3 days algo. I havent post it yet cos its very soon, but for me, since the update, it work.

[egelinotte]

Ok. I will try. You are right, I have a pending update. I did not do it on purpose as I thought it would make it worse as it seems that this update has big things.

[fmartinou]

Hi,

I'm aware of that high cpu usage problem; I don't known yet where it comes from. Unfortunately, these days I have absolute no time to investigate so don't put too high expectations on me :/

[egelinotte]

In the meantime and until we have a bug fix, how can we automate a daily restart of the integration ?

[egelinotte]

The continous hang up makes this addon unusable to driver the covers. This is quite disappointing. A new version 3.2.0 was released this week and I was hoping that the bugs would be fixed. But no change. Does every have these bugs or did you find a turnaround ?

[fmartinou]

Hi,

Along with every new release there is a changelog you can read: https://fmartinou.github.io/tydom2mqtt/#/changelog/ As you can see it doesn't mention this bug so... don't expect it to be resolved ;)

Unfortunately, I don't have neither time nor enough devices to troubleshoot it so I cannot work on it right now; sorry about that.

If someone with more time or hardware is able to troubleshoot it; he's welcome 😃 .

[BlackMagik88]

I also have this problem.

I checked the code rapidly, I think we need an outer while loop in the main function to handle connection exceptions (Error 1000… etc…) rised by the websocket (and so, re-do the setup in the outer loop.

The current while loop catch all exceptions, and, if the websocket is closed, it will rise an infinite number of exceptions, leading to massive logs and cpu usage.

I didn’t try this theory for the moment, but i will do my best to check it soon.

[egelinotte]

Thanks mate. That would be great if you can solve this issue. The only solution I found is to restart the service every hour with an automation.

[r0m1CH]

I had the same issue as you guys.

[egelinotte]

With the new HA update today, there is a new warning that devices and entities name can't be the same. This issue is raised with most of the mqtttydom entities and it says that this needs to be fixed before the 2024 02 update of HA as it won't be compatible anymore. Hummm

[BlackMagik88]

I made a PR here #119 for this bug.

[BlackMagik88]

With the new HA update today, there is a new warning that devices and entities name can't be the same. This issue is raised with most of the mqtttydom entities and it says that this needs to be fixed before the 2024 02 update of HA as it won't be compatible anymore. Hummm

I saw the changelog regarding this. There is a PR here #116 which improves the naming of devices and entities, but it's only for sensors. I think we need to do the same on other types (covers, switch, light...).

Maybe you can create another issue about this improvement, so we can keep track of the progress.

[fmartinou]

Hi,

The #119 is available in the version 3.3.0; please give it a try and report here if the app is more stable or not. Thanks!

[egelinotte]

See what it says now for the entities names:

Some MQTT entities have an entity name that starts with the device name. This is not expected. To avoid a duplicate name the device name prefix is stripped of the entity name as a work-a-round. Please inform the maintainer of the software application that supplies the affected entities to fix this issue.

List of affected entities:

binary_sensor.battdefect_tydom_volet_tele binary_sensor.battdefect_tydom_volet_chambre_mylene binary_sensor.onfavpos_tydom_volet_sejour binary_sensor.onfavpos_tydom_volet_fenetre_salon binary_sensor.obstacledefect_tydom_volet_sejour sensor.position_tydom_volet_sejour binary_sensor.intrusion_tydom_volet_chambre_parent binary_sensor.battdefect_tydom_volet_fenetre_salon binary_sensor.battdefect_tydom_volet_sejour sensor.position_tydom_volet_bureau binary_sensor.obstacledefect_tydom_volet_chambre_parent binary_sensor.intrusion_tydom_volet_chambre_mylene binary_sensor.obstacledefect_tydom_volet_tele binary_sensor.thermicdefect_tydom_volet_dressing sensor.position_tydom_volet_fenetre_salon binary_sensor.obstacledefect_tydom_volet_fenetre_salon binary_sensor.intrusion_tydom_volet_dressing sensor.position_tydom_volet_chambre_mylene binary_sensor.onfavpos_tydom_sejour sensor.position_tydom_volet_cuisine binary_sensor.thermicdefect_tydom_volet_tele binary_sensor.intrusion_tydom_volet_tele binary_sensor.onfavpos_tydom_volet_bureau binary_sensor.thermicdefect_tydom_volet_fenetre_salon binary_sensor.intrusion_tydom_volet_cuisine binary_sensor.battdefect_tydom_volet_cuisine binary_sensor.intrusion_tydom_volet_canape binary_sensor.thermicdefect_tydom_volet_cuisine sensor.level_tydom_sejour sensor.position_tydom_volet_chambre_parent binary_sensor.onfavpos_tydom_volet_tele binary_sensor.obstacledefect_tydom_volet_dressing binary_sensor.thermicdefect_tydom_terrasse binary_sensor.onfavpos_tydom_volet_chambre_mylene binary_sensor.obstacledefect_tydom_volet_canape sensor.position_tydom_volet_dressing binary_sensor.thermicdefect_tydom_volet_bureau binary_sensor.thermicdefect_tydom_sejour sensor.position_tydom_volet_tele binary_sensor.battdefect_tydom_volet_dressing binary_sensor.onfavpos_tydom_terrasse sensor.position_tydom_volet_canape binary_sensor.obstacledefect_tydom_volet_cuisine binary_sensor.intrusion_tydom_volet_fenetre_salon binary_sensor.battdefect_tydom_volet_canape binary_sensor.onfavpos_tydom_volet_cuisine binary_sensor.thermicdefect_tydom_volet_chambre_mylene binary_sensor.intrusion_tydom_volet_sejour binary_sensor.thermicdefect_tydom_volet_sejour binary_sensor.battdefect_tydom_volet_chambre_parent binary_sensor.obstacledefect_tydom_volet_bureau binary_sensor.intrusion_tydom_volet_bureau binary_sensor.onfavpos_tydom_volet_dressing binary_sensor.onfavpos_tydom_volet_canape binary_sensor.battdefect_tydom_volet_bureau binary_sensor.obstacledefect_tydom_volet_chambre_mylene sensor.level_tydom_terrasse binary_sensor.thermicdefect_tydom_volet_chambre_parent binary_sensor.thermicdefect_tydom_volet_canape binary_sensor.onfavpos_tydom_volet_chambre_parent Avertissement - 04/08/2023

[fmartinou]

This warning appears with HA 2023.8.0 (see #121). I personally also have this warning for all my sensors reported by zigbee2mqtt 🤷‍♂️ . It doesn't cause any issue right now (we just have to fix the code until 2024.2.0 is released ;)

[egelinotte]

Hi, Unfortunately, the stability is still not there. Although the bug of the CPU load seems to be solved, the connection with the Tydom seems to continue to drop. I still have to reload periodically the service. The observed difference is that when the connection is dropped, the CPU load is now zero instead of 24% or higher with previous version.

[BlackMagik88]

Do you have any logs from when the connection drop ?

The fix only catch the ConnectionClose exception (which is websocket related).

[egelinotte]

Where should I look for those logs ?