2.5.1 and before, extreme delay and unstable Hub when many devices connected and active update question option in the Settings. #103
Comments
|
I found one Issue with Battery Level Update, some Sensors are not present the Battery State. Update for sensor.battery_percentage_13 fails |
|
Would u try 2.5.2 and let me know if the status of the outlet is updated as I took out polling. It should be much faster. Also for the above a full log would help |
|
Sorry I'm a bit clumsy with HAS, where can I find the complete debug log for your integration. For the other integrations I find an option under system / protocols at the top right, but unfortunately dirigera addon does not appear there. Does it then write the things to the system log? |
|
Just read here https://github.com/sanjoyg/dirigera_platform/wiki/Calling-dump_data-to-dump-the-JSON (the part of enabling debugging) |
|
Thank you, my system answer with error Code |
|
Traceback (most recent call last): |
|
You dont need to call the service call, just enable debug and u should see the logs in the system log |
|
Hy, my feeling is that it's much better than before. I noticed through the log that I also had my own problem. Due to the reconnection, a few sensors were not yet available in HAS, so it is possible that such ghost devices are then repeatedly requested from the hub and thus generate additional load. Or does the integration only ask for a limited amount and then deactivates the entities that were not found. I still see an error in the log, something with the time zone, is it a problem with my system or with the integration? But thank you very much, you are the best, the integration is great. Due to the IPv6 and mDNS issues, Matter is not really mature enough to easily work with it in complex networks. |
|
please paste error log for the error u mentioned |
|
s6-rc: info: service s6rc-oneshot-runner successfully started |
|
Doesnt seem to be from this integration. Can you please test to see that the outlet status is reflected quickly. Also let me know other devices you have, you could help with status updates for some others too |
|
I also checked all of these icons exist, have to do little more debug |
|
I think you did a good job, everything is still happening without delay and very quickly. I have all Senors from ikea then was exist. Currently i think the Updates are fast enough. |
|
I have check the water leak sensor BADRIN. |
|
The PARASOLL the same <1sec delay. |
|
Hy, i have detect a issue with automations. And without comes a error message when i save Message malformed: Integration '' not found |
|
can you forward me the logs |
|
Hy, my logs. and with debug and reload the integration |
|
Please try it now, should be fixed |
|
Hy, the Automation Issue is not solved. |
|
This will take some rounds of debugging, please try the latest release |
|
the log is not uploaded properly |
|
Please try release 2.6.3 |
|
Hy, i try it. No available Action on device are Available |
|
home-assistant_2024-11-07T10-11-23.556Z.log Hy a, new Log. |
|
LEts see if the news release 2.6.4 solves it for u |
|
home-assistant_dirigera_platform_2024-11-08T11-23-19.700Z.log Hy, sorry the Triggers on Light Device is still not available. |
|
Sorry I dont understand what is meant be triggers on Light Device are not
available?
…On Fri, Nov 8, 2024 at 4:59 PM vvbasti ***@***.***> wrote:
home-assistant_dirigera_platform_2024-11-08T11-23-19.700Z.log
<https://github.com/user-attachments/files/17677797/home-assistant_dirigera_platform_2024-11-08T11-23-19.700Z.log>
Hy, sorry the Triggers on Light Device is still not available.
The Performance Issue from Integration Connections is solved, no issues
after your fix.
—
Reply to this email directly, view it on GitHub
<#103 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB2X3CTQQPOGCDHGSVKKG2LZ7SOBLAVCNFSM6AAAAABREEM7YCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRUGQ3TKNBUG4>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Here a example with controlled device, a light device normal deliver the trigger on, off, change |
|
please provide the dump json to debug |
|
description: ""
The Device data not Fill when no trigger is selectet |
|
Here the normal Trigger list for a E27 Bulb
And when select a Trigger the device Data was filled description: ""
|
|
sorry I meant the dump of the entire device set, the link is in the readme on how to generate the dump |
|
Hy, i Have a Second HUB, the Productive System has to Many Devices and heavy large Logs, i set Up a LAB Enviroment for you. Here the log from Productive |
|
These are lightControllers, they dont publish hub events unfortunately. |
|
2024-11-12 13:22:36.732 INFO (SyncWorker_0) [custom_components.dirigera_platform] === START Devices JSON === |
|
Hy, I now have a complete LAB setup so that I can test things better in the future without my family exposing me to jungle (-; I probably have a problem understanding it, because it works perfectly with the old 1.8.4, so it must be due to the changes. I just installed the old version and it works immediately.
2024-11-12 13:31:29.055 INFO (SyncWorker_2) [custom_components.dirigera_platform] === START Devices JSON === |
|
Addendum, I tested all versions, 1.8.9 is the last one in which it works, after that a change probably caused the problem. |
|
Its possible to bring this Feature back, or is this extreme strong in the new code > 2.x Best regards from Germany |
|
I compared it with the matter integration, here the trigger works and you can select it on the devices. But I don't want to switch to matter, I think their integration is better, matter doesn't handle the sensors well. Do you see a way to bring the function back? |
I've had this problem for a long time that the integration is hindering the HUB, commands are only executed after 10 seconds or not at all. It is very noticeable when turning on lights from the Ikea APP, they change to on in the app but are not on, then after 2-3 seconds they change back to off in the display. After a long time > 5 seconds they are actually switched on.
I suspect it is due to the frequent update requests from the sensors. Could this cycle possibly be made configurable? so that the hub is not put under as much strain on many devices. It is reproducible, if I deactivate the integration the response time returns to normal immediately.
Which debug logs can I contribute to further analysis?
The text was updated successfully, but these errors were encountered: