Centralite 3 series temp and humidity sensor current temp is not being read in RM app

Using the Smart Things driver on 2.3.9.158, the device reports 72.3 if I look at the device in 'devices' but RM app's show the last sample (70.4) not the current value.

Where in the rule are you seeing this? A screenshot may help explain.

In any case, it's unlikely to be an actual problem. Device states in RM are not dynamically refreshed, only on (I think) page load, and if you're looking at it through some "secondary" means like the value of a variable that is set to an attribute in some action, keep in mind that that action won't run again until a trigger -- among other possible explanations for what you're seeing.

1 Like


The device shows 75.68 is the current temp and is dead on.
In the app, the same device is showing the current value is 70.4.
Refresh the page, update the app - same outcome.
i have deleted the device in RM and reinstalled it, same outcome.
Thanks for the reply. jj

Does the rule work as intended when it actually runs? Enable all logging, or at least action logging, to make this kind of troubleshooting easier.

My suspicion is still that this is just a display issue--either that or you have the wrong device selected. The display here is fairly meaningless, just intended to help you see truth evaluations as you set up the rule in case you have problems thinking through one possible logical outcome (though they are normally up-to-date aside from what I mentioned above). It does not affect how the rule actions run--the evaluation of the truth values at that time does.


So i added a rule in the last line to set a variable based on the device, and its temp. same outcome. The rule reads a value from who knows where, but its not the current sensor value. The rule runs btw - if i adjust an offset in the app that is a global variable to tweak where i want the fans to kick on. Anyway sure not working right.

The driver btw is the HE defaulted, 'Smart things humidity sensor'. if you know of a better driver pls LMK thank you jj

Are you sure it's the same device? Might you have two with the same name? Check your Devices list (left-side menu on the hub) to be sure.

While it won't be super-meaningful, you can also click the App Status (gear) icon in the upper right of the rule, look at the "Settings" table (nothing else here matters for this, including event subscriptions), and see if the device with this name that you see referenced there is the same device you are expecting (and if clicked takes you to the same device detail page as the device you posted above).

This isn't meaningful information without knowing your entire rule (everything is cut off in your screenshot except the actions), but I suppose that's good in general.

The driver will not affect this if it's working fine on the device detail page. That's what matters. Apps don't know anything you can't see here--they just read the same values.


got me stumped. for sure, 1 device. look at the last 5 minute report. the app that controls the fans above, the app is stuck on 70.4. it's not getting the current variable handed to it right.,

This isn't exactly what I suggested, but: what is that app (in "Triggered Apps")? If it's not your rule, something is wrong.

If everything above is correct (no way to verify with the information that has been provided, so just going on what you are saying), you might want to try a database backup and restore to see if it helps. Going to Settings > Reboot, checking the setting to show advanced options, and selecting the database restore option is the easiest way to do that.

1 Like

turned the log on for a while; please LMK your thoughts please. and thank you

Debug logs aren't going to show you much beyond more information about the underlying Zigbee messages that correspond to the events you are already seeing. You don't seem to have a problem with those. The device detail page and Events page there is the authoritative source.

I recommend trying the suggestions I mentioned above.

i just ran line for line what you suggested, and it appears it is linked in what i see here to the right device.

The rest of that suggestion: if you click the links for the device (in the right column), does it take you to the device detail page for the same device? Compare the URLs, in particular the numeric device ID you'll find towards the end, to be sure.

Other suggestions:

Less drastic than the above (but actually slightly less easy), you could consider removing and re-creating this rule (the entire rule, not just re-creating one of the actions--not sure what you tried above) to see if the behavior is different.

I'd try one of these and then the other, in no particular order, to see if either or both helps before trying any other steps.


I wrote a new rule, one line, The device temp variable still stuck on 70.4 here also, this has to be a bug.

I ran a cloud backup then shut down and powered down for 1 minute.
Reran zwave repair, many failed nodes but after 2 runs it ran clean.
After this, the variable is passing properly now - closed issue. thank you for the suggestions. jj

Note that this is not what I suggested. A backup alone does not change your existing database; the suggestion was to do a rebuild, now fairly easy using the steps outlined above (a couple checkboxes).

The CentraLite is a Zigbee device, not a Z-Wave device, so this would not have changed anything -- nor did you appear to be dealing with a device problem given that the authoritative sources (on the device detail page) were updating fine.

Regardless, that is good! A reboot alone may have been the key if you were experiencing elevated hub load or something else that may have caused the problem. I'd still suggest the database rebuild if you notice anything similar come up again.