...snip...
Hard coding makes change difficult.
...snip...
If house_temp = too_hot
then open_window_3
end if
If house_temp = too_cool
then close_window_3
end if
Some where you define too_hot=93F, too_cool=65F, house_temp = ????, open_window= ?
I'm specifically talking about the logic, so your example (assuming it was written in the controller's source code) would be what I refer to as hard coding. The variables might be defined elsewhere, but if you wanted to change it to:
If house_temp = too_hot && last_rain > 2hr
then open_all_windows
end if
then you have to recompile and reflash the controller.
By using a scripting approach the code that is built into the controller would be more like:
function process_sensor_data (sensor_id, sensor_value) {
script = find_script_file (sensor_id)
execute (script, sensor_value)
}
There would then be a bunch of files somewhere (SD card, USB stick, tftp server, RAM, whatever), find_script_file searches through them until it finds one that matches the sensor_id and execute runs whatever code is in that file (and passes in the value). To completely change what a given sensor does you just replace the script file for that one sensor.
If I did decide to use scripts, I'm tossing up between implementing them on the main controller (which would be a uC), since space and processing power would be limited I was thinking a simple stack based scripting language (sort of a mixture of the PIC10F instruction set with RPN and a touch of FORTH with some high level functions thrown in); or offloading to a separate computer so that the scripts could be written in a more full featured language, like python.
I had been shying away from the separate computer option because I wanted it to be self contained, but the more I think about it the more something like a RPi seems like it might be a good fit. The function specific code (alarms, motion activated lights, etc.), stuff that is unlikely to change could be hard coded and things that might need tweaking every now and then, but aren't as critical (AV gear, sprinklers, etc.) could be handled by the PC.
I have variables that I can change by connecting a computer to the USB port. The variables are stored in EEPROM. I don't do that very often. If your system doesn't have a volatile state worth preserving, it doesn't give you any advantages over reprogramming.
I can set something wirelessly, but not much.
I also have an LCD with buttons where I can set simple things, such as disabling furnace for summer time.
The main reason I don't want to have to reflash isn't so much the downtime or loss of state, but rather for usability reasons. If I go to all the trouble of installing this thing throughout the house, I don't want to then have to rip it out when we sell or if something happens to me then my wife needs to be able to manage it. Changing some basic "if-then" type code and saving it to a USB stick is probably within the capabilities of most people. Hooking up a programmer to the ICSP port, switching jumpers, recompiling a hex file, and flashing it probably a bit more trouble than most people want to go to. But then maybe I am overestimating how much reconfiguration is actually going to be required. Maybe once it is in and working, no one will worry about reprogramming it.
What does your system control? How much have you extended it since it was first installed?