Condition/Action that won't go away (Solved)

Hi -
I’ve got PLEG working really well on a couple of Vera Lites that I’ve installed but am having crazy problems with one of them. It seems somewhere along the way I created a Condition and Action that is still in the system and won’t go away. It is a Guest Status virtual button that is the Input. The Condition was GuestOn and the action was to change some thermostat settings. I followed previous advice and had PLEG install another instance and then methodically went through the first instance and removed all Actions, Conditions and Inputs. I then uninstalled the first instance of PLEG. The ghost Condition and Action still worked so I’ve tried deleting the entire PLxx app set and it’s still there so clearly it lives on.

Is there anyway to reset this to know that everything is cleared out of Inputs, Triggers and Actions and I’ll just start over with a new PLxx?

Forgot to mention, this is at a remote location so I can’t get to the log files (at least I don’t know how) to see what’s happening real-time.

Thanks,

Pat

I might be able to figure out by looking at the state of your Vera.
Do not post the result … Send it to me via email … Also it could have passwords that
you have saved as parameters in to Plugins in Vera. So you may want to obfuscate any passwords in the data.
[hr]
You can get it remotely as follows:
[hr]
http://fwd2.mios.com/VeraUserID/VeraPassword/VeraSerial/data_request?id=user_data2&output_format=json

Where:
fwd2 is the server to access your Vera remotely … see below
VeraUserID is your user ID on cp.mios.com
VeraPassword is the associated password.
VeraSerial

You can find your VeraSerial and your fwd? Server from:

http://sta1.mios.com/locator.php?username=[b]VeraUserID[/b]

Hi Richard
I have the same issue !

I have set an action for On and another one for Off and then edit it. The action tab shows one action per statud but PLTS launches 2 differents actions on the On trigger
I have done a reboot, a browser reload (CTRL+F5 in Firefox) thus still the same issue
In the advanced tab, the action

I have another PLEG with a condition that run in a infinite loop. I have edited the condition with no luck. Deleting the condition did not resolve anything, still an action
I have deleted the PLTS and still the code remain

I found that the trigger (PROGRAMLOGIC_xx) was still in the trigger list
I have disable it (can’t remove it) and then the code stopped to be executed…

It drive me crazy :slight_smile:

Any advice ?

Thanks for your help…

If it can help, here is an extract of my log file

I clicked on the On button of the device 194
This device has only one action (in actions tab and in advanced tab)
Actions=
{‘On’:[{‘device’:‘187’,‘service’:‘urn:upnp-org:serviceId:SwitchPower1’,‘action’:‘SetTarget’,‘arguments’:[{‘name’:‘newTargetValue’,‘value’:‘1’}]}],‘Off’:[{‘device’:‘187’,‘service’:‘urn:upnp-org:serviceId:SwitchPower1’,‘action’:‘SetTarget’,‘arguments’:[{‘name’:‘newTargetValue’,‘value’:‘0’}]}]}

But it’s launching 2 jobs (one OFF for device 190 → unwanted, one ON for device 187 → the real one)

