Stelpro Maestro ASMT402AD with Zigbee

WestCoastXS · November 12, 2021, 5:44am

Hi Folks,

Been using the Stelpro Maestro stats for a few years.
Looking to migrate them to OH with their zigbee functionality but don’t seem to have all the channels necessary to change the setpoint.

Reason for the migration is we are not super happy with the Stelpro app. Also looking to get some Sinope Zigbee tstats.

Saw @chris mention a couple years ago that the setpoint functions were not implemented in the binding at that time but the posts seem to imply that is has been since then.

Currently running OH 3.0.2 on a raspberri pi 4.
3.0.2 of the Openhab Zigbee binding.
Using a HUSBZB-1 USB stick for Zigbee and ZWave.
(ZigBee Ember EM35x Coordinator)

Looked into installing a newer snapshot, if there is one, but still new to this and wasn’t able to find one.

Some screenshots for info. I’m sure there may be some logs I can enable that may help.
My main suspicion is an improper Zigbee implementation by Stelpro.

chris · November 12, 2021, 5:48am

Setpoints should be available, but it may depend on exactly what the device implements. I’ve tested this on a few different devices - it was initially implemented for Hilton and tested on 3 different thermostats they were using in their hotels, but sometimes manufacturers do something different

Can you provide the XML file for this device (in the userdata/zigbee folder) and I’ll take a look. That won’t give me the full story, but it will give me some indicators and we can take it from there.

WestCoastXS · November 13, 2021, 3:07am

Hi Chris, thanks for getting back to me.
xml file attached.

F8F005FFFFF96994.xml (42.9 KB)

chris · November 13, 2021, 4:56am

At the top level, this looks like a pretty standard device so I would have expected it to present the thermostat channels.

Can you please log on to the openhab command line and run the following command -:

zigbee fingerprint 36892

Let’s see what that shows.

The next thing we’ll probably try is to get a debug log during initialisation - so enabling debug logging as per the binding docs, then setting the parameter to reinitialise the device in the devices config, and see what that shows.

WestCoastXS · November 13, 2021, 5:29am

When doing the fingerprint command in openhab-cli console I get:

openhab> zigbee fingerprint 36892
Error: Could not find command: fingerprint

Digging into the zigbee commands further.

In the meantime here’s the debug log after initializing device.

openhab.log (138.7 KB)

WestCoastXS · November 13, 2021, 5:34am

Ran NODEID and got the following:

IEEE Address     : F8F005FFFFF96994
Network Address  : 36892
Node Descriptor  : NodeDescriptor [apsFlags=0, bufferSize=89, complexDescriptorAvailable=false, manufacturerCode=1185, logicalType=ROUTER, serverCapabilities=[], incomingTransferSize=61, outgoingTransferSize=61, userDescriptorAvailable=true, frequencyBands=[FREQ_2400_MHZ], macCapabilities=[FULL_FUNCTION_DEVICE, MAINS_POWER, RECEIVER_ON_WHEN_IDLE], extendedEndpointListAvailable=false, extendedSimpleDescriptorListAvailable=false, stackCompliance=21]
Power Descriptor : PowerDescriptor [currentPowerMode=RECEIVER_ON_IDLE, availablePowerSources=[DISPOSABLE_BATTERY, RECHARGABLE_BATTERY, MAINS], currentPowerSource=MAINS, powerLevel=FULL]
Associations     : []
Endpoints        :
            25   : Profile     0104 ZIGBEE_HOME_AUTOMATION
                 : Device Type 0301 THERMOSTAT
                   -> BASIC
                   -> IDENTIFY
                   -> GROUPS
                   -> THERMOSTAT
                   -> THERMOSTAT_USER_INTERFACE_CONFIGURATION
                   -> RELATIVE_HUMIDITY_MEASUREMENT
                   <- IDENTIFY
                   <- TIME
                   <- TEMPERATURE_MEASUREMENT
Neighbors:
Routes:

WestCoastXS · November 13, 2021, 5:53am

One other question:
When using the Stelpro app it provides power consumption in kWh.
Their literature states this is only available through the app, not zigbee.
Does what you see corroborate this?

I think eventually I’ll run all the heating circuits in my panel through a current transformer to log power consumption for heating so the function is nice but not required.

chris · November 13, 2021, 5:57am

Ok, your version might be a bit too old to have this included unfortunately

Probably… There is no electrical measurement cluster showing, so that’s likely to be the case. That said - if it doesn’t read the data through Zigbee, then I don’t know how it gets that information. So, it might be that it is there somewhere, but it’s a non-standard feature that only the manufacturer knows how to read.

WestCoastXS · November 13, 2021, 6:25am

I can try to figure out installation of a newer version if the fingerprint command will help.

When not using a generic Zigbee hub the Stelpro Maestro system uses one master thermostat as a hub that connects to the internet via wifi. Must have proprietary communication that the master hub handles.
The app communicates with their servers. One reason why I’d like to migrate to zigbee via openhab.

Thanks for the help so far. I’ll report back when I get the fingerprint info.

WestCoastXS · November 14, 2021, 2:25am

Hi Chris,

