Pacificwing

Fair enough. It is true that all of the devices within a scene could have different statuses, so naturally the question would be, what is the overall status of the scene? But that wasn't my question. My question was regarding when a scene is "triggered". My question was not in regards to the status of a scene or the devices therein. The latter seems possible; the former apparently isn't. Allow me to define what I mean by "triggered". Using your example above: Scene "0x001" Device 1 - On 100% Device 2 - On 50% Device 3 - Off From what I've read (and my understanding could be wrong), when a scene is triggered in the insteon protocol, the device that triggers it (keypad, REST, switch, etc) sends out a broadcast that basically says "Engage Scene 0x001". This command is broadcast to all devices. When Device 1 sees this command, it knows to set itself to 100%. Device 1 doesn't really care what the other devices are doing. Device 2 sees the command and sets itself to 50%. Again, it is basically a stand-alone device specific response to a broadcast command. This is why the scenes continue to work even if the controller dies. The scenes are programmed into the devices themselves. It seems fairly basic to allow the controller to respond to the "Engage Scene 0x001" command as well. This is not a "status" so much as a one-time event. Yes, it is possible that the individual devices may change their states after the scene trigger command is broadcasted, but that wasn't what I was asking about. I was asking about responding to the main scene broadcast trigger. That works for REST commands, yes, but there is no way to apply that whenever a scene is triggered. And if there was, it wouldn't necessarily have to be hidden.

The scene is being invoked by keypad, REST or occasionally by program. Basically, any way a scene would be invoked. I can figure out how to trigger a scene when a program runs. I suppose I could have the REST command call the program instead (this is not ideal), which would then run the scene. But it gets a little tricky when I try to run a program when a (for example) light switch changes state. There seems to be no way to do this. Seems like (yet another) very basic functionality that should be there but isn't.

Hi, I feel like I'm missing something obvious here. How do I get a program to run any time a scene is triggered? -PW

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.

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.

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

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?

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.

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. Yes. They are pretty much the same thing. The only difference being that a state variable triggers events. 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.

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.

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.

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

Hello, I have a strange problem. I purchased a ZTS-110 Z-wave thermostat, and it has a bug that is really annoying me. When it is set to metric, the "heating setpoint" value performs the conversion from imperial->metric twice. Meaning that if I set the setpoint to 21C, it will report that it is set to -4C. This is very annoying. I've checked the logs, and the thermostat actually is reporting (in this instance) -4C to the ISY. Another example: At 16C it reports -9C. I've given up trying to get support for this thing (my vendor is useless, Vera hasn't been any help, and my GF threw out the packaging), so here is my question: Is there any way that I can filter that raw value coming in from the thermostat and perform a conversion on it before it populates the thermostat object in the ISY? Like a calibration factor or something? I know that is a lot of "behind the curtain" type stuff, but I really can't think of another way to band-aid this. Any other suggestions on how to get around this particular problem? I really can't justify buying a new thermostat just to fix this annoyance. -Chris