Premise HAI Omnistat2 RC-2000 - Driver Development

[123]

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.

 

[123]

I've made progress stabilizing the communications between Premise and Omnistat2. As mentioned in my first post, at 9600 baud the thermostat would frequently fail to respond to a polling request. After reducing the speed to 2400 baud, I now get about 3-4 failures per day (polled at 15 second intervals).

Another strange phenomenon is a complete loss of communications; the thermostat will simply fail to respond to any and all commands. I have not been able to correlate this failure with any of the thermostat's activities (i.e. it doesn't happen at the moment when the HVAC is activated ... it seems to occur randomly).

I don't know if the failure is due to Premise, the Omnistat2, or my PC's serial port but the only solution is to reset the COM port. I've introduced a Watchdog timer that keeps track of the number of communication failures. The Watchdog allows the thermostat 5 seconds (an eternity even at 2400 baud!) to respond to a command. If the thermostat fails to respond to three consecutive commands, the Watchdog resets the COM port. I've tested this by disconnecting/reconnecting power to the thermostat.

I'm still optimizing the design of the polling algorithm. The Omnistat's serial protocol allows you to, with a single command, request the contents of 14 consecutive registers. If you poll the thermostat every 15 seconds, it'll take several minutes before you iterate through all of the registers. In addition, there are a few high-priority registers whose status you'd like to have updated frequently (at least once a minute or less) such as current temperature, HVAC state, Fan state, heating/cooling setpoints, humidity, etc. My current plan is to interleave two polling cycles.

• Polling Cycle #1 runs every 30 seconds and acquires the high-priority registers.
• Polling Cycle #2 runs every 30 seconds and iterates through all of the registers (no more than 14 registers per request).
• The polling cycles are phase-shifted by 15 seconds (i.e. polling cycle 2 starts 15 seconds after polling cycle 1).
• Each polling cycle has 15 seconds (the amount of the phase-shift) to accomplish its work.

This technique ensures that high-priority registers are acquired every 30 seconds. In contrast, the status of all registers is collected over a period of approximately 4 minutes. So if someone accesses the Omnistat2's menu and changes the backlight color, Premise will be aware of this change no more than 4 minutes later. Whereas if you change the heating or cooling setpoint, it'll be communicated within 30 seconds.

I don't plan to test this driver with mulitple thermostats but I think the proposed polling technique should work properly with 1-3 thermostats. I suspect the phase-shift would have to be increased if one were using more than 3 thermostats (on the same COM port).

I've decided that the driver's presentation will be similar to Premise's Honeywell EnviraCOM driver (see the attached images). The EnviraCOM driver supports multiple thermostats per COM port and shows each day's schedule as a child object.

 

[etc6849]

Your serial issue intrigues me although I don't have an Omnistat, I do have the exact same serial port issues like you are describing.

123, what OS and SP are you using now days? Is this a custom driver you are developing or is it in c++?

The serial communications issue you are having is the exact same issue I have when I place heavy traffic over a serial port for all custom drivers I have on my system. I doubt it's your driver, try the betabrite custom driver you helped me make a while back and see if it hangs too. It will always hang for me after a 3 hours or so with 30 second updates going to it.

I have tried multiple types of usb to serial adapters (Digi and a non branded generic adapter) and even network based rs232 controllers at this point and they all have the issue you are describing if I send multiple commands in a repetitive manner. I recently built another PC only to have the same issue although I switched to an old copy of XP Pro X64 SP2. Prior to that I've used Vista SP1 and Windows 7 and they both reacted in the same manner. I think it must be the OS assuming there is a hardware failure of some sort (kind of like sticky keys in windows) and closing the port. Perhaps it is a security capability MS has added too as you suggested before.

The one test I can try when I get home is to use the GC-100 rs232 port with your Vizia driver to see if it still has these errors. I'm not sure yet, but I think since the GC100 is an add in, it may not use the same serial classes and may not have the problem! If the problem is with the serial class of the custom drivers or how this class interacts with windows, the GC100 test may shed some light on the issue. I'm very tempted to try windows 2000 SP1 at this point, but I'm not sure how to add the drivers I'd need to the installation disk. The only thing I haven't tried is completely nuking the Premise installation and starting over from scratch, only installing the test module and running testing my ports for a week.

