Bogus Temperatures Reported by ADC-S40-T Temp Sensors

Ever since I added two ADC-S40-T temperature sensors to my system, I have been getting intermit bogus events where these RTSes report an incorrect (and wildly inaccurate) temperature reading. They eventually correct themselves with an updated (correct) temperature reading minutes or sometimes hours later. In the example below, the reported temperature was off by 30 degrees!

I have temperature threshold alerts set up for all my thermostat and RTS units, so I get ding’ed everytime this occurs. Since these RTS units are also used to drive thermostat setpoints, this creates more than just an issue with nuisance alerting.

I also have a few of the older ADC-S2000-T temperature sensors, but I have never had the same issue with them despite also having temperature threshold notifications set up for them. All RTSes are being used with a Qolsys IQPanel 2+ and the same ADC-T3000 thermostat.

I have tried rebooting both the IQPanel and the thermostat, but this doesn’t appear to have made any difference, as I continue to see repeat events. Any ideas?

Ever since I added two ADC-S40-T temperature sensors to my system, I have been getting intermit bogus events where these RTSes report an incorrect (and wildly inaccurate) temperature reading. They eventually correct themselves with an updated (correct) temperature reading minutes or sometimes hours later. In the example below, the reported temperature was off by 30 degrees!

Just to clarify, are you seeing the actual temperature reported in the app or website for that temp sensor to be off by that much? Or are you only seeing the discrepancy in the notifications, like the ones in your image?

We’ve seen some various issues with the notifications specifically in the past which is why I want to clarify and make sure those notifications accurately reflect what the sensor is inaccurately reporting, not the other way around.

I just had this happen again today and was able to verify that:

  1. Triggers ADC app notification rules (as per initial example / screenshot)

  2. Bogus temperature shows for the RTS in ADC app under Temperature Sensors

  3. Bogus temperature is verified to be impacting the system’s view of Current temperature. In this morning’s example, the RTS claimed it was at 32 degrees. A different RTS was selected at the time per the schedule, so I manually unselected that one, selected the RTS showing the bogus temp and the thermostat began to show 32 degrees as the Current temperature (in the ADC app, at least - I was not home to see what the physical thermostat may or may not have been indicating).


Alright, I think the next step will be to remove those from the panel, factory reset those devices, then relearn them.

Delete them from the panel using the Clear Device step under Z-wave settings.

Factory reset them:
Remove the battery door, tap the tamper switch three times in a row, press and hold the tamper switch for 10 seconds until the LED starts flashing. Then, release to reset to default.
After the tamper switch is released, the LED will blink quickly and then turn solid for 3 seconds indicating that the device is resetting.

Then learn them in again and monitor. Do you see the same unusual temps reported?

Sorry for the delayed response. So, I ran this exact test with a third brand-new ADC-S40-T that I had added in for the first time and was waiting to see if it would experience the same thing. Unfortunately, it finally did so today. Prior to joining it, I performed the factory reset exactly as you described, and also performed the Clear Device sequence twice in succession.

One other item of note that may or may not prove relevant: I am still running Qolsys firmware 2.7.2. I did not see this listed as a known issue resolved in the 2.8.1 release. I normally update proactively, but was apprehensive after reading this in the update notes:

Improvements to processing of commands for Schlage Z-Wave door locks.

I have some older Schlage door locks and I experienced a pretty bad round of compatibility issues from an earlier firmware update. So, not sure how “safe” these particular changes might be in my situation, and again, not it is not clear if this firmware update would have any positive bearing on the RTS issue.

I am not aware of 2.8.1 having any negative effect on any Schlage locks currently functioning. Schlage locks compatibility is limited based on their physical manufacture dates, from what I understand due to the Z-wave version at the time of manufacture and implementation choices by Schlage.

Schlage BE468ZP and BE469ZP locks manufactured before December 2019 are just not supported.

That said I understand being gun-shy around the Schlage locks. From memory, issues are typically caused by new Z-wave radio versions, not panel firmware though. I think the last issue you are referencing occurred in relation to a unique Z-wave radio update.

2.8.1 firmware does not actually change the Z-wave radio software version. I would recommend trying the new version.