Force Celsius in UI

[Pacificwing]

Hi,

 

It seems that folks that want to use metric are getting forgotten by most thermostat manufacturers. Many thermostats are incapable of doing the conversion, and when they are, they get it  wrong. I'm on my third model of thermostat now that can't seem to make metric work properly (if at all).

 

Is there a way to configure the ISY to convert to °C through the UI? So, for instance, if a thermostat is reporting 71°F, it would just do the conversion to 21°C automatically before importing the data? Is there a way to do this outbound as well? Like a scale filter?

 

The interface would seems to indicate that this functionality is present, since all of the drop-down menus and displays in the admin console have °F beside the raw data inbound from the device. The ISY, at some point, has made the decision that it is going to display in °F. Either it got this instruction from the thermostat directly, or there is a setting I'm missing.

 

-PW

[stusviews]

Which specific thermostats are you having difficulty with?

[Pacificwing]

Which specific thermostats are you having difficulty with?

 

I just set back my ZTS-110. It would convert to Celsius, but it reported the wrong value.

 

I can't recall the model # of the one I had before it off hand, but it was another Z-wave model.

 

The CT-32 is the one I have now. The display will change to Celsius, but the Z-wave will only report in Fahrenheit. According to the manual, there is a Z-wave parameter to change this (which may or may not work), but the parameter appears to be a bit array, which the ISY doesn't appear to support.

 

As I stated before, the ISY has (somehow) made the choice that it is going to appear in °F regardless of what comes back from the thermostat. The drop-downs and displays in the admin tool all suffix with °F. There does not appear to be an option to change this. You can change the units to Celsius in the web interface, but it only effects the range available on the temp selection drop-downs.

[Amigo]

Good evening,

I can tell you that Honeywell YTH8320ZW1007/U, and go control GC-TBZ48  report in Celsius when you setup the tstat to use degC units.

The only issue so far that I have seen with both is the z-wave reports with 0 precision which means you get only whole numbers, eventhough on the stat display the increments are 0.5

So for example tstat may say 21.5, z-wave reports 22.

My observations above are when I am in the Admin console.

 

My favorite so far is the honeywell, gives the most options that I was after, but it is also the most expensive.

 

cheers.

Edited December 31, 2015 by Amigo

[larryllix]

A program should be easy

 

You would need a scratchpad variable and a finished product variable. Set them both to one decimal point of precision (v5)

 

If the temperature_reported < 999 (must be enabled to trigger on every change)

Then

    scratchpad = temperature_reported

    scratchpad  -= 32

    scratchpad *= 5 (for v5 with 0.1 precision)

    scratchpad */ 50 (if using v4 for temp x 10)

    scratchpad  /= 9

    finished = scratchpad

Else

   --

 

 

The Insteon 2441ZTH reports in C just fine.

There is an option in ISY to report in C at bootup time. Can't remember how to get access to it though.

Edited December 31, 2015 by larryllix

[Pacificwing]

A program should be easy

 

You would need a scratchpad variable and a finished product variable. Set them both to one decimal point of precision (v5)

 

If the temperature_reported < 999 (must be enabled to trigger on every change)

Then

    scratchpad = temperature_reported

    scratchpad  -= 32

    scratchpad *= 5 (for v5 with 0.1 precision)

    scratchpad */ 50 (if using v4 for temp x 10)

    scratchpad  /= 9

    finished = scratchpad

Else

   --

 

 

The Insteon 2441ZTH reports in C just fine.

There is an option in ISY to report in C at bootup time. Can't remember how to get access to it though.

 

 

A couple of things.

 

Version 5 doesn't yet support assigning Z-wave device values to variables. As I understand it, this functionality is quite a while away.

 

Even if the ISY did support it at present, I'm already aware of the formula  to convert metric to imperial and back again, and how to accomplish that programmatically. It is a basic function. The problem is that having the metric value in a variable is pretty useless if there is nothing I can do with it after I've done the conversion, beyond storing it in a variable that the end user will never interact with. I can't "trick" the thermostat device to use the variable value instead of the raw device value. This won't correct any of the user interface problems since any third party interface is going to pull data directly from the device object; not the custom variable.

 

