OpenZwave to Zwave-JS-UI problems with Eurotronic Spirit and Philio PAT02-1B

[toxwa]

I am trying to migrate from openzwave to Zwave-JS-UI and most of it is working well. There are 2 types of devices I have problems with:

1. Eurotronic Spirit radiator valves: I used to set thermostat mode to "manufacturer specific" with some scripts. But now that I moved to Zwave-JS-UI Domoticz adds the mode as a switch with "Off", "Heat"and "Cool" as options. In the web interface of ZWave-JS-UI I can see and edit all the options I used to have in Domoticz with openzwave. If I change it to "Off" or "Heat", the switch in Domoticz changes as well. Why don't I get all the options from Zwave-JS-UI in Domoticz?

• Philio PAT02-1B temperature and RV sensor: I can see the sensor in Zwave-JS-UI but it is not recognized. The node info in ZWave-JS-UI shows 0xXXXX 0xXXXX-0xXXXX as device Identifier. I can see the humidity and temperature values changing, but nothing is sent to Domoticz.

Does anyone know how to fix this?

[toxwa]

The Philio problem is fixed by waiting. The device sends temperature and humidity data based on changing values, but only wakes up completely once a day.

The radiator valve is still a problem. I can see this code in zwave-js-ui under node>home assistent:

Code: Select all

{
  "type": "climate",
  "object_id": "thermostat",
  "values": [
    "64-0-mode",
    "49-0-Air temperature",
    "67-0-setpoint-1",
    "67-0-setpoint-11"
  ],
  "mode_map": {
    "off": 0,
    "heat": 1,
    "cool": 11
  },
  "setpoint_topic": {
    "1": "67-0-setpoint-1",
    "11": "67-0-setpoint-11"
  },
  "default_setpoint": "67-0-setpoint-1",
  "discovery_payload": {
    "min_temp": 8,
    "max_temp": 28,
    "modes": [
      "off",
      "heat",
      "cool"
    ],
    "mode_state_topic": "zwave/Badkamer/Radiatorkraan/thermostat_mode/endpoint_0/mode",
    "mode_command_topic": "zwave/Badkamer/Radiatorkraan/thermostat_mode/endpoint_0/mode/set",
    "current_temperature_topic": "zwave/Badkamer/Radiatorkraan/sensor_multilevel/endpoint_0/Air_temperature",
    "temp_step": 0.5,
    "current_temperature_template": "{{ value_json.value }}",
    "temperature_state_template": "{{ value_json.value }}",
    "temperature_command_topic": "zwave/Badkamer/Radiatorkraan/thermostat_setpoint/endpoint_0/setpoint/1/set",
    "mode_state_template": "{{ {0: \"off\", 1: \"heat\", 11: \"cool\"}[value_json.value] | default('off') }}",
    "temperature_state_topic": "zwave/Badkamer/Radiatorkraan/thermostat_setpoint/endpoint_0/setpoint/1",
    "temperature_unit": "C",
    "precision": 0.1,
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xd8468ee8_node12"
      ],
      "manufacturer": "Eurotronics",
      "model": "Thermostatic Valve (Spirit)",
      "name": "Badkamer-Radiatorkraan",
      "sw_version": "0.16"
    },
    "name": "Badkamer-Radiatorkraan_thermostat",
    "unique_id": "zwavejs2mqtt_0xd8468ee8_Node12_thermostat"
  },
  "discoveryTopic": "climate/Badkamer-Radiatorkraan/thermostat/config",
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "climate_thermostat"
}

and also under node>values>thermostat mode v3 i get these options:
[0] Off
[1] Heat
[11] Energy heat
[15] Full power
[31] Manufacturer specific

I tried editing the home assistent code, but I could not get these options in domoticz. With openzwave the mode is a Utility called Thermostat Mode of type "general".

[waltervl]

Can you check with Domoticz beta on a test system (eg in a docker)? There have been a lot of mqtt ad changes in beta so your issue could be solved already.

[mgugu]