Fingerprint returned this information:

|>| Node Descriptor
| |> Logical Type               ROUTER
| |> MAC Capabilities           [FULL_FUNCTION_DEVICE, MAINS_POWER, RECEIVER_ON_WHEN_IDLE]
| |> Stack Compliance           21
| |> Server Capabilities        []
| |> Buffer Size                89
| |> Incoming Transfer Size     61
| |> Outgoing Transfer Size     61
|
|>| Power Descriptor
| |> Available Power Sources    [DISPOSABLE_BATTERY, MAINS, RECHARGABLE_BATTERY]
| |> Current Power Source       MAINS
| |> Current Power Mode         RECEIVER_ON_IDLE
| |> Power Level                FULL
|
|>| ZDO
| |> ManagementBindRequest      SUCCESS
| |> IeeeAddressRequest         SUCCESS
| |> ManagementLqiRequest       SUCCESS
| |> ManagementRoutingRequest   SUCCESS
|
|>| Basic Information
| |> Generic Device Class
| |> Generic Device Type
| |> Manufacturer Name          Stelpro
| |> Model Indentifier          MaestroStat
| |> Product Code
| |> Product URL
| |> Date Code                  20180122 00032
| |> Application Version        203
| |> Software Build ID
| |> Hardware Version           1
| |> Zcl Version                2
| |> Stack Version              24
| |
| |>| Endpoint 25
| | |> Profile                  0104  ZIGBEE_HOME_AUTOMATION
| | |> Device Type              0301  THERMOSTAT
| | |> Device Version           1
| | |
| | |>| Input Clusters
| | | |
| | | |>| Cluster 0000 Basic
| | | | |> Type                 Server [Input]
| | | | |> Manufacturer Spec.   No
| | | | |
| | | | |>| Commands Generated
| | | | |
| | | | |>| Commands Received
| | | | | |> 0000 ResetToFactoryDefaultsCommand
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 ZCL Version
| | | | | |> 0001 Application Version
| | | | | |> 0002 Stack Version
| | | | | |> 0003 HW Version
| | | | | |> 0004 Manufacturer Name
| | | | | |> 0005 Model Identifier
| | | | | |> 0006 Date Code
| | | | | |> 0007 Power Source
| | | | | |> 0010 Location Description
| | | | | |> 0011 Physical Environment
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type                 Server [Input]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0004 Groups
| | | | |> Type                 Server [Input]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0201 Thermostat
| | | | |> Type                 Server [Input]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0204 Thermostat User Interface Configuration
| | | | |> Type                 Server [Input]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0405 Relative Humidity Measurement
| | | | |> Type                 Server [Input]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | |
| | |>| Output Clusters
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type                 Client [Output]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 000A Time
| | | | |> Type                 Client [Output]
| | | | |> Manufacturer Spec.   No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0402 Temperature Measurement
| | | | |> Type                 Client [Output]
| | | | |> Manufacturer Spec.   No
| | | | |
| | | | |>| Commands Generated
| | | | | |> 0000 Unknown
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> FATAL_ERROR

chris · November 14, 2021, 4:29am

Thanks.

Unfortunately that wasn’t so useful - possibly because the device isn’t reporting what it supports. Let’s try a few other things…

zigbee attsupported 36892/25 0x201

zigbee cmdsupported 36892/25 0x201

In theory the fingerprint command should have done this already so I’m not hopeful we’ll get something useful, but worth a try.

The next command reads the attributes that the binding uses.

zigbee read 36892/25 0x201 0x11 0x12 0x13 0x14

If this last one doesn’t come back with 4 results, then try the 0x11, 0x12 etc by themselves (ie one at a time).

WestCoastXS · November 14, 2021, 6:53pm

Having issues with updating OH to 3.2.0 where all my bindings disappear and no bindings can be reinstalled. The console commands seem to work fine so here are those results.

Working on the upgrade issue. Backed up first so nothing lost.

openhab> zigbee attsupported 36892/25 0x201
Supported attributes for server cluster Thermostat (0201)
AttrId  Data Type                  Name
     0  SIGNED_16_BIT_INTEGER      Local Temperature
     1  SIGNED_16_BIT_INTEGER      Outdoor Temperature
     2  BITMAP_8_BIT               Occupancy
     3  SIGNED_16_BIT_INTEGER      Abs Min Heat Setpoint Limit
     4  SIGNED_16_BIT_INTEGER      Abs Max Heat Setpoint Limit
     5  SIGNED_16_BIT_INTEGER      Abs Min Cool Setpoint Limit
     6  SIGNED_16_BIT_INTEGER      Abs Max Cool Setpoint Limit
     8  UNSIGNED_8_BIT_INTEGER     Pi Heating Demand
     9  BITMAP_8_BIT               Hvac System Type Configuration
 65533

cmdsupported looks promising

openhab> zigbee cmdsupported 36892/25 0x201
Supported generated commands for server cluster Thermostat (0201)
CommandId  Command

Supported received commands for server cluster Thermostat (0201)
CommandId  Command
       0  SetpointRaiseLowerCommand

