Waterbed energy saver

My assumption is that I can save energy if I turn off the heating of my waterbed during daytime, when the bed is not used. Since the temperature difference beween bed and room decreases, less heat is leaving the bed. Of course the heating should be re-actived early enough to return to a convenient temperature at end of day.
My assumption is that I can save energy if I turn off the heating of my waterbed during daytime, when the bed is not used. Since the temperature difference beween bed and room decreases, less heat is leaving the bed. Of course the heating should be re-actived early enough to return to a convenient temperature at end of day. First phase is to confirm this assumption with data loggers and experiments. This should also include a rough estimation of achievable savings. Second part (if first part is confirmed) would be the implementation of a predictive controller with various options, e.g. sickness detection, vacation mode. For both steps I would like to use the Elektor-Linux-Board ("gnublin"). It has all IO types, is easy to program, and is energy efficient. I do not plan to replace the built-in thermostat with this controller unless some findings suggest it.
Update 2013-01-13:
Tried to log heating activity with a Gnublin (Elektor version) and two IOs.
1) Thermo sensor (one of those sensors that come with PC motherboards) with 10kOhm pullup connected to the ADC. Problem: ADC range seems to be 0 ... 1.7V instead of 0 ... 3.3V. Solution: my Gnublin has a wrong resistor soldered as R19. Adding 10 Ohm in prallel to the (incorrect) 10kOhm now gives me full range and more stable measurements.
2) A simple phototransistor BPW17 with pullup connected to a digital input. On first tests this worked pretty well to "see" the original thermostat's inidicator light. On a closer look the transistor is too fast. Since this indicator is driven from AC, my polling sometimes sees a dark indicator, although it is lit (polling exactly when AC passes 0V).
I see two ways to solve this: with interrupt-driven IO instead of polling, I would get notified of every bright measurement, then start a 20ms software delay. Since Gnublin interrupt-driven IO is not working yet, I could also do this in hardware: add a retriggerable monoflop (74LS123) with a pulse length of slightly >20ms between phototransistor and IO pin.
Either one is required for correct measurements of heating activity and thus valid logs. What I already saw from the logs is that temperature changes are very minimal. I might need higher presision temperature measurements.
Update 2013-10-06:
After a long time without any visible activity, here's an update.
I spent quite some time with different defficiencies of Gnublin. It now seems usable. ADC issues are fixed. I found a workaround for the on-board power regulator's ripple (up to 10%!), and interrupt-driven IO now works on my 8MB version.
Finally I get acceptable, relative temperature measurements and can detect the indicator lamp of the thermostat, which is a gas discharge lamp with short flashes!
Next step will be to update my gpio library for Gnublin to support interrupt-driven IO.
Update 2013-10-19:
The logging can start ...
Discussie (3 opmerking(en))
DE205929 11 jaar geleden
My gnublin now supports interrupt-driven GPIO.
This requires a current Gnublin distribution on a gnublin-elektor or better (8MB is ok!).
My approach is now to have a photo-transistor conntected to an interrupt-enabled input. The short flashes of the gas discharge lamp trigger interrupts and therefore will be detected, no matter how short they are. Well, within reasonable limits :-)
As long as I polled the input, it was pure luck to read the input while the lamp was bright. The flases are in the range of several microseconds with a frequency of 100 Hz (line frequency times two). Even reading in a loop for several seconds was unrealiable.
Bobbylebob 11 jaar geleden
Hi,
Instead of adding a monoflop to filter your phototransistor's signal, I would suggest to poll it at a frequency which is not a multiple of 50Hz. (Lets say 8Hz). You acquire 5 samples and check :
If all are 1 : thermostat's indicator is off
If all are 0 : thermostat's indicator is on
If 1 and 0 are mixed : thermostat's indicator is considered on.
You may have a small delay added if acquisition occurs just on indicator going off (0 and 1 mixed), but it will be confirmed on the next acquisition (1 only)
.David.
ClemensValens 12 jaar geleden
DE205929 12 jaar geleden
DE205929 11 jaar geleden
... I think it goes without saying: of course do I look for assistance and fruitful discussions. Otherwise I would not post this idea here.
I am German, therefore: wir können auch Deutsch reden, wenn das jemand leichter fällt.
DE205929 12 jaar geleden
Andreas Schölver 12 jaar geleden