dbuss Posted January 21, 2019 Share Posted January 21, 2019 I have two Stelpro thermostats controlling baseboard heaters. They have worked great. The issue I'm having is trying to change the setpoint using the admin console, Mobilinc, and AGave. When changing the setpoint on the thermostat manually, each click changes the setpoint by +-1 degree. In the admin console, each click of the setpoint of the up/down arrows changes the setpoint by +- .1 degree. To increase the thermostat setpoint by 1 degree using the admin console, the up arrow must be clicked at least five times to get to at least the current setpoint.5 setting. To decrease the thermostat setpoint by 1 degree the admin console down button must be clicked at least seven times to get to at least current setpoint.3 setting. Of course, the desired temperature can be manually entered into the admin console and that changes the thermostat temperature as expected. The larger problem is when trying to change the thermostat setpoint up or down using Mobilinc or Agave, one click of the up or down in button in both apps causes the thermostat setpoint to go to 86 degrees. This is the maximum setting for the thermostat. The only way to get the setpoint changed at this point is to use the admin console or manually change the setpoint on the thermostat. This happened at one of the upgrades, as when I first installed the thermostats this was not a problem. I think it happened when changing from 4.xxx to 5.xxx current I am using 5.014. Is there anything that can be done to remedy this situation? Link to comment
Michel Kohanim Posted January 21, 2019 Share Posted January 21, 2019 @dbuss, The issue with this thermostat is that it does not report the unit of measure properly. Can you please try going back to Celsius and then to Fahrenheit? With kind regards, Michel Link to comment
simplextech Posted January 21, 2019 Share Posted January 21, 2019 I've changed the unit from F to C at the unit and the change is recognized in the Admin Console. Then I change it back to F and again it is recognized. Unit increase from Admin Console is still in tenths which is normal for this thermostat. From the Web portal (udAjax and HAD) any setpoint change goes to the max 86 degrees F. Agave can see the Thermostat and reports the status. Increments in .5 is how Agave changes the temp. However after a change the setpoint jumps to 85.5 (max temp) no matter what is chosen. Increase/decrease and then wait and it will jump the temp to Max like the Web interface does. Alexa nor Google Home can connect/display/control this Thermostat through ISY portal. No testing from Mobilinc currently. ISY 994i ZW+/IR Shipped FW: 5.0.13D - had the same issues Upgraded to 5.0.14 - still has issues Link to comment
dbuss Posted January 21, 2019 Author Share Posted January 21, 2019 I also tried changing from Fahrenheit to Celsius and back to Fahrenheit again with the same results.Stelpro tells me they don't support the ISY controller. So there's no help there.Sent from my SM-N950U using Tapatalk Link to comment
simplextech Posted January 22, 2019 Share Posted January 22, 2019 5 hours ago, dbuss said: I also tried changing from Fahrenheit to Celsius and back to Fahrenheit again with the same results. Stelpro tells me they don't support the ISY controller. So there's no help there. Sent from my SM-N950U using Tapatalk Same with most vendors. They will say they don't support XYZ controller even though they proudly display the Z-Wave Plus certification logo Link to comment
Michel Kohanim Posted January 22, 2019 Share Posted January 22, 2019 @dbuss, Thanks to help from @simplextech, we found a workaround till we find a permanent fix for this issue. The issue is that the thermostat is reporting nonsensical unit of measure and UDAjax (and Alexa) throw an error while the Admin Console simply uses the UOM from ISY and sends it through the REST interface. So, it should be fixed in the next release. With kind regards, Michel Link to comment
simplextech Posted January 22, 2019 Share Posted January 22, 2019 The effort and thanks all belongs with @Michel Kohanim who was answering support and working through a Sunday evening and Monday (Holiday). I have great appreciation for the level of customer support that has been provided around what I consider to be a small issue. I can only imagine at this point what kind of effort would go towards a critical or outage type problem. This was fantastic support. Link to comment
dbuss Posted January 22, 2019 Author Share Posted January 22, 2019 @Michel Kohanim your efforts are greatly appreciated. It was more of an inconvenience than a serious problem. There are so many companies that could benefit greatly by modeling their customer service after yours. Thank you!! Link to comment
Michel Kohanim Posted January 23, 2019 Share Posted January 23, 2019 @dbuss, I greatly appreciate your appreciation @bmercier(Benoit) fixed the issue in the ISY Portal. So, please give it a try. It'll be included in the next build for the local version of UDAjax. With kind regards, Michel Link to comment
simplextech Posted January 23, 2019 Share Posted January 23, 2019 Checked Alexa App and Google Home and they both are working correctly also. Link to comment
dbuss Posted January 23, 2019 Author Share Posted January 23, 2019 It works great with the Alexa app. Link to comment
bmercier Posted January 24, 2019 Share Posted January 24, 2019 9 hours ago, Michel Kohanim said: @bmercier(Benoit) fixed the issue in the ISY Portal. So, please give it a try. It'll be included in the next build for the local version of UDAjax. With kind regards, Michel Just to be precise, the fix for ISY Portal is done, but this only fixes Echo and GH. The ISY Web Access currently is not fixed. Benoit Link to comment
simplextech Posted January 24, 2019 Share Posted January 24, 2019 41 minutes ago, bmercier said: Just to be precise, the fix for ISY Portal is done, but this only fixes Echo and GH. The ISY Web Access currently is not fixed. Benoit @bmercier, yes I noticed the Web Access problem still exists. Link to comment
bmercier Posted January 25, 2019 Share Posted January 25, 2019 I made a fix to ISY Web Access. Can someone try it to make sure it indeed fixes the problem? Link to comment
simplextech Posted January 25, 2019 Share Posted January 25, 2019 22 minutes ago, bmercier said: I made a fix to ISY Web Access. Can someone try it to make sure it indeed fixes the problem? Hooray it's working now! ? Validated changing temp up and down with selector. Link to comment
simplextech Posted May 25, 2019 Share Posted May 25, 2019 On 1/24/2019 at 9:34 PM, bmercier said: I made a fix to ISY Web Access. Can someone try it to make sure it indeed fixes the problem? @bmercier, it's been a while but I ran into this issue with Agave a couple months ago and I just now tried testing this again. No rush on this as it's almost summer, but I'd like to plan for fall/winter to determine if this will be fixed/resolved especially with mobile/tablet app usage as I have plans for installing some tablets around the house this summer. UDAjax - control works fine with the drop down and the heating setpoint is set correctly. HAD - you can click and set the temp but afterwards it automatically jumps the temp to the max setpoint 86F. The issue with HAD I think is also affecting Agave and probably other interfaces as they exhibit the same issue. [EDIT] Just tested with eKeyPad ISY and same issue of any setPoint change jumps the thermostat to 86F Link to comment
Michel Kohanim Posted May 27, 2019 Share Posted May 27, 2019 @simplextech, It seems that those apps are not including the uom. The solution in UDAjax was to always pass the uom (4 or 17). Any app that will use rest commands to change setpoints without specifying the uom will see this behavior, which currently includes HAD, Agave and eKeypad. With kind regards, Michel Link to comment
simplextech Posted May 27, 2019 Share Posted May 27, 2019 1 hour ago, Michel Kohanim said: @simplextech, It seems that those apps are not including the uom. The solution in UDAjax was to always pass the uom (4 or 17). Any app that will use rest commands to change setpoints without specifying the uom will see this behavior, which currently includes HAD, Agave and eKeypad. With kind regards, Michel Michel, Good to know the cause and solution. I would think HAD would be corrected as that's builtin/provided by UDI? I'll work with eKeyPad to get that corrected on their end. Link to comment
bmercier Posted June 14, 2019 Share Posted June 14, 2019 On 5/27/2019 at 4:12 PM, simplextech said: Michel, Good to know the cause and solution. I would think HAD would be corrected as that's builtin/provided by UDI? I'll work with eKeyPad to get that corrected on their end. This is in response to your private mail, I'm posting here for everyone interested in the fix. The best practice is to always pass the uom (unit of measure) whenever setting the heat or cool setpoint. Celsius is '4', Fahrenheit is '17'. This is true for ZWave thermostats, not insteon. So, let's say we want to set the heat setpoint to 23 Celsius instead of doing this: /rest/nodes/<address>/cmd/CLISPH/23 We need to do this: /rest/nodes/<address>/cmd/CLISPH/23/4 Benoit Link to comment
simplextech Posted June 14, 2019 Share Posted June 14, 2019 Great. I'll send this over to eK and to Wes at Mobilinc as they have the same problem. Link to comment
James Peterson Posted January 8, 2020 Share Posted January 8, 2020 On 6/13/2019 at 9:44 PM, bmercier said: This is in response to your private mail, I'm posting here for everyone interested in the fix. The best practice is to always pass the uom (unit of measure) whenever setting the heat or cool setpoint. Celsius is '4', Fahrenheit is '17'. This is true for ZWave thermostats, not insteon. So, let's say we want to set the heat setpoint to 23 Celsius instead of doing this: /rest/nodes/<address>/cmd/CLISPH/23 We need to do this: /rest/nodes/<address>/cmd/CLISPH/23/4 Benoit @bmercier I know this is kindof a late response to this message, but if a setpoint is incremented by half values ie (20.5). What is the appropriate way to set the precision? /rest/nodes/<address>/cmd/CLISPH/235/4?prec=1 /rest/nodes/<address>/cmd/CLISPH/23.5/4 Link to comment
bmercier Posted January 18, 2020 Share Posted January 18, 2020 On 1/8/2020 at 5:07 PM, James Peterson said: @bmercier I know this is kindof a late response to this message, but if a setpoint is incremented by half values ie (20.5). What is the appropriate way to set the precision? /rest/nodes/<address>/cmd/CLISPH/235/4?prec=1 /rest/nodes/<address>/cmd/CLISPH/23.5/4 To my knowledge, precision can't be passed. So I just send as many digits as required after the decimal point. Like this: /rest/nodes/<address>/cmd/CLISPH/23.5/4 This is how I set the value with the uom: const valueWithUom = (t.isInsteon ? newValue * 2 : newValue).toFixed(precision) + ((t.uom && t.uom.length && !t.isInsteon) ? '/' + t.uom : ''); Benoit Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.