HAI Omnipro II Temperature Logger
- Thread starter ckuczun
- Start date
I couldn't find one so I wrote a simple console program in .net using their SDK that logs to a SQL database. I have it set to run every 10mins on my WHS using task scheduler. I was going to make it into a real service, but it works great this way. I also have it read the event log and write new entries to the SQL database also for long term storage.
I could post the code if your interested, but it pretty ugly and specific to the old Omni protocol not the new 3.0 firmware.
I then graph the data using the open source ZedGraph library in ASP.Net here is a sample of the last 30 days:
I could post the code if your interested, but it pretty ugly and specific to the old Omni protocol not the new 3.0 firmware.
I then graph the data using the open source ZedGraph library in ASP.Net here is a sample of the last 30 days:
I was hoping to not have to write my own program, but I guess I will. I have over 30 tstats to monitor and will need an interactive charting solution. I have the 3.0 HAI chip so I think I need the new SDK. If your code works at all with 3.0, I'd like to see how you did it. Mostly I just need to extract the raw temps from the controller. Once I have that ability, I can do the rest.
I have attached the source to my Omni Logging program. It is C# .Net 3.5 and is structured as a windows service but I never implemented it that way, instead it is just a console application for now that loads, logs then ends.
Since it was based on code in their SDK sample it actually has some code for the newer v3.0 protocol which I have never tested, only the older protocol code I know works.
Be sure to set the IP address and Controller key in the StartLog method.
You will need create a SQL DB that matched the SQL statements in there or get rid of the DB logging code.
You will also need HAI's SDK in order to get the HAI.Controller.dll in the project.
Since it was based on code in their SDK sample it actually has some code for the newer v3.0 protocol which I have never tested, only the older protocol code I know works.
Be sure to set the IP address and Controller key in the StartLog method.
You will need create a SQL DB that matched the SQL statements in there or get rid of the DB logging code.
You will also need HAI's SDK in order to get the HAI.Controller.dll in the project.
PaulD
Active Member
Cool!
I love to see people doing stuff like this.
So...when is HAI going to start building & releasing handy applications like this?
Sorry I don't have time to make it into a reusable program right now and the controller key embedded in the source code. Also you mentioned you had many thermostats, the code is pretty specific to just logging my 3, you would need to change it some to request all the ones you want temps for.
If you have any .Net knowledge it should be trivial to adapt it to your needs, otherwise maybe someone else can help out using this as a starting point.
Thanks to HAI for releasing a .Net SDK, so many possibilities.
If you have any .Net knowledge it should be trivial to adapt it to your needs, otherwise maybe someone else can help out using this as a starting point.
Thanks to HAI for releasing a .Net SDK, so many possibilities.
OK, so now I have a program that works with the HAI 3.0 controller and it is logging all my tstats temps 24/7. I am currently writing a plotting solution that lets you interactively select the date and which tstats to plot. The code from the HAI SDK is only returning the temps in integer form. Does anyone know if there is a way to get the actual temp in a decimal?
Hi jharrell,
Your code does convert to a decimal, but I am still only getting one-degree steps from the HAI controller. So before when I was getting integer steps like 62, 63, and 64, with your code I am now getting the decimals 62.4, 63.4 and 64.4. I guess that is because the value is in a byte array of only 256 values which can't provide much precision. Anyone know if you can get real values from the tstats?
Carl K
Your code does convert to a decimal, but I am still only getting one-degree steps from the HAI controller. So before when I was getting integer steps like 62, 63, and 64, with your code I am now getting the decimals 62.4, 63.4 and 64.4. I guess that is because the value is in a byte array of only 256 values which can't provide much precision. Anyone know if you can get real values from the tstats?
Carl K
The thermostat itself is 8bit precision and based on celsius hence the odd alignment in fahrenheit so it is the "real" value, they are not exactly 1 degree steps in fahrenheit, they are .5 celsius steps.
This is from the Omni docs for the thermostat protocol:
Temperatures: "Omni" format: Temperatures are 1 byte, 0 to 255. 0 is -40 degrees Celsius and -40 degrees Fahrenheit. 255 is 87.5 degrees Celsius, 189 degrees Fahrenheit. Each increment is .5 degrees Celsius. A table is presented in appendix A relating temperature bytes to degrees C and F. In Fahrenheit mode, the thermostat rounds the display to the nearest whole degree. (71.6 and 72.5 will be displayed as 72.) In Celsius mode, half degree increments are displayed.
So given the that, my code gets fahrenheit by the fact the 256 steps represent 229.5 degrees of temperature change (-40 to 189.5). It is accurate and double checked against their table from the SDK.
Do you really need better than 8bit or .5 celsius precision in a HVAC thermostat?
OK, that explains it. If the tstats report in increments of .5 C that is almost 1 F at 60-70 degrees which is what I am seeing. When the temperatures that I am analyzing have ranges of, say, 5 F, then it is almost impossible to see trends caused by solar, office equipment, door openings, adjoining rooms, outdoor temp, etc., when I can only observe 1 F increments. When you look at a tstat to see what the temp is, 1 F increments are fine. But to programatically look at the cause and effect relationships of the local environment to the heating system, 1 F steps are too course. But now that I know what I can get, I can deal with it. Thanks for the information.
I question the tstat designers' decision to use a temperature range of -40 F to 189 F for an indoor temperature device. They could have chosen a much more realistic range and doubled the reporting accuracy. They also could have offered a setup option that would have provided two ranges, one with the extreme temperatures for those of us who leave our windows open in the antarctic, and one with reasonable temperatures. A range of 0-50 C (32 - 122 F) would almost triple the accuracy of the output.
I question the tstat designers' decision to use a temperature range of -40 F to 189 F for an indoor temperature device. They could have chosen a much more realistic range and doubled the reporting accuracy. They also could have offered a setup option that would have provided two ranges, one with the extreme temperatures for those of us who leave our windows open in the antarctic, and one with reasonable temperatures. A range of 0-50 C (32 - 122 F) would almost triple the accuracy of the output.
This format it not just used for indoor thermostats, it is the "Omni" temp format used by the outdoor extended range thermostats as well and any temperature value in the Omni. Basically it seems many years ago HAI had to settle on a common temperature format that fit in 8bits, probably for memory constraints on older Omni's. All their thermostats where built around this common data type regardless of location or enviroment.
Given todays advances it would be nice to see them move to a 16bit value for temperature which should give much finer resolution for just about any Automation need, say .1F from -1500 to +1500 or so. This would of course require a big change to Omni firmware and protocols and maybe even hardware.
