Is an app not working as expected? Or, is a device not working like you think it should? If so, start here for some troubleshooting tips!
Is an app not working as expected? For example:
If so, here are some tips that may help.
Most apps have one or more types of logging that can be enabled. For example, Rule Machine rules have a Logging option that allows you to enable one or more of Trigger, Action, and Event logging. Enabling Action logging in particular will tell you what actions the rule is executing when (though enabling all may be helpful) and is a good first step to answering questions like "why didn't my rule run?" (perhaps it did and your devices simply didn't respond as expected, or it will reveal issues with your rule logic):
Most simpler apps have a toggle to enable all logging. For example, in Basic Rule:
Other apps may have different options (and custom/community apps may vary), but most built-in apps offer one or more logging options similar to the above that may help.
Check the Logs page to view logs that apps may generate if logging is enabled as described above. You may also wish to scan the Past Logs (also accessible from the Logs page) for "error" or "warning" entries that may indicate a problem. Sometimes, error or warning logs are generated even without any kind of app (or device) logging specifically enabled, so it's always helpful to consult the logs even if you're troubleshooting a problem and did not have logging enabled when it happened.
HINT: Consult the Logs documentation to learn how to use features that may be helpful when troubleshooting specific apps or devices, like how to filter log entries to just specific apps or devices.
If you are unsure how to interpret logs, the official Hubitat Community forum is a great resource! Be sure to specify what app or device you are wondering about, your hub model, and the platform version – and anything else that may be helpful or relevant (e.g., screenshots of the log).
Ensure the options you have selected in the app are the correct options to achieve your desired outcome. The Apps documentation section may be helpful. For Rule Machine rules or other complicated (or not!) apps, it may be helpful to ask the Community to look at your rule or other app configuration. For rules, it is generally helpful to post:
If the app appears to be configured correctly and logging suggests it should be sending commands to devices correctly, perhaps there is a problem with the device. Try navigating to Devices, selecting the device in question, and manually running commands (buttons at the top of the device page) to see if they work as expected. For example, a switch device may present
Off commands, and they would be a good idea to test if you're troubleshooting an app that is supposed to turn the device on or off.
Besides Logs, another way to check whether an app did with a device is to check the Events page for that device, accessible from the Events button at the top of the device detail page for that device. This table shows a history of events and commands sent to the device:
on). The name of the app that sent the command will be displayed in the "Produced By" column, C. This can be helpful if app logging is not helpful enough (or was not enabled) to determine what app sent a command to a device or if the app sent a command but the device did not response (see below).
Is a device not working as you expect? For example:
NOTE: Beyond the tips here, if your device is a Z-Wave device or you are having Z-Wave problems in general, see: How to Troubleshoot Z-Wave.
To help verify if a device is working correctly, try navigating to Devices, selecting the device in question, and manually running commands (buttons at the top of the device page) to see if they work as expected. The goal is to test by manually running commands from the device page to see if the command works here; if it does not, then it will not work with any app, either (including Hubitat® Dashboard, Rule Machine, Motion Lighting, or any built-in or custom app).
For example, a dimmer or bulb should have a
Set Level command (and many others). For this command, type a level value (for example, 50), then select the
Set Level button itself to run the command. Verify that the device responds as expected. Try other commands if needed, ideally ones you think the app would be calling based on what the app should be doing, if you are troubleshooting a device as part of an app/automation.
If commands appear to work here, additional troubleshooting with the app in question may be necessary (see above).
Most device drivers offer an Enable debug logging option, which (when enabled) will generally log information that comes into the hub from the device. This can be helpful to determine if/how this information becomes an event, such as "switch on" or "level is 50%" but provides view closer to the "raw" data from the device before it gets parsed into an event (or not). Some drivers may also log when commands are executed, but not all do; most apps offer an option that will indicate when they are running a command (see above) and will be more helpful in such cases.
Most drivers also offer an Enable descriptionText logging option. This generally logs events, like "switch on" or "thermostat operating state is heating." This does not show when commands are executed, simply when the device sends information to the hub and the driver creates an event. Its use in troubleshooting is therefore more limited than debug logging on devices or most app logging, but it may still be helpful.
Enable debug logging is turned on for 30 minutes by default for new devices added to the hub, then automatically disabled. It it also automatically disabled 30 minutes after any time it is manually enabled. Enable descriptionText logging is enabled by default and remains enabled until manually disabled.
These descriptions apply to built-in drivers. Custom code (community drivers) may vary, though third-party developers are encouraged to offer similar options.
Check the Logs page (current logs or past logs) to see logs that device drivers may generate if logging is enabled as described above.
With or without logging enabled, errors that the driver does not handle are automatically logged. Thus, even before enabling logging, you can still scan the Logs page for "error" entries that may indicate a problem (but it is generally helpful to enable).
Here is an example of how an "error" entry might appear in Logs (circled in red for clarity here; your logs will not show this circle):
Configurecommand on the device page after switching drivers. Try this if you haven't.
Configurecommand can also be run manually as part of troubleshooting specific device problems, including a Zigbee device not reporting updated states back to the hub as expected (note that you will not see anything happen on the device page when this command is executed; you may see entries in Logs)
Select (click or tap) the "Configure" button to execute the command, then wait a few seconds. Normally, you will not see anything happen after executing the command, but it may be important in order for the driver to work correctly.
Beyond the app- and device-specific troubleshooting above, the App Stats and Device Stats pages, accessible from the Logs page, may help with troubleshooting general hub issues. These issues include slowdowns, a "Severe hub CPU load detected" notification, a notification that the Zigbee radio turning offline unexpectedly (often caused by extreme load on the hub), and sometimes slow or unreliable app or device behavior that could result from this problem. In general, an app or driver that is using a large total percent of the CPU or other resources may be problematic. However, every app and driver — and everyone's hub setup — is different. Consulting the Hubitat Community for assistance may be helpful. If you suspect a specific app or device is causing excessive resource usage, you may wish to consider if removing or disabling that app or device eliminates the problem (see Disable Device Drivers and Disable Apps).
For cases of suspected database corruption (for example, apps with "Scheduled Jobs" that appear to be scheduled correctly but do not execute when expected; SQL errors in Logs; and others), a soft reset and restore from a backup may help. A soft reset does not affect the radios and is thus a generally safe procedure. To perform a soft reset:
Did you recently update your hub and suspect that the upgrade "broke" an existing device or automation? Hubitat allows you to downgrade to up to three previously installed platform versions. You can downgrade to test again and verify your suspicion.
NOTE: Sometimes, downgrading a platform version requires restoring a matching database due to changes made to the database as part of the platform version upgrade. The release notes will indicate when this is the case. You may wish to restore a backup made under the previous/matching platform version to be certain, though this is often not necessary.
NOTE: A hub backup does not include the platform version (though it does note the version as part of the default filename to assist with matching if required as described above). The platform version can only be downgraded through the Diagnostic Tool and upgraded from either the Diagnostic Tool (if available) or the regular hub interface.