¶ Device Events
The device events page is accessible from the Events button at the top of the device detail page page and shows a a history of recent events generated by the device and commands sent to the device:
- Name (A) shows you the name of the event (also called attribute name) or command:
- For events, the Name column will list the name of the event (also called attribute name). For example, this may contain "motion" or "battery" for a motion sensor or "pushed" and "held" for a button device. The item labeled N demonstrates a "switch" event showing the switch reporting to the hub that it was turned on.
- For commands, the Name column will start with "command-", followed by the name of the command that was called. The item labeled M above shows the
setColorTemperaturecommand was called on the device around that time.- Most commands (e.g., "On" or "Set Color Temperature") are intended to change the state of the device, so if you see a command listed without an event shortly after (or sometimes before, as in this screenshot--all happened within thousandths of a millisecond, and the command history happened to not be committed until after the event had been processed in this example) and the device was not already in the desired state (generally, only state changes will produce an event), it may indicate a device or mesh/network problem.
- Command history can be helpful to rule out app problems (e.g., determining if an app sent a command or not and whether you need to troubleshoot an app or device problem).
- Value (B) shows the new value for the event/attribute. This could be anything, including "active" or "inactive" for the "motion" attribute of a motion sensor, a number in Watts for an energy monitoring device "power" event, or the button number for "pushed," "held," etc. on a button device.
- Unit (C) shows the unit, if applicable, that was sent with the event value, as determined by the driver. For example, in the case of a temperature value, you may see ˚F or ˚C (usually as determined in Settings > Hub Details and your preferred units, though some drivers may also offer their own settings). For color temperatures, you may see K (Kelvin), for humidity sensors you may see %, and so on.
- Description (D) shows the description text sent with the event, as determined by the driver. This may be blank, but often drivers generate this text in a format like "Device name event name is event value."
- Source (E) will normally show "DEVICE" and does not currently have a documented use for end users (other columns can reveal more about why an event may have occurred)
- Type (F) shows the type of event that has occurred if the driver sends this information with the event. For example, some switches and dimmers will show "physical" or "digital" here, depending on whether the event was made in response to paddle/switch presses on the dimmer itself (physical) or commands from the hub (digital). Not all drivers report this information for all events. Some apps, e.g., Rule Machine, may offer the ability to distinguish between physical vs. digital events for certain triggers or other configuration options.
- If the row represents a command instead of an event, the Type column will show "command". This is not an event and is not usable as a "trigger" or subscription in any app, but for commands intended to change the state of a device, it would normally be accompanied by an event around the same time if the command was successful.
- Produced by (G) will show the app or driver that called the command or that likely generated the event. (For events, steps will be traced backwards to determine an app or driver that likely created the change. This may not always be accurate, particularly if multiple apps or physical interaction with the device may have caused multiple changes around the same time. Command history is traced back to the app or driver that called the command and will likely be more helpful. If the device/driver itself is listed here, the command may have been called manually on the device detail page.)
- Triggered apps (H) lists apps that were subscribed to this device event at the time the event was generated. Normally, this is because they do something in response to this event or need to know about these changes for other reasons. Each app name is a link to the app configuration page that should show you more information about how the app is using the device. If a state change in this device caused a change in another device and you're trying to troubleshoot why, this can be a good place to start (but see also the "In use by" section on the other device's device detail page). The name of the "handler method" is displayed in parentheses after the app name, which is generally of use only to the app developer or if you are troubleshooting a problem with them.
- Date (J) is a detail time and date stamp of when the event occurred. This time and date stamp together with the event type can be very helpful information in determining if your device has been interacted with by physical manipulation (e.g. Somebody turned the light on) or by a digital event (i.e. A Rule Machine rule or app resulted in the device event that occurred.
- The search box (K) can be used to filter the list of event and command history to just rows that contain the specified text in any column. This search is currently case-sensitive.
- The Edit device (L) link returns you to the device detail page.
NOTE: Do not confuse the Events page for a device with the platform Logs feature. Logs will show anything that the driver (and apps, etc.) writes to Logs. This may include event descriptions and other information, as determined by the driver and your chosen settings. The "Enable descriptionText logging" and "Enable debug logging" options common in system drivers relate to Logs and do not affect the display of entries in Events.
¶ Events vs. Commands
What is the difference between an event and command? The Events page displays both (although it originally only displayed events, hence its name).
- A command is something sent to the device from the hub.
- This could come from a rule or other app, the mobile app, a dashboard, you manually on the device detail page, any third-paty integrations like voice control that go through Hubitat integrations, etc.
- Think of a command as a request to the device. It is not a guarantee that the device responded (or that the driver generated an event).
- An event typically represents a change that actually happened.
- Examples include a switch turning on and off or a sensor becoming active or inactive.
- Most drivers generate events when the device sends a message to the hub indicating that something happened, but this behavior is ultimately under control of the driver and may vary depending on the exact device, what protocol it uses, and any device-specific quirks.
- Events typically follow successful commands (e.g., sending an "On" command to a switch that is currently off should result in an "on" event for the "switch" attribute).
If a device is changing unexpectedly (e.g., a switch keeps getting turned on or off and you don't know why), looking at commands may help you figure out why. The app that sent the command will be listed as the "Source."
If an app is not triggering/running/etc. and you aren't sure why (e.g., a rule that should trigger when a switch turns off is not performing the expected actions), looking at events may help. For example, maybe the switch didn't really turn off, at least as far as the hub can see.
See How to Troubleshoot Apps or Devices for more on both of these troubleshooting topics.