"Poke" a Reactor Sensor

Plugins & Plugin Development Reactor
#1

@ rigpapa

thanks for this awesome plugin/app
it has replaced several older plugins/apps that no longer worked properly in UI7
its very flexible and offers so much more than combo switch

one thing missing in comparison that I would like, if possible
is a pulse/poke/probe button found in the combo switch
i realize i can use the reset button, but this adds load on the system and takes about 30 plus seconds to reload that reactor
please let me explain one use case

in our bedroom i have 3 reactors that look at occupancy, room temp, home state, and current fan running state
all 3 have the same conditions except for the temperature range
this then decides based on the active reactor if the ceiling fan will run at low, medium, high, or simply off as its not hot enough
well, last night there was a power outage, but when it comes back on zwave devices do not restore last state
they are off even though the reactor state was still on
as the scene is not triggered if nothing changes
so when this happened the fans stopped running
with a poke/pulse/probe command
i can poke/pulse/probe the reactor as an example every 5 minutes
then the 3 scenes could have each 2 triggers instead of one
1- reactor tripped 2- reactor poked/probed/pulsed while tripped
by poking it every 5 minutes if the reactor is triggered but the fan is stopped the scene will re-trigger and the fan will be on

this would be a great addition
hopefully its something you can do
if you want to see how it was implemented in combination switch by futzle here is the github

i see you are working on a scene implementation for reactor
perhaps this may also somehow achieve what i am trying to do
i basically just need it to re-trigger periodically

#2

[quote=“charettepa, post:1, topic:199808”]@ rigpapa

thanks for this awesome plugin/app
it has replaced several older plugins/apps that no longer worked properly in UI7
its very flexible and offers so much more than combo switch

one thing missing in comparison that I would like, if possible
is a pulse/poke/probe button found in the combo switch
i realize i can use the reset button, but this adds load on the system and takes about 30 plus seconds to reload that reactor
please let me explain one use case

in our bedroom i have 3 reactors that look at occupancy, room temp, home state, and current fan running state
all 3 have the same conditions except for the temperature range
this then decides based on the active reactor if the ceiling fan will run at low, medium, high, or simply off as its not hot enough
well, last night there was a power outage, but when it comes back on zwave devices do not restore last state
they are off even though the reactor state was still on
as the scene is not triggered if nothing changes
so when this happened the fans stopped running
with a poke/pulse/probe command
i can poke/pulse/probe the reactor as an example every 5 minutes
then the 3 scenes could have each 2 triggers instead of one
1- reactor tripped 2- reactor poked/probed/pulsed while tripped
by poking it every 5 minutes if the reactor is triggered but the fan is stopped the scene will re-trigger and the fan will be on

this would be a great addition
hopefully its something you can do
if you want to see how it was implemented in combination switch by futzle here is the github

i see you are working on a scene implementation for reactor
perhaps this may also somehow achieve what i am trying to do
i basically just need it to re-trigger periodically[/quote]

OK. It sounds to me like what you really need is for Reactor to have the option to retrigger on startup. It should not otherwise be necessary to “poke” a ReactorSensor, since they are watching the underlying devices, and any change in an underlying device causes an immediate re-evaluation of the ReactorSensor condition and trip state. It is already the case that a ReactorSensor re-evaluates all conditions on startup. But for either a sensor restart or Luup reload/reboot, if the outcome of that re-evaluation is that the ReactorSensor should be tripped, but it is already tripped, it is not retriggered, so any connected scene or event processing will not rerun. I can look into providing an option to force a retrigger at startup.

Here’s what concerns me about what you’ve said, though. You said you are checking the fan state in your Reactor conditions. If the fan is off after a power fail restart, Vera should know that, and therefore Reactor should know that. If the Z-wave device (in the wall) has the fan off, but Vera thinks the device is on, then Vera’s Z-wave startup/configuration for that device is broken and Vera needs to fix that bug–it should query the current state of the device during initialization, and therefore know that the fan is off. This, in turn, should be seen by Reactor as cause to turn the fan on (if your logic is correct).

I’d like to see your logic. If you go the Test tab, there’s a “Device Status” link at the bottom of the page. Hit that, and PM or email me the output (my email address is on my profile here).

#3

@charettepa and I have been exchanging emails out of band with data, and I now understand the problem and his objectives. I’m bringing it back here, because I think it will be good to have this as part of the forum record in case other users run into similar issues.

