So did the issue you fixed explain why a pocket socket that doesn’t have a lux sensor was reporting illuminance?
I am glad you were able to find something, and to find out I was not alone with this issue.
1 Like
I have a few hypothesis about this issue, I am keeping an eye on that to see if it happens again. The logs available to me did not go back that far to get a better idea about the issue.
Will monitor the situation. I will try to reproduce the issue myself. It could be the backend that was syncing the device to run locally used a different DTH (Maybe the author changed DTH) and it wrongfully associated illuminance as a possible capability. Again, lack of logs, otherwise I would know better.
2 Likes
I will add that that GE device could be a relay for a device the has LUX, long short but hey, I seen stranger things. The other switch, I find it very unlikely that any device that has lux would relay though it. I guess it is possible, but unlikely
Do you mean a repeater?
yes that is what I was meaning. I use the words interchangeably. Sorry
1 Like
Have been following this thread with interest. My ‘hunch,’ like Megan’s, is data corruption.
Three of my devices have shown errant reports–false positives in my case–over the course of three years of continuous operation. All are ZWave. All were used as inputs to SHM. Is it the ZWave stack in the hub? Is it something in the data transport from hub to cloud? Is it something clobbering the device data after it arrives in the cloud? I have no way to know and suspect there have been other issues in my two ST systems that I just never noticed.
My latest issue–and how I ‘fixed’ it remotely-- is described here (see Is there a way to recheck a door sensor?) if you’re intersted…