STHM not working, so trying to use Location Mode

locationmode
#1

1) Give a description of the problem
As STHM doesn’t work with webCORE anyore in the new app, I have modified my pistons to read the Location Mode (away, home, stay, holday), but none of the pistons seem to be working. I want them to perform specific actions if mode is AWAY and a Presence Sensor arrives.

Would anyone be able to suggest how to get this same piston working please?

**4) Post a Green Snapshot of the piston![image|45x37]

image
image.png1178×532 27.7 KB

5) Attach logs after turning logging level to Full
29/08/2020, 20:25:22 +343ms
+1ms ╔Received event [Imran Hamid’s Galaxy S10+ - impee].presence = present with a delay of 63ms
+102ms ║RunTime Analysis CS > 13ms > PS > 51ms > PE > 38ms > CE
+104ms ║Runtime (39713 bytes) successfully initialized in 51ms (v0.3.110.20191009) (102ms)
+105ms ║╔Execution stage started
+142ms ║║Comparison (time) 73522453 is_between (time) 1598727120000 … (time) 82800000 = true (8ms)
+143ms ║║Time restriction check passed
+145ms ║║Condition #9 evaluated true (35ms)
+149ms ║║Comparison (string) :8738474949c6356822c47aa4d94e3dee: is (string) :8738474949c6356822c47aa4d94e3dee: = true (1ms)
+151ms ║║Cancelling condition #13’s schedules…
+152ms ║║Condition #13 evaluated true (6ms)
+165ms ║║Comparison (enum) present changes_to (string) present = false (0ms)
+167ms ║║Condition #14 evaluated false (13ms)
+168ms ║║Condition group #1 evaluated false (state did not change) (58ms)
+170ms ║╚Execution stage complete. (65ms)
+171ms ╚Event processed successfully (171ms)

#2

Do you have any automations that changes location mode based on presence?

If so, you might want to incorporate the two pistons into one.
Otherwise, it will be a race to see which piston sees the presence change first.

#4

I know it probably seems like a waste of time, but could you try moving the Any of ... changes to present to be the first of the conditions in the group and gives things a go? You may need to have each presence sensor cycle from present to not present to present again before they behave themselves.

I am suggesting this because changes to compares the attribute value carried in the events, which is present in your logs, to a previous value cached by the piston. It should be not present but the comparison is failing in your case. I’ve seen this quite a bit in this forum and I believe it is because the piston needs to evaluate the changes to trigger comparison in order to cache the value. In your case the time and location conditions can prevent the changes to being reached and so the cache may get out of sync. This could be nonsense but it is worth a try.

#5

@orangebucket thank you very much for your advice, that worked! :slight_smile: i.e. I put the Presense Sensors condition first.

#6

Thanks for confirming!

There are still many people who do not follow this structure…