Can we have "Physical Thermostat Cool/Heat Setpoint" as a trigger for rules/automations?

[hubitrep]

@chrisbvt

Fine, Lutron does it from THEIR hubs, but it appears HAP does not do that.

Nope, Lutron doesn't do anything, it's the HE driver doing it.

The thing is, physical doesn't really mean physical. It just means "the hub did not ask for this".

As an example, if you command lights with the Lutron app, HE will generate a physical event.

[chrisbvt]

Ok, good, I've learned some stuff, but I said way back it was the driver's responsibility

@chrisbvt

If you thermostat driver does not, it is just your particular thermostat and driver.

So forget all my misunderstandings from Google about HomeKit and matter, this all goes back to what I first said before that. It is the driver OP is using for that particular thermostat, which is in this case is the driver for the HomeKit thermostat.

Also, back to the point I was demonstrating from the original post. Hubitat DOES do that. The original post implied Hubitat does not offer that functionality for thermostats, so I simply proved it does with the Webcore example.

@aaiyar

For my thermostat automations, it would be super convenient if digital setpoint changes made by Hubitat could be distinguished from setpoint changes that originate outside of Hubitat

[hubitrep]

@chrisbvt

Hubitat DOES do that

There's different layers of "doing", here.

The Hubitat platform does allow distinguishing between "physical" and "digital" device events in general, and a convention for understanding which is which.

I believe the OP is explicitly asking for Rule Machine to support this distinction in triggers for thermostats (it's in the title) and implicitly asking for built-in thermostat drivers to implement the distinction.

[chrisbvt]

Yes, my first reply was if Rule Machine doesn't do it, you can do it with Webcore. Nothing to do with a request to have it added to RM.

@chrisbvt

I didn't realize you cannot do that with Rule Machine, but I don't really use it.

Then they didn't think the Webcore piston would even work, when they said

@aaiyar

Have you tried this? Because I don’t understand how that would work if the thermostat drivers cannot distinguish between physical and digital events. AFAICT, they don’t.

Then I posted the results of the piston run to prove that a thermostat driver (in general) can actually do this. I don't know if other built-in thermostat drivers do this or not, but it was clear that was the ask by OP, as well as asking for a way to check for physical events in RM.

[chrisbvt]

@aaiyar

If you understood how Hubitat distinguishes between digital and physical events for the Lutron devices, you’d understand the same process applies for other connected devices.

I assume Lutron drivers use this method then (since you felt no need to explain it even though you referenced it):

Inference and Approximation:

When a device does not provide this information directly, the Hubitat driver may attempt to infer the event type.

• It might look at the timing of commands and events, assuming that if a digital command is followed closely by an event with a change in state, the event might be a response to the command.
• Sometimes, the device may send an "unsolicited" event, which is a change in its state that the hub didn't directly command. This type of unsolicited event is often interpreted by the system as "physical".

I would also note that many Zigbee and Zwave devices DO report this to the hub, and the driver does not need to make an inference to determine it in that case. I hadn't thought about how a driver could infer that info, which is why I was going down the road that matter and HAP do not send those events and that is maybe why it was not there, which is essentially true unless the driver infers the event source based on if it sent the command or not.

[nclark]

@chrisbvt

When a device does not provide this information directly, the Hubitat driver may attempt to infer the event type.

You are way over thinking this...

Digital is a change of state that was made from the hub (HE and HE only) via software app like RM, Webcore (since you seem to so like it), custom app, etc.

Physical is a change of state that the device reported to the hub (again to HE and HE only) without having any app within HE initiate that change, so it is assumed that the change was physical by someone pressing a button even if it might be like in the case of Lutron, been initiated from some app on the Lutron hub.

So when making the distinction between digital and physical, you must of course consider that if you have another hub that might control your stuff, if might be considered a physical change of state without really being one.

[chrisbvt]

@nclark

You are way over thinking this...

You are way over explaining this. Yes, I am very clear in the difference.

The discussion was devolved to how the driver determines if the event from the device is physical or digital, which is not clear cut depending on protocol used and other factors.

@nclark

if you have another hub that might control your stuff, if might be considered a physical change of state without really being one.

Of course. If Hubitat didn't request it, it would infer it to by physical.

I take it with Zigbee, this does not need to be inferred based if the hub asked for it, as it is sent by the device:

The hub identifies the origin. Based on the source address and endpoint, the hub can tell that the "on" command originated from the specific light switch and not from another device (like an automation or a different switch)

Edit: What I learned in this thread:

I assumed the devices always sends with its payload the origin of the event, but learning that Matter and HomeKit do not send that info made me assume that is why @aaiyar device driver could not determine event source.

That is true, but I learned there are ways for a driver to infer this info based on if the driver requested that event within a small timeframe, in which case the event is inferred to be digital since it was requested.

I must say people jumping down my throat on this thread when all I did was offer suggestions for why @aaiyar thermo events were not being classified by the driver as physical or digital is a bit off putting. I was correct the source of events are not being sent by HomeKit, and it is now clear that the Hubitat driver for HomeKit is not using inference to make that determination, even though it is possible when the device does not send the source device.

The only thing I was actually wrong about was stating that the Hubitat HomeKit integration is based on matter, which was a result of Google AI being stupid as it told me that, and I guess that I assumed Hubitat could not infer source in another way for HomeKit, even though the driver doesn't actually do that when it apparently could.

[TArman]

So, back to the OP’s original question. Can we? Please?