Call for Beta Testers -- Reactor 3.5

rigpapa · January 1, 2020, 8:05pm

Logic summary, not screen shots, please.

cokeman · January 1, 2020, 8:07pm

INSTRUCTIONS FOR POSTING TO VERA COMMUNITY FORUMS:
* COPY/PASTE ALL lines AFTER the ===== separator below, INCLUDING the lines. * DO NOT omit the lines! They must be included to preserve report formatting!
* DO NOT edit or redact this report. If you have privacy concerns about posting it to the forums, send via email, below.

INSTRUCTIONS FOR EMAILING:
> Use this method if you have concerns about posting the report contents publicly.
* Right-click in this pane and choose “Save as…” to save this entire report to a file.
* ATTACH the file in an email to: reactor@toggledbits.com
* DO NOT copy/paste the report text into the email body! Attachments only please.
* Include your forum name in the body of the email, so I know who you are.
* Please let me know via the community forums that you’ve emailed the report.
* Please do not use this email address for any other communication. It’s for report attachments only.

THANK YOU IN ADVANCE FOR READING AND FOLLOWING THESE INSTRUCTIONS! ALTHOUGH MY TIME IS FREE, I DON’T ALWAYS HAVE A LOT OF IT, SO
YOUR DILIGENCE REALLY HELPS ME WORK AS QUICKLY AND EFFICIENTLY AS POSSIBLE.

=====

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.5develop-19354 config 19295 cdata 19305 ui 19349 pluginDevice 884 LuaXP 1.0.1
    System: Vera version 1.7.4903 (7.31) on Sercomm G450 ID 36 (Vera Plus); loadtime 1577897249; systemReady 1577897270; ALTUI v2.46; Lua 5.1; JSON dkjson 2.5+LPeg
Local time: 2020-01-01T21:06:06+0100; DST=0; Storvorde, North Denmark Denmark; formats %d/%m/%Y %H:%M:%S
House mode: plugin 1; system 1; tracking on
  Sun data: 
  Geofence: not running
************************************************************************************************************************************
Reactor Bad auto lys (#910)
    Version 19082.7 12/24/19 12:34:11
    Message/status: Not tripped
    Condition group "No Motion Timer is TRUE" (AND)  false as of 17:47:07 <root>
      &-F-service Bad_Lys (333) urn:upnp-org:serviceId:SwitchPower1/Target = 1 for ge 600s [1 => 0 at 17:47:07; F/F as of 17:47:07/17:47:07] <cond0>
      &-F-group "grplzzn9qc" (AND)  false as of 17:47:07 <grplzzn9qc>
      |     &-T-service Motion Bathroom (403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped isfalse  for ge 600s [1 => 0 at 20:13:52; T/T as of 20:13:52/20:23:52] <condlzznhvj>
      |     &-F-service Bad_Lys (333) urn:upnp-org:serviceId:SwitchPower1/Status = 1 for ge 10s [1 => 0 at 20:13:31; F/F as of 20:13:31/20:13:31] <condlzznir4>
      &-F-group "Light on" (AND)  false as of 20:13:31 <grplzzre8q>
      |     &-F-service Bad_Lys (333) urn:upnp-org:serviceId:SwitchPower1/Status = 1 [1 => 0 at 20:13:31; F/F as of 20:13:31/20:13:31] <condlzzrl74>
    Activity grplzzre8q.true
        Device Hue bathroom door (895) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="99" )
        Device Hue bathroom shower (907) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="99" )
        Device Hue bathroom WC (903) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="99" )
        Device Hue bathroom window (887) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="99" )
    Activity grplzzre8q.false
        Device Hue bathroom door (895) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="45" )
        Device Hue bathroom shower (907) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="45" )
        Device Hue bathroom WC (903) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="45" )
        Device Hue bathroom window (887) action urn:upnp-org:serviceId:Dimming1/SetLoadLevelTarget( newLoadlevelTarget="45" )
        Delay 3 inline
        Device Hue bathroom door (895) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
        Device Hue bathroom shower (907) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
        Device Hue bathroom WC (903) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
        Device Hue bathroom window (887) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Activity root.true
        Device Bad_Lys (333) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="0" )
    Events
        2020-01-01 19:56:47: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "1" to "0"
        2020-01-01 19:56:47: Condition condlzznhvj test state changed from false to true
        2020-01-01 19:56:47: Condition condlzznhvj holding evaluation state for check that duration >= 600 (600 to go)
        2020-01-01 19:56:47: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 297)
        2020-01-01 20:03:57: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "1"
        2020-01-01 20:03:57: Condition condlzznhvj test state changed from true to false
        2020-01-01 20:03:57: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 727)
        2020-01-01 20:04:36: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 766)
        2020-01-01 20:06:52: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "1" to "0"
        2020-01-01 20:06:52: Condition condlzznhvj test state changed from false to true
        2020-01-01 20:06:52: Condition condlzznhvj holding evaluation state for check that duration >= 600 (600 to go)
        2020-01-01 20:06:52: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 902)
        2020-01-01 20:06:56: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "1"
        2020-01-01 20:06:56: Condition condlzznhvj test state changed from true to false
        2020-01-01 20:06:56: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 906)
        2020-01-01 20:07:17: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "1" to "0"
        2020-01-01 20:07:17: Condition condlzznhvj test state changed from false to true
        2020-01-01 20:07:17: Condition condlzznhvj holding evaluation state for check that duration >= 600 (600 to go)
        2020-01-01 20:07:17: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 927)
        2020-01-01 20:07:25: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "1"
        2020-01-01 20:07:25: Condition condlzznhvj test state changed from true to false
        2020-01-01 20:07:25: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 935)
        2020-01-01 20:11:45: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "1" to "0"
        2020-01-01 20:11:45: Condition condlzznhvj test state changed from false to true
        2020-01-01 20:11:45: Condition condlzznhvj holding evaluation state for check that duration >= 600 (600 to go)
        2020-01-01 20:11:45: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 1195)
        2020-01-01 20:12:27: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "1"
        2020-01-01 20:12:27: Condition condlzznhvj test state changed from true to false
        2020-01-01 20:12:27: Condition condlzznir4 successfully sustained for at least 10 seconds (actual 1237)
        2020-01-01 20:13:31: Device Bad_Lys (#333) urn:upnp-org:serviceId:SwitchPower1/Status changed from "1" to "0"
        2020-01-01 20:13:31: Condition condlzznir4 test state changed from true to false
        2020-01-01 20:13:31: Condition condlzznir4 evaluation state changed from true to false
        2020-01-01 20:13:31: Condition condlzzrl74 test state changed from true to false
        2020-01-01 20:13:31: Condition condlzzrl74 evaluation state changed from true to false
        2020-01-01 20:13:31: Group Light on test state changed from true to false
        2020-01-01 20:13:31: Group Light on evaluation state changed from true to false
        2020-01-01 20:13:31: Launching Light on.false activity
        2020-01-01 20:13:31: Launching scene/activity grplzzre8q.false
        2020-01-01 20:13:32: Starting "grplzzre8q.false" group 1
        2020-01-01 20:13:32: Delaying scene grplzzre8q.false group 2 actions until 20:13:35
        2020-01-01 20:13:35: Starting "grplzzre8q.false" group 2
        2020-01-01 20:13:35: Activity "grplzzre8q.false" finished
        2020-01-01 20:13:52: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "1" to "0"
        2020-01-01 20:13:52: Condition condlzznhvj test state changed from false to true
        2020-01-01 20:13:52: Condition condlzznhvj holding evaluation state for check that duration >= 600 (600 to go)
        2020-01-01 20:13:54: Device Motion Bathroom (#403) urn:micasaverde-com:serviceId:SecuritySensor1/Tripped changed from "0" to "0"
        2020-01-01 20:13:54: Condition condlzznhvj holding evaluation state for check that duration >= 600 (598 to go)
        2020-01-01 20:16:52: Condition condlzznhvj holding evaluation state for check that duration >= 600 (420 to go)
        2020-01-01 20:23:52: Condition condlzznhvj successfully sustained for at least 600 seconds (actual 600)
        2020-01-01 20:23:52: Condition condlzznhvj evaluation state changed from false to true
    Devices
        ZWave (1) urn:schemas-micasaverde-com:device:ZWaveNetwork:1 (19/0); parent 0; plugin -; mfg  model ; dev D_ZWaveNetwork.xml impl 
        Motion Bathroom (403) urn:schemas-micasaverde-com:device:MotionSensor:1 (4/3); parent 1; plugin -; mfg  model ; dev D_MotionSensor1.xml impl 
        Bad_Lys (333) urn:schemas-upnp-org:device:BinaryLight:1 (3/0); parent 1; plugin -; mfg Fibaro model FGS221; dev D_BinaryLight1.xml impl

rigpapa · January 1, 2020, 8:10pm

You’re testing a different state variable in the first test than you are the other two.

cokeman · January 1, 2020, 8:12pm

Thanks, I’ll give it a go

ErnieF · January 2, 2020, 11:40pm

Unable to get SMTP to send w/ gmail.
I used the same values that were working before:
SMTPServer: smtp.gmail.com
SMTPSender: myusername@gmail.com
SMTPUsername: myusername@gmail.com
SMTPPassword: mypassword
SMTPPort: 465

This is the version info from the log summary that I am running.

Version: 3.5develop-19354 config 19295 cdata 19305 ui 19349 pluginDevice 72 LuaXP 1.0.1
System: Vera version 1.7.4832 (7.30) on Sercomm NA301 ID 35 (Vera Edge)

rigpapa · January 3, 2020, 12:19am

Can you look in your LuaUPnP log file for the string SMTP Send failed, which should provide more diagnostic info. Probably best to PM that to me, rather than post it in this thread.

kwieto · January 8, 2020, 1:12pm

I have strange issue with some sensors related to geofence.
The Idea is that if I pass two locations in certain order, and home mode is set to Away reactor should start some actions.

Previously I’ve had it set in a way that all conditions were in one group, condition for 1st geofense was “latched” for about 30 minutes, then it was condition for 2nd geofence and the house mode. It worked fine.

Recently I’ve redesigned this logic and I have separate condition for 1st geofence and a group where there are two conditions: one for the house mode, the other with 2nd geofence and a parameter that it is tru only after 1st geofence would be true not longer than about 30 minutes ago.
Activities are running when this group will became true.

And that is not working. When I’ve tested it, I can see that both conditions within the group are true, but the group itself is false (see screenshot). Is that an reactor error, or am I doing somenthing wrong?

rigpapa · January 8, 2020, 1:18pm

Please post a Logic Summary, preferably when the RS has just entered the unexpected condition.

Note, however, that “Terma 2” is a precondition (within 1800 seconds) for the “Terma 1” condition, so while the “Terma 1” geofence test may be true (as shown), the overall condition is false because “Terma 2” is false.

kwieto · January 8, 2020, 2:10pm

Hmm, I thought that if you put a restriction that something has to occur after another condition, then it doesn’t matter what is the current state of the first condition but is important if it was true in specified period?
Like: you enter the “Terma 2”, then leave it, but if you enter the “Terma 1” not later than 1800s after “Terma 2” WAS true (regardless of its current state), and the house mode is away, then the group “Powrót|Terma” is true (?)

The logic summary is below, unfortunately it would be difficult to have it at the time when condition is true, as I won’t be there for couple of days. I may create another sensor with the same logic if needed.

*************************************************** REACTOR LOGIC SUMMARY REPORT ***************************************************
   Version: 3.5develop-19349 config 19295 cdata 19305 ui 19349 pluginDevice 599 LuaXP 1.0.1
    System: Vera version 1.7.4903 (7.31) on Sercomm G450 ID 36 (Vera Plus); loadtime 1578446225; systemReady 1578446302; ALTUI v2.46; Lua 5.1; JSON dkjson 2.5+LPeg
Local time: 2020-01-08T15:27:07+0100; DST=0; Brochow, Mazovia Poland; formats %d/%m/%Y %H:%M:%S
House mode: plugin 4; system 4; tracking on
  Sun data: 
  Geofence: running in long mode, last update 08:41:00, data version 2
            User 1858602 ishome=0 inlist=21574880516 since=08:41:00
            |1574880516 "Aleja 3 Maja 2" type="other" status="in" since=17:41:00
            |    3 "Terma 1" type="other" status="out" since=01-06.17:32:00
            |    2 "Aleja Katowicka 9, 05-830 Wolica, Poland Wolica" type="other" status="in" since=08:41:00
            |    5 "Dom" type="home" status="out" since=01-06.16:58:00
            |    4 "Terma 2" type="other" status="out" since=01-06.17:28:00
            User 2015171 ishome=0 inlist= since=04-26.21:21:00
            |1503007106 "PaÅ‚ac na wodzie" type="home" status="" since=03-21.11:22:00
            Raw: {"updated":1578493620,"users_settings":[{"id":1858602,"ishome":0}],"mode":-1,"users":[{"id":1858602,"Level":1,"Name":"kwieto","IsGuest":0}],"usergeofences":[{"geotags":[{"radius":250,"PK_User":1858602,"color":"006e45","status":"Enter","id":2,"ishome":0,"name":"Aleja Katowicka 9, 05-830 Wolica, Poland Wolica","address":"Aleja Katowicka 9, 05-830 Wolica, Poland Wolica","longitude":"20.87165494","latitude":"52.12050917","accuracy":0,"notify":1},{"radius":605,"notify":1,"color":"006e45","status":"Exit","id":3,"ishome":0,"name":"Terma 1","address":"DK7 5-3, 05-092 Åomianki, Polska Åomianki","longitude":"20.902199372649193","latitude":"52.3279464517224","PK_User":1858602,"accuracy":0},{"radius":605,"accuracy":0,"color":"006e45","status":"Exit","id":4,"ishome":0,"name":"Terma 2","address":"DK7 208, 05-092 KieÅ‚pin, Polska KieÅ‚pin","longitude":"20.860310979187492","latitude":"52.34811681403751","notify":1,"PK_User":1858602},{"radius":500,"PK_User":1858602,"id":5,"status":"Exit","color":"006e45","ishome":1,"name":"Dom","address":"DW575 17, 05-088, Polska ","longitude":"20.37774129","latitude":"52.37604959","notify":1,"accuracy":0},{"radius":250,"accuracy":0,"id":1574880516,"status":"Enter","PK_User":1858602,"ishome":0,"name":"Aleja 3 Maja 2","address":"Aleja 3 Maja, Warszawa, Polska","longitude":"21.03500993659987","latitude":"52.235107373337755","notify":1,"color":"ff0000"}],"iduser":1858602}]}
************************************************************************************************************************************
PowrÃ³t|Woda|OFF (#849)
    Version 19082.9 12/23/19 23:33:30
    Message/status: Not tripped
    Condition group "Terma 2 True" (NUL)  false as of 12-21.12:16:47 <root>
      Z-F-ishome at 1858602,4 [in => out at 01-06.17:28:01; F/F as of 01-06.17:28:01/01-06.17:28:01] <condlkvfo3e>
      Z-F-group "PowrÃ³t|Test" (AND)  false as of 12-23.23:32:06 <grplz80xc3>
      |     &-F-ishome at 1858602,3 within 1800s after condlkvfo3e [in => out at 01-06.17:32:01; F/F as of 01-06.17:32:01/12-21.12:16:47] <condlkvhay7>
      |     &-F-housemode in 2 [2 => 4 at 01-06.18:44:58; F/F as of 01-06.18:44:58/01-06.18:44:58] <condlkviixc>
    Activity grplz80xc3.true
        Device Spust|ZamkniÄ™ty (594) action urn:upnp-org:serviceId:SwitchPower1/SetTarget( newTargetValue="1" )
    Events
        2020-01-08 02:17:31: Reactor startup (Luup reload)
        2020-01-08 02:17:32: Starting (Luup Startup/Reload)
        2020-01-08 08:41:01: { dev=849, name="Reactor", var="IsHome", device=599, event="devicewatch" }

rigpapa · January 8, 2020, 2:51pm

Currently, the predecessor condition still has to be true. I’ve considered making an option for ignoring the reset state–it’s not hard, nobody has ever asked yet. But it certainly makes sense, especially when using a time restriction on the predecessor.

Sit tight, let me see about adding this option…

rigpapa · January 8, 2020, 5:49pm

OK. Stable branch updated. There’s a new checkbox with the sequence options that lets you turn off the restriction that the predecessor has remained true.

kwieto · January 8, 2020, 9:19pm

Thanks! I’ll see how it work next time and report result, but it might be in some days or even weeks

rigpapa · January 8, 2020, 9:47pm

No worries. It turns out I’m going to be traveling a good bit of the month coming up… a bit more than expected. So, I’m not going to release 3.5 this month as I expected. I am resetting for early February. So still plenty of time to hammer on it.

blacey · January 15, 2020, 9:35pm

I’m getting a Handler failed error when I try to run a Logic Summary. I see this in the logs:

01	01/15/20 16:33:10.038	LuaInterface::CallFunction_Request function reactorRequestHandler name Reactor failed [string "--[[..."]:5770: attempt to index upvalue 'luaxp' (a nil value) <0x711a7520>
02	01/15/20 16:33:10.039	JobHandler_LuaUPnP::REQ_Handler handler failure for lr_Reactor <0x711a7520>

I’m running 930ed81:

* 930ed81 - (HEAD -> stable, origin/stable) Support mode 1 sequencing--condition of predecessor ignored (7 days ago) <Patrick Rigney>
* 530c088 - Text cleanup (3 weeks ago) <Patrick Rigney>
* 8159396 - Cleanup around log snippet (3 weeks ago) <Patrick Rigney>

Ideas?

rigpapa · January 15, 2020, 9:44pm

Yes, found and fixed. I just updated stable to make sure it’s included. You can pull all, or just J_ReactorSensor_UI7.js.

blacey · January 16, 2020, 12:58am

Just git-pulled the latest and confirmed the Logic Summary fix but with 22 commits to stable since 930ed81, it’s clear that someone has been busy, travel and all, and that I have more beta testing to do

rigpapa · January 16, 2020, 1:12am

When I deferred the release to after my travel, I decided to incorporate some of the changes I had queued for 3.6. Most of the commits are on the JS side, improving compliance with standards and tightening visual appearance. A few bugs found and fixed along the way. But the biggest issue was that Chrome in particular is beginning to get very fussy about having more than one document element with the same ID.

On the Lua side, child creation was working harder than it needed to, and the running of root group activities is now done by the same depth-first traversal scan as the other groups–it was previously handled as an exception because of the association with the “Tripped” flag. This means, though, that tripping the RS manually no longer runs the root activities (however, if the root group changes, it still drives the Tripped flag to the same state–it’s now a one-way road). Eventually, I will remove the controls from the UI for the Tripped and Armed states. They will still work as they always have, they just won’t be published to the UI, since the “modern” way of having an RS do work is Activities, not Vera scenes.

I try to do “one change one commit” (guideline, not rule), and for some tasks, I commit work in progress. This makes for a lot of commits, but that seems to be what the git community recommends.

I appreciate your help!

blacey · January 16, 2020, 1:16am

Thanks for summarizing the changes - very helpful! That said, I just discovered this:

Warning! "Unsafe Lua" is not enabled, which will prevent the successful operation of some Reactor features. You can turn this setting on under Users & Account Info > Security.

Which Reactor features use “Unsafe Lua”? Trying to understand if I need to enable it or not.

rigpapa · January 16, 2020, 1:30am

Some notifications use wget for the API calls
Run Lua actions
Scenes – there’s no Luup function to fetch the content of a scene (or update it), so it has to be done through the request interface (wget).
Geofencing; again, there’s no Luup function to fetch the geofence data; in fact, there’s no request to do it either, so I have to request user_data and extract it (wget).
Housekeeping of expression state variables: there’s no Luup function to fetch the list of state variables for a device, so again, request interface (wget).
Logic summary, same use as #5 (enumerating state variables)

PITA…

blacey · January 16, 2020, 1:59am

Ok, sounds better to enable than disable so no one wastes time scratching their head over a non-issue That said, I have 2 side questions that are a bit outside the beta…

Very rarely but it has happened a couple of times over the past few months, my Reactor scenes don’t run the activities or the Vera/devices fail to change state. What’s the best way to force the activities to re-run when this happens? With scenes, I just run the scene manually to overcome the failure.
I use voice assistants to control devices and run scenes via a bridge to Vera. Reactor is a completely different modality so is there a way to “externally” run the activities without doing something like creating a virtual switch? The impetus is that I have not ported some of my scenes to Reactor purely due to need to link to voice assistants (e.g. Rainy/Gloomy day lighting scene).