In the past, I experienced inconsistencies between the homematic bridge and child thing status if one of them went OFFLINE. I observed child things that were ONLINE although the bridge was, e.g., in OFFLINE/DUTY_CYCLE, and I observed child things that were OFFLINE due to a communication error with the gateway, although I could see that there was already successful communication to the device afterwards.
In order to resolve these inconsistencies, this PR changes the handling of the thing status in the HomematicThingHandler in two ways:
In the updateStatus() method, the thing was only set to OFFLINE depending on the state of the "status datapoints" (UNREACH, CONFIG_PENDING etc.). However, is the bridge is OFFLINE, all its devices are expected to be in the status OFFLINE/BRIDGE_OFFLINE. Therefore, the bridge status is now checked in this method and the thing is set to OFFLINE/BRIDGE_OFFLINE if the bridge is OFFLINE.
So far, only updates to the status datapoints triggered a thing status update. However, in general it is possible that a communication failure between the binding and the homematic gateway results in things that are in status OFFLINE/COMMUNICATION_ERROR without any of these status datapoints indicating such a failure. In order to restore these things to the status "ONLINE" after a successful communication with the gateway, the updateStatus() method should be called for any kind of datapoint update.
In the past, I experienced inconsistencies between the homematic bridge and child thing status if one of them went OFFLINE. I observed child things that were ONLINE although the bridge was, e.g., in OFFLINE/DUTY_CYCLE, and I observed child things that were OFFLINE due to a communication error with the gateway, although I could see that there was already successful communication to the device afterwards.
In order to resolve these inconsistencies, this PR changes the handling of the thing status in the
HomematicThingHandlerin two ways:updateStatus()method, the thing was only set to OFFLINE depending on the state of the "status datapoints" (UNREACH, CONFIG_PENDING etc.). However, is the bridge is OFFLINE, all its devices are expected to be in the status OFFLINE/BRIDGE_OFFLINE. Therefore, the bridge status is now checked in this method and the thing is set to OFFLINE/BRIDGE_OFFLINE if the bridge is OFFLINE.updateStatus()method should be called for any kind of datapoint update.