Continuing the discussion from Device Event History Usage:
To stay on topic in the other thread, let's move this here and to a better category.
For a change to happen something needs to trigger it. Narrowing that down is the hard part... Maybe someone with a similar issue has some insight instead of my wild guesses?
I'm very confused...the setpoint changes when you either change it on the device or via the driver either manually or through an app. The attribute thermostatSetpoint can also change if you change the mode of the thermostat. Most thermostats will have a heatingSetpoint and coolingSetpoint. If you change from heating mode to cooling mode then thermostatSetpoint would change from matching the heatingSetpoint to matching the coolingSetpoint.
If @mark.cockcroft does need some feedback on this, I'm sure he can explain it best.
I'm putting it down to one of those ghosts in the system. The driver has no reason to send the command the the events show it as manually being changed (on the trv) but no one was home....
Unless someone broke in and changed it
Or the wife changed it and the message spent 30min bouncing round the meshlol
You see an event with a "new" setpoint or a dup event with the same setpoint? Did the mode change?
Looks like it dropped off the network
There should be a check in event every 10 min
Mesh mesh mesh fun
Its 2ft from the hub with no obstructions
Then I would understand getting the setPoint again. If it was just "found" again. That makes complete sense. What is nextHeatingSetpoint? It sounds like you're working with some custom attributes here and that, of course, will greatly complicate matters. If so, your custom driver could be creating duplicate events, especially is the isStateChange is set to true.
It's a sleepy devices so nextsetpoit is what it store it as waiting the wakeup notification
This is the one device I haven't had issues with
State change isn't set as true in any send events.. unless I've missed one u have seen
Knowing that the expected check in events are not there could account for a new setpoint being set but not recorded until much later. Great fun when all is so instant... 
I'll have to check with the boss to see she manually changed it and if it dropped from the mesh it would explain the set point catching up later when it rejoined.
Doesn't explain why it dropped, I'm sure mesh will be blamed, do you need a mesh when it's in touching distance to the hub
strang its showing in a RM rule
edit i cloned the rule and its showing in the in use section as well
The in-use by is just an artifact of the fact that the device was included in the rule at one point. It doesn't mean it's still included. That's just a red herring and isn't the cause of the "issue" you are seeing.
I'm sorry but I'm not understanding what you see as happening. If the thermostat is battery powered, what's the problem with the device sleeping. You're running a custom driver, so we would have to look at the driver's code to see why you are getting multiple events. There are many possibilities of why this could be seen.
there arnt multi events, its running events it shouldn't, something is sending a heat or on command to it, looking at the driver if no preference for on/heat is set the it defaults to 21, but i have and for a long time had it set for 18.
edit -- also i have itset on 10 min wake up and looking if was on the default 5min
so the parameters for the device have been corrupted, ive save them again, and somthing (the rule i guess) it triggering it
Your driver is using createEvent instead of sendEvent. I believe that createEvent will always create an event even if the value associated with the event hasn't changed. Try using sendEvent instead.
Also, why are you creating an event based on the temp received from the device? I see one event being created is:
createEvent(name: "thermostatSetpoint", value: radiatorTemperature, unit: getTemperatureScale(), descriptionText:discText)
Isn't that going to use the temp reported by the radiator as the setpoint?
Edit: Scratch the first part. I just tried it and it works the same. So, I don't think that is really the issue.
yes but its meant to, one varent dosnt report temprature, so shows on the dashboad as null so for that varent it dispalys the setpoint as the temp to remove the null
ive recreated the rule to 'rule' that out, and save the preferances just have to wait and see
edit, also just notice duplicte events
No, the event name I quoted is thermostatSetpoint. Not temperature. I would think you would report radiatorTemp as temp, not setpoint.
its poor use of a phrase in the method the at the begining the set point reported by the device is called radiatorTemp
def zwaveEvent(hubitat.zwave.commands.thermostatsetpointv2.ThermostatSetpointReport cmd) {
if (logEnable) log.debug "ThermostatSetpointReport ${cmd}"
.........
def radiatorTemperature = Double.parseDouble(convertTemperatureIfNeeded(cmd.scaledValue, cmdScale, cmd.precision)).round(1) //reported setpoint
edit - also noticed that my "night" scene, didnt run complete last night.
So, why are you setting the thermostat Setpoint to the current temperature? It still makes no sense that you would report a current temp as a setpoint to me. And it won't ever make sense. But if it works for you, then go with it.
its dosent, radiatorTemperature is the setpoint reported by the device
Download the Hubitat app