Programmatically, if I need to perform any math or conditional operations on the thermostat value, there is no reason to do the conversion at all. That can all be done behind the scenes in Fahrenheit. The only reason I would convert to metric is for user interface purposes, and the program (from my understanding; correct me if I'm wrong) isn't going to help with that.

 

Ideally, it would be nice if the ISY allowed us to filter/modify the raw values as they came in. This wouldn't be very difficult to implement at all. The same filter process would be very useful for software calibrations as well, as well as artificial min/maxes, etc etc. The sky is the limit on how this would be useful.

 

Right now the ISY reports the raw device value, and gives you very little flexibility to manipulate or scale that data. This means you are totally at the mercy of the device to output the proper data.

[larryllix]

A couple of things.

 

Version 5 doesn't yet support assigning Z-wave device values to variables. As I understand it, this functionality is quite a while away.

 

Even if the ISY did support it at present, I'm already aware of the formula to convert metric to imperial and back again, and how to accomplish that programmatically. It is a basic function. The problem is that having the metric value in a variable is pretty useless if there is nothing I can do with it after I've done the conversion, beyond storing it in a variable that the end user will never interact with. I can't "trick" the thermostat device to use the variable value instead of the raw device value. This won't correct any of the user interface problems since any third party interface is going to pull data directly from the device object; not the custom variable.

 

Programmatically, if I need to perform any math or conditional operations on the thermostat value, there is no reason to do the conversion at all. That can all be done behind the scenes in Fahrenheit. The only reason I would convert to metric is for user interface purposes, and the program (from my understanding; correct me if I'm wrong) isn't going to help with that.

 

Ideally, it would be nice if the ISY allowed us to filter/modify the raw values as they came in. This wouldn't be very difficult to implement at all. The same filter process would be very useful for software calibrations as well, as well as artificial min/maxes, etc etc. The sky is the limit on how this would be useful.

 

Right now the ISY reports the raw device value, and gives you very little flexibility to manipulate or scale that data. This means you are totally at the mercy of the device to output the proper data.

Stuffing the result in a variable can trigger any program to run and cause anything to happen that ISY can perform.

 

Do you understand the difference between Integer and State variables?

 

I have no Zwave modules but I would be sure their values would be usable for variable substitutions in V5. If not yet they will be soon and that means you can set your variables via Rest calls and work from the values from the resultant triggers in ISY.

 

Are you familiar with the Network Resources and how they work as well as variable substitution?

 

Maybe there is some waiting time yet for Zwave modules but it will come. Variable substitution is new in network resources but has existed in notifications for some time now.

 

If you are programming familiar then it shouldn't be too hard to create a series of Zane input module programs to get values into a variable and massage as needed. Later when advancements are made just swap out your modular code for simple methods available.

Edited January 1, 2016 by larryllix

[Pacificwing]

Stuffing the result in a variable can trigger any program to run and cause anything to happen that ISY can perform.

 

My point was in the context of what I was originally asking. I know what variables can do, but having a variable with a thermostat value in Celsius doesn't help for interface purposes. Most interfaces reference the device directly, so sticking a metric value into a variable doesn't provide any value for this application.

 

Also, if what I wanted to do was trigger a program to run or "cause anything to happen", then I could trigger it directly from the raw value; I wouldn't need the variable to begin with.

 

Do you understand the difference between Integer and State variables?

 

Yes. They are pretty much the same thing. The only difference being that a state variable triggers events.

 

 

I have no Zwave modules but I would be sure their values would be usable for variable substitutions in V5. If not yet they will be soon and that means you can set your variables via Rest calls and work from the values from the resultant triggers in ISY.

 

Are you familiar with the Network Resources and how they work as well as variable substitution?

 

Maybe there is some waiting time yet for Zwave modules but it will come. Variable substitution is new in network resources but has existed in notifications for some time now.

 

If you are programming familiar then it shouldn't be too hard to create a series of Zane input module programs to get values into a variable and massage as needed. Later when advancements are made just swap out your modular code for simple methods available.

 

Yes. As I stated, the Z-wave support isn't there yet to manipulate the data from Z-wave devices. I'm not sure what the timeframe is; I've not seen a development roadmap for version 5.

 

I've looked a Network Resources module, but don't see a need for it. I have no additional network devices I need to communicate with at present.

 

Again, I feel I'm fairly aware of what the programs and variables are capable of, but I still don't see how the program you posted above helps me with my original problem. All I want to do is three steps.

 

1:  Capture the Fahrenheit value reported by the thermostat device or held in thermostat object in the ISY.

2:  Convert the value into metric.

3:  Replace/mask the held Fahrenheit value in the ISY thermostat object with the metric value. Presumably this is buffered somewhere and could be modified.

 

Your program helps with 1 and 2; but 3 doesn't appear to be possible. As previously stated, any third-party interface device is going to reference the device object directly. It isn't going to care what value I stick into a variable. So that means all of my UIs are reading Fahrenheit regardless of what I do programmatically.

[Teken]

The reality is most American companies are still living in 1878. The majority of the free world use Metric as the measuring scale but as you noted even if a company offers Metric in their system.

 

Its either inaccurate or hobbled down where it simply makes no sense! If you look around at other EU TSTAT's which offer some kind of open API / Network access perhaps you might find a happy medium.

[hart2hart]

Have you looked at combination of Venstar T7900 and VenLink or v5 equivalent? It supports using C in settings. I'm stuck in last century so have not tried it out. Post something in third party applications, automationshack, Venstar and io_guy may chime in....

[Pacificwing]

Have you looked at combination of Venstar T7900 and VenLink or v5 equivalent? It supports using C in settings. I'm stuck in last century so have not tried it out. Post something in third party applications, automationshack, Venstar and io_guy may chime in....

 

No, I've not tried that. I have no local z-wave/insteon dealer, and my main on-line dealer charges a restocking fee for each item returned. It is not conducive to trial and error, and makes it irritating when an advertised/specified feature fails to live up.

 

As I've learned, just because a thermostat supports metric, doesn't mean it supports it correctly. Device manufactures are unreliable at best.

 

I expected this, to some degree. I work in commercial automation (PLCs/DDCs) and I can't tell you how many times raw data from the device doesn't report correctly. Usually a small conversion or an offset is enough to correct it, but it is usually done in the controller since the device manufacturers rarely care once they have your money. With my home automation system, I was hoping to mitigate this problem the same way: by having a smarter controller that would allow me to manipulate erroneous data that came in from devices. Sadly, I'm discovering, as powerful as the ISY is for processing logic within the controller, it is fairly limited when it comes to imputing or outputting that data to/from a user-interface or another device. This is surprising, since in the world of home automation, user-interfacing is equally (if not arguably more) important than programming ability. All of the interfaces (that I've researched) that connect to the ISY read data directly from the device objects, not from the variables or program outputs. There appears to be no way to manipulate that data before it gets sent out to the UIs. It is astonishing that this functionality isn't available.

 

This will become a problem as I add more temperature sensors and devices where the raw input value. I may have to filter them through a cheap PLC before sending them on to the ISY. Given the ISY's limited ability to talk to anything, its going to be an interesting challenge.

Edited January 1, 2016 by Pacificwing

[hart2hart]

Understood but io_guy wrote interface code (most use a simple RPi to execute) to Venstar thermostats and I believe he uses metric system. He will give you the straight up truth about thermostats metric capabilities.

 

In general, are you aware of v5 ISY firmware architecture? All that you mention is accounted for but full release is still in future. UDI and Michel are moving forward in a responsible way.

Edited January 1, 2016 by hart2hart

[Pacificwing]

In general, are you aware of v5 ISY firmware architecture? All that you mention is accounted for but full release is still in future. UDI and Michel are moving forward in a responsible way.

 

No. I've searched the forums and learned about variables, but I understood that to be the limit of the V5 release.

 

Is there a particular thread with a roadmap or a full list of intended features?

[Michel Kohanim]

Hello all,

 

All great solutions alas I think they would make life very difficult for the user. At the moment, and unfortunately, we have no plans of forcing things into Metric vs. English including temperatures.

 

With kind regards,

Michel

[larryllix]

Metric or Foreignheat make no difference to ISY or io_guy's NodeLink or VenLink. Temperatures are just numbers to be interpreted by the end user in whatever form YOU choose. Depending on C or F selected in ISY it only assigns the correct suffix to the number in notifications etc..

 

In the serious world of data acquisition values are not sent in engineering units but in bit counts to take advantage of the best resolution available with the hardware in use. IOW if you have a 16 bit channel you don't send attempt to send the result of a 10 bit A/D conversion down the pipe. You attempt to send the best resolution you can to take advantage of the channel resolution. 

 

If this means a transducer with a range of 10 degrees to 20 degrees is represented by a 16 bit A/D converter then 0 counts = 10C and 65535 = 20C. The end user has to scale the bits and add the zero offset to achieve engineering units for the human to look at.

 

You wouldn't have equipment massage and manipulate a raw data value and then give it to another piece of equipment to rescale it down or up. Resolution accuracy can be lost each time.

 

This become evident in many Insteon analogue channels. The 2441ZTH converts it's temperature measurements to C or F and then ships them out Insteon in a 1 bit - 0.5 degrees format. Any further resolution available from the A/D temperature measurement is lost regardless of what the end user wanted. Compensation scales, calibrations and/or end user scaling/offsets could have been done to increase accuracy but it's too late once the truncation has happened. Having said that the Insteon analogue channels can be very limited in bits.

Edited January 2, 2016 by larryllix

[larryllix]

No, I've not tried that. I have no local z-wave/insteon dealer, and my main on-line dealer charges a restocking fee for each item returned. It is not conducive to trial and error, and makes it irritating when an advertised/specified feature fails to live up.

 

As I've learned, just because a thermostat supports metric, doesn't mean it supports it correctly. Device manufactures are unreliable at best.

 

I expected this, to some degree. I work in commercial automation (PLCs/DDCs) and I can't tell you how many times raw data from the device doesn't report correctly. Usually a small conversion or an offset is enough to correct it, but it is usually done in the controller since the device manufacturers rarely care once they have your money. With my home automation system, I was hoping to mitigate this problem the same way: by having a smarter controller that would allow me to manipulate erroneous data that came in from devices. Sadly, I'm discovering, as powerful as the ISY is for processing logic within the controller, it is fairly limited when it comes to imputing or outputting that data to/from a user-interface or another device. This is surprising, since in the world of home automation, user-interfacing is equally (if not arguably more) important than programming ability. All of the interfaces (that I've researched) that connect to the ISY read data directly from the device objects, not from the variables or program outputs. There appears to be no way to manipulate that data before it gets sent out to the UIs. It is astonishing that this functionality isn't available.

 

