Use interviewed setpoint byte size and precision in setpoint command #2458
Conversation
Added missing value for the CreateValueByte call to actually retain the size of the field
Added precision override support
Augmented AppendValue to have a precision override
Apply cached setpoint precision setting to the setpoint command
Added SetPointPrecision type to the thermostat enum to hold the minimum precision required by the thermostat
… reworked GetAppendValueSize
This reverts commit 72a626b.
… the hard-coded instance index
|
@Fishwaldo anything I can do to help in the inclusion of this pull request? |
|
@nechry anything I can do to help in the inclusion of this pull request? |
|
I need this fix too. Can someone approve this PR? |
|
I‘m also interested. What‘s missing for this PR? |
|
I'm also very interested. However, i also have an addidtional question. How can I download the comitted changes to my openhabian installation? Do I have to modify the files, or can I "download" them somehow? |
|
Unfortunately downloading the files is not enough. Assuming your home
automation is based on open zwave, the entire program needs to recompiled
after this is merged.
Once that is done, you'd be able to just get this through a normal update
to the open zwave core.
…On Sun, 6 Dec 2020, 20:16 Roy, ***@***.***> wrote:
I'm also very interested.
However, i also have an addidtional question.
How can I download the comitted changes to my openhabian installation? Do
I have to modify the files, or can I "download" them somehow?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2458 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOMT6LJZM6YL6CJI7YORRDSTPKADANCNFSM4TS6KCTQ>
.
|
If you are using OpenHAB as your automation software, you will need to seek support from that project. OpenHAB does not use OpenZWave. |
|
Also hoping this will be merged soon 👍 |
|
+1 |
|
+1, right now I cannot set the thermostat from Domoticz... |
|
+1 |
|
Hi @Fishwaldo |
|
Hi! |
|
Hi! I upgraded the firmware on mine to the version that fixes this issue. I used OTA with zwavejs2mqtt to upgrade. |
|
@nechry any reason this pull request is being ignored? |
|
I'm also wondering. Hope this can be merged, so I can use my device. I myself have not the knowledge to resolve the conflict or build/compile it.... |
yes, @Fishwaldo initially started reviewing this code and he will finish. |
|
Is there an eta on this? Would really appreciate this fix, but may go with the "experimental update" if it drags on :) |
|
Just for reference zwave-js/node-zwave-js#1443 |
|
Hi @nechry @Fishwaldo , a lot of people wait for this fix. Please provide any information about status please. |
|
New bump. Hope someone can find time to merge this! |
|
Waiting for this as well. Multiple Z-TRM3 thermostats waiting to be controlled from HA. |
switch over to zwave_js in home-assistant. It's working fine with the Z-TRM3. |
|
Dear all, After reading the whole thread at the Norwegian forum, I tried to go with the OTA firmware upgrade. And luckily this worked! I performed the firmware upgrade with the setpoint_workaround.zip file provided in that forum-thread. My system: Domoticz 2021.1 with OpenZwave 1.6 and a Aeon Z-Wave USB stick. Regards, |
|
Any particular reason why this PR isn't reviewed and merged? |
Seeing that @Fishwaldo has not contributed to this project since dec 2020, maybe someone else should take over the review? Kind of frustrating that tons of PRs that was created after this one have already been merged. |
HeatIt has a thermostat called Z-TRM3 (and perhaps others from the same manufacturer) which does not work with OZW currently.
Investigation by the manufacturer and various customers resulted in the conclusion that HeatIt implemented the setpoint command in such a way that it requires 2 byte setpoint values, as that is the field size advertised in the capability report (for both min and max temp they use 2 bytes in that report). They claim this is how they have had it certified for Z-wave compatibility and thus changing this is not possible without losing certification. At the same time, all the sold units so far and those in stores already are using firmware with this limitation. Also see #2435 for more information and links to other sources on this topic.
So to lower the threshold and prevent users from having to do firmware updates (which in some cases seems to require manufacturer specific programming cables), I patched OZW instead.
There is now a new compat flag called "EnforceMinSizePrecision" (bool) which enables caching the minimum byte size and minimum precision (as that was also indicated in the failure analysis report from HeatIt as attached to #2435) as received during decoding of the capability report. If these values are present when calling SetPoint, they will be applied to enforce the value has at least that many bytes and the desired precision.
For all thermostats which do not have this, the default is to use the minimum number of bytes and minimum required precision, as was before.
On my search for information while initially troubleshooting I think I also found other thermostats which might have the same issue but I can not find it in my history so these can receive the compat flag later in their XML.
How to apply for existing users: refresh the node so the XML is reloaded, then exclude each Z-TRM3 and include it again. This is mandatory as the limits are only sent to OZW when including the node, so existing nodes need to be re-added. (Unless someone knows of another trick of getting the setpoint capability report after refreshing the XML).