ok. update now that I am back home.
Running the older version with the newer version string. No good. Conditions inconsistently evaluating. In addition, I see these long strings in the log - somewhere the code is confused for sure. Given more reports are on this thread wrt conditions evaluating incorrectly - do we have a pattern emerging that can be fixed?
@ipaterson - quick clarification - I don’t think the issue has to do with physical sensors only. In my case, pistons get called by other pistons and either evaluate physical or non-physical events incorrectly. Also it depends if you consider presence change as physical or programmatic in your code but there seems to be a cluster of issues surrounding incorrect evaluation of presence.
Do you still want me to paste the new code vs. github? Would this get you anywhere in troubleshooting the issues? Happy to do so unless there is a prevailing theory that needs a different set of testing activities?
9/6/2019, 3:20:47 PM +254ms
+1ms ╔Received event [Valerie K].presence = present with a delay of 105ms
+148ms ║RunTime Analysis CS > 27ms > PS > 68ms > PE > 52ms > CE
+151ms ║Runtime (42640 bytes) successfully initialized in 68ms (v0.3.10e.20190826) (149ms)
+152ms ║╔Execution stage started
+170ms ║║Comparison (enum) present changes_to (string) present = true (1ms)
+172ms ║║Cancelling condition #7’s schedules…
+173ms ║║Condition #7 evaluated true (17ms)
+178ms ║║Comparison (string) :49914fee05dd0ba22460bac202289976: is_not (string) :49914fee05dd0ba22460bac202289976: = false (2ms)
+180ms ║║Condition #20 evaluated false (6ms)
+181ms ║║Condition group #1 evaluated false (state did not change) (25ms)
+190ms ║╚Execution stage complete. (38ms)
+191ms ╚Event processed successfully (191ms)