open-zwave
open-zwave copied to clipboard
OpenZWave
Use interviewed setpoint byte size and precision in setpoint command
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).
@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'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, [email protected] 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 https://github.com/OpenZWave/open-zwave/pull/2458#issuecomment-739549158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOMT6LJZM6YL6CJI7YORRDSTPKADANCNFSM4TS6KCTQ .
@DoleoR
How can I download the comitted changes to my openhabian installation?
If you are using OpenHAB as your automation software, you will need to seek support from that project. OpenHAB does not use OpenZWave.
Hi! I have 3 Z-TRM3 thermostats running fw 4.0. I experience bug #2435 when running OpenZwave:master. Cyberwizzard:master resolves the issue and I can control my thermostats from homeassistant :)
Hi! I upgraded the firmware on mine to the version that fixes this issue. I used OTA with zwavejs2mqtt to upgrade.
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....
@nechry any reason this pull request is being ignored?
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 :)
Hi @nechry @Fishwaldo , a lot of people wait for this fix. This PR is ignored or under review?
Please provide any information about status please. I am waiting too for this fix.
New bump. Hope someone can find time to merge this! It has been merged in other branches if I'm right...
Waiting for this as well. Multiple Z-TRM3 thermostats waiting to be controlled from HA.
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. Maybe this is useful for migration: https://community.home-assistant.io/t/switching-from-openzwave-beta-to-zwave-js/276723
Dear all,
After reading the whole thread at the Norwegian forum, I tried to go with the OTA firmware upgrade. And luckily this worked! https://www.hjemmeautomasjon.no/forums/topic/6330-z-trm3-target-temperature-f%C3%A5r-ikke-satt/?do=findComment&comment=90958
I performed the firmware upgrade with the setpoint_workaround.zip file provided in that forum-thread. I didn't even have to exclude and include the thermostat in the network.
My system: Domoticz 2021.1 with OpenZwave 1.6 and a Aeon Z-Wave USB stick.
Regards, Steven
@nechry any reason this pull request is being ignored?
yes, @Fishwaldo initially started reviewing this code and he will finish.
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.
