Is there any good write up, on how to debug failed rules? I have “IF condition logic check failed” and “State retrieval failed”. I assume there is a device from the wrong family in the rule (another discussion maybe having additional icon next to hubitat icon when you selecting the things for the rule so you know what you are selecting). In the log it shows device with the ID 105. I don’t have such an ID in hubitat, so what is this ID? Any other tricks besides selecting/unselecting device in dozens?
What is the full error message? If your smart home hub platform responded with a particular status code, the log entry may be enriched with that status code which can shed insight into what went wrong.
That sounds like it could be the issue. If I’m understanding correctly, it sounds like the rule was configured to check the status of device ID 105 from Hubitat and that device doesn’t exist in Hubitat anymore.
It looks like that device is “Dirty Kitchen” – was that device changed recently, as it still seems to be authorized to SharpTools?
Since that device still appears to be authorized to SharpTools, I would have expected the log to have included the device name in the error. The rule logs often include a special device reference format which is automatically translated to the user-friendly device name if it’s still authorized to your account, otherwise it’s left in the raw format:
device@{platform}:{locationId}:{deviceId}
Can you clarify what you mean? Do you mean showing an error indicator in the device selection screen for the IF Condition?
In theory, if the device was removed from Hubitat and a device sync was performed between SharpTools↔Hubitat, then when you went to edit the IF Condition, that device wouldn’t exist anymore.
You would see the distinction between the cached label displayed on the IF Condition when it’s in summary mode compared to when you switched the condition into Edit mode. If you then opened the device selection screen and that device didn’t exist in SharpTools anymore, then it wouldn’t be in the list, so just saving the list of selections (and saving your IF Condition and Rule) would effectively remove that device from the list.
Keep in mind that the cached label displayed is a snapshot from when the condition/rule was saved. It’s just intended as a performance thing to make rules load faster – the rules store the unique platform + locationId + deviceId for identifying which device you are referring to as part of the actual action or condition.
You see I have dirty kitchen leak sensor and dirty kitchen contact sensor when I’m selecting it for the rule I dont know what I’m selecting
Something is strange there, I have a rule now with 1 device. It fails the same way. Somehow it does not like the active/inactive rule on motion sensors. I have 5 other rules of the same structure, for battery, contact, etc. All work perfectly.
What is the full error message shown in the log?
So I was looking a bit more here, (thought maybe because I did not see a default attribute for the multi capability device, but now I did), so what is actually wrong with this reply, it looks like hubitat sent all the info you need, no?
[
{
"type": "event",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"objectId": "63",
"source": "DEVICE",
"description": null,
"descriptionText": "Office sensor motion became active",
"eventID": "170971",
"value": "active",
"isPhysical": false,
"isDigital": false,
"isStateChange": true,
"datetime": "2024-04-10T23:13:02.248Z",
"attribute": "motion",
"data": []
}
}
]
That’s an event. The error you mentioned originally is with retrieving state as part of an If Condition.
Both of them fail, here is the other response
[
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "9",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:46:05.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "16",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:53:08.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "15",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:51:54.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "8",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-12-04T02:03:29.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "17",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:53:50.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "10",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:47:19.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "14",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:51:09.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "11",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:48:03.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "12",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:49:02.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "13",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "inactive",
"timestamp": "2023-08-03T04:50:14.000Z",
"isStateChange": null
}
}
},
{
"type": "state",
"subtype": "device",
"data": {
"platform": "hubitat",
"locationId": "869dcdcc-b1c2-4ddd-89d7-1777cf08d3dd",
"deviceId": "63",
"attribute": "motion",
"state": {
"attribute": "motion",
"value": "active",
"timestamp": "2024-04-10T23:13:02.000Z",
"isStateChange": null
}
}
}
]
Both of what fails?
You originally mentioned device 105 showing up in some log and you commented that no device exists in Hubitat with that ID. We looked up the device name from the ID and that device was “Dirty Kitchen”.
That device was still shown in your subsequent screenshots… so if that was never taken care of and it’s a device that doesn’t exist or otherwise has issues, then clearly that issue would still exist.
–
Please also make sure to format your community posts accordingly when including snippets. I’ve edited the replies above with code blocks.
Both condition logic check and status retrieval, it happens for any device.
Your example snippet with the list of states shows that it was able to get the state for most of the devices in that IF Condition. It shows that it got states for all the devices shown in the Runtime Data section that you shared.
Combining that log snippet with the rule configuration, we see the following:
| ID | Name | State |
|---|---|---|
| 8 | cam1 | inactive |
| 9 | cam2 | inactive |
| 10 | cam3 | inactive |
| 11 | cam4 | inactive |
| 12 | cam5 | inactive |
| 13 | cam6 | inactive |
| 14 | cam7 | inactive |
| 15 | cam8 | inactive |
| 16 | cam9 | inactive |
| 17 | cam10 | inactive |
| 63 | Office Sensor | inactive |
| 126 | Hallway Keypad |  |
So it looks like Device ID 126 (Hallway Keypad) is the one that’s absent from the state list and is the most likely suspect for causing issues.
Halleluiah, you were right, Keypad for some reason is a culprit I need to understand why, but less important -:). Thanks a lot, really appreciate it. As usual you guys are awesome!
Ok, I think I figured, there are 3 ring devices Keypad, Doorbell and Floodlights, which in Zwave terms have motion sensors capabilities, however Hubitat unofficial Ring implementation does not have this motion attribute implemented. The question however is, why sharptools shows them as legit motion sensors when I build the rules?
Those devices report that they have the Motion Sensor capability, but they don’t implement the motion attribute. In other words, it’s a faulty driver implementation as the attribute must be exposed if the capability defines it.
The Hubitat platform historically has exhibited other issues when a device driver exposed a capability but didn’t implement the required attributes – including hub sluggishness when making API requests for those devices (w/ status detail).
Yep, looked at the driver code, you are right. Hard to complain though, the guy who wrote it, is a hero -:), the whole Ring suite covered and works ok in most cases…