charettepa has a Vera Secure. Since it’s battery-backed, when the power goes out, his Z-Wave devices go off-line, but VS doesn’t seem to be aware of it (presumably the outage was short, so the devices were back before any Z-Wave timeouts would have occurred). The problem, then, is that one device in particular, a fan controller, powers up with the fan off rather than its prior state, so now VS and the fan control are out of sync (VS thinks it’s still on). They will not come back into sync until (a) the fan control is explicitly manipulated, either at the control or by VS, (b) VS polls the device and then discovers its real state, or (c) VS reloads Luup and restarts the Z-Wave network, at which point the initialization/configuration process for the device should get VS and the device back in sync.

Now, if you’ve followed the conversation above, my initial thought was to add a retrigger-on-restart flag to have Reactor retrigger when a Luup reload occurs (if it was triggered before and should continue to be triggered after), to “tickle” the scene that turns on his fan (thus meeting condition “(a)” above and resyncing the device in addition to turning it on). The problem with that is that Luup isn’t reloading–since the Vera Secure is battery-backed, it doesn’t care that the power went off, and doesn’t reload Luup when it comes back on, at least, not that I know of (I’m going to ask this in a separate thread to be sure).

The alternate solution I now propose for charettepa is this:

[ul][li]Change the ReactorSensor’s existing “Retrigger” state variable from 0 to 1; this will cause Reactor to set [tt]Tripped[/tt] every time an evaluation of conditions is done, even if it hasn’t changed (normally, Reactor only sets it if it changes).[/li]
[li]Make a new ReactorSensor and move his house mode conditions (Home, Night) there (and keep Retrigger=0 in this new sensor), then change his existing fan control ReactorSensor’s to use the new ReactorSensor.[/li][/ul]

Why #2? House mode is an attribute of the Vera, not a variable, so when Reactor is looking for changes in house mode, it can’t “watch” the house mode as it can with state variables on device (where Vera triggers a callback immediately and only when the value changes), it has to poll the house mode to see if it changes (blech). So, if you have a ReactorSensor with house mode conditions, that sensor is force-re-evaluating itself every 60 seconds (if any other plugin devs know of a way to detect house mode changes better than this, please chime in). That basically means his ReactorSensor will also, then, retrigger every 60 seconds, and this is not necessary and probably undesirable. So moving the house mode test to another sensor removes the unnecessary retriggers from the fan logic sensor.

#4

thanks so much for looking in to this
i can confirm that retrigger=1 is working as you described
unfortunately exactly as you describbed it retriggers every 60 seconds even if nothing changes
to minimize impact on the system
is there a way to retrigger only if a value changes even if its still within scope

ie.

temp is above 72 but below 75
and is currently 73 but changes to 74
its still true but retriggers

this would cause much less load on the vera system as it would only retrigger based on change rather than 60 seconds

#5

Did you move your house mode test out to a second Reactor with only that? This is key.

#6

i have
the issue is that it was still retriggering every minute but only for house mode
its the change in temp im interested in
my temperature is granular down to .1
the house mode really only changes in the morning when we leave

are you saying its the house mode that actually causes it to retrigger every minute?

i tried to reverse the process and it has helped alot

i set the house mode evaluator to NOT retrigger
but the main reactor to retrigger
now it only retriggers about every 4-5 minutes

so it seems that house mode refreshes every 60 seconds
but my room sensoes for temp only every 4-5 minutes
this might work

#7

The house mode ReactorSensor MUST NOT be set to retrigger. Now that you fixed that, it sounds like you are getting the right behavior.

#8

thank you so much
i just went back and re-read your message
i did read it backwards

while it still retriggers everytime the temp changes
its alot less
and will be even less once its fully configured
as it will only do so during the night in a specific thermostat mode

does retrigger
recheck for every change only if triggered
or on every change even if not triggered?

#9

If you simplified your ReactorSensor to a single condition that only tests temperature > 77F, then if your temperature sensor updates every five minutes, Reactor is rechecking the condition every five minutes. Every time your sensor updates TemperatureSensor1/CurrentTemperature, Luup fires the watch callback to Reactor. That’s true whether Retrigger is 0 (the default) or 1, because Reactor is notified by Luup every time the sensor updates.

The difference Retrigger makes is what Reactor does when the condition is met (e.g. the temperature really is > 77F). When Retrigger=0, then the first time the condition is met, the ReactorSensor sets Tripped=1, and that’s it, it will not set Tripped again until the condition becomes false (temp 77 or less, when it will then set Tripped=0). But, if Retrigger=1, then every time the sensor updates and the temperature is still > 77F, the ReactorSensor will set Tripped=1 again.

Or put another way, if we look at a sequence of temperature measurements, here’s what Reactor does with Retrigger=0 (the default):