I do not think this is a Domoticz problem.
In zwave-js-ui you can read that the Eurotronic manufacturer specific mode should work but "some code at app level should be necessary".
In fact the problem is that the config messages are missing "manufacturer specific" but updates messages work OK (You can check by switching to manufacturer specific with the js interface and you can see that Domoticz raises an error because the received code does not correspond to a config message.)
My working workaround:
- Interception of Eurotronic config mqtt messages by Nodered
- Modification of config messages by adding missing codes
- Sending back to Domoticz
Not very complicated but of course some time is needed...

[waltervl]

I do not think this is a Domoticz problem.
In zwave-js-ui you can read that the Eurotronic manufacturer specific mode should work but "some code at app level should be necessary".
In fact the problem is that the config messages are missing "manufacturer specific" but updates messages work OK (You can check by switching to manufacturer specific with the js interface and you can see that Domoticz raises an error because the received code does not correspond to a config message.)
My working workaround:
- Interception of Eurotronic config mqtt messages by Nodered
- Modification of config messages by adding missing codes
- Sending back to Domoticz
Not very complicated but of course some time is needed...

Perhaps you should raise in issue on the ZwaveJS repository with your detailed findings so they can fix it on their side.Then other users do not have to go this route. But mode_state_topic and mode_state_template are valid topic. Strange they seem not to be supported in Domoticz.

What config topics did you miss?

[mgugu]

Perhaps you should raise in issue on the ZwaveJS repository with your detailed findings so they can fix it on their side.Then other users do not have to go this route. But mode_state_topic and mode_state_template are valid topic. Strange they seem not to be supported in Domoticz.

What config topics did you miss?

This valve is no longer manufactured so I doubt that zwave-js will spend some time on it.
The modifications I made to incorporate "manufacturer specific" mode (in addition to some other missing modes):

Original template:

Code: Select all

"mode_state_template": "{{ {0: \"off\", 1: \"heat\", 11: \"cool\"}[value_json.value] | default('off') }}",

Modified template:

Code: Select all

"mode_state_template": "{{ {0: \"Off\", 1: \"Heat\", 11: \"Energy heat\", 15: \"Full power\", 31: \"Manufacturer specific\"}[value_json.value] | default('Off') }}",

[waltervl]

I see on zwavejs github that they seemed to implement your change in October: https://github.com/zwave-js/node-zwave- ... 72852911a5

[mgugu]

I see on zwavejs github that they seemed to implement your change in October: https://github.com/zwave-js/node-zwave- ... 72852911a5

You are right, we speak of the same change. I just pulled latest zwave-js-ui image and it looks like the change is not implemented in ui image yet.

[toxwa]

Original template:

Code: Select all

"mode_state_template": "{{ {0: \"off\", 1: \"heat\", 11: \"cool\"}[value_json.value] | default('off') }}",

Modified template:

Code: Select all

"mode_state_template": "{{ {0: \"Off\", 1: \"Heat\", 11: \"Energy heat\", 15: \"Full power\", 31: \"Manufacturer specific\"}[value_json.value] | default('Off') }}",

Where can I us these templates? I tried in zwave-js-ui under device Eurotronic...>home assistant>climate_thermostat to replace the original template line with the modified. I then pressed update to update the in memory discovery template. I deleted the thermostat in domoticz under devices and then pressed rediscover in zwave-js-ui.
But this doesn´t do anything. If I check the template later, the changes are also reverted.

[waltervl]

As mentioned before it should be in the latest Zwave-JS-UI release as the change was already in the driver part in October.

I have no idea how to check it really is. It probably means removing the device an repair it and be sure there are no retained MQTT topics of this device (but they should be overwritten).

[mgugu]

Where can I us these templates? I tried in zwave-js-ui under device Eurotronic...>home assistant>climate_thermostat to replace the original template line with the modified. I then pressed update to update the in memory discovery template. I deleted the thermostat in domoticz under devices and then pressed rediscover in zwave-js-ui.
But this doesn´t do anything. If I check the template later, the changes are also reverted.

I never managed to do the change directly in zwave-js-ui.
As I wrote in my first message, I made the change with nodered by intercepting/modifying/resending config messages.

[toxwa]

