OH5.X: Stelpro KI STZW402WB+ (Z-Wave) & Alexa Issue(s)

thomasthomas · December 15, 2025, 9:49pm

OH5.X (latest stable build with M4) image downloaded and installed VIA PI Imager on a PI4 w/8GB.

I’ve been going back and forth on this for days and am at the end of my rope.

Trying to setup the Stelpro baseboard thermostats to be controllable through OH5.X/Alexa and having zero luck. They are installed and operate/function fine in OH through the UI/model, but I am unable to make that magic happen with Alexa. I either end up with multiple devices (Sensor temperature and Setpoint heating - and boy what a going’s on to try and remove them at times!) or a single (what appears to be properly setup device) e.g. Bedroom Thermostat - looking as it should (combines fields for temp and setpoint into a single widget), except it is devoid of any meaningful data (usually that means goofed metadata/configuration issue).

I should point out that I am attempting to add these VIA the UI/Model, not config files. Further, to add salt to my wounds, I HAVE set these up in the past/had this working perfectly in OH3.X I’m pretty sure it has something to do with metadata for the three points/channels (setpoint, temperature and mode) or perhaps even the order in which they are set up? My Google Fu (including Gemini) has been exhausted, and indeed, yields conflicting advice.

To be clear. OH5.X is installed and functioning fine. I have others devices added that I can control perfectly though the model AND Alexa, I’m simply struggling with Alexa control of the thermostats.
Could someone please provide a compass heading?

Much thanks in advance.

Thomas

rlkoshak · December 16, 2025, 3:40pm

I’ve not done this for Alexa but I do know it works similarly to Google.

You need a Group with the “thermostat” Alexa device type for it’s alexa Item metadata.

All the thermostat related Items are members of this Group. Each member has it’s alexa Item metadata set to the appropriate attribute. For example, the Item that represents the target setpoint would be set to “TargetTemperature”.

All the attributes and what they mean and further restrictions can be found at openHAB Skill For Amazon Alexa | openHAB.

Note that Alexa doesn’t know nor care about the semantic model. All it looks at is the Group, members of the Group, and the contents of the alexa metadata

thomasthomas · December 17, 2025, 10:27pm

Thanks Rich. I’ve peeked at this, and that’s where part of the confusion came from. I have managed to get it sorted (mostly).

Added baseboard thermostat through Z-wave binding, then…

Things→ thermostat→Channels tab. From there used “Add equipment to Model” and selected three (of the four available) channels:
Sensor (temperature)
Thermostat mode
Setpoint (heating)
SAVE
Note: the above creates the thermostat as a group, and links necessary points/items.

CONFIGURATION:

Items →Sensor_temperature → Edit
Type → Number
Dimension → Temperature
Semantic Point → Measurement
Semantic Property → Temperature
SAVE
Metadata → Amazon Alexa →Thermostat.CurrentTemperature
Scale → Celsius
SAVE

Items → Setpoint_heating→Edit
Type → Number
Dimension → Temperature
Semantic Point → Setpoint
Semantic Property → Temperature
SAVE
Metadata → Amazon Alexa →Thermostat.TargetTemperature
Scale → Celsius
Setpoint Range→7:23 (change to match needs)
SAVE

Items→Thermostat_mode→Edit
Type → Number
Dimension → Leave empty/blank
Semantic Point → Point
Semantic Property → None
SAVE
Metadata → State Description → Options→ 1=HEAT 11=ECO
Note: the above definitions are specific to Stelpro Ki Z-wave thermostat
SAVE
Metadata → Amazon Alexa → Thermostat.Mode
SAVE

Items→Thermostat→Edit
Metadata → Amazon Alexa → Thermostat
SAVE

Model→Locate & select Thermostat →Mode→Toggle Mode
Note: This step is used initially to force the Setpoint and Temperature to display current thermostat values instead of “NULL.”

Issue Alexa command “Alexa, discover new devices”

This seems to work… mostly. That is to say the thermostats can be controlled with voice commands and they do show (and can be controlled) in the Alexa app, however, the Alexa app does not show the mode options (just a single Mode button labeled “Customized” that does nothing), nor does it recognize a voice command to change modes. One can, however, change modes using the UI model or the openHAB app (tested on Android version) with ease.

Google/Gemini makes note of using “ThermostatMode” as Alexa metadata (notice the missing period). Unfortunately, that also had no impact on allowing one to view/change modes with Alexa. I’m sure there’s some magical metadata that works, but I’ve yet to discover it.

At the end of the day, I have the control I need, though workable mode control from Alexa (for completeness) would have been nice.

That out of the way, I think I may have found a bug in either OH or the PI image build as it relates to my region. I was wondering why thermostats were not kicking in at times specified in rules. Log reveals everything executes 30 minutes later local time than what I have actually specified in my rules. FWIW, I live in an odd time zone (NST - Newfoundland Standard Time), so we’re a half-hour off pretty much most of the world. That is to say, we are UTC-3:30. Oddly enough timedatectl shows the correct time, and time zone shows America/St_Johns (which is where I live, well, technically I am in Canada, not America, but hey), yet rules execute 30 minutes behind (according to the logs). Your thoughts?