Temp Action 76 Do nothing (condition not met) 77 Do nothing (condition not met) 78 Set Tripped = 1 (condition met) 79 Do nothing (already tripped) 80 Do nothing (already tripped) 75 Set Tripped = 0 (condition not met) 74 Do nothing (condition not met)

And with Retrigger=1 (alternate behavior):

Temp Action 76 Do nothing 77 Do nothing 78 Set Tripped = 1 79 Set Tripped = 1 80 Set Tripped = 1 75 Set Tripped = 0 74 Do nothing

#10

perfect ,got it, thats what i thought
further tested and confirmed

now if there was just a way to enable the retrigger based on a condition
or the opposite and steal an idea from your light timer
a re-trigger inhibitor
then we could inhibit the retrigger based on conditions being true or not true using invert

is this something you would consider since its in your other app?

#11

You have to clarify for me why you would need to do that. Even so, an inhibit condition is just an AND added to other conditons (e.g., othercondition AND not inhibitcondition), and you can do that with the existing logic.

#12

i dont want to inhibit the conditions
i want to inhibit the retrigger being active

in my case i only want it to retrigger while we are sleeping and my thermostat running mode is night/sleep
so retrigger can be inhibited by a particular trigger
in my case that would be thermostat running mode not equal to sleep

so retrigger would = 0 as its inhibited
but as soon as thermostat is sleep
the retrigger would not be inhibited
therfore retrigger would =1

#13

You’re not really giving me enough to understand what problem you’re trying to solve, so the request seems really odd to me. But, if you feel you need to do it, here’s how:

Create two scenes. Scene #1 – triggered by the thermostat going into “sleep” mode (either a direct trigger using the thermostat, or you can make another ReactorSensor to look at the thermostat’s mode and device if it’s sleep or not), runs this Lua code:

luup.variable_set( "urn:toggledbits-com:serviceId:ReactorSensor", "Retrigger", 1, reactorsensor_device_num ) return true -- always end scene lua with a return bool

Then make the counter-scene – triggered by the thermostat leaving “sleep” mode (again, direct device trigger, or using the not-tripped test of the ReactorSensor created for the first scene), runs this Lua code:

luup.variable_set( "urn:toggledbits-com:serviceId:ReactorSensor", "Retrigger", 0, reactorsensor_device_num ) return true -- always end scene lua with a return bool

#14

i currently have 2 scenes that does exactly that
but you also need to reload luup as the new value only takes effect after the reactor restarts
i was just hoping to have it in the app as an option
it would eliminate extra scenes and be cleaner and be easier to manipulate

to help understand the problem i am trying to solve

the reasoning behind it is that when retrigger is enabled
as you mentioned
it puts more load on the system
which i want to avoid as much as possible

i only want to allow that extra load on the system under certain conditions
that condition is typically only met sometime after midnight and up to 6am or later
everyone asleep, no motion, no occupancy, etc…
so i dont mind the extra load as the controller is not doing much

#15

[quote=“charettepa, post:14, topic:199808”]i currently have 2 scenes that does exactly that
but you also need to reload luup as the new value only takes effect after the reactor restarts[/quote]

This is not correct. Changing the value of Retrigger is effective immediately, and will be noticed the next time a device changes and conditions are evaluated.

the reasoning behind it is that when retrigger is enabled as you mentioned it puts more load on the system which i want to avoid as much as possible

The load on the system is negligible. The Reactor is responding anyway every time the temperature changes, regardless of what the house mode or sleep state of your thermostat is. Every change wakes Reactor up so it can see what it needs to do. The only additional overhead is that of your scene execution, which for setting a fan controller to a prescribed speed is a tiny effort. I don’t even think it’s worth the return on investment for you to implement the two scene Lua control over it, but it’s there if you really want to do it.

EDIT: To be clear, what would load the system is having the house mode check retrigger–that’s why we moved it off. Even so, that load isn’t much, and I don’t think any Vera 3 or above would even whimper at the task (including executing your scene). It’s just best-practice.

#16

actually its putting heavier load on zwave system than needed
as when it retriggers it resends the fan switch loadstate to the desired level
even if already at that level
this is happening for all 3 bedrooms
so every 4-5 minutes a zwave command is sent to all 3

i suppose i could add a piece of luup code that says not to send the command if the current state
is already the value it is sending
ie set fan to 60%
with luup code that blocks the scene from running if the current state is 60% (device loadstate <> 60)
i’m just trying to avoid additional devices and extra scenes
i like to keep it clean

#17

i understand these are your applications and it is up to you to change or not change as you see fit
i truly appreciate these applications
i am just trying to get involved and add value/functionality where i think myself others could also benefit

please do not misinterpret my comments/suggestions/requests as disrespect

