Temperature sensor that works with SmartThings

The configuration changes is not always accepted by the device, it depends on its design:

  • There are devices that accept them almost always and others almost never or never.
  • There are some that have a factory setting to improve battery life and do not accept the changes
  • Some sleep until next report time and there is no way to wake up them. In these cases they usually accept the configuration sent in the pairing.

The maximum interval value tells the device every how time have to send temperature reports.
In the app history you will only see temperature changes, you should not see consecutive repeated values.

Last value in device History is 04:16 p.m 19.2Āŗc

In the temperature graph you can see repeated values. the values will coincide with the maximum interval.

Last value in temp graphic is 04:40 p.m 19.2Āŗc, but repeated every 5 minutes since 04:15 p.m.

The reportable change tells the device to report any temperature change >= to the set value, even if the maximum range has not been met.

The way to see that the new configuration has been successful is with the CLI logs.
In this example change the maximum reporting interval value from 10 minutes to 15 minutes (900 sec 0x0384)

If you do not see in log ConfigureReportingResponse || ZclStatus: SUCCESS > > > device did not accept the new configuration

2023-02-28T15:56:22.420011860+00:00 PRINT Zigbee Temp Sensor and Child Thermostat Mc << Preference changed: name, old, new >> tempMaxTime 10 15
2023-02-28T15:56:22.423269860+00:00 PRINT Zigbee Temp Sensor and Child Thermostat Mc Temp maxTime & changeRep: 900 30.0
2023-02-28T15:56:22.425565527+00:00 INFO Zigbee Temp Sensor and Child Thermostat Mc <ZigbeeDevice: eb7c780e-e667-46ab-ba47-ea81341df249 [0x8689] (Environment Sensor)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x8689, dest_endpoint: 0x08, profile: 0x0104, cluster: TemperatureMeasurement >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x00, seqno: 0x00, ZCLCommandId: 0x06 >, < ConfigureReporting || < AttributeReportingConfiguration || direction: 0x00, attr_id: 0x0000, DataType: Int16, minimum_reporting_interval: 0x001E, maximum_reporting_interval: 0x0384, reportable_change: 30 > > > >
2023-02-28T15:56:22.694577860+00:00 INFO Zigbee Temp Sensor and Child Thermostat Mc <ZigbeeDevice: eb7c780e-e667-46ab-ba47-ea81341df249 [0x8689] (Environment Sensor)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x8689, src_endpoint: 0x08, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: TemperatureMeasurement >, lqi: 0xB8, rssi: -88, body_length: 0x0004, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x76, ZCLCommandId: 0x07 >, < ConfigureReportingResponse || ZclStatus: SUCCESS > > >

If these are zwave battery powered devices, it is very common for these to accept configuration changes only two or three times a day in order to save battery life. They will be ā€œacceptedā€œ in the sense that the instruction will be sent successfully, but they will be held in a queue at the hub until the next time the device asks for updates.

This can also explain why you might try to update several devices of the same model at about the same time, and the changes will only ā€œtakeā€œ on some of them. It just means that one was likely near the time when it was updating its configuration and the others were still in wait mode. They should all catch up by the next day.

See the FAQ on this issue:

FAQ: Configuration Changes for Battery-powered Zwave Devices

Thanks! Is this your experience with SNZB-02 specifically?

Got it thanks for the links. I have quite a few z-wave devices so thatā€™s helpful. The issue Iā€™m have above is with a couple (not all for some reason) ZigBee SNZB-02 temperature/humidity sensors.

1 Like

Zigbee is somewhat more primitive in this regard than zwave. Itā€™s up to the manufacturer, but many inexpensive battery powered zigbee devices only accept configuration changes at the time they join the network. And others will accept them but you have to physically put the device into ā€œconfigure modeā€ first, typically with a specific button press pattern. And theyā€™ll only stay in configure mode for a short time.

Check the user manual or contact the manufacturer to find out the method for making parameter changes on the specific model you are working with.

1 Like

This device accepts the settings fine on pairing.
Configuration changes are not always accepted
to force acceptance what I usually do is:
Change the value in preferences and if it does not accept it then I make a change to another driver, zigbee Thing mc, for example or another that has the fingerprints and when I return to the driver it resends the configuration in the pairing and usually accepts it.

Of the ones I have, the ones that practically always accept configuration changes are the samjin sensors (aeotec, smartthings), movement and multipurpose, and a KMPCIL, environment sensor that uses a 5 vdc power supply and no batteries.

2 Likes

I should add that in zwave this is called ā€œconfigurationā€œ. In zigbee, it is sometimes called ā€œconfigurationā€œ and sometimes called ā€œcluster management.ā€œ again, it varies by manufacturer.

Hi my friendā€¦ I got itā€¦and looks worked well for a yearā€¦but now, seems temp report does not match with real temp inside the house, maybe 6-8 Celcius degrees aboveā€¦this device needs some calibration or something ?..why it went crazy ā€¦?