Have you tried going into Edit and adding those "levels" (0, 1, 11, 15, 31, etc.) manually?

I'm showing the versions jumped from 3.5.0 to 4.0.0, which is also from 2021: https://github.com/zwave-js/zwave-js-ui ... es?page=23

Where did 3.11 come from?

Thank you for the info. Odd that is used to be correct - see the screenshot above where it was a thermostat mode in v2023.1 and in the "Utilities" tab.

Since it's really a thermostat mode and thermostat fan mode, it should be in the "Utilities" tab in Domoticz. That's the purpose of the tab grouping. Not a light switch as it is currently:

Can you please paste your code - don't forget to format it as code so it appears correctly

You are on the latest/stable channel which tracks the "Latest version of the last *major* release" so you are on the right release for it. If you want the "Latest minor or patch release of latest major release" then switch the channel: sudo snap refresh zwave-js-ui --channel=latest/candidate The ...

I agree as others have mentioned with dzVents you can write some really powerful automation scripts.

On the other hand blockly is great for those that need basic automation but might not have the capability or skills for scripting.

The best of both worlds here!

Since it is a switch, the android app sees the selector levels as a light level:

They should be set as 'thermostat mode' and 'thermostat fan mode' like this:

(Split into multiple posts due to attachment limit) Hi just reporting that I have noticed that Domoticz incorrectly sets thermostat modes and thermostat fan modes to selector switches instead of correctly setting them as 'thermostat mode' and 'thermostat fan mode'. It does switch and indicate as ...

{ "modes": [ "Off", "Low" ], "mode_state_template": "{{ {0: \"Off\", 1: \"Low\"}[value_json.value] | default('Off') }}", "temperature_state_topic": "zwave/Test/ThermostatTest2/67/0/setpoint/2", "temperature_state_template": "{{ value_json.value }}", "temperature_command_topic": "zwave/Test ...

OpenZWave is in the latest version. But better to migrate to ZwaveJS-UI with MQTT Auto Discovery, and while your doing so, maybe switch to the docker compose version of Domoticz as well so you don't have issues with ssl libraries in the feature I completely agree and the migration to ZwaveJS-UI ...

Ok after first installing libssl1.1 ( viewtopic.php?t=42200 ) and then changing the line in the script it did install 2023.2 successfully.

However, OZW is not in the list. Wasn't v2023.2 the last version to have it?

cool53 wrote: ↑Wednesday 06 November 2024 19:26 It does not work on my LTS 2024 ubuntu. The libssl1.1 states it is not a deb package.

Frustrating, Domoticz worked well on my ubuntu server, but that seems to be over now.

Try as superuser

I want v2023.2 due to OpenZWave. When OpenZWave was added back it lost some capability with my older thermostats. This is the easier path for now versus replacing thermostats or when I finally migrate to ZWaveJS.

Thank you... I did replace the link to download "domoticz_linux_2023.2_x86_64.tgz". Are you aware of anything else required to change in the script?

Hello, By default the script at install.domoticz.com will install the latest version. I want to use the script to install v2023.2 as I would like the transfer my v2023.2 from Windows to my Ubuntu server and stay on the same version. Looking through the script, I see line 380 which is: wget -O ...

waltervl wrote: ↑Wednesday 17 July 2024 13:27 Check also menu Setup - Users if the admin user has devices assigned as that is not the preferred way and could lead to hidden devices.

Can you elaborate on that please? Do you mean devices should not be assigned to the admin user?

2024.7 has the GCM messaging fix

Thank you @waltervl for pointing that out.

Google is deprecating the old API starting July 22nd, so messaging will permanently break for all users on the stable Domoticz release around that time:

https://firebase.google.com/docs/cloud- ... migrate-v1