${ccuNotReady}
\r\n' + '${ccuNotReadyHint}
\r\n' + 'Closed alexbde closed 1 year ago
Right after creating the issue I noticed there is a pre-release that might fix the issue 🙈
I'll test with the pre-release.
No worries, the beta should solve the problem for the homebases. Please leave this issue open, I will close it on releasing the next release, thank you.
Sadly, this is not solving the issue, because it looks like the eufy Security server is no longer starting:
The restart service
button is not working, restarting the CCU ends in the same result.
Any idea what is wrong? It is not even displaying the log information. How can I supply further information to you?
Please establish a ssh connection to your CCU and check the two logsfiles /var/log/eufySecurity.log
and /var/log/eufySecurity.err
. In your case, the eufySecurity.err
should contain the cause.
Here we go, cat /var/log/eufySecurity.err
:
${ccuNotReadyHint}
\r\n' + 'Any insights based on that log?
Just a fast shot in the dark: Have you changed something with your CCUs firewall settings or addon settings? It looks like, that the addon could not connect to port 8081 (Homematic-Script API). This is used for all the stuff regarding system variables.
The only thing I changed recently is that I uninstalled the NEO server. Not sure if this has any impact on the eufy Security addon.
I figured out, the eufy Security addon is not starting automatically after CCU restart. It is still showing this error. After hitting the restart button on the addon details page...
...the plugin is working again o.O And it is switching guard modes again! :) But this starting issue is still strange.
No, the NEO server addon has no impact on this addon. Does the error logfile contains the same error after rebooting?
The log is cleared on reboot, correct? If yes, it still contains the error:
/usr/local/addons/eufySecurity/node_modules/axios/dist/node/axios.cjs:1909
reject(new AxiosError(
^
AxiosError: Request failed with status code 503
There is another one from yesterday night:
2023-08-28 03:01:55 - Station <redacted> - All address lookup tentatives failed.
2023-08-28 03:51:58 - onSocketError Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:217:20) {
errno: -104,
code: 'ECONNRESET',
syscall: 'read'
}
Yes, the log files are cleared on reboot, because there are located in the ram.
Meanwhile, I test a solution regarding service crashing. After that, the service should in your case not crashing anymore on startup, but this will not resolve your problem. Maybe, we will get an idea where the problem is located.
The other two error entries occurring from time to time.
Please give the new v2.2.1-b5 a try. As outlined, you will receive a error message but the addon should not crash anymore.
Please give the new v2.2.1-b5 a try. As outlined, you will receive a error message but the addon should not crash anymore.
I tested and the service is no longer crashing on startup 👍 There are still the error messages as you said though:
Ok, that's good. The problem is now, that the CCU will not accepts the requests. If this occurs only after (re)start, than the service on the CCU will take some time to come up. You can try to check the CCU logs, but this might have not been related to this add-on.
Successfully tested with version 2.2.1
. Thank you very much for handling this issue short-term!
Describe the bug Since 2-3 weeks setting the guard mode (either manually or via API) is no longer working. It was working before. I first noticed using version
2.1.1
and experience the same issue after upgrading to version2.2.0
.To Reproduce Steps to reproduce the behavior:
Statusänderung
abwesend
Error occured at setGuardMode: Failed to communicate with station.
in the logAs an alternative: execute
system.Exec("curl -sS http://192.168.<redacted>:5<redacted>/setMode/schedule &");
in the CCU.Expected behavior The guard mode is set to the chosen value.
Screenshots
Desktop/Mobile Device (please complete the following information):
System.exec
CCU/RaspberryMatic (please complete the following information):
Additional context There is an additional
onSocketError Error: read ECONNRESET
in the logs, every night at around 4 am without manual interaction.