07 05/07/13 0:18:23.470 Event::Evaluate 167 DeclenchementAllumageLumiereExterieureCuisine scene ProgramLogic_194 is true users:(null) allow:1 <0x34e4e680> 08 05/07/13 0:18:23.470 Scene::RunScene running 126 ProgramLogic_194 <0x34e4e680> 08 05/07/13 0:18:23.471 JobHandler_LuaUPnP::HandleActionRequest device: 190 service: urn:upnp-org:serviceId:SwitchPower1 action: e[36;1mSetTargete[0m <0x34e4e680> 08 05/07/13 0:18:23.471 JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=0 <0x34e4e680> 06 05/07/13 0:18:23.472 Device_Variable::m_szValue_set device: 190 service: urn:upnp-org:serviceId:SwitchPower1 variable: e[35;1mTargete[0m was: 0 now: 0 #hooks: 0 upnp: 0 v:0xdbf290/NONE duplicate:1 <0x34e4e680> 02 05/07/13 0:18:23.473 e[33;1mZWJob_SendData UPDATE MANUAL ROUTE 45=(nil)e[0m <0x34e4e680> 02 05/07/13 0:18:23.475 e[33;1mUPDATE MANUAL ROUTE2 45=(nil)e[0m <0x2c40d680> 02 05/07/13 0:18:23.475 e[33;1mZW_Send_Data node 45 NO ROUTE (nil)e[0m <0x2c40d680> 06 05/07/13 0:18:23.478 Device_Variable::m_szValue_set device: 194 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: e[35;1mToggleTimee[0m was: 1367878458 now: 1367878765 #hooks: 0 upnp: 0 v:0xe98448/NONE duplicate:0 <0x34e4e680> 08 05/07/13 0:18:23.479 JobHandler_LuaUPnP::HandleActionRequest device: 187 service: urn:upnp-org:serviceId:SwitchPower1 action: e[36;1mSetTargete[0m <0x34e4e680> 08 05/07/13 0:18:23.479 JobHandler_LuaUPnP::HandleActionRequest argument newTargetValue=1 <0x34e4e680> 06 05/07/13 0:18:23.480 Device_Variable::m_szValue_set device: 187 service: urn:upnp-org:serviceId:SwitchPower1 variable: e[35;1mTargete[0m was: 0 now: 1 #hooks: 0 upnp: 0 v:0xdbf290/NONE duplicate:0 <0x34e4e680> 02 05/07/13 0:18:23.481 e[33;1mZWJob_SendData UPDATE MANUAL ROUTE 44=(nil)e[0m <0x34e4e680> 06 05/07/13 0:18:23.482 Device_Variable::m_szValue_set device: 194 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: e[35;1mStatuse[0m was: 1 now: 1 #hooks: 1 upnp: 0 v:0xe9a8e8/NONE duplicate:1 <0x34e4e680> 06 05/07/13 0:18:23.483 Device_Variable::m_szValue_set device: 194 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: e[35;1mStatee[0m was: 0 now: 3 #hooks: 0 upnp: 0 v:0xe9a8c8/NONE duplicate:0 <0x34e4e680> 06 05/07/13 0:18:23.483 Device_Variable::m_szValue_set device: 194 service: urn:rts-services-com:serviceId:ProgramLogicTS variable: e[35;1mLastStateChangee[0m was: 1367878431 now: 1367878703 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x34e4e680> 02 05/07/13 0:18:23.573 e[33;1mUPDATE MANUAL ROUTE2 44=(nil)e[0m <0x2c40d680> 02 05/07/13 0:18:23.573 e[33;1mZW_Send_Data node 44 NO ROUTE (nil)e[0m <0x2c40d680> 02 05/07/13 0:18:23.683 e[33;1mUPDATE MANUAL ROUTE2 45=(nil)e[0m <0x2c40d680> 02 05/07/13 0:18:23.683 e[33;1mZW_Send_Data node 45 NO ROUTE (nil)e[0m <0x2c40d680> 06 05/07/13 0:18:23.811 Device_Variable::m_szValue_set device: 190 service: urn:upnp-org:serviceId:SwitchPower1 variable: e[35;1mStatuse[0m was: 0 now: 0 #hooks: 2 upnp: 0 v:0xdbf2e8/NONE duplicate:1 <0x2c00d680> 04 05/07/13 0:18:23.813 <Job ID="99" Name="OFF node 45" Device="190" Created="2013-05-07 0:18:23" Started="2013-05-07 0:18:23" Completed="2013-05-07 0:18:23" Duration="0.339899000" Runtime="0.338097000" Status="Successful" LastNote="Transmit was ok" Node="45" NodeType="ZWaveMultiEmbedded" NodeDescription="Lumi?re ext?rieure Salle ? manger"/> <0x2c00d680> 02 05/07/13 0:18:23.815 e[33;1mUPDATE MANUAL ROUTE2 44=(nil)e[0m <0x2c40d680> 02 05/07/13 0:18:23.816 e[33;1mZW_Send_Data node 44 NO ROUTE (nil)e[0m <0x2c40d680> 06 05/07/13 0:18:23.921 Device_Variable::m_szValue_set device: 187 service: urn:upnp-org:serviceId:SwitchPower1 variable: e[35;1mStatuse[0m was: 0 now: 1 #hooks: 0 upnp: 0 v:0xdbf2e8/NONE duplicate:0 <0x2c00d680> 04 05/07/13 0:18:23.923 <Job ID="100" Name="ON node 44" Device="187" Created="2013-05-07 0:18:23" Started="2013-05-07 0:18:23" Completed="2013-05-07 0:18:23" Duration="0.441713000" Runtime="0.349859000" Status="Successful" LastNote="Transmit was ok" Node="44" NodeType="ZWaveMultiEmbedded" NodeDescription="Lumi?re ext?rieure cuisine"/> <0x2c00d680>

Richard,
in log it seems like PLTS is calling the scene number 126

The scene is hidden but with UserData2 I could extract the content:

<scene name="ProgramLogic_194" notification_only="194" id="126" onDashboard="0" Timestamp="1367879809" room="0"> <triggers> <trigger name="ModeNuit" enabled="1" template="1" device="55" lua="luup.call_action(&apos;urn:rts-services-com:serviceId:ProgramLogicC&apos;,&apos;TriggerAction&apos;, {triggerName=&apos;ModeNuit&apos;}, 194)"> <arguments> <argument id="1" value="0"/> </arguments> </trigger> <trigger name="OuverturePorteFenetreCuisine" enabled="1" template="1" device="181" lua="luup.call_action(&apos;urn:rts-services-com:serviceId:ProgramLogicC&apos;,&apos;TriggerAction&apos;, {triggerName=&apos;OuverturePorteFenetreCuisine&apos;}, 194)"> <arguments> <argument id="1" value="1"/> </arguments> </trigger> <trigger name="OuverturePorteFenetreSalleAManger" enabled="1" template="1" device="18" lua="luup.call_action(&apos;urn:rts-services-com:serviceId:ProgramLogicC&apos;,&apos;TriggerAction&apos;, {triggerName=&apos;OuverturePorteFenetreSalleAManger&apos;}, 194)" last_run="1367877239"> <arguments> <argument id="1" value="1"/> </arguments> </trigger> <trigger name="DeclenchementAllumageLumiereExterieureCuisine" enabled="1" template="1" device="194" lua="luup.call_action(&apos;urn:rts-services-com:serviceId:ProgramLogicC&apos;,&apos;TriggerAction&apos;, {triggerName=&apos;DeclenchementAllumageLumiereExterieureCuisine&apos;}, 194)" last_run="1367881366"> <arguments> <argument id="1" value="1"/> </arguments> </trigger> </triggers> <groups> <group delay="0"> <actions> <action device="187" service="urn:upnp-org:serviceId:SwitchPower1" action="SetTarget"> <arguments> <argument name="newTargetValue" value="1"/> </arguments> </action> <action device="190" service="urn:upnp-org:serviceId:SwitchPower1" action="SetTarget"> <arguments> <argument dataType="boolean" name="newTargetValue" value="0"/> </arguments> </action> </actions> </group> </groups> </scene>

Clearly there are 2 calls in the groups…
Hope it’s helping you

Nice to read you soon…

@Richard and @beerguy
I was able to delete the ghost action and trigger with running the http command for deleting scene ([url=http://wiki.micasaverde.com/index.php/Luup_Requests#scene]http://wiki.micasaverde.com/index.php/Luup_Requests#scene[/url])

I found the ID of the scene used by the PLTS number 92 (before I delete it) in the UserData2 (or in status URL) and used the http://ip_address:3480/data_request?id=scene&action=delete&scene=xx

The ghost triggers are no more annoying me :smiley:

Hope it helps

Folks, Thanks for providing some details … I have found the source of the problems and will have two fixes shortly.
[ul][li]Fix the problem of phantom Actions when a PL plugin is deleted.
When you delete a PL plugin, the LAST defined Actions will be run when ANY of the defined input triggers are fired.
If you had deleted the inputs before deleting the plugin, you would not have seen a problem.[/li]
[li]I will add some startup code that will scan for previously deleted PL plugins and clean up any left over notification scenes.[/li]
[list]
[/list][/ul]

Thanks for your work Richard

I have another strange statement…
In the PLTS 194, I have a condition called ModeNuit (NightMode) wich prevent the On status to be activate:
(OuverturePorteFenetreSalleAManger OR OuverturePorteFenetreCuisine) AND ModeNuit
->could be translated in (MainDoorOpened OR KitchenDoorOpened) AND NightMode

Actually the Plugin Day or Night is in day mode, so the On action can’t be activated
If I open one of this door, the plugin stay in Off mode, but launches scene 126 which lights up all my devices like if the plugin was in On mode

Thanks for your work…

Wow. So that explains why Vera has been going insane here. I was about to factory reset it this afternoon.

Have you ever deleted a PL device ? This may be the same phantom action I was describing.
Are you running the Scene as an Action … or does the scene have a trigger on the PL device for the appropriate condition ?

I have already tested the fix … So it will take a day or so to get through the MCV audit.

I’ve deleted a lot of PLxx because last day I had a lot of trouble that made my lights unable to be shutoff
I tought first it was the fibaro module, then I discovered that it was the Vera which aws sending a On command
Then I tought about my conditions which could be false. So I deleted all the conditions. Always the same
So I decided to delete all the PLTS that ware sending On command
With no luck till I discovered the trigger in the list

I’m running the scene as an action
The fisrt PLTS I made were by trigger on condition in a separate scene. these are running well for the moment (I do not touch anything now until the release will be published…)

Hi Richards,
have you any news about the release please…

I have to remove my home fuse to avoid lights getting on all the day when I open a door…

Thanks for your reply

I just checked … 4.0 is now available

Thanks for this! I was having the same problem.

I’ll report back if I have any findings.

Thanks Richard
I try right now ! :smiley: (since it’s 3AM in France…)

Advice for those who had the same problem of launching unwanted actions by PLTS
After the upgrade to 4.0, nothing changed… :frowning:

A little luup reload after, always the same…
A complete reboot of Vera, always the same…

I had to return in the action tab in all “bad” PLTS, make a change (at this stage I had strange behaviors like switching off unwanted lights in an on action), revert to old parameters and save and then Alleluiah !!

For the moment all is good, I’ll continue tomorrow in the morning my tests

Thanks Richard, you’re my hero (and my energy saver because the outside lights no more getting on in day mode)

I have been bit by this bug. I re-installed w/ the latest update and the issue persists.

In my case, I get a text message every time an event occurs.

I’ve pulled the power to reboot the unit, and the issue is still there. The phantom action is still there.

Any idea how I can remove this?

Thanks.

Many folks have reported this problem …
I need a PLEG Reports and DEBUG log files demonstrating the problem in order to determine the cause.

Turns out I had not deleted the scene - so once I did that the notifications ceased.

100% user error

And how do you delete the scene ? (I suppose it was an action in the PLEG you initially removed?)
Thanks