Open sezlony opened 2 years ago
Hello, @sezlony,
Thanks for your feedback! 👍🏻
No, this is not how the boot time should look like. If you put your cursor over the timeslot in the history, you will see the value at a specific time. Are the values every hour different for an hour?
Example of the usual history with a device being rebooted much too regularly in comparison to the average one (due to the testing purposes):
Does your router really reboot as regularly as it looks from your history? You can check the last boot time from the log in the device web admin panel.
Does any other sensor of the integration have similar problems? If the device really reboots, any of the traffic sensors (e.g. sensor.{}_wan_download
/ sensor.{}_wan_upload
and others, where {}
should be changed to your device prefix) should reset to zero.
P.S. List of compatible devices only includes those, reported by the users or tested by me to work. Other devices should work as well (with some limitations for the oldest firmware). Boot time is available for all the models even on the older firmware like 3.0.0.4.382, so the problem you are experiencing is really unusual.
I'll try to answer your questions one by one :)
Are the values every hour different for an hour? yes, the history shows (almost) exactly 60 mins (60 mins 1 sec to be precise)
Does your router really reboot as regularly as it looks from your history? no, routers own log has not recorded any restarts, in fact uptime is 3 days 20 hours now
Does any other sensor of the integration have similar problems? no, none of the other sensors show unusual behaviour, all seems normal
did that help by any means?
We can definitely narrow the search down now. Since the device doesn't reboot and other sensors are fine, probably something is not correct with the value parsed from the device API.
Could you please log into the web panel and then go to the my.router.address/ajax_status.xml
(use the correct IP/hostname of your device instead of my.router.address
). It will be the XML with the devicemap. You are looking for the string similar to this:
<sys>uptimeStr=Wed, 29 Jun 2022 21:03:56 +0200(1212437 secs since boot)</sys>
Please, copy it here. Is it the correct one with the real device boot time/time delta? Or one similar to what the integration is showing?
here come the data:
<sys>uptimeStr=Wed, 29 Jun 2022 21:26:51 +0200(338228 secs since boot)</sys>
and here is a screenshot of the actual uptime data in the common log: (translation: Uptime 3 days 21 hours 59 mins 47 secs)
there does not seem to be a difference between these two data (btw. I use some khm peer-to-peer file transfer service which never gets interrupted)
Strange... The format is exactly as it is for any device.
I suppose there is nothing in the HA log at the warning
or error
level from the integration?
Also, did you try reloading the integration completely? You can do it from the Integrations page in HA - press 3 dots (menu) - Reload. Would it be the same?
Reload probably won't help, but just in case.
Meanwhile, I'll try to think about the reason behind such strange behaviour.
i only have these warnings/errors related to the asus integration:
2022-06-25 17:38:29 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration asusrouter which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2022-06-25 17:38:43 ERROR (MainThread) [homeassistant.setup] Unable to prepare setup for platform asusrouter.light: Platform not found (cannot import name 'ColorMode' from 'homeassistant.components.light' (/usr/src/homeassistant/homeassistant/components/light/__init__.py)).
2022-06-25 23:21:13 WARNING (MainThread) [asusrouter.connection] Connection refused. Endpoint: appGet.cgi. Payload: hook=cpu_usage(appobj);memory_usage(appobj);netdev(appobj);wanlink_state(appobj);.
2022-06-28 22:07:52 WARNING (MainThread) [asusrouter.connection] Connection refused. Endpoint: ajax_ethernet_ports.asp. Payload: .
2022-06-28 22:07:52 WARNING (MainThread) [asusrouter.connection] Connection refused. Endpoint: appGet.cgi. Payload: hook=cpu_usage(appobj);memory_usage(appobj);netdev(appobj);wanlink_state(appobj);.
2022-06-29 22:42:32 WARNING (MainThread) [asusrouter.connection] Connection refused. Endpoint: ajax_ethernet_ports.asp. Payload: .
they seem to be harmless, no other clue what is happening :(
EDIT: as predicted by you reloading the integration did not help also!
EDIT #2: I just realized it's even worse, reload makes the integration inperable, the complete integration is unavailable after reload
Hello,
Did you try any of the newer versions of the integration (0.8.0 would be the best, as the latest one)? Do you still have this bug with the boot time?
HACS doesn't indicate any new versions for me, I assume it's because I'm stuck on core version 2022.4.0... :(
However it would be great to know if the issues are gone, but I don't feel the urge the update HA as everything else works fine.
Oh, yes. Unfortunately, version 0.6.0+ of AsusRouter requires HA 2022.5+. That is because of some deprecated HA constants, which should not be used anymore starting from this HA version, and are changed to the new ones (used in the integration from 0.6.0 on).
Backward compatibility is not working really well for custom components with Home Assistant's love for changing things each release.
If you will be updating, please let me know whether the bug is solved. I will leave the issue open.
well... I just couldn't fight against my curiosity and updated everything to the latest version
sadly this integration still has this visual problem, although I should wait longer to let things settle
Ok. I will prepare some python code which you may try to test with your device and let you know. Thanks for the updated info! :+1:
big respect sir 🙌
I'm still stuck with this f_ckin rainbow... 😢
do you think there will be any updates on this?
Hi,
Sorry for taking so long. I still didn't figure it, how to fix this problem for you.
But, by the end of December, I am planning to add other API endpoints and one of them also has boot time data - I hope taking the data from there will fix the issue.
I just found something interesting: looking at CPU history data it shows the same pattern, there is a strange "hiccup" in the connection and it appears the router does this reset (or whatever) hourly, with a 30 sec pause
so this may be a programmed something in the firmware (operating as expected) or a bug, but rather in the router and not in the integration
as no other people reported this behavior I'm more and more convinced, that this is a specific case, I don't know how to handle...
This is a really weird bug in such a case. Did you try resetting your device fully? I know that this is a headache, but might help. Especially if the device is actually restarting each hour - that does not seem to be good for a network
I'm rather willing to replace this sh!t, than reconfigure from scratch 😆
btw it's surely not restarting because it's still accessible even when HA reports connection lost 😕
I can imagine. With an even medium-sized local network, there is a lot of trouble to make sure everything works. If the network is larger, that might take a ridiculous amount of time.
In principle, with such a periodicity, there might be something in the device log itself
wow, I've just discovered, the history looks almost the same in the case of my truenas server! what the f* this could be???
The problem
first of all I don't really know if it's really a bug or not, because AC1200G+ isn't even listed as compatible...
looking at history, the "graph" of boot time enity is like a rainbow, meaning the router restarts every hour
is that possible (a bug maybe in the integration) or just a consequence of incompatibility?
?
Your device model
RT-AC1200G+
Firmware type
Stock
Firmware version
3.0.0.4.382.52272
Integration version with the issue
0.5.1
Method of the integration installation
HACS
What version and type of Home Assistant installation do you use
core 2022.4.0
Is there anything useful in the logs?
No response
Diagnostics information
No response
Additional information
No response