EDIT: if the GC-100 port works, the next best bet would be a lantronix device from ebay. The GC100-10 uses the RemoteCOM class as do the lantronix devices. I think this really might work and solve all of my port problems. I've never had an issue with the GC-IRE I have plugged into the GC100. I'm going to have to coax my wife into plugging the RZC0P into the GC100 tonight

 

[etc6849]

I'll give another update on the serial issue Wednesday, Thursday and Friday too. So far though, the results are very impressive using the GC100 rs232 port. See attached job data. 3000 jobs so far (5 zwave devices at 20 second polls).

I'm assuming you kept a job class similar to your very clever Vizia driver. I am fairly certain that a regular serial port would have given me an error now, but by Friday if there are still no errors, I will be highly impressed. I have never made it more than 30 hours without the job error/port reset and this was with minimal polling of only the thermostat only every 140 seconds.

EDIT: Spoke too soon. Right before I went to bed I looked and there was the first 2 consecutive failed jobs Doh! This is good though because it does eliminate windows from being the cause (I think) and at least the serial port subsystem within Premise. This leaves us with the custom device driver though and what it's inheriting from and how the driver interacts with the serial subsystem or the RemoteCom class.

 

[etc6849]

Here's an update. I still haven't given up on my zero error quest and I suspect you are hard at work debugging this (pretty please).

A few more ideas I have that I plan to try in the near future:
1. Construct a loop back db9 cable and find an old laptop running Windows XP SP1 or 2000. Set up a Premise install with only a generic serial driver that will poll the port, wait for the response to be repeated, then poll again. Count the responses up until port failure.

2. Play with the serial settings some more. I've restarted my test, after enabling "Enable Events". It turns out none of my drivers had this enabled. The results look good (so far over 5400 jobs with no errors yet ) I know enable events should not matter for 3 wire communication, but I am to the point of trying random things and testing them Besides, enable events can't hurt. Who knows how the actual hardware is communicating. The hardware may very well come with an undocumented option of using CTS, DSR or Ring.

EDIT: Errored again at 7400 jobs... oh well

 

[123]

I have two Module-based drivers that use serial-communications (the others are all Native drivers) and I've been monitoring their error-rates. The Omnistat2 driver has about about 2 or 3 failed transmissions in 1000. Once or twice a day, three successive transmissions will fail and the driver will reset the serial port. The serial communications aren't flawless and I'm trying to determine the cause of the hiccups.

My server is a 1GHZ VIA C7 with 256 RAM running Windows XP SP3. It is also drives a touchscreen using Internet Explorer. If you attempt to watch YouTube videos, the playback stutters frequently ... and while this is happening, I noticed that the number of failed transmissions increases dramatically.

I'm going to increase the priority of the Premise Server service (prkernel.exe) and see if that helps (and avoid watching videos).

FWIW, here's some code that allows Premise to adjust the priority level of its Windows Service. Put this code in Modules > Default > GlobalScripts > Global.

function gSetPremisePriority
	' REALTIME = 256
	' HIGH = 128
	' ABOVE_NORMAL = 32768
	' NORMAL = 32
	' BELOW_NORMAL = 16384
	' LOW = 64

	set oWMIService = GetObject("winmgmts:\\.\root\CIMV2")
	set oProcesses = oWMIService.ExecQuery("Select * from Win32_Process Where Name = 'prkernel.exe'")
	for each oProcess in oProcesses
		oProcess.SetPriority(128)
	next
	set oProcesses = nothing
	set oWMIService = nothing	
end function

' Set prkernel priority at startup
gSetPremisePriority

 

[123]

FWIW, increasing Premise Server's priority has not reduced the error-rate. Approximately 2 out of 1000 transmissions continue to fail. It is revealing to learn that serial-communications, even under the best conditions, can experience an occasional hiccup.

 

[etc6849]

123, sorry you are still having problems. Have you tried an RS232 test connector and a simple driver just to test the port? I'm curious to see if you remove the Omnistat, does the problem go away?

My GC100 still ended up freezing when I used a loop back connector even at 1 second intervals. I tried an MSS4 and was able to get to 65000 before it froze (polling interval was 500ms). The MSS4 appears to be the most reliable networked solution, but it still freezes so I'm worried something is wrong with Premise too. It's interesting to note that the GC-IRE driver add in will reset the port like you do if the port is unresponsive. Who ever designed the add-in may have ran into the same problem we are describing.