i highly respect the work you have done

#18

[quote=“charettepa, post:16, topic:199808”]actually its putting heavier load on zwave system than needed
as when it retriggers it resends the fan switch loadstate to the desired level
even if already at that level
this is happening for all 3 bedrooms
so every 4-5 minutes a zwave command is sent to all 3[/quote]

Well, if your network can’t take 3 Z-wave commands every 5 minutes, you may have other problems! :slight_smile:

i suppose i could add a piece of luup code that says not to send the command if the current state is already the value it is sending ie set fan to 60% with luup code that blocks the scene from running if the current state is 60% (device loadstate <> 60)

Actually, let’s take a step back here. I kind of feel like you’re trying to have it both ways–you want Retrigger, but you don’t want the effect of Retrigger. Let’s go back to the original problem, which was that your fan control switch comes up “off” after a power failure, and because your battery-backed Vera Secure rides that out (doesn’t restart) and doesn’t see that the switch reset, the state of the device on the Vera side is out of sync, and your fan never recovers after the power failure. So to start, we’re working pretty hard to solve a problem that I would think is actually pretty rare. But I agree it’s worth solving, and I’m sure we can.

I propose that a better solution may likely be turning Retrigger back off (Reactor’s default), and making sure your fan control switch has a reasonable polling interval set. When Vera polls the device, it will update the status, so if the polling interval is relatively short (say 600 seconds or 10 minutes), it would soon discover the fan’s new post-power-fail off state. Then, if you add a specific check to your ReactorSensors to make sure the fan is in the right state (your “loadstate <> 60” test), done correctly, that should make the ReactorSensor trip to bring the fan back up to the correct speed. No retrigger necessary.

And don’t worry. I’m all about discussion and figuring out what needs to be done. That will never offend me. But both Reactor and DelayLight have a very clear charter in my mind: keep it light, keep it clear. I don’t want to clog in features where other approaches can be made to work, so I want to make sure I pursue those first.

#19

thanks for your response
im glad you are not offended
and discussing this solution with me

also you are correct, its a rare issue and is not likely worth all the time i am putting in to it

i really do think the best solution is the retrigger that you suggested but with the additional luup code that only fires the scene if the switch state is not what its sending

i think the best of both worlds with the least amount of stress on the system is as follows

the out of sync fan switch does catch up within about 10-15 minutes already
thats less of an issue

the issue is that
the fan is now off
and the reactor sees that its off
but one of the other groups are on
so its still triggered but not turning it on as its not re-triggered
so retrigger does solve that issue

the frequent retrigger issue was solved by you yesterday
by moving the homestate to its own reactor

i also have retrigger only active for those 3 rooms overnight while asleeep/no occupancy/ no motion

and now finally to minimize excessive zwave sends
i can just use luup to only allow the scene to run if the desired load state is not currently true

i think this will work
its multiple pieces but gets the job done
thanks for being so active in finding a solution
i will let you know if it continues to function as expected

#20

[quote=“JJ10, post:1, topic:199806”]For one of my lights i have three options how the light can be turned on:

  1. Via motion during daytime → Light is set to 100% – light should be turned off after 5 min
  2. Via motion during nighttime → Light is set to 20% → light should be turned off after 5 min
  3. Manual by switch at all time → Light is set to 100% → light should be turned off after 1 hour[/quote]

You could probably work that out in steps with Reactor, but since you’re already using DelayLight, I don’t think you need to. Here’s how I would address your question:

First, since your motion timings are both 5 minutes, set your DelayLightTimer’s auto delay to 300. Manual at one hour would be 3600 seconds. Set the DLT’s trigger device to be your motion sensor, as you normally would. Then, set the “off” list to the controlled light, but leave the “on” list empty for the moment.

Jump out and create a single scene with manual triggering and no devices, but at the final page, copy/paste this (and edit in your light’s device number) into the scene’s Lua (click “Also, execute the following Luup code” to get to the Lua insert block).

local controlledLight = <device number of your light> local brightness = 100 if luup.is_night() then brightness = 20 end luup.call_action( "urn:upnp-org:serviceId:Dimming1", "SetLoadLevelTarget", { newLoadlevelTarget=brightness }, controlledLight ) return false

Save this scene. Then go back to your DLT, and set the “on” list to this new scene.

That should be all you need. No ReactorSensor necessary for this setup. The function of the scene Lua should be pretty straightforward. The trick here is that the DLT is watching both the “on” list and the “off” list for manual triggering. Since the “on” list is a scene with no devices, there’s nothing to see, but keeping the light in the “off” list makes it visible to/watched by the DLT, and also lets it turn it off directly when timing expires.