Hi All: I’m revisiting this, as I shelved it my mind and never was able resolve it. I tried to contact the manufacturer and never got a response. I thought that the unit itself may have been defective, so I got another one and experienced the same behavior.
It really would be nice to be able to use the additional parameters and take advantage of this powerful thermostat, so I’m taking another stab to see if anyone has an idea.
As discussed in the original thread, the device is reporting the values shown in the screenshot for the parameters identified, which are out of range. If you attempt to provide a value as the binding advises (e.g. “80” for maximum cool setpoint), the device ignores the command.
I did an experiment and copied ‘704771072’ from the ‘minimum cool setpoint’ and pasted that into the ‘maximum heat setpoint’. It worked! The device accepted the value and set the ‘max heat setpoint’ to 50 degrees, which is what the ‘minimum cool setpoint’ was. So, ‘704771072’ is somehow communicating ‘50’ to the thermostat. If I can find out how to convert expected values into the apparent 9-digit value the device is expecting, it looks like I can set the parameters.
Think in hexadecimal and with bit masking. I ran few a few of the numbers. They all have the pattern
2A0xxx00 where xxx is the temperature. For instance 704771072 = 2A01F400; 1F4 = 500 or 50.0 degrees f. I calculate the max cool and heat are 95.0 and the min heat is 35.0.
@apella12 Thank you so much! You are exactly correct and have successfully given me a workaround!
The last parameter that leaves me puzzled is how to work around the calibration temp when it comes to negative values. For example, using your method, I can enter ‘704648192’ into the calibration temperature (for a value representing 2 degrees) and it works! the thermostat temp increases 2 degrees. The question is: How to handle negative values with this method in order to calibrate the temp down 2 degrees. I don’t know how to represent a negative decimal value in this. Any thoughts?
I tried prefacing the entire value as a negative (e.g. -704648192), but it didn’t work.
I’m guessing, but zwave is supposed to use signed values (pos 000 - 7FF), so -.1 might be FFF. -2 would be FD0.
Edit: just playing with an online calculator and I’m not an expert, but these may actually need to use 4 places, so ffec might be worth a try too. (-2.0)
Edit2: Sorry I couldn’t help on the negative number. Just not an area where I have any real knowledge. Anyway just to be clear I was suggesting 2AFFEC00 or 721415168 as -2.0
I applaud and really appreciate the effort @apella12! Unfortunately, both did not work. I’ll continue to experiment and see if anyone else chimes in. You’ve helped a great deal though, thank you.
Do you have a manual that describes the parameters? This doesnt seem to be defined in the manual that’s attached to the database, so it’s hard to comment - other than to say that it looks like the database is wrong!
We could just change the min/max values to allow the full 4 byte range. I’m pretty sure that what @apella12 described will be at least partly correct - the bit in the middle seems to be the setpoint. The bigger question is what the rest of the 4 bytes does, and without a manual, you can only guess, and this might result in a bad configuration of the device…
Thanks, @chris . The manual does not go into details about the parameters: The only details I’ve been able to find in that area are from Z-Wave alliance. We’re also not alone, as I’ve found several threads on this very issue in smart things and home assistant forums. Those users have also reported being stonedwalled from the manufacturer. The manufacturer told me that they only support customers using building36 or alarm.com systems. I’ve opened threads in the ST and HA forums to see if and how they’ve ironed this out.
How to represent negative temperature values for calibration seems to be the only remaining unknown function.
I have another guess for you. Reasonable calibration may only require one byte so instead of FFEC, just try 00EC for a signed 8 bit Hex (2A00EC00 = 704703488)
You were almost there, but you got me to the solution! the full 2’s complement is actually what it wanted, assuming a change to the format (2A + 4 digit temp value in tenths of degrees + 00). So, for -2, it would be 2AFFEC00 = 721415168. I sent 721415168 to the unit and it worked! I can’t thank you enough @apella12 , I can now really use these units. @chris , I don’t know if this is enough information to carry out a DB update or what the options are. Let me know if I can help.
I’m writing this up to tag it as a solution to help anyone looking to solve this in the future.
To enter temperature values in device parameters, you need to send a 9 digit value converted from a masked HEX string using the below steps.
Example: We want to set the min cool setpoint to 60 degrees F.
Since we can set temperature in tenths of degrees, convert 600 into HEX, this value is 258.
Using this HEX format, "2A + XXXX + 00, replace the middle part with the HEX value for the temperature. Add zeros before the value when less then 4 digits. In this case, the value would be 2A025800.
Convert the entire HEX string to decimal. 2A025800 = 704796672
Enter the converted value, 704796672 in this example, into the parameter field.
To enter negative values for the purposes of temperature calibration, convert the temperature to a signed HEX 2’s complement value. e.g. -2 = FFEC.
There are two cautions/mysteries remaining that only others with the device can help resolve.
Is the leading 2A byte the same for all devices? Does it have some meaning (2 stage, c-wire, no AC, etc.)
Same for the trailing 00 byte. My guess here is 00 is degrees F and suspect maybe 01 for degrees C, but it could be something else. Does the device even support degrees C?
Anyway glad I could help. (I just learned about signed Hex in January when the strict validation was being rolled out).
I guess it should be possible to create a parameter for this, using a mask of FFFF00. This will allow the user to type in the value directly - of course it can’t be calibrated so you can’t account for the /10, but otherwise I think this should work ok.
! Unfortunately, both did not work. I’ll continue to experiment and see if anyone else chimes in. You’ve helped a great deal though, thank you.