This will become a problem as I add more temperature sensors and devices where the raw input value. I may have to filter them through a cheap PLC before sending them on to the ISY. Given the ISY's limited ability to talk to anything, its going to be an interesting challenge.

This isn't really the limitation with ISY but rather the Insteon system itself. HA systems were based on turning lights and appliances on and off only. Analogue is really something new.

 

ISY has provided for this expansion quite well with it's REST interface and now Node interface that are gateways to the rest of the world and could leave Insteon in the dust. IMHO Insteon is still the gold standard of non-hardwired HA though but SmartHome is just fumbling too badly for the speed of popular wants. They probably just don't understand the Chinese documents for the latest developments presented to them

 

I have a WC8 PLC board stuffing windspeed, gust speed, inside temp. outside temp, hi and low temps for the day, a RPi stuffing every aspect of my Venstar T7900 thermostat into my ISY and use most of the parameters for logical HA responses. These are all analogue inputs. Currently ISY reports my cold cellar ventilation, HRV, and HVAC heating times each day via text message for monitoring purposes.

 

ISY is not limited by Insteon, just our imaginations.

Edited January 2, 2016 by larryllix

[Pacificwing]

ISY is not limited by Insteon, just our imaginations.

 

 

I don't know man. I can imagine seeing my thermostats in Celsius.

