WebCore Subscribing to Events without Triggers

[dnickel]

@nh.schottfam
Curious if this is an anomally or me just being dumb.
I have moved a common piece of code to its own piston.
I am not acting on events but just testing conditions. It seems the piston says I am subscribed to events and if I close a door the piston catches the event and locks the door. This piston should actually warn me that I am not subscribing to any event and that it will not run.
I have turned off Event Subscriptions in the options for the moment.

[thebearmay]

The lightning bolts along the side are indications that those events will trigger actions; i.e. you are subscribed to those events even though the is is listed under the condtions instead of the triggers.

[eibyer]

In the absence of triggers, conditions will cause subscription to device events.

[terminal3]

You should be able to select each statement that you don't want to use as a trigger and unsubscribe in the tools icon.

[dnickel]

There must have been a change to WebCore at some point then.
I have been using it since Ady wrote the app and conditions never have lightening bolts. If you only have conditions there was always a Warning that your piston will never execute.
I have disabled events so all is fine.

[nh.schottfam]

There is an overall setting for a piston that says don't promote conditions to triggers.

There is no change to webcore on HE, this is how webcore works on both platforms.

My guess is you don't have the piston setting to not promote conditions to triggers when there are no triggers.

[LibraSun]

Can I chime in with a (potentially) equally "dumb" question?

I successfully set up my first WebCoRE piston this afternoon, after much(!!) noodling around and tinkering. It works. But until I added one last ingredient, it would not fire and I was left puzzled as to why.

To wit:

1. When I had "Rule ► Executes ► My_Rule_Here" as the sole entry under IF, I received the warning about "No events subscribed", and the Piston never fired (judging from Logs and checking other results) no matter how often that RM rule executed;

Pretty sure there was even a yellow lightning bolt next to that sole condition, which had me believing it was somehow secretly subscribed, to which I thought, "Neat! But it's not acting accordingly."

2. After adding an OR "Device ► Switch ► My_Switch_Here = ON", the warning dialogue vanished and the Piston fires as expected on every execution of the rule in #i1 (as well as when the switch in question first turns ON, of course).

So, I'm happy, but if anyone has insights worth sharing on this topic, I'm all ears. Until then, I will surely consult the Docs once my head clears.

Thanks - Libra

[eibyer]

Post a green snapshot of the piston that didn't work to make it easier for others to give input.

[LibraSun]

Sure thing, here ya go:

[nh.schottfam]

I don't see the rule access in this piston ???

[LibraSun]

No, and I suspect that's what I'm implicitly asking: By what means would one affirmatively grant WebCoRE "access" to RM rules, if that is even a "thing" one must do? Like I said, the Piston is chugging along nicely, executing each time my RM rule (as shown in the recipe) triggers. But it would not be doing so had I not included the "Switch = ON" Trigger in the OR block. Hmm...

[nh.schottfam]

If you can show an example of the problem then I can debug what is going on.

[LibraSun]

Thanks but no need to debug, as my workflow is functioning fine. Was just curious why both Conditions appear to be required.

I'll do further testing and testing to understand.