Debugging a Fridge

No, I am not referring to some new IoT wifi smart fridge of the future. As a Software Engineer, I like applying the same problem solving techniques I use in my day job to other domains – like fixing fridges!

Recently, our fridge started giving problems – it just never cooled down and kept running. The first suspect was the door rubber seals. The door seemed to have drooped slightly over the years, but the seals were ok.

Next, I checked the ventilation. I threw out some preserves that were old and moldy and repacked everything to assist the air flow. I places a thermometer inside so I could monitor improvements.

The fridge purge didn’t have much effect. Then I realized something – because of the door drooping slightly, the switch that controls the interior fridge light was no longer triggered when the door closed because it is mounted above the door.

But why would the light switch affect the cooling of the fridge? I figured that modern, energy efficient fridges would likely want to disable the interior fan that circulates cold air inside the fridge when the door opens, preventing the cold air from escaping.

A quick test by taping the switch in closed position confirmed that this was indeed the problem.

I attached a small spacer to the top of the door with double sided tape to accommodate for the door droop so that the switch is once again triggered when the door closes.

For now, the fix will do. Time to start saving for a new IoT wifi smart fridge! 😀

The Biggest Python Trap!

If I had a Dollar for every hour I’ve wasted debugging this issue in Python, I’d be … uhh… well a little more well off than I am now.

The way that Python handles modules is fantastic, but sometimes if you don’t pay attention, you can end up wasting time debugging an issue when the error message leads you down the wrong path.

Often – and this blog is probably more a reminder for myself than anyone else – I create small test scripts to play around with new modules. In the most recent example, I started experimenting with Kivy – the Python UI library.

I created a script called “kivy.py” and copied the hello world example code and ran it.

Traceback (most recent call last):
  File "kivy.py", line 1, in <module>
    from kivy.app import App
  File "C:\Python\hal\kivy.py", line 1, in <module>
    from kivy.app import App
ModuleNotFoundError: No module named 'kivy.app'; 'kivy' is not a package

Of course, the first thought is that the module was not properly installed. It could take some time (as is usually the case with me) to realize that the actual problem is that I named the test script (kivy.py) the same as the module I am trying to import:


from kivy.app import App
from kivy.uix.button import Button

class TestApp(App):
    def build(self):
        return Button(text='Hello World')

TestApp().run()

Silly, silly mistake, but somehow I do this ALL THE TIME. I think it’s time to start naming my scripts “trying_out_kivy.py” or something 😀

ESP-12 not waking from deep sleep

I recently spent a lot of time trying to get the deep sleep functionality on my ESP-12 working – whenever the ESP went into deep sleep, it would not wake up again after the delay had passed. If I had a serial session open via my CP2102 USB to serial converter, I would get some garbled characters back from the ESP as soon as it woke up. Also, with a multimeter connected, the current draw would go up from a few microamps in deep sleep to a current of around 600mA as it woke up, but without booting up normally. Eventually, I accidentally fixed it by removing a pull up connection that was clearly causing the problem…

2016-04-16 22.38.22

The module I have is labelled as a ESP-12-E, but the CH_PD pin usually found on the ESP-12-E is labelled as EN instead (I’m not sure if this makes it a ESP-12-Q instead?)

Most threads recommend the following connections to enable proper deep sleep operation of the ESP:

– GPIO0 -> 4k7 resistor -> VCC (to avoid “Zombie mode”)
– GPIO2 -> 4k7 resistor -> VCC (to avoid “Zombie mode”)
– GPIO15 -> 4.7k resistor -> Ground
– CH_PD / EN -> 4k7 resistor -> VCC (needed for start-up)
– GPIO16 -> RST -> 4.7k resistor -> VCC (to enable deep sleep)

However, this caused the above symptoms for my ESP. It was only when I accidentally removed the pull up connection to RST that I realized how to get my ESP module to wake up from deep sleep properly. The following wiring now works for me:

– GPIO0 -> 4k7 resistor -> VCC
– GPIO2 -> 4k7 resistor -> VCC
– GPIO15 -> 4.7k resistor -> Ground
– CH_PD / EN -> RST
– GPIO16 -> RST

Effectively, neither GPIO16, CH_PD / EN or RST are now connected to VCC via pull-up resistor. I am not sure why this wiring works, but it does and hopefully it will save someone else a few hours too!