Feature Request - Disable reactor when condition inputs are missing

If I do changes to the input variables to a reactor sensor(i.e delete sensors or virtual switches), i see that its tagged “missing”. This is OK, but wouldn’t it be better if the Reactor sensor was disabled so its clearly visible that it doesn’t have all inputs anymore?

I’d prefer that it disabled itself rather than doing work on wrong inputs?

(Can’t say this enough, outstanding work on this plugin Rigpapa! Its the core function of my HA system now, Thanks!)

[quote=“Forzaalfa, post:1, topic:206238”]If I do changes to the input variables to a reactor sensor(i.e delete sensors or virtual switches), i see that its tagged “missing”. This is OK, but wouldn’t it be better if the Reactor sensor was disabled so its clearly visible that it doesn’t have all inputs anymore?

I’d prefer that it disabled itself rather than doing work on wrong inputs?

(Can’t say this enough, outstanding work on this plugin Rigpapa! Its the core function of my HA system now, Thanks!)[/quote]

Yeah, I’ve been pondering this for a while as well. It seems a double-edged sword. Consider a time condition group to run some lights on a regular schedule, but you use a virtual switch to disable the schedule when on vacation. If the virtual switch was accidentally deleted, bringing the entire schedule crashing down may not be the most desirable behavior. I think you’d certainly like to know about it without having to discover it when you just happen to go into the config. That may not be the best example, as the schedule not working is likely to be noticed and thus would send you to investigate and discover the problem, but I think there are probably many cases where you don’t really want a hard stop if everything isn’t perfect. Device problems are often transient, too (e.g. motion sensor battery dies, mesh problems, etc.); having the ReactorSensor disable itself would prevent self-recovery.

I think an interim step would be to have a “trouble” flag that I could set on the ReactorSensors and Reactor itself, which would cause some kind of feedback on the UI (e.g. different icon and/or status message), and also be able to trigger a notification. That way you can determine the urgency and base your response accordingly. What do you think?

I see your point, but wouldn’t there be a difference in how reactor sees a sensor thats not responding vs a sensor ID beeing deleted?

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…?

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.

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.

wow, i was certain that luup was reloaded on deleting sensors. I see the problem then. :slight_smile:

I suppose the notification is the best approach then, but what about having a “reevaluate” button in the reactor controller that you can use to verify all logic when changes have been made?

This may be better solved by me having more structure in my change process, but thats a bigger issue to solve. ;D

I suppose the notification is the best approach then, but what about having a "reevaluate" button in the reactor controller that you can use to verify all logic when changes have been made?

ReactorSensors “restart” (soft reload themselves) whenever configuration changes are saved (and the “Restart” button does it manually), so that’s already done. But that won’t address the issue of a device being deleted after the fact (when the RS has been up and running trouble-free to that point), which I think is the most general case.

To that end, the Status tab will show missing devices (as device IDs only with “(missing)” appended), so a quick perusal of that would turn up any immediate problems without having to go into the condition editor. I’m prepping Reactor 3.0 for beta now, so I’ll see what I can fit in with regard to the rest of the discussion. It’s definitely an area that could use more effort to assist the user.

Follow up… Reactor 3.0, now released, does more complete handling of device and scene references, and missing devices encountered are now flagged. Your ReactorSensor will inherit a yellow warning triangle over its icon if there’s a problem with its configuration that requires your attention. The additional state variable “Trouble” (boolean) can be watched for notifications or other event-driven purposes.

reactorsensor-trouble

Thanks for the suggestions!

1 Like