Positive news: I ran a port on the Digi Edgeport for weeks using the loop back connector and it never froze. It also had the lowest error rates I have seen.

PS: I'll send you a free loop back connector if you want.

 

[123]

etc6849,
I have a Home Electronics IRA3 receiver connected to Premise and its driver polls the device once a minute. It fails to respond to a poll once every few thousand polls but it never needs to have its serial-port reset.

The Omnistat2 driver polls at a much higher rate; at least four commands are issued every polling cycle (20 seconds). The driver needs to reset the serial-port several times a day. I'm now logging all transmissions to a text file in the hope I can spot what causes the instability.


Progress report:

I'm waiting to have a few items in the Omnistat2's serial protocol clarified. Other than that, the driver works well and reports 95% of the Omnistat2's registers (I don't collect the wireless parameters) and provides control over 80% of the thermostat's registers (I don't provide control over core settings like HVAC type and the like). Basic thermostat settings, schedules, backlighting, energy, air filter, runtime, etc are all available.

The tricky part now is to get the Omnistat2's schedule to become visible in AutomationBrowser (AB). AB already has everything need to display the schedule for a Honeywell thermostat. I'm trying to adapt the Omnistat2 to share the Honeywell's resources. It is isn't easy because the Honeywell thermostat is 'special-cased'; there are four places in AB where support for the Honeywell thermostat is hard-coded. I've had to 'special-case' the Omnistat2 as well. Not the most elegant technique but it works.

 

[123]

Thanks to assistance from Ryan at HAI, the Omnistat2 driver is very close to completion. I've had it running for several weeks and it works reliably. The attached diagram shows how I've modelled the HAI Omnistat2.

The OmnistatNet object handles serial communcations for one or more Omnistat2 thermostats.

The Omnistat object represents one instance of an Omnistat2 thermostat. It has numerous properties that are categorized as follows:

• Omnistat
  Basic information about the thermostat.
• Climate Control
  Controls the HVAC operating mode and fan.
• Temperature Controller
  Controls the setpoints and displays the outdoor temperature.
• Temperature Sensor
  Reports the indoor temperature.
• Binding Target
  Used by Premise to bind this driver to a Thermostat object.
• Humidity Control
  Controls Humidify/Dehumidify setpoints and reports indoor/outdoor humidity.
• Filter
  Reports the remaining filter days.
• RunTime
  Reports the HVAC system's runtime for the last four weeks.
• Backlight
  Controls the backlight mode/color/intensity as well as the proximity sensor's sensitivity.
• Energy
  Reports all Energy-related properties
• Display
  Controls how infomration is displayed on the Omnistat2's screen and which messages are displayed.
• HVAC
  Controls various HVAC-related properties.
• Vacation
  Controls vacation setback and period.
• Messages
  Writes messages to the Omnistat2's screen.
• DirectCommand
  For sending raw Omnistat commands.

Each day of the week is a separate scheduling object that contains four child-objects representing the period-of-the-day (Wake, Leave, Return, Sleep). Each period has properties that let you set the time and Heating/Cooling setpoints.

The Occupancy object contains four child-objects representing the arming mode (Day, Night, Away, Vacation). Each mode has Heating/Cooling setpoints.

The diagram shows temperatures in Celsius but this simply reflects my locale settings. The driver automatically performs temperature conversions based on the end-user's locale settings.

 

[etc6849]

123,

I'd love to see what your progress is on this? I'm looking to upgrade from my $70 Wayne Dalton Z-Wave thermostat. Your module looks to have many well thought out features from the image.

Thanks

 

[123]

The driver was completed last March and has been successfully controlling my home's Omnistat2 ever since. The only thing I never completed was an interface for Premise Browser that would let you interactively change the thermostat's schedule. The schedule can be interactively changed using Premise Builder (see the attached image in the my post above) or using script.

 

[etc6849]

Did you post a beta version? I can't seem to find it

 

[123]

I haven't posted it; I may in the future.

 

[etc6849]

Thanks 123. No hurry. I still haven't finished my Elk M1G install, so that will come way before I look into a better thermostat. PS: I sent you a PM about the Elk driver.