Zwave thermostate climate entity gone since updating to 0.103.x #30180
Comments
|
Hey there @home-assistant/z-wave, mind taking a look at this issue as its been labeled with a integration ( |
|
I think it is related #30067 |
|
Another user with the SRT321/Horstmann HRT4ZW thermostat - I have two. These are no longer recognised by climate. I've tested a fresh install of the latest hassio release and no climate entities are created, though the thermostats do show up as devices. |
|
I have the same issue with the SRT thermostats since updating - the climate/setpoint entity is no longer part of the entities shown for the thermostat. Only temperature, switch and battery level. I'm not a programmer so can't help much there but let me know if any logs etc would help |
|
Having read a bit more this looks to be similar to this issue which has a fix in progress. I've not tried the fix yet but will do when I get some time. |
|
In my case this custom component not helped :( My file: |
|
I realised that fix was included in the 103.1 update so this does seem like a different issue. I've not had any luck with any of the other threads/issues despite it looking quite similar to quite a few other issues. I've attached some extracts from my OZW log and ZWCFG files in case they are of use in diagnosing the issue. |
|
in the meanwhile I went back to 0.102.3 and I have the climate entity again, so definitely a 0.103 issue |
|
Just to update the thread, I updated to 103.5 and this issue is still there. There wasn't anything to suggest otherwise in the release notes but thought it was worth confirming it. I've rolled back to my last snapshot which was 102.1 and the climate entity for my SRT321 is back again. |
|
@oandrew @basnijholt @Santobert Would you mind having a quick look at the zwcfg.log extract I uploaded and see if there is anything "special" about this device which wouldn't work as expected with any of the changes you made to the zwave\climate.py code? I've tried to look myself but I'm a bit lost so I thought it was worth asking you all as you'll be most familiar with the individual blocks you've worked on. I'm might be well off the mark as I am at my limit of debugging skills but I noticed that these thermostats accept only a single set point and have COMMAND_CLASS_THERMOSTAT_MODE with two options, HEAT and OFF. I'm not sure if that is normal as it looks like the most recent code expects there to be multiple set points where the COMMAND_CLASS_THERMOSTAT_MODE is present? I'll keep looking through the code and see if I can isolate the issue any further but any pointers in the meantime would be really appreciated. Thanks! |
|
@zacpotts Take another look at #29844, starting at this comment. After that comment are suggested fixes. Either modify your XML file, or try the custom component that has a code fix. Doesn't look like that fix has been submitted as a PR yet. |
@allmoney What exactly is your problem? The custom component is not going to help you, it is for a different type of thermostat. Do you have a climate entity? I am guessing your temperature settings are not working? If not, try a modification to your zwcfg*.xml file. First, shutdown HA. Then change this: <CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="2" request_flags="2" innif="true" base="1" typeInterpretation="B">
<Instance index="1" />
<Value type="decimal" genre="user" instance="1" index="2" label="Cooling 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
<Value type="decimal" genre="user" instance="1" index="4" label="Unused 4" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
<Value type="decimal" genre="user" instance="1" index="8" label="Dry Air" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
</CommandClass>to this: <CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="2" request_flags="2" innif="true" base="0" typeInterpretation="A">
<Instance index="1" />
<Value type="decimal" genre="user" instance="1" index="1" label="Heating 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
<Value type="decimal" genre="user" instance="1" index="7" label="Furnace" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
<Value type="decimal" genre="user" instance="1" index="11" label="Heating Econ" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" />
</CommandClass>Then start HA again. |
Thanks @kpine I had thought that the PR #29955 which is tagged on that issue had incorporated this custom component but looking at the zwave\discovery_schemas.py in @oandrew 's "non-specific" branch you're right and this isn't merged into 103.1. I'll run this when I get home later and report back. |
|
@kpine thanks for your answer! But it works now with 2 problems:
In manual I fount 2 parameters №5 and №6: Parameter No. 5 (1 byte) - The maximum width of the corridor with temperature Parameter No. 6 (1 byte) - Maximum allowable temperature @kpine please help to fix it! I can't understand how :( |
|
Thanks for pointing that out. I've not taken the full custom component as I wasn't sure what else was in it, and to be honest I wanted to understand better the issue. Having looked at the custom component though, it was a simple as adding the "SPECIFIC_TYPE_NOT_USED" to the thermostat climate discovery section (same as in the custom component). I've done this with the latest zwave component from the master branch and all works perfectly. It would be good to see if we can merge this into the master branch if it is really that simple - I'm not sure whats involved with that though as I've never done anything like that before. Also, if that is the only change in the non-specific branch @oandrew has created, I guess its his change to merge....maybe there is a reason it's not been merged when #29955 was. |
|
Sounds like quite a different issue there than this one, might be worth starting a new one? |
|
I have the Horstmann HRT4-ZW and I've tried several changes to fix this, but it still isn't working. No climate device discovered. I have removed the unit, factory reset and added back into z-wave & HA, but just not discovering correctly. The only thing I managed to get working was when changing the <typeInterpretation="A"> to A from B, the switch entity was discovered, but no climate entity. Is this a permanently broken issue with no fix? It seems to have been a braking change since early December and now we're in mid Jan and still no fix pushed out to production? |
|
I have just tried downloading the modified zwave component from #29844 (comment) and when I updated to 103.6 the climate component was there |
|
I've been using the modified Zwave Component pointed on this comment: #29844 (comment) but after upgrading to 0.104.1 I have had to remove it from my custom_components folder as it generated an error and the Zwave network didn't start. |
|
You should copy the zwave component from the 0.104.1 release, and then modify the file to fix the bug. It's a one line change. As another workaround, I think if you modify the zwcfg*.xml file you won't need to bother with the custom component, and it will stick between upgrades, as long as the cache file is not lost. |
|
thanks kpine, copying the zwave component and adding the line in the py file worked for me. I'm not sure about how to modify the zwcfg*.xml file but I will take a look on it. thanks again, |
|
is the fix going to be included in the next versions? |
|
I was thinking about going to create a PR for this but, other than my massive inexperience, I'm a little conscious that the extra line which is working for me was included in the fork from @oandrew for fixing Legacy Z-Wave Thermostats as @kpine notes above, but was for some reason left out of the PR which was submitted for that item....I can't help but wonder why? Is it a bit of a fudge to make it work but falls down if you have other devices which use the specific type of "NOT_USED"? In the meantime I just keep copying the latest Z-Wave Component whenever I upgrade and changing that one line, not ideal, but at least I know I'm not breaking everyone else's set up. I really don't understand the code enough to propose a PR for something like this. Given I don't understand really why it works, it's probably not a good idea for me to propose other people do it :-) |
|
Just to update the thread, I still have this issue with 107. Same fix applied with a modified z-wave component. |
|
FYI This has been working for me since 0.103 so I've submitted a PR for this: #35609 |
|
Closing, as this looks to be fixed with #35609 |
Home Assistant release with the issue: 0.103.4
Last working Home Assistant release (if known): 0.102
Operating environment (Hass.io/Docker/Windows/etc.): hassio in docker (Ubuntu Server 18.04 LTS)
Integration: Z-Wave / Climate
https://www.home-assistant.io/integrations/zwave/
Description of problem:
I have a Zwave.me ZME_UZB1 stick (EU band) and a Secure SRT321 (known otherwise as Horstmann HRT4-ZW) thermostat. Until updating to 0.103.x I had a climate entity, a temperature sensor entity and a switch entity. Since I updated to 0.103 the climate entity is gone, therefore I don't have access to the current thermostat setpoint value in HA anymore. Since my thermostat has manual controls I'd like to have a feedback on the actual setpoint values, not just the one that I used to update occasionally from HA. I also don't know how could I update the setpoint now that I don't have a climate entity, since the climate.set_temperature service also needs a climate entity. When looking at Settings/Integrations/Z-wave, the thermostat still lists the climate entity but in grey and disabled with no way of bringing it back. When I went back to 0.102 it was all right, then on 0.103.3 or 0.103.4 the climate entity is missing.
The text was updated successfully, but these errors were encountered: