I realize this is more than one question, but is is all related to Capture.
when I execute a Capture in Rule Machine 5.1, is it capturing the value from the physical device, or from a DB inside of Hubitat (i.e. the actual device value vs. what Hubitat thinks it is)?
Is there a way to Capture the value of a Dimmer, for example, and write that value to a variable or to a virtual dimmer?
Same question as #1 but for the Maker API call: Get Device Info (replace [Device ID] with actual subscribed device id http://10.0.0.41/apps/api/682/devices/[Device ID]?access_token=92b79d18-c131-4a3c-993b...
It is capturing the value of the attributes as reported by the hub (the hub can't possibly know anything else). You can see what these are by looking at "Current States" towards the top of any device detail page. For most devices, these should reflect the current state; some polling-based LAN/cloud integrations or very old Z-Wave switches/dimmers that changed via a physical rather than hub action are the rare exception, outside of driver or configuration problems.
Yes. You can create a variable and use the "device attribute" option to set the value of the variable. Choose the device (your dimmer), then choose the attribute (level in your case, assuming that is what you mean with "value"; note that unlike my example, you'd probably want a numeric variable rather than a string):
There is a way you could get this into a virtual device if you really need to (set the level of the virtual device just like you would with a real device, but provide the variable instead of a fixed value, in the action). However, the above is all you'd need for a a variable, and there's no avoiding this intermediate step if you don't, at least not if you want to use Rule Machine for this automation.
This is the same answer as #1; Maker API also does not have a way to know anything about the device that the hub itself doesn't know.
Thank you so much for the informative answers, I really appreciate you taking the time to provide so much detail.
The reason I question the hub is based on experience. I can say "Alexa, set the office light brightness to 30 percent", and yet the brightness does not change, and when I look at the device in Hubitat, I see it is in fact set to 30%. Is there not a way to read the device upon request and get the true value it is set to?
Over a year ago, I created a routine to capture the value of every light in my house, and then turn them all on to max brightness, then return them to their original value using restore. About half of them returned to their original levels and the other half did not. I've also set up a webhook, and about 1 or 2 times in 20, when I issue a command via Alexa or the UI, I see nothing reported via my Python application that monitors the webhook. That is why I believe the only reliable way to know the true values within a device is to read the value from the device.
I have mostly Z-Wave devices, at least for the switches and dimmers that control my lights and fans, and I cannot tell you how many times I have Repaired my Z-Wave network, and there is a Z-wave wall switch less than 15' from my hub, and another less than 15' from that, and the rest are closer to each other than that.
Sadly, I have a reason not to trust what the hub is telling me and wanting actual values from the devices, but I am not sure how to do that.
What device (brand/model) is this, and what driver ("Type" on the device detail page) is it using? This is odd behavior. Normally, when you send a command, it goes off to the device, the device changes, and then the device sends back a report that it has changed. When that last thing comes back to the hub, then the driver parses that report into an event (attribute change) on the device. This is why they are normally in sync. Some LAN/cloud drivers that require polling may "optimistically" generate the event after sending the command (to save you from needing to wait for the polling interval), or possibly after something indicates it was sent without error, regardless of what actually happens afterwards, and that might explain what you're seeing. But for most devices/drivers, that would be odd.
A "Refresh" on the device, if the device/driver supports that command, will normally fetch the current states from the device (though, again, depends on the actual implementation). If yours are out of sync for some reason, that's one thing you can try to see if it helps--whether manually or part of a rule (though I'd give it a second or two to catch up before trying to capture the state if you do this in a rule). Doing this occasionally on one device is fine, even if unusual; doing it frequently on a lot of devices could generate a lot of network traffic and be bad for your Zigbee and Z-Wave mesh or overall hub load, so I wouldn't go overboard with this technique. But if you need to try it...
With further investigation I see that the Lutron hub reflects the change but the bulbs do not. Seems to be an issue with their hub. A reboot is likely the solution. Gone are the days when I wrote code in assembly language or C without an OS and when the code locked up, I had to fix the code before the product was released. Software engineering has changed a lot, mostly for the better. I explained the differences to my kids 15 years ago, and we all agreed we’d rather ride in a space shuttle coded in assembly language rather than one coded within Windows or UNIX!