openhab> zigbee read 36892/25 0x201 0x11 0x12 0x13 0x14
Reading endpoint 901C/25, cluster server cluster Thermostat (0201), attributes Occupied Cooling Setpoint, Occupied Heating Setpoint, Unoccupied Cooling Setpoint, Unoccupied Heating Setpoint
Response for cluster 0x0201
Attribute 17, type SIGNED_16_BIT_INTEGER, value: 3500
Attribute 18, type SIGNED_16_BIT_INTEGER, value: 2100
Attribute 19, type SIGNED_16_BIT_INTEGER, value: 4000
Attribute 20, type SIGNED_16_BIT_INTEGER, value: 1700

chris · November 14, 2021, 7:30pm

Thanks. So I think this explains what’s wrong. In the above, the device does not report that it supports the attributes for setting the setpoints - but it does support these as we can read them back.,

The binding does pretty much what you did above - first it reads the list of supported attributes. If that returns a successful list, then it checks to see if the setpoints are supported. Since this command to read the attributes is not supported by all devices, if this request fails, then the binding will attempt to read back the attribute to see if it gets a response.

The reason the binding works this way is getting the supported attributes list is a lot more efficient during initialisation, however it of course requires the device to report this correctly, and it seems this one doesn’t. I might change this around - live with the inefficiency for these channels at least and improve the robustness.

Do you have debug logging enabled - or can you enable it please. Then do this attsupported request again so I can check the low level response(s) that are returned. The list of debugging I need is in the binding docs. I just want to be 100% sure that this is a problem with the device and not the way the binding is requesting this data.

chris · November 14, 2021, 8:12pm

github.com/openhab/org.openhab.binding.zigbee

Simplify mechanism to detect thermostat channels

openhab:main ← cdjackson:setpoint-detection

opened 08:12PM - 14 Nov 21 UTC

cdjackson

+69 -133

This changes the thermostat channel detection to just rely on reading the attrib…utes rather than requesting the supported attributes list from the device. This should make the detection more robust as we have seen a thermostat that incorrectly reports the supported attributes. The downside of this is that more requests are made to the device - 8 requests rather than 1. However this is only required during initialisation, and it seems that robustness is probably a stronger requirement here. Signed-off-by: Chris Jackson <chris@cd-jackson.com>

WestCoastXS · November 14, 2021, 11:32pm

I have debug logging turned on as per binding docs:

log:set debug org.openhab.binding.zigbee
log:set debug com.zsmartsystems.zigbee
log:set info com.zsmartsystems.zigbee.dongle.ember.internal.ash

But nothing gets added to the log when I enter the console and run:

zigbee attsupported 36892/25 0x201

Might be an issue with my version again as I went back down to 3.0.2 while attempting to update again and retain bindings.
Will keep trying at it.

It is probably a device problem. Stelpro seems to like releasing semi-functional software then abandoning it to work on their next idea.

chris · November 14, 2021, 11:46pm

This should be ok so I’m not sure why nothing is being logged.

I also think this is most likely as there has been a lot of testing on this and IIRC it was formally tested as part of a product we had Zigbee certified early last year. I would be keen to see the logs if possible as it would be nice to understand the issue and confirm why this is happening, but it’s not the end of the world.

I’ve now merged the above change, so if you can get the latest binding installed and working it will hopefully resolve the issue. Dependencies need to be updated, so I’m just going to update the binding to create a KAR file which includes everything you need in one place and you should be able to uninstall the old binding, and drop this directly in the addons.

chris · November 15, 2021, 7:23pm

The last build of the ZigBee binding is now at the link below. This is a KAR file, so you should just have to drop this into your addons folder - it includes all the zigbee dependencies as well as the binding itself.

https://ci.openhab.org/job/openHAB-Zigbee/lastStableBuild/artifact/feature/target/openhab-binding-zigbee-3.2.0-SNAPSHOT.kar

WestCoastXS · November 27, 2021, 9:27pm

Hi Chris,

Took a while to figure out how to upgrade without seemingly breaking OH.

Got it done, installed that snapshot, and all the channels show up. On the same day the Zigbee Sinope stats arrived.
Thank you very much for sorting this issue out. I appreciate it very much.

blobule · November 28, 2021, 6:19pm

Hi Chris,
Thank you for your help figuring out this thermostat.

I have never added “addons” manually before. Any suggestion on how to proceed, besides copying the .kar into the addons folder?
(my addons folder already contains openhab-addons-3.1.0.kar, I assume I leave that there?

Im using openhabian, OH3, on a Rpi4.
Sorry for the naive question. I am not familiar with the dev environment of OpenHab.

Thanks!
Sebastien

chris · November 28, 2021, 8:01pm

Hmmm - I’m not sure what will happen in this case. Do your really need to have the full addons loaded? You may need to ensure that there is no other zigbee binding loaded using the console - log on to the console and use the list command to list all the loaded/running bundles, then uninstall them (with uninstall followed by the bundle ID).

You might simply be able to uninstall the zigbee binding through the UI - I’m not 100% sure if this works though given you have the addons kar file loaded in this way.

Once you’ve uninstalled the current binding, then yes, just drop the new KAR into the addons folder and it should install and run.