The first version of zwave-js-ui I installed was already the latest which includes the change (12.4.0). But I believe this only added the options in the webinterface of zwave-js-ui, where I could set the modes manually. The discovery templates used by home assistent and domoticz don't include the other modes. I don't know how or where the discovery templates are generated in zwave-js-ui, but after testing a few extra edits I finally made one that works.
To use it I went to the specific valve in zwave-js-ui. I navigated to home assistent>climate_thermostat and changed these lines in hass device JSON:
Zwave-js-ui default version:

Code: Select all

  "values": [
    "64-0-mode",
    "49-0-Air temperature",
    "67-0-setpoint-1",
    "67-0-setpoint-11"
  ],
  "mode_map": {
    "off": 0,
    "heat": 1,
    "cool": 11
  },
  "setpoint_topic": {
    "1": "67-0-setpoint-1",
    "11": "67-0-setpoint-11"
  },
  "default_setpoint": "67-0-setpoint-1",
  "discovery_payload": {
    "min_temp": 8,
    "max_temp": 28,
    "modes": [
      "off",
      "heat",
      "cool"
    ],



    "mode_state_template": "{{ {0: \"off\", 1: \"heat\", 11: \"cool\"}[value_json.value] | default('off') }}",
}

replaced with:

Code: Select all

  "values": [
    "64-0-mode",
    "49-0-Air temperature",
    "67-0-setpoint-1",
    "67-0-setpoint-11",
    "67-0-setpoint-15",
    "67-0-setpoint-31"
  ],
  "mode_map": {
    "off": 0,
    "heat": 1,
    "Energy heat": 11,
    "Full power": 15,
    "Manufacturer specific": 31
  },
  "setpoint_topic": {
    "1": "67-0-setpoint-1",
    "11": "67-0-setpoint-11",
    "15": "67-0-setpoint-15",
    "31": "67-0-setpoint-31"
  },
  "default_setpoint": "67-0-setpoint-1",
  "discovery_payload": {
    "min_temp": 8,
    "max_temp": 28,
    "modes": [
      "off",
      "heat",
      "Energy heat",
      "Full power",
      "Manufacturer specific"
    ],
   
   
    "mode_state_template": "{{ {0: \"off\", 1: \"heat\", 11: \"Energy heat\", 15: \"Full power\", 31: \"Manufacturer specific\"}[value_json.value] | default('off') }}",

I then pressed update in zwave-js-ui, deleted the thermostat switch in domoticz and pressed rediscover in zwave-js-ui and it works.

[waltervl]

Then you should add that to Zwave-JS-UI GitHub issue, then everybody with this thermostat can benefit from this change.

[mgugu]

I then pressed update in zwave-js-ui, deleted the thermostat switch in domoticz and pressed rediscover in zwave-js-ui and it works.

Interesting, but you have to do the change for each Spirit instance.
Does the changes survive to a container restart or an image upgrade ?

[toxwa]

Interesting, but you have to do the change for each Spirit instance.
Does the changes survive to a container restart or an image upgrade ?

Yes, you do need to make the changes for each spirit valve individually (only 2 in my setup so relatively easy)

I just tried a restart. The changes do not survice a container restart. I'm not sure if that's a problem. Is this info only used for discovery? In that case a change to the discovery template isn't really a problem until you want to re-add the valve to domoticz.

[mgugu]

I just tried a restart. The changes do not survice a container restart. I'm not sure if that's a problem. Is this info only used for discovery? In that case a change to the discovery template isn't really a problem until you want to re-add the valve to domoticz.

In fact I found that you can store permanently the HASS json by cliking the store button in the menu:

2023-12-10 23_03_11-Z-Wave JS UI.png (40.91 KiB) Viewed 2024 times

This appends the HASS json to the nodes.js file, so it will be not rebuilt at restart.
For multiple instances you can also edit the nodes.js file and copy the HASS json to all instances. Should be simpler than doing with the UI.

[toxwa]

Then you should add that to Zwave-JS-UI GitHub issue, then everybody with this thermostat can benefit from this change.

I was recently looking at their GitHub and found several issues with very similar solutions that are all closed (like this one: https://github.com/zwave-js/zwave-js-ui/issues/1804). The problem is that they are focused mainly on home-assistent and use the climate component. This component has several default options and manufacturer specific and full power are not default options. They always suggest changing the payload manually.