Thanks for your time.

Thomas

rlkoshak · December 18, 2025, 2:22pm

This is frustrating, but I suppose this is the world we live in now.

Did you look at the docs after some LLM which doesn’t know openHAB from a hole in the ground gave the wrong answer? We put a lot of effort into the docs and while they are not perfect, they are really pretty good. The LLMs will confidently just make stuff up on the spot.

There is lots of discussion in the docs about thermostats and how to configure the Alexa metadata, including lots of examples. But this row from the list of all Device Types holds the answer to the problem.

Device Types Supported Attributes Description

Thermostat *HeatingCoolingMode, TargetTemperature, CoolingSetpoint, HeatingSetpoint, EcoCoolingSetpoint, EcoHeatingSetpoint, ThermostatHold, ThermostatFan, CurrentTemperature, CurrentHumidity, BatteryLevel An endpoint that controls temperature, stand-alone air conditioners, or heaters with direct temperature control. If your endpoint senses temperature but does not control it, use TemperatureSensor instead.

You can see from that it’s called “HeatingCoolingMode”. Clicking on that link takes you to

HeatingCoolingMode

Items that represent the heating/cooling mode of a thermostat.

Supported item types:

Number [OFF=0, HEAT=1, COOL=2, AUTO=3, ECO=4]

String [OFF=“off”, HEAT=“heat”, COOL=“cool”, AUTO=“auto”, ECO=“eco”]

Switch [OFF=“OFF”, HEAT=“ON”]

Supported binding presets:

broadlinkthermostat (opens new window)[HEAT=“manual”, AUTO=“auto”]

daikin (opens new window)[HEAT=“HEAT”, COOL=“COLD”, AUTO=“AUTO”]

ecobee (opens new window)[OFF=“off”, HEAT=“heat”, COOL=“cool”, AUTO=“auto”]

insteon (opens new window)[OFF=0, HEAT=1, COOL=2, AUTO=3]

max (opens new window)[HEAT=“MANUAL”, AUTO=“AUTOMATIC”, ECO=“VACATION”]

nest (opens new window)[OFF=“OFF”, HEAT=“HEAT”, COOL=“COOL”, AUTO=“HEAT_COOL”, ECO=“ECO”]

radiothermostat (opens new window)[OFF=0, HEAT=1, COOL=2, AUTO=3]

venstarthermostat (opens new window)[OFF=“off”, HEAT=“heat”, COOL=“cool”, AUTO=“auto”]

zwave (opens new window)[OFF=0, HEAT=1, COOL=2, AUTO=3]

Supported metadata parameters:

OFF=<state>

HEAT=<state>

COOL=<state>

ECO=<state>

AUTO=<state>

binding=<id>

id formatted as <bindingId> (e.g. binding="nest")

only for GUI-based configuration(opens new window)

defaults to channel metadata value for items configured via text files

supportedModes=<modes>

comma delimited list (e.g. supportedModes="OFF,HEAT,COOL,AUTO")

defaults to, depending on the parameters provided in order of precedence:

user-defined mappings (e.g OFF=0,HEAT=1,COOL=2)

preset-based related to the thermostat binding linked

item type-based default mappings

supportsSetpointMode=<boolean>

set to false to disable the thermostat setpoint mode-aware feature (Refer to cooling/heating setpoints)

defaults to true

Utterance examples:

Alexa, set the <device name> to heat.

Alexa, set the <device name> to cool.

Alexa, set the <device name> to auto.

Alexa, set the <device name> to eco.

Alexa, set the <device name> to off.

Alexa, turn on the <device name>. (Switch only)

Alexa, turn off the <device name>. (Switch only)

Alexa, what’s the <device name> set to?

There are several examples of thermostat configurations in the docs which can be found at openHAB Skill For Amazon Alexa | openHAB starting at the third code block.

In the UI, HeatingCoolingMode is in the list.

There are three places where the timezone must match or else you might see odd behavior.

/etc/timezone
/etc/default/openhab
MainUI → Settings → Regional Settings

If the timezone doesn’t match in all three of these places, conflicts can occur. The second place can sometimes get changed during an update of OH which we don’t know why it occurs.

thomasthomas · December 19, 2025, 12:19am

That did the trick! Thermostat mode now accessible/functional in app. Thank you so very much!

As for the time zone data, it exists in:
/etc/timezone as ”America/St_Johns”
Main UI regional settings as “(GMT-3:30) America/St_Johns”

However, there’s no related item in /etc/default/openhab. Is there a particular format and/or placement I should use?

Thanks for your time, Rich.

rlkoshak · December 19, 2025, 2:21pm

It is an addition to the EXTRA_JAVA_OPTS line. There should be an example in the comments. I don’t have a Linux install handy to give specifics.

It should be something like

EXTRA_JAVA_OPTS="-Duser.timezone=America/St_Johns"

thomasthomas · December 28, 2025, 8:14pm

Thanks again, Rich.