Smarthome/INSTEON Thermostat support

[wayneph]

I've started digging into my Thermostats (Smarthome/INSTEON) and trying to figure out why they were just showing up with the temperature and normal On/Off buttons. It appears the Control Type doesn't match any of the items in isyrest.js. I've included the nodes below for all 3 parts of a single thermostat. I also attached an image of how they look on the screen with the controls "grouped" and "ungrouped" in ISY.

 

Looking through the code, I found the line where I needed to add "5.11" in order to set tableItem.specControls="stat". That at least got the buttons showing up. It also appears the values for my thermostat are on the 0-255 scale as opposed to a "normal" Celsius or Fahrenheit. After I took this screenshot, I set the max up to 255 and got the actual values represented in the nodes below. I have not gotten anything to change on the thermostat, but I'll have to dive into that in the next few days. It may be more isyProxy related than the acutal HAD code.

 

As an enhancement request, can the "min" and "max" (and apparently a conversion value) for the Thermostats be options configurable from the custom js file? That way if I don't want anyone going above or below a certain value, I can restrict things? (I can probably play with some of the things directly in the file, but I don't want to stray too far from your version so that I can get new features down the road as well.)

 

Ungrouped Thermostat

AA BB CC 1
Downstairs Thermostat - Main
63364
5.11.13.0
true
0
0
0
AA BB CC 1
C08






AA BB CC 2
Downstairs Thermostat - Cool
63364
5.11.13.0
true
0
0
0
AA BB CC 1
C09



AA BB CC 3
Downstairs Thermostat - Heat
63364
5.11.13.0
true
0
0
0
AA BB CC 1
C10

Grouped Thermostat

11 22 33 1
Upstairs Thermostat - Main
63364
5.11.13.0
true
0
0
0
11 22 33 1
A05






11 22 33 2
Upstairs Thermostat - Cool Ct
11 22 33 1
5.11.13.0
true
0
0
0
11 22 33 1
A06



11 22 33 3
Upstairs Thermostat - Heat Ct
11 22 33 1
5.11.13.0
true
0
0
0
11 22 33 1
A07

[bmercier]

I've started digging into my Thermostats (Smarthome/INSTEON) and trying to figure out why they were just showing up with the temperature and normal On/Off buttons. It appears the Control Type doesn't match any of the items in isyrest.js. I've included the nodes below for all 3 parts of a single thermostat. I also attached an image of how they look on the screen with the controls "grouped" and "ungrouped" in ISY.

 

Looking through the code, I found the line where I needed to add "5.11" in order to set tableItem.specControls="stat". That at least got the buttons showing up. It also appears the values for my thermostat are on the 0-255 scale as opposed to a "normal" Celsius or Fahrenheit. After I took this screenshot, I set the max up to 255 and got the actual values represented in the nodes below. I have not gotten anything to change on the thermostat, but I'll have to dive into that in the next few days. It may be more isyProxy related than the acutal HAD code.

 

As an enhancement request, can the "min" and "max" (and apparently a conversion value) for the Thermostats be options configurable from the custom js file? That way if I don't want anyone going above or below a certain value, I can restrict things? (I can probably play with some of the things directly in the file, but I don't want to stray too far from your version so that I can get new features down the road as well.)

 

Hello Wayne,

 

Great, I will make sure to add this device type. Should be fixed in the next version.

 

I think I know what you mean with the scale. By looking at the values vs formatted values, it looks like the values are twice the degrees. Probably due to the fact the the resolution is .5 degrees. I think there will be changes required in HAD to support it.

 

Yes, the min and max should be easy to implement. I will do for the next version.

 

Question; what do you mean by grouped, and ungrouped thermostat? To me, they looked the same.

 

Thanks,

 

Benoit.

[wayneph]

The difference in grouped vs. ungrouped is how the devices are related in ISY and the screenshot attached is how it looks in the Admin console. The two devices with "Main" in the name will always show up. Depending on the grouping setting, it appears that HAD doesn't see the "sub-items". On the original Screenshot, there are 3 controls for the Downstairs Thermostat, but only 1 control for the upstairs thermostat. In the node XML, the parent element shows the grouping differences related to the screenshot. I am seeing something similar for my KeypadLincs and FanLincs. In ISY, I have the "grouped" option turned on, so instead of 3 (or 8 for my KPLs) devices I just see a single device.

 

For the scale, I only have one thermostat type, so mine all look alike. I don't know if assuming "value/2=format" would always be valid if someone was in Celsius or using a different device. I'd have to think through the math involved, but could we determine the appropriate "ratio" by checking Temp, Heat SetPoint and Cool SetPoint? If all 3 match consistently, the scale could be automatically calculated. I just don't know if Celsius and Fahrenheit would play well with the same rules since there is a constant involved in the conversion.

[wayneph]

