123
Senior Member
I'm writing a driver for the HAI Omnistat2 RC-2000 communicating thermostat. Here's my progress so far:
I took the existing HAI Omnistat driver and changed its architecture so that it supports multiple thermostats connected to the same serial port. Although I own only one Omnistat2, it doesn't take much more effort to have the driver handle multiple thermostats.
The driver is reporting all of the key thermostat properties (Fan/HVAC status, Fan/HVAC mode, current temperature, heat/cool setpoints) and I've added humidity.
The original Omnistat code did not implement all of a thermostat's functionality (i.e. it lacks User Hold) and does not handle fan status the way I think it should. For example, if a furnace handles the fan's operation then the thermostat need not explicitly turn on the fan when it calls for heat. That means that, as far as the thermostat is concerned, when the furnace is on, the fan is off. That may be an accurate picture of how the thermostat sees the world but it does not reflect the fact that the fan is definitely on when the furnace is running. When viewed in Premise Browser, it is unsettling to see the furnace is on but the fan is off! I'm currently sorting out the basic functions before moving on to the fancier stuff like schedules, run-time logs, and backlighting.
Running at 9600 baud is not recommended. Although the total cable length from PC to thermostat is less than ten feet (CAT6 cable), I noticed that now and then (after about 12 to 20 requests) there'd be no reply to a polling request. Sometimes there were two or three successive failures. I reduced the speed to 2400 and the problem disappeared.
The thermostat does not report any changes so all data must be acquired via polling. The Omnistat2 has over 200 properties so polling has to occur in some sort of intelligent fashion. I'm thinking of separating the properties into three categories and polling each category at different intervals. For example, temperature and humidity would be polled frequently whereas other would be polled hourly and yet others on a daily basis.
I took the existing HAI Omnistat driver and changed its architecture so that it supports multiple thermostats connected to the same serial port. Although I own only one Omnistat2, it doesn't take much more effort to have the driver handle multiple thermostats.
The driver is reporting all of the key thermostat properties (Fan/HVAC status, Fan/HVAC mode, current temperature, heat/cool setpoints) and I've added humidity.
The original Omnistat code did not implement all of a thermostat's functionality (i.e. it lacks User Hold) and does not handle fan status the way I think it should. For example, if a furnace handles the fan's operation then the thermostat need not explicitly turn on the fan when it calls for heat. That means that, as far as the thermostat is concerned, when the furnace is on, the fan is off. That may be an accurate picture of how the thermostat sees the world but it does not reflect the fact that the fan is definitely on when the furnace is running. When viewed in Premise Browser, it is unsettling to see the furnace is on but the fan is off! I'm currently sorting out the basic functions before moving on to the fancier stuff like schedules, run-time logs, and backlighting.
Running at 9600 baud is not recommended. Although the total cable length from PC to thermostat is less than ten feet (CAT6 cable), I noticed that now and then (after about 12 to 20 requests) there'd be no reply to a polling request. Sometimes there were two or three successive failures. I reduced the speed to 2400 and the problem disappeared.
The thermostat does not report any changes so all data must be acquired via polling. The Omnistat2 has over 200 properties so polling has to occur in some sort of intelligent fashion. I'm thinking of separating the properties into three categories and polling each category at different intervals. For example, temperature and humidity would be polled frequently whereas other would be polled hourly and yet others on a daily basis.