Zwavjs2mqtt addon 0.4.2 caused climate.thermostat entity to become undefined

Configuration Z-Wave
#1

FYI. Updated zwavjs2mqtt addon from 0.4.1 to 0.4.2 causing zwavejs2mqtt to be updated to 1.2.1. climate.thermostat entity of Nortek Security & Control LLC Z-Wave Plus Thermostat GoControl GC-TBZ48 Thermostat became unavailable. Had been OK with deprecated zwave integration, zwavejs addon, and zwavjs2mqtt addon 0.4.1. Opened issue #682 in zwavejs/zwavjs2mqtt repository.

Update: issue closed. Suggested error is in hass core.

Update: 0.4.3 did not fix this.
Update: Not fixed by 0.4.4 (zwavejs2mqtt v1.2.3).
Update: Not fixed by 0.5.0 (zwavejs2mqtt v2.0.0).

Update: Fixed by core-2021.3.0 and zwavjs2mqtt addon 0.6.0.

#2

I have the same problem except that I have 4 Heatit Z-TMR3 floor heaters. The climate was working in 4.1 but then become unavailable in 4.2-4.3.

I also have a problem that the energy reporting on them is not updating value unless you send a refresh value request manually. In which case they will report the value but then not update again by themselves.

#3

If you have a snapshot from before updating, do a partial snapshot restore of just the addon. If you don’t have a useful snapshot, you can still ssh to hass.io to update the addon to a specific version.

If you haven’t seen it, look for the “Auto Backup” integration in HACS.

Since zwavejs2mqtt addon 0.4.1 works correctly for me I probably won’t update it until some future release of the official zwavejs addon.

#4

Same with Eurotronic Spiri-Z - seems that something changed in code of node_js addon on HA core.

#5

Jakub, if you have a good handle on the problem, please create an issue for the core developers.

#6

Same here with Eurotronic zwave radiator valves climate entity unavailble, after restoring previous version it is working good.

#7

Issue appears to be present in 0.4.3 as well. I’ve also rolled back to 0.4.1 for the time being.

#8

Jeff, already found git issue with thermostat entity and if i’m correct it has been resolved and scheduled for next update…but i dont’t know if this will be in core update or smth else? :slight_smile:

ZwaveJS Eurotronic Spirit Z-Wave Plus climate entity not detected ¡ Issue #46781 ¡ home-assistant/core (github.com)

also I’ve created issue with sending Boost command couses integration to hang

Z-Wave JS - Setting thermostat to full power (boost) causes add-in to stop working ¡ Issue #46357 ¡ home-assistant/core (github.com)

#9

Thanks, Jakub.

#11

Not fixed by 0.4.4 (zwavejs2mqtt v1.2.3).

#12

confirmed. We need to wait for HA core update as I unterstood :frowning: luckily we have warm days now in Poland :slight_smile:
Switching from OZW Beta was to fast for me :slight_smile:

#13

So what have you all done? I installed the JS container (not in HA) when it was announced with 2020.2, and was working perfectly, super easy migration. I personally went back to OZW Beta at this point, climate control is a pretty important part of my HA setup…
I did like the JS UI, much more pleasant than the VNC connection to OZW’s outdated interface, but that’s a detail!

#14

0.4.1 works fine, but nothing since then including 0.5.0.

#15

You can switch to HA Core Beta (core-2021.3.0b6 ATM), or wait till tommorow for stable release which should fix climate control.

#16

Fixed by core-2021.3.0 and zwavjs2mqtt addon 0.6.0.

1 Like
#17

Out of curiosity.

Do all the functions of the valves work?
Can we also manually control the valve? (0-100%)

I currently use that functionality with OZW via mqtt, but I would prefer to do it directly.

I use it as a workaround when using an external thermometer. It would be ideal if I can also use that functionality in stead of manually controlling the valves, but apparently the way Eurotronic set that up is not ideal.

#18

I’ve just moved from OZW Zwavejs2mqtt and Z-Wave JS Integration.

With OZW I controlled the valves via mqtt but moving to Z-Wave JS I can’t as the Manufacturer Specific thermostat mode is missing which is what you need to manually control the valves.

#19

I got it working in the end.
I now completely migrated from OZW to ZwaveJS (w00t! :smile:)

ZwaveJS can’t set the valves to ‘Manufacturer specific’. The details are described in this item. (it’s about another valve, but the Eurotronic valves are also mentioned)

Missing Manufacturer Specific mode and valve control for Aeotec TRV ¡ Issue #45703 ¡ home-assistant/core ¡ GitHub
It boils down to the fact that the valves don’t advertise Manufacturer Specific option to zwave-js. To ‘resolve’ it, either Eurotronic needs to provide a firmware update. Or zwave-js needs an update for ‘device specific quirks’ which would allow to push settings to the valve that the valve itself doesn’t advertise it can handle.

Add compat flag to override values reported by a device ¡ Issue #1625 ¡ zwave-js/node-zwave-js ¡ GitHub

I ‘resolved’ (more a delicate workaround) my issue by setting the valves to ‘Manufacturer specific’ using the OpenZwave addon. (didn’t need the integration of course).

So what I effectively did:

  • Disable ZwaveJS Integration (which also shuts down the ZwaveJS addon)
  • Start MQTT broker (I don’t have it running by default)
  • Start OpenZwave addon
  • Change the settings to ‘manufacturer specific’ using ozw-admin (the gui for OpenZwave)
  • Shut down OpenZwave addon
  • Shut down MQTT broker
  • Reenable ZwaveJS Integration (which also starts up the ZwaveJS addon again)

The ZwaveJS integration also provides a ‘numeric’ entity which controls the radiator valve’s position.
The only I need to keep in mind, is to not touch the ‘Mode’ in HA, else I can’t change it back to Manufacturer specific without the above workaround.

Edit: I have put my setup under the Community Guides:
Eurotronic Spirit radiator valves with external temperature sensors in ZwaveJS - Community Guides - Home Assistant Community (home-assistant.io)

#20

This is quite the extreme solution. It would be much simpler to switch to the zwavejs2mqtt addon, which provides a control panel that allows you to set the manufacturer specific value. Enable the MQTT gateway setting if you want the option of setting the value from MQTT (e.g. in an automation).

#21

I completely agree with you. What you’re describing would be the ideal solution
However. The ZwaveJS driver doesn’t support the required functionality yet. The MQTT-part can only do things that the driver supports. It’s not a matter of a lacking UI.

Edit:
I noticed my reply was a bit short, so let me elaborate:
The ZwaveJS driver currently does not support setting settings that are not advertised by the device.

For example. This is the current status of my TRVs:
(tiny part of the dump created by the integration)

              {
                "endpoint": 0,
                "commandClass": 64,
                "commandClassName": "Thermostat Mode",
                "property": "mode",
                "propertyName": "mode",
                "ccVersion": 3,
                "metadata": {
                  "type": "number",
                  "readable": true,
                  "writeable": true,
                  "min": 0,
                  "max": 255,
                  "states": {
                    "0": "Off",
                    "1": "Heat",
                    "11": "Energy heat",
                    "15": "Full power"
                  },
                  "label": "Thermostat mode"
                },
                "value": 31
              },

My valve is currently set to value ‘31’ (which is “Manufactorer Specific” setting). But this setting is advertised as a possible value. OpenZwave has a mechanism which allows extra settings to be added that the device doesn’t propagate, so that it can be added manually. ZwaveJS does not have that option yet.. This means that the GUI will not show the option in the interface, nor via MQTT, since the driver itself doesn’t support it yet.

The above given. Ideally the vendor would just publish a firmware update, so that it does advertise the relevant setting.