Perhaps not. Especially in the upcoming version of Reactor, which expands the condition logic structure substantially, it’s possible that the absence of a device may only affect one group, and the inability of that group to resolve may or may not cause a severe enough problem for the logic overall that another user would want the ReactorSensor disabled. I don’t want to make that choice for my users. I’d rather just give them an indication that something isn’t right and otherwise proceed as best able to complete the task.
For the former i'd think a GUI representation like AVT does would suffice, but if the sensor is completely gone then there's no chance of self recovery anyway..?
Sure, but as soon as the logic involves several devices, or devices and time, or whatever else someone may come up with, whether the loss of a single device is irretrievably fatal to the logic overall can only be determined by the user who programmed it, because it includes not only the literal functionality of the logic as programmed, but that user’s perceived importance of the function it performs. I have no way to judge that.
No big deal, i just noticed that when i made som changes, some reactors would go about their business like before, and there may be several missing some inputs.. If they were to go gray i would see which ones was affected by my changes instantly.
Sure, and that’s desirable, because anyone would want to fix even a broken subset of their overall logic–you want to know when something isn’t right, no matter how trivial that problem may ultimately turn out to be. That’s why I favor the notification option, as it serves to potentially remove the delay caused by the user having to notice, without disabling logic that might otherwise be functional.
It is still the case, however, that there may be a substantial delay between the act (deleting the device) and the detection/report. For example, consider a ReactorSensor with just a single condition that looks at a device, and you delete the device. Luup does not send an event to indicate that the device is deleted, and state change events for the device simply stop coming. There is therefore no way for the ReactorSensor to know that the device is no longer there, until it has reason to contact the device, which in this case would only be a manual ReactorSensor restart or Luup reload. Even in cases where there are multiple conditions, one of the other conditions would need to cause a re-eval for the missing device to be detected, and that could be a very long time. Although Reactor re-evaluates all conditions on Luup reload, deleting a device does not cause a Luup reload.
Fortunately, most users are very cautious about deleting devices, with good reason. It still amuses me no end that renaming a device or changing its assigned room causes a Luup restart, while deleting a device does not.