[ | Date | | | 2020-04-30 22:32 -0400 | ] |
[ | Mod. | | | 2024-11-28 15:16 -0500 | ] |
I have a small bunch of little network-connected projects at home. They were all fun to set up, but having software and hardware in “production” means handling failures in a way or another. One way is to tolerate flakiness, when bearable, another is to increase robustness.
Setup: Adafruit 24-segment bi-color bargraph display, I²C on Raspberry Pi, display-side REST server a simple Python program waiting for numbers getting pushed to it by machine that has network interface to monitor. Number-pushing service is handled by supervisord.
Failure modes:
I discarded the device after perhaps four years of use, because the LEDs had become dim by then, and replacing it did not seem worth the price of more than USD10 when larger, 32x8 matrix displays are readily available for about CAD10 all-included.
Setup: ESP8266, DHT22 temperature and humidity sensor, optional I²C OLED display.
Failure modes:
Datapoints are sometimes lost. At the moment, the device builds five-minute summaries of measurements, with attempts to retrieve the latest one every minute. This should be made more robust against extended network flakiness by retaining more than one chunk of data, and letting the client specify how far back it wants to go.
Sometimes, devices get off the Wi-Fi network, and don’t automatically reconnect, needing a reset, upon which they immediately reconnect successfully.
I have not yet investigated the reasons, and whether the sotware could be improved to automatically recover from this condition. In particular, the device is aware that it is off Wi-Fi; I can tell because those that have a display attached mention it. It is surprising that the built-in Wi-Fi library apparently does not try reconnecting eternally; reading its source code could help understanding what happens.
Setup: off-the-shelf smart plugs and smart switches, cron jobs on a local machine.
Failure modes:
Setup: ESP8266, relay module controlled by separate power supply, off-the-shelf smart plug.
Failure modes:
Exceptionally, the UDP command doesn’t make it from the ESP8266 to the smart plug, requiring two togglings to fix;
Sometimes the light turns on for a split second and then off again. I can’t tell for sure whether the repeater is to blame, since it doesn’t emit any kind of logs.
Setup: ESP8266, PIR motion sensor.
Failure modes:
The light being controlled turns on for no good reason from time to time, perhaps because of vibration or temperature changes in the nearby furnace;
rarely, the light does not get turned off after the on period has elapsed, probably because of a lost UDP message.
This has worked fine for months, requiring no maintenance; the only glitch:
Later:
Same failure modes as for the clock; plus
sometimes responses from Kodi come slowly, resulting in minor flashing of the display (as, for example, time displayed goes backward for a fraction of a second).
Occasionally, the display part would stop properly communicating with the ESP8266-based computer.
Quick links: