Call for Beta Testers -- Reactor 3.5

blacey · January 17, 2020, 12:15pm

You know, that makes complete sense and I should have thought of that…

{"source":"int","civdawn":1579261753,"nautdawn":1579259910,"sunset":1579299927,"nautdusk":1579303400,"stamp":2020017,"latitude":34.2085,"astrodusk":1579305205,"longitude":-77.7964,"civdusk":1579301557,"astrodawn":1579258105,"sunrise":1579263383}

Things are looking good - this morning window treatments opened in time for dawn golden hour and the landscape lights turned off.

Happy wife, happy life!

anon37769099 · January 18, 2020, 7:17pm

Regarding “Notify” activity: This is still limited to one “Vera Native” per RS, right?
As I understand it, this is due to how notifications are set up in Vera?

rigpapa · January 18, 2020, 8:43pm

No such limitation. You may create as many as you wish!

anon37769099 · January 19, 2020, 12:31am

Really? I tried to do that earlier, and all notification texts were overwritten to say the same as the last i set up… And that wasn’t the text it Sent to my Phone… This was 3.4 with latest hotfix though… If its supposed to work, I’ll try again tomorrow and give you some data.

rigpapa · January 19, 2020, 1:23am

That may actually have to do with a bug in the UI, not the messages themselves. Make sure you’re on the latest 3.5 stable branch, stamped 20017 (yesterday).

In fact, everyone on 3.5 stable, please update if you haven’t recently.

pukka · January 19, 2020, 9:26am

If I got to “tools” and click Logic Summary i get an error Handler failed. this is the same for all of the reactor sensors on my vera.

debug dont know if it will help

<0x777d6320>
50	01/19/20 9:24:38.370	luup_log:314: Reactor(<func@4434>:4463): startSensor() event log file disabled for this RS <0x777d6320>
50	01/19/20 9:24:38.377	luup_log:314: Reactor(getSensorConfig:1150): getSensorConfig(325,true) <0x777d6320>
50	01/19/20 9:24:38.380	luup_log:314: Reactor(<func@981>:982): loadSensorConfig(325) <0x777d6320>
50	01/19/20 9:24:38.385	luup_log:314: Reactor(<func@981>:993): loadSensorConfig() loaded configuration version 19082 <0x777d6320>
50	01/19/20 9:24:38.389	luup_log:314: Reactor(loadCleanState:1160): loadCleanState(325) <0x777d6320>
50	01/19/20 9:24:38.393	luup_log:314: Reactor(getSensorConfig:1150): getSensorConfig(325,nil) <0x777d6320>
50	01/19/20 9:24:38.396	luup_log:314: Reactor(loadCleanState:1227): loadCleanState() returning restored cstate <0x777d6320>
50	01/19/20 9:24:38.400	luup_log:314: Reactor(scheduleDelay:666): scheduleDelay({ id="325", owner=325, func=function: 0x1f71078 },1,{ replace=true }) <0x777d6320>
50	01/19/20 9:24:38.405	luup_log:314: Reactor(<func@624>:625): scheduleTick({ id="325", owner=325, func=function: 0x1f71078 },1579425879(01/19/20.09:24:39),{ replace=true }) <0x777d6320>
50	01/19/20 9:24:38.409	luup_log:314: Reactor(<func@624>:647): scheduleTick() new task { id="325", owner=325, func=function: 0x1f71078 } at 1579425879(01/19/20.09:24:39) <0x777d6320>
50	01/19/20 9:24:38.413	luup_log:314: Reactor(<func@624>:656): scheduleTick() rescheduling plugin tick for 1s to 1579425879(01/19/20.09:24:39) <0x777d6320>
04	01/19/20 9:24:38.414	<Job ID="137" Name="" Device="325" Created="2020-01-19 9:24:38" Started="2020-01-19 9:24:38" Completed="2020-01-19 9:24:38" Duration="0.119275000" Runtime="0.118418000" Status="Successful" LastNote=""/> <0x777d6320>
50	01/19/20 9:24:39.105	luup_log:314: Reactor(<func@5195>:5196): tick("5") pluginDevice=314 <0x75000520>
50	01/19/20 9:24:39.109	luup_log:314: Reactor(<func@5195>:5217): tick() to-do list is { 1={ info="", args={  }, id="325", owner=325, func=function: 0x1f71078, when=1579425879(01/19/20.09:24:39) } } <0x75000520>
50	01/19/20 9:24:39.113	luup_log:314: Reactor(<func@5195>:5220): tick() running eligible task "325" <0x75000520>
50	01/19/20 9:24:39.117	luup_log:314: Reactor(<func@4075>:4076): sensorTick(325) <0x75000520>
50	01/19/20 9:24:39.121	luup_log:314: Reactor(updateSensor:4049): updateSensor(325) "Office Side Light Ti" <0x75000520>
50	01/19/20 9:24:39.125	luup_log:314: Reactor(<func@3895>:3896): processSensorUpdate(325) <0x75000520>
50	01/19/20 9:24:39.129	luup_log:314: Reactor(getSensorConfig:1150): getSensorConfig(325,nil) <0x75000520>
50	01/19/20 9:24:39.133	luup_log:314: Reactor(loadCleanState:1160): loadCleanState(325) <0x75000520>
50	01/19/20 9:24:39.136	luup_log:314: Reactor(loadCleanState:1167): loadCleanState() returning cached cstate <0x75000520>
50	01/19/20 9:24:39.142	luup_log:314: Reactor(<func@3895>:3922): processSensorUpdate() base time is 1579425879(01/19/20.09:24:39) ({ hour=9, min=24, wday=1, day=19, month=1, year=2020, sec=39, yday=19, isdst=false }) testing=false <0x75000520>
50	01/19/20 9:24:39.145	luup_log:314: Reactor(updateVariables:2782): updateVariables(cdata,325) <0x75000520>
50	01/19/20 9:24:39.149	luup_log:314: Reactor(loadCleanState:1160): loadCleanState(325) <0x75000520>
50	01/19/20 9:24:39.153	luup_log:314: Reactor(loadCleanState:1167): loadCleanState() returning cached cstate <0x75000520>
50	01/19/20 9:24:39.156	luup_log:314: Reactor(processCondition:3514): processCondition("root",nil,cdata,325) <0x75000520>
50	01/19/20 9:24:39.160	luup_log:314: Reactor(processCondition:3523): processCondition() new condition state for "root" <0x75000520>
50	01/19/20 9:24:39.164	luup_log:314: Reactor(evaluateCondition:2932): evaluateCondition("root",nil,cdata,325) <0x75000520>
50	01/19/20 9:24:39.168	luup_log:314: Reactor(evaluateCondition:2939): evaluateCondition() condstate { statestamp=0, stateedge={  }, valuestamp=0, id="root", evaledge={  } } <0x75000520>
50	01/19/20 9:24:39.172	luup_log:314: Reactor(<func@3837>:3838): evaluateGroup("root",nil,cdata,325) <0x75000520>
50	01/19/20 9:24:39.176	luup_log:314: Reactor(<func@3837>:3845): evaluateGroup() process "root" #1/3: "sun" "cond16800ee048c" <0x75000520>
50	01/19/20 9:24:39.180	luup_log:314: Reactor(processCondition:3514): processCondition("cond16800ee048c","root",cdata,325) <0x75000520>
50	01/19/20 9:24:39.183	luup_log:314: Reactor(processCondition:3523): processCondition() new condition state for "cond16800ee048c" <0x75000520>
50	01/19/20 9:24:39.187	luup_log:314: Reactor(evaluateCondition:2932): evaluateCondition("cond16800ee048c","root",cdata,325) <0x75000520>
50	01/19/20 9:24:39.191	luup_log:314: Reactor(evaluateCondition:2939): evaluateCondition() condstate { statestamp=0, stateedge={  }, valuestamp=0, id="cond16800ee048c", evaledge={  } } <0x75000520>
50	01/19/20 9:24:39.195	luup_log:314: Reactor(evaluateCondition:3207): evaluateCondition() cond "cond16800ee048c" check 564 "bet" 985 and 547 <0x75000520>
50	01/19/20 9:24:39.199	luup_log:314: Reactor(doNextCondCheck:2803): doNextCondCheck({ id=325, info="sun cond16800ee048c" },564,985,547,false) <0x75000520>
50	01/19/20 9:24:39.203	luup_log:314: Reactor(doNextCondCheck:2815): doNextCondCheck() edge 985, scheduling next check for 1579451100(01/19/20.16:25:00) (delay 25260secs) <0x75000520>
50	01/19/20 9:24:39.208	luup_log:314: Reactor(scheduleTick:625): scheduleTick({ id=325, info="sun cond16800ee048c" },1579451100(01/19/20.16:25:00),nil) <0x75000520>
50	01/19/20 9:24:39.211	luup_log:314: Reactor(processCondition:3530): processCondition() group "root" cond "cond16800ee048c" result false timer nil <0x75000520>
50	01/19/20 9:24:39.215	luup_log:314: Reactor(processCondition:3538): processCondition() recording "cond16800ee048c" state change <0x75000520>
50	01/19/20 9:24:39.220	luup_log:314: Reactor(<func@3837>:3870): evaluateGroup() result "root" #1/3: "sun" "cond16800ee048c" = false; passed false <0x75000520>
50	01/19/20 9:24:39.224	luup_log:314: Reactor(<func@3837>:3845): evaluateGroup() process "root" #2/3: "trange" "cond16800f1dd57" <0x75000520>
50	01/19/20 9:24:39.228	luup_log:314: Reactor(processCondition:3514): processCondition("cond16800f1dd57","root",cdata,325) <0x75000520>
50	01/19/20 9:24:39.233	luup_log:314: Reactor(processCondition:3523): processCondition() new condition state for "cond16800f1dd57" <0x75000520>
50	01/19/20 9:24:39.238	luup_log:314: Reactor(evaluateCondition:2932): evaluateCondition("cond16800f1dd57","root",cdata,325) <0x75000520>
50	01/19/20 9:24:39.243	luup_log:314: Reactor(evaluateCondition:2939): evaluateCondition() condstate { statestamp=0, stateedge={  }, valuestamp=0, id="cond16800f1dd57", evaledge={  } } <0x75000520>
50	01/19/20 9:24:39.248	luup_log:314: Reactor(evaluateCondition:3251): evaluationCondition() clean tpart={ 1=2020, 2=1, 3=19, 4=21, 5=0, 6=2020, 7=1, 8=19, 9=21, 10=0 } <0x75000520>
50	01/19/20 9:24:39.254	luup_log:314: Reactor(evaluateCondition:3254): evaluateCondition() time-only comparison, now is 1579425879(01/19/20.09:24:39), ndt is { hour=9, min=24, wday=1, day=19, month=1, year=2020, sec=39, yday=19, isdst=false } <0x75000520>
50	01/19/20 9:24:39.259	luup_log:314: Reactor(evaluateCondition:3262): evaluateCondition() time-only comparison 564 before 1260 <0x75000520>
50	01/19/20 9:24:39.264	luup_log:314: Reactor(doNextCondCheck:2803): doNextCondCheck({ id=325, info="trangeHM cond16800f1dd57" },564,1260,nil,false) <0x75000520>
50	01/19/20 9:24:39.269	luup_log:314: Reactor(doNextCondCheck:2815): doNextCondCheck() edge 1260, scheduling next check for 1579467600(01/19/20.21:00:00) (delay 41760secs) <0x75000520>
50	01/19/20 9:24:39.276	luup_log:314: Reactor(scheduleTick:625): scheduleTick({ id=325, info="trangeHM cond16800f1dd57" },1579467600(01/19/20.21:00:00),nil) <0x75000520>
50	01/19/20 9:24:39.281	luup_log:314: Reactor(processCondition:3530): processCondition() group "root" cond "cond16800f1dd57" result true timer nil <0x75000520>
50	01/19/20 9:24:39.285	luup_log:314: Reactor(processCondition:3538): processCondition() recording "cond16800f1dd57" state change <0x75000520>
50	01/19/20 9:24:39.293	luup_log:314: Reactor(<func@3837>:3870): evaluateGroup() result "root" #2/3: "trange" "cond16800f1dd57" = true; passed false <0x75000520>
50	01/19/20 9:24:39.298	luup_log:314: Reactor(<func@3837>:3845): evaluateGroup() process "root" #3/3: "weekday" "cond1680107316d" <0x75000520>
50	01/19/20 9:24:39.303	luup_log:314: Reactor(processCondition:3514): processCondition("cond1680107316d","root",cdata,325) <0x75000520>
50	01/19/20 9:24:39.318	luup_log:314: Reactor(processCondition:3523): processCondition() new condition state for "cond1680107316d" <0x75000520>
50	01/19/20 9:24:39.329	luup_log:314: Reactor(evaluateCondition:2932): evaluateCondition("cond1680107316d","root",cdata,325) <0x75000520>
50	01/19/20 9:24:39.346	luup_log:314: Reactor(evaluateCondition:2939): evaluateCondition() condstate { statestamp=0, stateedge={  }, valuestamp=0, id="cond1680107316d", evaledge={  } } <0x75000520>
50	01/19/20 9:24:39.354	luup_log:314: Reactor(evaluateCondition:3119): evaluateCondition() weekday condition, setting next check for 1579478400(01/20/20.00:00:00) <0x75000520>
50	01/19/20 9:24:39.362	luup_log:314: Reactor(scheduleTick:625): scheduleTick({ id=325, info="weekday cond1680107316d" },1579478400(01/20/20.00:00:00),nil) <0x75000520>
50	01/19/20 9:24:39.368	luup_log:314: Reactor(evaluateCondition:3123): evaluateCondition() weekday 1 among { 1="2", 2="3", 3="4", 4="5", 5="6" } <0x75000520>
50	01/19/20 9:24:39.373	luup_log:314: Reactor(processCondition:3530): processCondition() group "root" cond "cond1680107316d" result false timer nil <0x75000520>
50	01/19/20 9:24:39.378	luup_log:314: Reactor(processCondition:3538): processCondition() recording "cond1680107316d" state change <0x75000520>
50	01/19/20 9:24:39.386	luup_log:314: Reactor(<func@3837>:3870): evaluateGroup() result "root" #3/3: "weekday" "cond1680107316d" = false; passed false <0x75000520>
50	01/19/20 9:24:39.392	luup_log:314: Reactor(processCondition:3530): processCondition() group nil cond "root" result false timer false <0x75000520>
50	01/19/20 9:24:39.397	luup_log:314: Reactor(processCondition:3538): processCondition() recording "root" state change <0x75000520>
50	01/19/20 9:24:39.406	luup_log:314: Reactor(<func@3895>:3932): processSensorUpdate() root was false now false, retrig false <0x75000520>
50	01/19/20 9:24:39.421	luup_log:314: Reactor(<func@3895>:3961): processSensorUpdate() checking groups for state changes <0x75000520>
50	01/19/20 9:24:39.427	luup_log:314: Reactor(<func@3895>:3964): processSensorUpdate() checking group "root" for state change <0x75000520>
50	01/19/20 9:24:39.432	luup_log:314: Reactor(<func@3895>:3969): processSensorUpdate() group "grp16800ee048b" <"root"> state changed to false, looking for activity "root.false" <0x75000520>
50	01/19/20 9:24:39.438	luup_log:314: Reactor(getSceneData:1406): getSceneData("root.false",325) <0x75000520>
50	01/19/20 9:24:39.443	luup_log:314: Reactor(getSensorConfig:1150): getSensorConfig(325,nil) <0x75000520>
01	01/19/20 9:24:39.444	luup_log:314: Reactor: access to "untripactions" in cdata, which is undefined! <0x75000520>
50	01/19/20 9:24:39.451	luup_log:314: Reactor(isSceneEmpty:1302): isSceneEmpty(nil) <0x75000520>
50	01/19/20 9:24:39.456	luup_log:314: Reactor(isSceneEmpty:1311): isSceneEmpty() true <0x75000520>
50	01/19/20 9:24:39.461	luup_log:314: Reactor(<func@3895>:3988): processSensorUpdate() evaluating tripped state <0x75000520>
50	01/19/20 9:24:39.466	luup_log:314: Reactor(<func@3895>:3995): processSensorUpdate() new trippped state false <0x75000520>
50	01/19/20 9:24:39.468	luup_log:314: Reactor: "Office Side Light Ti" (#325) now "untripped" <0x75000520>
50	01/19/20 9:24:39.476	luup_log:314: Reactor(loadCleanState:1160): loadCleanState(325) <0x75000520>
50	01/19/20 9:24:39.481	luup_log:314: Reactor(loadCleanState:1167): loadCleanState() returning cached cstate <0x75000520>
50	01/19/20 9:24:39.487	luup_log:314: Reactor(<func@3895>:4027): processSensorUpdate() trouble false <0x75000520>
50	01/19/20 9:24:39.492	luup_log:314: Reactor(<func@3895>:4044): processSensorUpdate() finished <0x75000520>
50	01/19/20 9:24:39.496	luup_log:314: Reactor(<func@5195>:5222): tick() return true from task "325", err=nil <0x75000520>
50	01/19/20 9:24:39.502	luup_log:314: Reactor(<func@5195>:5240): tick() finished, next eligible task at 1579425900(01/19/20.09:25:00) <0x75000520>
50	01/19/20 9:24:39.507	luup_log:314: Reactor(<func@5195>:5245): tick() scheduling next tick("5") for 21 (1579425900(01/19/20.09:25:00)) <0x75000520>
50	01/19/20 9:24:50.101	luup_log:275: TEXECOM: No zone Z002 <0x75200520>
50	01/19/20 9:24:50.103	luup_log:275: TEXECOM: No zone Z007 <0x75200520>
50	01/19/20 9:24:50.105	luup_log:275: TEXECOM: No zone Z008 <0x75200520>
50	01/19/20 9:24:50.106	luup_log:275: TEXECOM: No zone Z011 <0x75200520>
50	01/19/20 9:24:50.107	luup_log:275: TEXECOM: No zone Z012 <0x75200520>
50	01/19/20 9:24:50.109	luup_log:275: TEXECOM: No zone Z015 <0x75200520>
50	01/19/20 9:24:50.110	luup_log:275: TEXECOM: No zone Z016 <0x75200520>
50	01/19/20 9:24:50.111	luup_log:275: TEXECOM: No zone Z017 <0x75200520>
50	01/19/20 9:24:50.112	luup_log:275: TEXECOM: No zone Z018 <0x75200520>
50	01/19/20 9:24:50.113	luup_log:275: TEXECOM: No zone Z019 <0x75200520>
50	01/19/20 9:24:50.115	luup_log:275: TEXECOM: No zone Z020 <0x75200520>
50	01/19/20 9:24:50.116	luup_log:275: TEXECOM: No zone Z021 <0x75200520>
50	01/19/20 9:24:50.117	luup_log:275: TEXECOM: No zone Z022 <0x75200520>
50	01/19/20 9:24:50.118	luup_log:275: TEXECOM: No zone Z023 <0x75200520>
50	01/19/20 9:24:50.119	luup_log:275: TEXECOM: No zone Z024 <0x75200520>
50	01/19/20 9:24:50.120	luup_log:275: TEXECOM: No zone Z025 <0x75200520>
50	01/19/20 9:24:50.121	luup_log:275: TEXECOM: No zone Z026 <0x75200520>
50	01/19/20 9:24:50.122	luup_log:275: TEXECOM: No zone Z027 <0x75200520>
50	01/19/20 9:24:50.123	luup_log:275: TEXECOM: No zone Z028 <0x75200520>
50	01/19/20 9:24:50.124	luup_log:275: TEXECOM: No zone Z029 <0x75200520>
50	01/19/20 9:24:50.126	luup_log:275: TEXECOM: No zone Z030 <0x75200520>
50	01/19/20 9:24:50.126	luup_log:275: TEXECOM: No zone Z031 <0x75200520>
50	01/19/20 9:24:50.127	luup_log:275: TEXECOM: No zone Z032 <0x75200520>
50	01/19/20 9:24:50.130	luup_log:275: TEXECOM: No zone Z038 <0x75200520>
50	01/19/20 9:24:50.131	luup_log:275: TEXECOM: No zone Z040 <0x75200520>
04	01/19/20 9:24:58.472	<Job ID="138" Name="pollnode #34 3 cmds" Device="211" Created="2020-01-19 9:24:54" Started="2020-01-19 9:24:54" Completed="2020-01-19 9:24:58" Duration="4.371014000" Runtime="4.369819000" Status="Successful" LastNote="" Node="34" NodeType="ZWaveMultiEmbedded" NodeDescription="Hallway Front"/> <0x76c00520>
02	01/19/20 9:24:58.472	Device_Basic::AddPoll 211 poll list full, deleting old one <0x76c00520>
50	01/19/20 9:25:00.100	luup_log:83: Harmony Control_debug: Keep hub connection open <0x75c00520>
50	01/19/20 9:25:00.104	luup_log:314: Reactor(<func@5195>:5196): tick("4") pluginDevice=314 <0x75000520>
50	01/19/20 9:25:00.108	luup_log:314: Reactor(<func@5195>:5198): tick() stamp mismatch (got "4", expecting 5), newer thread running. Bye! <0x75000520>
50	01/19/20 9:25:00.111	luup_log:314: Reactor(<func@5195>:5196): tick("5") pluginDevice=314 <0x75000520>
50	01/19/20 9:25:00.116	luup_log:314: Reactor(<func@5195>:5217): tick() to-do list is { 1={ info="", args={  }, id="314", owner=314, func=function: 0x1f711e8, when=1579425900(01/19/20.09:25:00) } } <0x75000520>
50	01/19/20 9:25:00.120	luup_log:314: Reactor(<func@5195>:5220): tick() running eligible task "314" <0x75000520>
50	01/19/20 9:25:00.123	luup_log:314: Reactor(<func@4317>:4318): masterTick(314) <0x75000520>
50	01/19/20 9:25:00.127	luup_log:314: Reactor(scheduleTick:625): scheduleTick("314",1579425960(01/19/20.09:26:00),nil) <0x75000520>
50	01/19/20 9:25:00.131	luup_log:314: Reactor(<func@4317>:4342): masterTick() current DST "0", last "0" <0x75000520>
50	01/19/20 9:25:00.135	luup_log:314: Reactor(<func@5195>:5222): tick() return true from task "314", err=nil <0x75000520>
50	01/19/20 9:25:00.139	luup_log:314: Reactor(<func@5195>:5240): tick() finished, next eligible task at 1579425960(01/19/20.09:26:00) <0x75000520>
50	01/19/20 9:25:00.143	luup_log:314: Reactor(<func@5195>:5245): tick() scheduling next tick("5") for 60 (1579425960(01/19/20.09:26:00)) <0x75000520>
50	01/19/20 9:25:05.102	luup_log:275: TEXECOM: No zone Z002 <0x75200520>
50	01/19/20 9:25:05.104	luup_log:275: TEXECOM: No zone Z007 <0x75200520>
50	01/19/20 9:25:05.105	luup_log:275: TEXECOM: No zone Z008 <0x75200520>
50	01/19/20 9:25:05.106	luup_log:275: TEXECOM: No zone Z011 <0x75200520>
50	01/19/20 9:25:05.107	luup_log:275: TEXECOM: No zone Z012 <0x75200520>
50	01/19/20 9:25:05.109	luup_log:275: TEXECOM: No zone Z015 <0x75200520>
50	01/19/20 9:25:05.110	luup_log:275: TEXECOM: No zone Z016 <0x75200520>
50	01/19/20 9:25:05.111	luup_log:275: TEXECOM: No zone Z017 <0x75200520>
50	01/19/20 9:25:05.112	luup_log:275: TEXECOM: No zone Z018 <0x75200520>
50	01/19/20 9:25:05.113	luup_log:275: TEXECOM: No zone Z019 <0x75200520>
50	01/19/20 9:25:05.114	luup_log:275: TEXECOM: No zone Z020 <0x75200520>
50	01/19/20 9:25:05.114	luup_log:275: TEXECOM: No zone Z021 <0x75200520>
50	01/19/20 9:25:05.115	luup_log:275: TEXECOM: No zone Z022 <0x75200520>
50	01/19/20 9:25:05.116	luup_log:275: TEXECOM: No zone Z023 <0x75200520>
50	01/19/20 9:25:05.116	luup_log:275: TEXECOM: No zone Z024 <0x75200520>
50	01/19/20 9:25:05.117	luup_log:275: TEXECOM: No zone Z025 <0x75200520>
50	01/19/20 9:25:05.118	luup_log:275: TEXECOM: No zone Z026 <0x75200520>
50	01/19/20 9:25:05.118	luup_log:275: TEXECOM: No zone Z027 <0x75200520>
50	01/19/20 9:25:05.119	luup_log:275: TEXECOM: No zone Z028 <0x75200520>
50	01/19/20 9:25:05.119	luup_log:275: TEXECOM: No zone Z029 <0x75200520>
50	01/19/20 9:25:05.120	luup_log:275: TEXECOM: No zone Z030 <0x75200520>
50	01/19/20 9:25:05.120	luup_log:275: TEXECOM: No zone Z031 <0x75200520>
50	01/19/20 9:25:05.121	luup_log:275: TEXECOM: No zone Z032 <0x75200520>
50	01/19/20 9:25:05.122	luup_log:275: TEXECOM: No zone Z038 <0x75200520>
50	01/19/20 9:25:05.123	luup_log:275: TEXECOM: No zone Z040 <0x75200520>

blacey · January 19, 2020, 1:06pm

@rigpapa already fixed this issue - see his response above

pukka · January 19, 2020, 2:08pm

Thats interesting as i only downloaded the git this morning. I have just tried uploading the files to vera again with a Luup restart and hard refresh of the browser. still the same problem.

rigpapa · January 19, 2020, 3:25pm

OK. Download (right-click and “Save as…” this link): https://raw.githubusercontent.com/toggledbits/Reactor/develop/L_Reactor.lua

Push that up to your Vera (use the uploader at Apps > Develop apps > Luup files), and run a logic summary again. This should emit a more useful message.

pukka · January 19, 2020, 6:28pm

lets try this.

ERROR
Handler error: [string “–[[…”]:5783: bad argument #1 to ‘tostring’ (value expected)

rigpapa · January 19, 2020, 6:38pm

OK. That helps. My buddy @akbooer’s favorite: luup will return nothing rather than nil in some circumstances. Update to stable branch 20019.2

pukka · January 19, 2020, 6:48pm

That works great

rigpapa · February 14, 2020, 5:52pm

16 posts were split to a new topic: SMTP notification problem with Gmail

rigpapa · February 14, 2020, 7:13pm

The current beta/stable version of Reactor 3.5 is looking like a release candidate. The outstanding issue with SMTP notifications through Gmail reported by @ElCid was solved with configuration, as intended, and I’m not aware of any other outstanding issues in 3.5 (although I’m still taking stock of everything that transpired while I was travelling).

Barring anything else that comes up, plan on 3.5 being generally available Monday 2/17.

Edit: Update list of changes for this version…

POTENTIAL BREAKING: ReactorSensors no longer support the “Invert” state variable to reverse the sense of logic output to the Tripped state of the ReactorSensor. The better (and now required) choice is to apply “NOT” to the “root” group if needed. I doubt anybody has used the “Invert” flag, though.
POTENTIAL BREAKING: Until 3.5, tripping the ReactorSensor “manually” (e.g. with the UI buttons, or calling the “Trip” or “Reset” actions on the ReactorSensor, would run the root group’s corresponding activity. This is a legacy behavior from before Reactor had groups. As of 3.5, “Tripped” state is just a flag, and will no longer run any activity when changed. However, changes in the root group’s logic state will still drive the “Tripped” value (“root” true == Tripped, “root” false == Not Tripped/Reset), and the root group’s activities will run in response to logic changes as they would for any other group. The reverse path, however, is no longer true–forcing the ReactorSensor to trip or untrip doesn’t run the root’s activities. I doubt anybody actually relies on this behavior, and it actually creates more problems than it solves, which is why I’m removing it. If you must have the behavior, you should redo your logic, but while you’re figuring out how, you can set UseLegacyTripBehavior = 1 on any ReactorSensor that requires it. This flag and the ability to use the legacy behavior will be removed for 4.0. Also note that this change only affects Reactor activities; it does not change the behavior of Vera scenes using a ReactorSensor as a device trigger.
Enhancement: Added a “Stop Group Activity” to stop a specific activity, or all activities, running on the current ReactorSensor or another.
Enhancement: The “Run Group Activity” action now allows you to force-stop all other running activities before launching the selected activity. This is a short-cut for using a separate “Stop Group Activity” before.
Enhancement: “Pulse” output mode for conditions now allows repeat pulses with a configurable off/false period between and a limit on the number of pulses.
Enhancement: The new Expression Variable condition type allows direct condition testing of an expression’s most recent result value without using a self-referencing Device State condition.
Enhancement: The new Set Variable activity allows direct setting of a variable without using a self-directed Device State activity with a SetVariable service action. The target variable must be “expression-less” (that is, its configured expression is blank/empty).
Enhancement: New “Run Activity” button on each activity allows the entire activity to be tested. This does not stop other running activities, including contra-activities (i.e. if you run the “is TRUE” activity for a group it does not stop the group’s “is FALSE” activity if it is currently running).
Enhancement: Make event log entries more human-readable.
Enhancement: Reactor table in “Run Lua” actions now publishes state for all conditions (in table Reactor.conditions; keys are condition IDs). This makes the current condition states and values accessible directly in Lua without additional “gets”.
Enhancement: Reactor table in “Run Lua” actions now publishes group states (in Reactor.groups) by name as well as by ID. Previously the keys were group IDs. Now you can use either in “Run Lua” actions.
Enhancement: Do not check firmware version in debug mode, specifically for allowing testing on any firmware, including alpha/unblessed.
Enhancement: The Activities tab now can filter the display by “true” and “false” activities (suggestion by tunnus).
Enhancement: Update LuaXP to latest version (1.0.1); adds date() and map() functions, more trig; see GitHub - toggledbits/luaxp: Luaxp is a simple arithmetic infix expression parser/evaluator written in Lua
Enhancement: The new getstatetime() expression function is now available to return Luup’s last-modified timestamp for a state variable.
Enhancement: In places where variable substitution is allowed (i.e. where you can use {variablename}), you can now use an expression (same syntax as Expressions tab, just surround the expression in curly braces).
Enhancement: The “Device Spy” on the Tools tab reports changes in state variables (dynamically) on a selected device. This is intended to help users find state variables that change as the device is used/updated.
Enhancement: Add option for sequence (“after”) condition restriction to ignore current state of predecessor (so timing is based only on last true edge of predecessor).
Enhancement: When a ReactorSensor is disabled, its Status view will show all gray (as if all groups were disabled, which they effectively are).
Enhancement: Features that require the “Allow Unsafe Lua” flag now generate an alert if the flag is not enabled.
Internal: Clean up mechanism for determining SSL parameters for SMTP connections.
Internal: Upgrade of configuration is only done by core now; no duplication of effort on the JS side.
Fix: Improve the list contents for the “relative to” conditions on Interval conditions.
Fix: Fix color of text for ALTUI users using dark themes.
Fix: Fix reinitialization issue when switching between tabs without saving and user elects to abandon changes.
Fix: Do not clear operands when changing operators.
Fix: Condition value field IDs “unique-ified” similar to hotfix 19318-01 for some Mac browsers.
Fix: Delay input fields need same unique ID treatment, similar to hotfix 19318-01, for some Mac browsers.
Fix: “try” action operating in Activity editor was not substituting variables correctly; partly a limitation introduced by the evolation of variable, and partly bug, but in any case, fixed.
Fix: After clearing condition state, make sure initial update/restart runs all activities eligible (esp. root).
Fix: Try to reduce complexity of the interaction with VeraAlerts for notifications; fixes some issues in scene handling that create odd side-effects for users, and allows editing of recipients in the Activities tab. Messages on VA-controlled notifications are still required to be edited in VA. Recipient changes still require user to enter VA’s “Edit” tab to get those changes to take effect. It is what it is.
Fix: Cosmetic bug in the appearance of scene list for Run Scene activity.
Fix: Cosmetic bug–“updates” action does not need “ignore case” checkbox.
19240-01: SMTP notifications to Google/Gmail fail with 555 5.5.2 Syntax error (L_Reactor.lua)
19273-01: Using a variable reference in a delay doesn’t work properly. (L_Reactor.lua)
19288-01: It appears certain Unicode characters can make the ancient JSON library that is standard in current Vera firmware hiccup and produce empty results, erasing a ReactorSensor’s configuration. Several different approaches to preventing damage to the config are implemented in this hotfix. (J_ReactorSensor_UI7.js, L_Reactor.lua)
19317-01: Fix variable substitution in “Try” action operation in Activity editor (J_ReactorSensor_UI7.js)
19317-02: Fix action editor incorrectly reselecting currently configured value (J_ReactorSensor_UI7.js)
19318-01: Work around issue with Chrome getting confused when multiple data-list fields have same ID (minor but apparently really annoying)
19337-01: Attempt to deal with inconsistencies in variable handling in Vera’s JS API
19354-01: Fixes for VeraAlerts notifications mentioned above were backported to 3.4.

blacey · February 14, 2020, 7:43pm

Hey @rigpapa, welcome back! I just pulled and uploaded latest stable as a final run through but stable has been running well on my system. I had one day where non of my Reactors fired but I’ve written that off to a one-time event that was probably due to the Vera beta. Hope you and yours had a great trip.

Cheers,
Bruce

rigpapa · February 14, 2020, 8:08pm

My house and dev Plus’s are both on the beta, and although several people have reported actions not running since 7.30 (witness thread by that title), I have not seen it myself, and most of the other reports have been attributable to other causes. If that happens again, collect as much data as you can as soon as you can, because at the moment, I have pretty much nothing, and nothing that points to anything in Reactor itself.

Catman · February 14, 2020, 10:02pm

I trust your QA, Patrick!

C

rigpapa · February 16, 2020, 7:29pm

rigpapa · February 16, 2020, 7:30pm

rigpapa · February 16, 2020, 7:35pm