Temperature not reported anymore for lumi.sensor_motion.aq2 (RTCGQ11LM) since update to v2.17.1

[bcutter]

Describe the bug

Temperature is not available/updated anymore after updating deCONZ to v2.17.1 (from v2.16.1, using HA deCONZ addon/container - updated from v6.14.2 to v6.15.0).

Steps to reproduce the behavior

1. Run deCONZ v2.16.1
2. Get temperature of motion sensors
3. Update deCONZ to v2.17.1
4. No more temperature

Expected behavior

Temperature is still available

Screenshots

1st sensor 2nd sensor 3rd sensor 4th sensor

Environment

• Host system: Raspberry Pi
• Running method: Home Assistent deCONZ Add-on
• Firmware version: (26720700)
• deCONZ version: (2.17.1)
• Device: ConBee II
• Do you use an USB extension cable: yes
• Is there any other USB or serial devices connected to the host system? Yes, but irrelevant.

deCONZ Logs

Additional context

• Everything was working fine until the update (performed on 8th of July between 23:00 and 23:59).
• I have no idea what changed from v2.16.1 to v2.17.1 (both stable releases) for those devices (lumi.sensor_motion.aq2 (RTCGQ11LM)).
• I have few of them and all stopped providing/updating temperature values after updating to v2.17.1. See screenshots.

Please tell me which cluster and attribute shall be used for those devices so I can check those. For now I checked all clusters and could not find any temperature attribute (anymore).

[yamaha1983]

I can confirm this behaviour. Once I updated to version 2.17.1, motion sensor is not reporting new lux and temperature values. I mean temperature is not that important, as those values are not precise. The lux value instead is a must have.

I downgraded back to 2.14.1 and I am recieving lux and temperatures again.

[Mimiix]

Its really intresting because mine works like before. I even tested it in another issue.

@SwoopX Can you check in here?

[Mimiix]

It's funny, When i checked on the other issue, the temp was there:

When i check now, it's gone:

@Thomas-Vos Can you check yours?

[bcutter]

Maybe it only happens after a certain time or if deCONZ gets restarted once after the update?

Mine of course also all lack the temperature in Phoscon, one example:

Brightness is working well.

[LeoeLeoeL]

Same for me, Temperature shows 29 steady. Anyway, temperature data in this device and aqara door sensors, cube etc. are not precise. So, I think, reading a temperature value of those device could be useful only to understand if devices are fully integrated in Deconz/Phoscon.

[bcutter]

Anyway, temperature data in this device and aqara door sensors, cube etc. are not precise.

Luckily this issue is not about if values are right or wrong in absolute numbers - but an update which broke something.

Let's focus on that.

What is needed to make some progress here? I fear that even when the root cause for this introduced bug is found (maybe one of that many changes from 2.16.1 to 2.17.1), it will take weeks or even months until a fix will no shipped in the next stable release.

So once again: what is needed to make some progress?

Any log data needed for example? Any tweaks with the DDF?

[Mimiix]

I've deleted 2 off-topic comments. Please remain on-topic and respectful to each other.

So once again: what is needed to make some progress?

Nothing at this point. Lets wait for a dev to pick up.

[LeoeLeoeL]

Excuse me Mimiix, I don't think my last post was off topic. Deconz has many problems with Aqara end devices. I just paired 2 Aqara temperature sensors. Phoscon reported FAILED for both but Phoscon lists them and Deconz show them but....... with battery at 0%. Tested by a voltmeter, batteries are more than 3V. The other Aqara temperature sensor I have reports 100% battery. Few releases of Deconz ago was 91%. So that it's not a problem only for the sensor in this thread.

[Mimiix]

Excuse me Mimiix, I don't think my last post was off topic. Deconz has many problems with Aqara end devices. I just paired 2 Aqara temperature sensors. Phoscon reported FAILED for both but Phoscon lists them and Deconz show them but....... with battery at 0%. Tested by a voltmeter, batteries are more than 3V. The other Aqara temperature sensor I have reports 100% battery. Few releases of Deconz ago was 91%. So that it's not a problem only for the sensor in this thread.