[Teken]

I don't know man. I can imagine seeing my thermostats in Celsius.

 

LOL . . .

[larryllix]

I don't know man. I can imagine seeing my thermostats in Celsius.

I have never seen a thermostat that can't display Celsius temperatures and all mine display C in the ISY admin console.

 

Is your ISY set to use C or F?

Edited January 2, 2016 by larryllix

[Pacificwing]

I have never seen a thermostat that can't display Celsius temperatures and all mine display C in the ISY admin console.

 

Is your ISY set to use C or F?

 

The ISY is C, but I"m being told it makes no difference. It displays the value sent from the thermostat regardless. The only thing the ISY setting changes is the suffex, as far as I know. (eg, if you set the ISY to Celsius, it will display 71°C instead of 71°F. No conversion)

 

The CT-32 displays (on the front HMI display) in Celsius, but in order to communicate it uses a separate z-wave radio module called the RTZW-02, which only transmits in Fahrenheit. The ISY only gets displays what it sees directly from the transmitter, with no ability to modify it or convert it; or so I'm being told. Its annoying, because I know it won't be the last time I encounter a device that sends data back exclusively in the wrong engineering units.

 

I think, perhaps, the absence of this feature hasn't gotten the attention it should have, because (from what I understand) the ISY994i with the Z-wave chip is not marketing outside of the US officially. I had to import mine from an american retailer because it can't be currently sold in Canada. I suspect if the z-wave ISY goes global, you might hear more about this.