I also just determined (of course right after I posted) that the two Child Devices are how I can tell if the system is actually running. The "Main" device just reports the current temperature, mode and set points. If the thermostat is actually doing something, the other two related devices change their state from "Off" to "On".

 

As an example:

AA BB CC 1 is the Downstairs - Main device which gives "setting" information.

AA BB CC 2 is the Cool Control - ST = On if A/C running

AA BB CC 3 is the Heat Control - ST = On if heater running

 

I'm not sure how I would want to control this, but I think it would be cool to change the "green" color of the Main Temperature to Red if the Heater is on and Blue if the A/C is on. (Or come up with another way to indicate that the system is actually doing something in addition to showing the temp.)

[wayneph]

I was able to determine why the buttons weren't doing anything. In the spinnerChange function, the code is pulling in statid to determine the Insteon device ID which contains underscores. I changed the following line and was able to get updates to post back to ISY.

 

FROM: var id = $(this).parent().parent().parent().attr("statid");

TO: var id = $(this).parent().parent().parent().attr("statid").replace(/_/g, ' ');

 

I don't know if this is the best place to do the translation, or if there is another function that would be more appropriate, but for now it is working as I need it.

[bmercier]

Hello Wayne,

 

Could you try the following?

http:///rest/nodes/AA BB CC 1/cmd/CLISPH/130

 

I would like to make sure that it gets set to 65 (Temp x 2).

 

So far, I ajusted the code to:

- Support your thermostat cat/subcat.

- I also added configurable limits for high/low (independently for cooling and heating)

 

For the case of the temperature value being the double, I think the easiest will be to compare the value of a setpoint, and compare it to it's formatted value. If it is double, we know for sure. That would handle all cases. I just need to make sure that I can use temp x 2 as the command to send.

 

I would not try to convert from C to F or vice-versa. HAD does not need to know either. The setpoint given is the default setpoint give by ISY. We increase or decrease by 1. The limits are user configurables, so it will be up to the user to select appropriate limits based on the UOM used by his thermostat. I have set the default limits to be from 5 to 80, large enough no matter if using Celsius or Fahrenheit (Basically no limits).

 

 

FROM: var id = $(this).parent().parent().parent().attr("statid");

TO: var id = $(this).parent().parent().parent().attr("statid").replace(/_/g, ' ');

 

Good catch. I'm testing with ZWave thermostat devices, which don't have spaces in their address, but do have an underscore.

 

Would you mind testing this version instead?

var id = $(this).parent().parent().parent().attr("statid").replace(/\ /g,'_');

 

The one you suggested breaks the code when using ZWave adresses. I think this one would work in all cases.

 

Thanks,

 

Benoit.

[wayneph]

Good news and bad news for you...

Could you try the following?

http:///rest/nodes/AA BB CC 1/cmd/CLISPH/130

The link you provided acts exactly as expected. While I was playing with it, I didn't pay attention to if 131 rounded up or down, but it probably won't matter once the scroll is based on the formatted values since it would probably jump strait from 130 to 132 with a single click.

Would you mind testing this version instead?

var id = $(this).parent().parent().parent().attr("statid").replace(/\ /g,'_');

Unfortunately this regex left the Underscores in the name. 'AA_BB_CC_1' stays like 'AA_BB_CC_1' instead of becoming 'AA BB CC 1' which is what INSTEON needs. In my case, I could update isyProxy to replace "_" with space and handle outside of HAD, but that won't be an option for someone hosting directly on the ISY.

 

It almost seems like using Underscores to clean up the IDs won't be an option if there are devices that actually use underscores in the ID. There would not be an easy way to distinguish between an underscore that is valid and an underscore that needs to go away. In order to guarantee the real ID, another attribute would need to be used to determine if a replace needs to happen. I don't know if it would make sense to add an "isyID" next to "statID" that remains unchanged, or to have logic based on the category/subcategory combination for determination a the device type level.

[bmercier]

It almost seems like using Underscores to clean up the IDs won't be an option if there are devices that actually use underscores in the ID. There would not be an easy way to distinguish between an underscore that is valid and an underscore that needs to go away. In order to guarantee the real ID, another attribute would need to be used to determine if a replace needs to happen. I don't know if it would make sense to add an "isyID" next to "statID" that remains unchanged, or to have logic based on the category/subcategory combination for determination a the device type level.

 

Hello Wayne,

 

I need to bring the real address up to this function. Not just the "id".

 

At initialization time, when I convert from adresses to id, I replace spaces by underscores.

 

In the case of Zwave device, it does nothing because it does not have spaces. The address == the id.

 

In the case of an insteon device, an address like AA BB CC 1 will have an id of AA_BB_CC_1.

 

That's a design problem I need to fix.

 

I will correct that this weekend, and will be ready for the next release.

 

Thanks for catching that.

 

Benoit.