Off topic again. Feel free to post on the forums if you have any criticism on how deconz is or anything else. I am really not in the mood to start policing here. Please stay in this topic.

[MiguelCosta]

I have 2 Aqara Motion Sensors and with the last update only one of them has the temperature...

I don't understand why the same product has different properties 😕

[monpelaud]

Hi, I think there is also an issue with the battery level of the aqara sensors (RTCGQ11LM). Since the migration to deCONZ v2.17, the battery level went from 90% to 100%. Now all my aqara sensors have 100% battery level. The screenshots in this post seem to show the same issue.

Best regards.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[bcutter]

I've deleted 2 off-topic comments. Please remain on-topic and respectful to each other.

So once again: what is needed to make some progress?

Nothing at this point. Lets wait for a dev to pick up.

We waited for a month already...

[Mimiix]

I've deleted 2 off-topic comments. Please remain on-topic and respectful to each other.

So once again: what is needed to make some progress?

Nothing at this point. Lets wait for a dev to pick up.

We waited for a month already...

Nobody is obligated to pick it up. I'll tag @manup and see if he wants to have a look at it.

[manup]

Just checked the GIT history, we've moved this sensor to DDF in v2.17.0-beta in PR https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6038

The config/temperature item is missing here, it's a bit so so. It was a mistake to expose it in the past, since this isn't a actual environment temperature reading, but only represents the device on chip temperature. That resulted in quite some confusion since the value is off from expected environment temperature quite often.

So we need to make a decision here I see following options:

1. We bring it back as config/temperature to the DDF. Which is kind of ok in this case in the name of backward compatibility. But of course still have the confusing value which raises questions from time to time.

2. Keep it removed as this is not a temperature as one would expect.

3. (i) Bring it back as config/temperature mark it as deprecated, (ii) add a more sound state/device_temperature reflecting the same. Note I wouldn't settle it under config/ as it represents state not configuration.

@SwoopX @ebaauw What do you think?

[bcutter]

I'd vote for anything except 2. You don't know what (we) guys did or do with that information.

(Silently) Removing data/information/features is not a good thing in my opinion.

Everyone is or should be aware this value is not representing the actual environment temperature as dedicated temperature sensor devices would measure.

As a workaround: if you could post the former content of the corresponding DDF here, I would be thankful and meanwhile create a DDF in my custom location to finally get back the information.

[manup]

Indeed such changes need to be documented and should not happen without announcement / deprecation. We try but sometimes this slips through :)

Personally I'd go with option (3), so the config/temperature comes back in the next release but as deprecated, we can then figure out a way to move forward with a more clean solution.

[Mimiix]

Indeed such changes need to be documented and should not happen without announcement / deprecation. We try but sometimes this slips through :)

Personally I'd go with option (3), so the config/temperature comes back in the next release but as deprecated, we can then figure out a way to move forward with a more clean solution.

I agree with that.

Whats the downside of letting it be there? Perhaps we can leave it with just a warning in documentation.

[SwoopX]

My opinion on this "reading" is pretty simple: Xiaomi doesn't expose anything like that on any of their devices. Something which vaguely fits into some wanted pattern is not something to rely on. Just my 2 Cents...

[Danieleser]

I vote for anything except 2 too. I use the value to know more or less the external temperature and doesn't matter if it no precise.

[github-actions[bot]]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[bcutter]

Active.

[LeoeLeoeL]

Temperature is reported again; Probably due to 2.18.1-beta.

[bcutter]

Interesting. But because of what fix? Didn't see any PR linked here.

Coincidence?

[Mimiix]

https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6309

Wasn't linked to this issue.

[LeoeLeoeL]

Interesting. But because of what fix? Didn't see any PR linked here.

Coincidence?

Maybe. I updated to the latest beta at 00.09 of 11 september 2022 and temperature began to be reported (in Home Assistant) again at 10.42 of 12 september.

[bcutter]

Looking forward to see this patch/fix in stable release (and made available to deCONZ addon for Home Assistant), that unfortunately usually takes a quite long time (at least weeks, sometimes months).