Winter is coming

I've had the fancy thermostats for a year now and they have been updated as new capabilities were needed and work pretty darn well. I've had the house controller for several months and it is still growing and worked pretty well during the summer. Now, winter is coming and I have to think and experiment with the various controls a little differently.

For example when it is well over 90F outside, 70F is too cold inside for me. When it is 48F outside, will 70F still feel cold or will it be warm? Especially since I'll actually be wearing clothes and maybe even shoes. I don't know.

The current plan is to set the house for heating and the inside temp at 70F with recirculation and see what happens. I can test the heat and such to see what is the most comfortable and least costly. I like a cool room to sleep, so there may be different settings depending on the outside temperature.

So, maybe I'll turn the thermostats completely off if the outside temperature is between 70F and 80F and then adjust the inside temperature based on outside temp.

I just don't know and will have to research this over the coming winter. Wish me luck.

On another front, the house controller went through a major set of changes this last week and a half. I found a way to make the internet connection and response much, much better. The Arduino library will send one byte packets if you use certain facilities. This means each single byte of real data sent has about 50 bytes of overhead to get it to the destination. This is not a bug in the Arduino code, it's a pretty nice feature that allows new users a lot of flexibility. For me, it was something that was causing me a lot of trouble and had to go. It was simple to fix, just use client.write() instead of client.print(). This means I have to do my own formatting of data for display, but I was almost totally doing that already. So, I went through all the code and changed this. Now, the ethernet is very reliable and seems to work every single time.

I took the special code around Pachube out and modified it to allow for errors. Pachube has been incredibly reliable, but sometimes it takes more than 10 seconds to respond to a request. That would exceed my watchdog timer and cause the device to reset. So, I changed the ethernet library to allow me to set a time limit on connect() requests and time the Pachube connection out in 5 seconds. This is no big deal since I'll be back to that point in a minute anyway and Pachube seldom fails to respond in that amount of time. This is a nice solution because I can also time other interactions with the internet to prevent hanging up waiting for a connection to time out. The timeout for something like this seems to be around 30 seconds. For me, that's too long to wait.

The problem with this is that I now have a custom ethernet library. So, when the Arduino folks come out with a better IDE, I'll have to fit my changes into their stuff. That also means I have to keep careful track of my changes and make sure I have them all the time. I guess I'll have to look into cloud storage of my various code pieces for the devices and IDE. It's getting to the point now where I have a ton of time invested in these controlling devices and I'd hate to lose it all to a hard disk crash.

Also, the fixes to the internet interaction turned up another problem. The way I'm using the XBees allows for collisions. The more of them I have, the more likely collisions are to happen. Each collision causes a packet to get messed up and then my packet decoder will mess up. Yes, I know that each packet has a checksum, but what they don't tell you is that the XBee sending broadcasts will split a broadcast between two or more packets. That means each part of a packet has the correct checksum. Sigh, hard to find problem that was relatively easy to fix. Since I have packets constantly coming telling the status of the devices, I just have to check for the packet for consistency and dump it if it fails. There'll be another one in a minute or less. So, I check the incoming packets and discard the ones that have been fragmented. This works fine now and my little box has been running perfectly for a few days. The only reboot that has happened is the one I force at midnight every day to just clean it out.

The really, really cool thing about this is that I CAN do it. See, prior to starting this experiment, I couldn't control any of this, much less wonder what to do if the outside temperature went up or down. People just don't understand what is actually possible and are constantly frustrated by high bills or uncomfortable environments. My frustrations are related to how I want to control it, not whether I can or not.

Nice.