dbuss Posted January 21, 2019 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?
Michel Kohanim Posted January 21, 2019 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
simplextech Posted January 21, 2019 Posted January 21, 2019 (edited) 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 Edited January 21, 2019 by simplextech
dbuss Posted January 21, 2019 Author 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
simplextech Posted January 22, 2019 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
Michel Kohanim Posted January 22, 2019 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 1 1
simplextech Posted January 22, 2019 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. 5
dbuss Posted January 22, 2019 Author 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!!
Michel Kohanim Posted January 23, 2019 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
simplextech Posted January 23, 2019 Posted January 23, 2019 Checked Alexa App and Google Home and they both are working correctly also.
bmercier Posted January 24, 2019 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
simplextech Posted January 24, 2019 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.
bmercier Posted January 25, 2019 Posted January 25, 2019 I made a fix to ISY Web Access. Can someone try it to make sure it indeed fixes the problem? 1
simplextech Posted January 25, 2019 Posted January 25, 2019 (edited) 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. Edited January 25, 2019 by simplextech 2
simplextech Posted May 25, 2019 Posted May 25, 2019 (edited) 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 Edited May 25, 2019 by simplextech
Michel Kohanim Posted May 27, 2019 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
simplextech Posted May 27, 2019 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. 1
bmercier Posted June 14, 2019 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 2
simplextech Posted June 14, 2019 Posted June 14, 2019 Great. I'll send this over to eK and to Wes at Mobilinc as they have the same problem. 1
James Peterson Posted January 8, 2020 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
bmercier Posted January 18, 2020 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
Recommended Posts