[larryllix]

The ISY is C, but I"m being told it makes no difference. It displays the value sent from the thermostat regardless. The only thing the ISY setting changes is the suffex, as far as I know. (eg, if you set the ISY to Celsius, it will display 71°C instead of 71°F. No conversion)

 

The CT-32 displays (on the front HMI display) in Celsius, but in order to communicate it uses a separate z-wave radio module called the RTZW-02, which only transmits in Fahrenheit. The ISY only gets displays what it sees directly from the transmitter, with no ability to modify it or convert it; or so I'm being told. Its annoying, because I know it won't be the last time I encounter a device that sends data back exclusively in the wrong engineering units.

 

I think, perhaps, the absence of this feature hasn't gotten the attention it should have, because (from what I understand) the ISY994i with the Z-wave chip is not marketing outside of the US officially. I had to import mine from an american retailer because it can't be currently sold in Canada. I suspect if the z-wave ISY goes global, you might hear more about this.

Have you examined the data stream in the events log to see what the actual bitcounts look like? perhaps UDI needs to change the interface t match the ISY settings.

 

I would write software to change the value to Celsius in ISY.  If you can trigger programs on temperature reports from it you can extract the temperature reported to calculate from. This would be temporary until complaints get some action from the manufacturer about their defect.

 

Other hardware needs to do it's own thing with the data stream values or have ISY send out your calculated results..

[Pacificwing]

The ISY is C, but I"m being told it makes no difference. It displays the value sent from the thermostat regardless. The only thing the ISY setting changes is the suffex, as far as I know. (eg, if you set the ISY to Celsius, it will display 71°C instead of 71°F. No conversion)

 

 

I just noticed you asked specifically about the admin console. There is no option to change units in the admin console that I can find. The only options to change units are in the web interface,and that only affects the suffix.

[larryllix]

I just noticed you asked specifically about the admin console. There is no option to change units in the admin console that I can find. The only options to change units are in the web interface,and that only affects the suffix.

IIRC the option was only at boot up time and you are right...it only suffixes values.

 

A while back I wrote a series of programs to interrogate a thermostat and put the result in a variable. This was before v5 and there was no capabilities to do that. It takes a program, that calls one after the other in a daisychain fashion, for each value you could expect. The starting program triggered from any temp change for the stat and also has several times each day to trigger, just in case. The series ran a linear approximation until the logic switched and then you had your temperature in the variable. Of course this would all be replaced once the F/C problem gets fixed from the manufacturer.