1

I have a number of pending updates on my raspberry pi. Until I take a day to perform all those updates, I'm sitting at pilight version v8.1.5. Updating may potentially solve my ultimate problem, but until then, I'm dealing with about a once daily issue where pilight just silently stops working.

By "silently stops working", I mean, I issue any pilight-send command and no signal is sent and no error is printed or logged (that I can find). Going by the command line, you wouldn't think there's any issue at all except for the fact that the device being controlled doesn't change states. Whenever this happens, it's usually hours before I find out there's an issue. My automations don't work. I can't turn on/off any devices plugged into my 433Mhz outlets.

Restarting pilight with:

sudo service pilight restart

Always resolves the issue. Things start working again. It's such a frequent occurrence, I set up a "button" in the home app to restart pilight.

When there is an issue, the restart takes 20s-1m. When there is not an issue, the restart cycles in a second or so.

I tried setting up a nightly restart of pilight in order to try and head-off the issue, but it still seems to happen roughly once a day, sometimes twice, and sometimes it will go days without any issue.

Side note: A couple years ago, I disabled pilight's ability to receive because, due to background noise, it would cause my pi to run hot. Disabling pilight's ability to receive signals 100% resolved that issue.

What I would like is for some way to immediately catch when pilight stops working so that I can automatically restart it.

I realize that it would be better to solve the underlying problem, but until I'm running the latest version of pilight, it seems like working on that would be a waste. For now, it would just be nice to detect the problem faster.

hepcat72
  • 175
  • 6
  • 1
    Sorry about your plight with plight ! Until you fix either pilight or one of the drivers/plugins/modules that pilight uses, you're probably stuck. Perhaps you could also try rebooting/resetting the entire pi nightly, instead of just the service. – kalyanswaroop Jan 09 '24 at 16:09
  • Try issuing a command, then immediately checking to see if the command has executed. If so, it's functioning, if not, restart pilight. How you'd go about doing so is an exercise left to the reader (mostly because I haven't a clue what pilight is. ;) – FreeMan Jan 10 '24 at 17:44
  • @FreeMan, As mentioned in the post, the command executes without any indication of a problem. I also indicated that I wanted to "detect" the problem, I.e. automatically... so that when I try to turn on/off one of the outlets, it's more likely to always work. – hepcat72 Jan 10 '24 at 18:27
  • 1
    @kalyanswaroop. Thanks. I fear that's likely true. I was hoping someone knew some clever way to detect the problem. I would do a reboot, but I've let versions stagnate for too long and node-red no longer works with pm2. Might be a misconfig. I have to manually start it anytime I reboot these days. I have a lot of put off maintenance. Besides, based on the pattern, I don't think the intermittent failure is based on uptime. – hepcat72 Jan 10 '24 at 18:32
  • I got that part. I was thinking along the lines of: turn off living room light, delay 2 seconds, if living room light is on, send notification. Don't know if that can be done in pilight, hence comment, not answer. – FreeMan Jan 10 '24 at 18:33
  • No, it's one-way communication. If I hadn't disabled receive, the receiver chip might be able to detect the transmission from the transmitter chip on the breadboard, which would suffice, but as I mentioned, that frequently overheats the pi from the processing of background RF. – hepcat72 Jan 10 '24 at 18:36
  • program pilight to toggle a GPIO pin once a second ... connect an LED – jsotola Jan 11 '24 at 01:44
  • What happens if you restart the service everytime, as the first step in each automation sequence ? – kalyanswaroop Jan 11 '24 at 16:58
  • In the documentation, there is mention of a heartbeat command. It seems to help check connectivity issues. – kalyanswaroop Jan 11 '24 at 17:11
  • @jsotola - Interesting idea, though I don't know how that would lead to an automatic solution. Besides, I think my breadboard is full (though I could remove the receiver chip, I guess, but I like the fact that it would be easy to enable when I need to record an RF code, so I occasionally turn it on to be able to do that). – hepcat72 Jan 12 '24 at 14:47
  • Great insights/ideas @kalyanswaroop! I will explore those options, thanks! – hepcat72 Jan 12 '24 at 14:48
  • The definition of the heartbeat in the documentation apparently depends a lot on the context in which it sits in the documentation. I haven't read the full text, but my sense is that this pertains to checking the status of specific devices and it involves the receiver chip. I don't think it is meant to check the operation of the daemon. I don't have any devices with a supported protocol (I always use the RAW send protocol) or else I might be able to use it to infer the functioning state of the daemon. It was a good idea though. So I will explore the restart every time option... – hepcat72 Jan 12 '24 at 15:52
  • @hepcat72 ... I don't know how that would lead to an automatic solution ... if the GPIO can blink an LED, then it can also feed an external watchdog timer hardware – jsotola Jan 13 '24 at 00:52

0 Answers0