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:
Triggers ADC app notification rules (as per initial example / screenshot)
Bogus temperature shows for the RTS in ADC app under Temperature Sensors
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.
Thank you, I am reporting the bahavior and testing results to Alarm.com so that they can investigate. I’ve not seen another report of this specific behavior, but it does seem like a compatibility issue with the panel or a fault in the sensors. The same fault would be odd on two sensors though.
Thank you, Jason. Three of these RTSes are affected, and they were purchased and installed in two batches (I made a second purchase after the initial report).
We’ve not been able to pin it down yet, but we do have a few additional questions:
Was there any period of time where this did not happen after adding them, or have the errors occurred intermittently since first installing the sensors?
When this occurs, does it affect all the S40Ts at the same time, or just randomly affects one at a time?
Can you provide a few recent date and times when the invalid temp was showing for one or more of the sensors?
When this occurs, can you confirm that locally the thermostat shows that invalid temperature average?
No, there has never been a period when this behavior did not occur with this specific model of RTS (I also have the older ADC-S2000s that have never experienced this issue). I would say that I first experienced this issue within a week of installing the first ADC-S40T.
This issue always occurs randomly with individual RTS units, and has never simultaneously affected more than one unit at the same time (I have 3 of these units now now).
Recent instances have occurred on the following dates/times:
-7/20 @ 7:58am: MS Temp
-7/17 @ 12:41am: O Temp
-7/15 @ 5:34am: MS Temp
-7/13 @ 9:35pm: MR Temp
-7/9 @ 10:38pm: MS Temp
-7/1 @ 8:08am: O Temp
…with each of these occurrences, the temperature is called out at exactly 31.9 degrees F.
You’re asking if the current temperature average displayed locally at the thermostat accounts for the bogus RTS reading? If so, I don’t know, but I will make a point look for this the next time it occurs. The problem is that these excursions do not tend to last very long and frequently occur when I am either not at home, or am asleep. But I’ll make a point to check into this when it occurs again and if/when I’m able to do so.
I have this exact same issue with a customer. Been working on for 3 weeks. The problem is likely with the range. Add an extra repeater or two from Aeon Labs to the system between a known working device and the temp sensor. Run a network rediscovery to ensure the TS is getting a signal. From personal experience they have low range. This device is essentially tiny so the range is much shorter. once its taking well with the other devices, you will have better luck. Also don’t send a bunch of commands or refresh’s…give it time to work. The IQ2 is slower than the IQ4 and range is shorter. Consider upgrading. My 2 cents as an alarm. com dealer/installer pov
My customer still has this issue but with hours of trouble shooting, pretty sure this does the trick. I can also see the back end where this one sensor fails rediscovery every time. Its a brand new ADC-S40-T
@alarmexp Thank you for chiming in with your experiences. In my case, I have a strong mesh as I have something like 50 repeating nodes, and these affected RTS units range from 3’-10’ away (open air) from previously-installed repeating nodes (light switches, etc).
Additionally, some of these ADC-S40-T RTS units replaced older-model ADC-S2000 RTS units in the same locations, which ran for years without any type of signaling issue.
Regarding your comment on rediscovery, my understanding is that none of these RTS units participate in rediscovery by design (I gather as a battery conservation measure). They only learn about neighboring nodes/paths during initial inclusion when joined to the mesh, which is why ADC recommends that they only be joined once permanently installed in their intended location, as opposed to other types of Z-wave devices (i.e. door locks), where they recommend initial inclusion be performed close to the panel - regardless of intended location.
I read this somewhere, and this is also what I experience for myself when initiating a rediscovery against any ADC-S2000 RTS (all of which have worked flawlessly) and any ADC-S40 RTS (all of which have experienced this issue since installation).
The interface of that screenshot that you included doesn’t look familiar… If this from a dealer-only interface, or the ADC Mobile Tech app…?
@jwcsurety I do have some new observations (and a correction) to share, as I experienced this issue 2 days in a row this week, and in both cases was around to see what the thermostat was indicating:
When an RTS is showing the bogus indication, it does not appear to figure into the temperature average indicated either on the ADC app or at the thermostat itself. I may have indicated at an earlier point that it skewed the temperature average as viewed on the ADC app, so apologies for the bad data point there. I was able to confirm this consistent behavior during both incidents this week.
The behavior does affect both notifications (get alerts during these temperature excursions for upper/lower temperatures). Also, just to reiterate, the bogus temperature does show under Temperature Sensors card in the ADC app.
Hopefully this helps to clarify and narrow things down.
Regarding your comment on rediscovery, my understanding is that none of these RTS units participate in rediscovery by design
That’s correct. Alarm.com RTS do not respond to Network Rediscoveries.
When an RTS is showing the bogus indication, it does not appear to figure into the temperature average indicated either on the ADC app or at the thermostat itself.
Thank you for confirming this.
I have this exact same issue with a customer.
Are the temperatures being reported always the same temperature? If so, what is the temp?
@jwcsurety Ok, new information: I had another recurrence on August 19 at 8:21pm (and which cleared at 10:23pm). During this occurrence, the temperature average was genuinely skewed. On both the ADC app, as well as locally at the thermostat, it was showing current temperature average at 59 degrees, when in actuality it was in the low 70s.
I’m now second-guessing if during the previous couple times before that when I was able to check the thermostat locally, either the thermostat schedule did not have the affected RTS included in temperature averaging, or perhaps there was a timing element, and what I saw at the thermostat was in actuality some delayed indication.
In all 11 occurrences still available in my activity history, the temperature the affected RTSes were reading it always 31.9 degrees F.
@alarmexp Can you please chime in to confirm whether or not the events your customer’s experiences always have their RTS reading at this same incorrect temperature?
During this occurrence, the temperature average was genuinely skewed.
Thank you for following up and clarifying this. If it affects the average I would recommend not using that option at this time if this issue is frequent and causes problems.
I think it might escalate this between ADC and Qolsys since it is not just visual as previously thought.
the problem with ADC is their tech support is scripts only, no engineers. The set up I have also has the s2000 TS which do report neighboring devices. The S40 I am unable to pick up other devices.
So I officially completed the zoom call with Alarm.com commercial expert. We actually were able to fix our issue. When viewing the temp sensors on alarm.com(I suggest on a pc not the app) you may need to hit the refresh button a wait patiently. Also if you have an independent temperature gauge to confirm the temps in the room with the T sensors. Make sure they are installed at 5’ on a wall. Not in direct sunlight or directly under AC vent.
The biggest issue we had was on the schedules. You have to go in to each interval and make certain the T-stat and T-sensor are checked on cool AND on heat. If they are properly aligned when you view the t-stats you may see a (+1) number.
It also has to be checked at home, away, sleep, and custom for each t-stat
Also, the older s2000 will talk through the other devices, so a rediscovery is recommended for those. The newer s40 temp sensor will not talk through other devices. This can speed up the process when you are looking to refresh the temp reading on the sensor.
We did many trial and error. The easiest one is to have the temp sensor connected to a specific t-stat with out the schedule on it. If it still reads bad the sensor could be the issue. Always refresh with the circular arrow and wait until it stops flashing so you know you have the very latest reading. You may go to the page and see a temp that is inaccurate.
I also confirmed that T-sensors will go to sleep when running schedules and are pinged at the temp change intervals in your schedule.
I live in Florida where the temp seems to be much different than where you are located. Its always 90+ degrees every day in the summer.
There is always 2 temps to look at, the t-stat temp and The sensors temp. I have not read anywhere that the temp on the t=stat will read ANYTHING about the t-sensor.
I hope this info helps you. I will still follow this thread.
