01-27-2020, 08:33 PM
Hi,
I use pilight in conjunction with homebridge to be able to control some Etekcity RF outlets via Siri. I use the pilight-send command with raw codes to send signals to those outlets since there is no Etekcity "plugin". I don't really use the receiver except in pilight-debug to record the codes of various remotes. I maintain outlet state outside of pilight using a script that executes the send commands.
My overall problem is that often, I have to issue commands twice because Siri complains that my device isn't responding and I frequently see the "No response" state on all devices in the home app. With this in mind, I think that my expereince of the following might be a clue as to the cause of these things...
I logged into my pi yesterday to edit a config file and noticed significant slowness when just trying to move the cursor around in vi. I exited and checked `top` and I noted that `pilight-daemon` took up to 50% cpu. It hovered anywhere between 25-50%, but never went lower than that. The second item in `top` was `top`, using at most, 11%. I checked the cpu temp and it was fine - no warnings.
I also noted during that slowness that I had to issue commands to Siri twice and the "No response" message in the home app was showing up and going away intermittently.
I don't know if the cpu usage of pilight was the reason for the noticeable slowness, but I did some reading and inferred that this usage may be due to the processing of signals being received. Whether or not that's the case, I wondered whether there was something I could do to reduce the cpu load of pilight.
I found a mention of using a filter, but I couldn't find anything in the documentation on how to implement filtering. I saw something else suggesting it might be a physical filter? I also very briefly looked into the possibility of disabling the receiver in pilight before getting distracted with other items in my to-do list.
1. Is my understanding of the cause of the cpu usage correct?
2. If so, can I or how do I disable the receiver - and will that reduce the cpu load?
I use pilight in conjunction with homebridge to be able to control some Etekcity RF outlets via Siri. I use the pilight-send command with raw codes to send signals to those outlets since there is no Etekcity "plugin". I don't really use the receiver except in pilight-debug to record the codes of various remotes. I maintain outlet state outside of pilight using a script that executes the send commands.
My overall problem is that often, I have to issue commands twice because Siri complains that my device isn't responding and I frequently see the "No response" state on all devices in the home app. With this in mind, I think that my expereince of the following might be a clue as to the cause of these things...
I logged into my pi yesterday to edit a config file and noticed significant slowness when just trying to move the cursor around in vi. I exited and checked `top` and I noted that `pilight-daemon` took up to 50% cpu. It hovered anywhere between 25-50%, but never went lower than that. The second item in `top` was `top`, using at most, 11%. I checked the cpu temp and it was fine - no warnings.
I also noted during that slowness that I had to issue commands to Siri twice and the "No response" message in the home app was showing up and going away intermittently.
I don't know if the cpu usage of pilight was the reason for the noticeable slowness, but I did some reading and inferred that this usage may be due to the processing of signals being received. Whether or not that's the case, I wondered whether there was something I could do to reduce the cpu load of pilight.
I found a mention of using a filter, but I couldn't find anything in the documentation on how to implement filtering. I saw something else suggesting it might be a physical filter? I also very briefly looked into the possibility of disabling the receiver in pilight before getting distracted with other items in my to-do list.
1. Is my understanding of the cause of the cpu usage correct?
2. If so, can I or how do I disable the receiver - and will that reduce the cpu load?
