Help Understanding Log

#21

Sorry to waste your time. I just tested, and got the same results. :man_facepalming:

For what it’s worth, I try to keep DeviceA’s switch and DeviceA’s level in separate pistons (if they are triggers).

#22

Thanks, it was worth a try. Is this a bug in the DH or just the way webcore works? This seems to limit the use of the virtual & simulated dimmer switches in controlling other devices.

I need a rethink with the new knowledge!

I’m not sure how I could use separate pistons, as they’d need to share data through global variables and don’t think the updating at the end of a piston would enable another to have the up to date values it would need.

I’m also still not understanding why the second command from the switch (either on or dim) causes the piston to run, but then evaluates as false. This makes it difficult/impossible to code around the randomness.
e,g
22/09/2020, 00:07:35 +513ms +1ms ╔Received event [Kitchen Lights2].switch = on with a delay of 62ms +10087ms ║RunTime Analysis CS > 18ms > PS > 10050ms > PE > 20ms > CE +10088ms ║Piston waited at a semaphore for 10018ms +10090ms ║Runtime (42326 bytes) successfully initialized in 10050ms (v0.3.110.20191009) (10088ms) +10091ms ║╔Execution stage started +10098ms ║║Comparison (enum) on changes_to (string) on = false (1ms) +10099ms ║║Condition #2 evaluated false (4ms) +10100ms ║║Condition group #1 evaluated false (state did not change) (5ms) +10105ms ║║Comparison (enum) on changes_to (string) off = false (0ms) +10107ms ║║Condition #9 evaluated false (4ms) +10108ms ║║Condition group #8 evaluated false (state did not change) (5ms) +10117ms ║║Cancelling condition #31’s schedules… +10118ms ║║Condition #31 evaluated false (7ms) +10119ms ║║Cancelling condition #30’s schedules… +10119ms ║║Condition group #30 evaluated false (state changed) (9ms) +10121ms ║╚Execution stage complete. (30ms) +10122ms ╚Event processed successfully (10123ms)

#23

Upon reflection, it sounds normal.

(A) You subscribe to DeviceA’s switch
(B) You subscribe to DeviceA’s level

… then…

(C) You change DeviceA’s level (which executes the piston)
(D) SmartThings sends a command to “Turn on” DeviceA
(E) This switch change begins the piston all over at the top

It is that age-old paradox

IF DeviceA changes
    Then change DeviceA
END IF

Hmmm… I just had an idea…

We know the switch will turn on when the level changes, so what if your only trigger was based on the SWITCH. (and you kept your levels as conditions)

This would prevent double triggers, semaphore delays, and a bunch of other shenanigans…

Worst case, you can stall a second after the switch turns on before checking the current level.

#24

The trigger on the switch only could work, but you’d have to turn the switch off before changing the level if you wanted to move to a new scene. (The futronix does very nice transitions going from one scene to another!)

Just had a thought…
Could a separate piston triggered on level be paused and un paused by the main piston?
So When the light comes on, the level change piston is activated to handle any level changes. When the light turns off, the level change piston is paused.

A further thought…
It should be doable with a global variable (lightsOn)
The main piston will respond to on/off, setting the lightsOn variable as appropriate. For an on command, it will read the level and call the appropriate harmony activity.
The level piston will only process level changes if lightsOn is true

Think that’s got to your recommended two pistons.

#25

Traditionally, I would “reset” this a few seconds after the scene was set.
(instead of waiting for the next scene)
… but either way could work.

Yes, but you are back to the original issue where switch may be registered before or after the level change.

Not that anyone cares, but my current vote is for a single trigger based on switch, with levels as conditions. :grin:

#26

I’d rather not turn the switch off, as I’d like to use it as an indicator that the lights have been turned on.

I’m not sure you saw my edits above, I think you replied while i was typing them.

I don’t think the order of events would matter.
If you get on first
main piston will read level and set it
level piston will be activated and if it receives the level will set the same level

If you get level first
level piston will ignore it - LightsOn is false
main piston will read level and set it

I’m assuming with two pistons, the issue with the single piston solution of evaluating the second event to false, even though it had been triggered would not be an issue.

#27

I am not following fully, but it sounds like you have a good game plan, at least.

#28

Its getting late, and I’m not explaining it well!

I think you’ve given me the right ideas to get this working. I’ll write the two pistons tomorrow and post them here if they work. If not, I’ll start another thread as this one was really about understanding the log messages and I digressed.

#29

Sounds like a winner!

(I always code better after a good night’s sleep)

#30

Well, I think sleeping on it was a good idea. I’ve probably been over complicating things and going against what the DH does. In effect, I was trying to make the turn on command change the level to 100%, rather than just turning on at the current level.

The following piston seems to be working fine, it should handle the on & dim commands in any order.

image
image.png1178×1318 65.8 KB

#31

Lookin’ good!

#32

The next step would be to set the sim switch to on or off if the dimmer was operated manually. I could do this by monitoring the power usage. However, its quite expensive to add a power module, and then wire it into the consumer unit.

I need to come up with some use cases to justify! I’ve only come up with activating scene 1 (dim) if there’s movement in the room when the system is in night mode.

Just a thought on the sim switch…
Do the physical/programmatic feature work correctly? I’m thinking if I used the physical interaction in my piston, then if I changed the switch via webcore (when power increases/decreases) it wouldn’t trigger? It would be a bit easier & more elegant to code.

#33

Um… wouldn’t a simulated switch (by definition) only be toggled programmatically?
(I mean, how can you physically touch something that does not exist?)

#34

yes, I’m not sure, so why does it have the two options? I guess operating it via the St app could be classed as physical?

#35

In reference to this:

pic

The interaction option (physical or programmatic) is webCoRE’s code, but it only works on the devices that report accordingly.

So if ST set the flag at the event, it could likely be picked up…

Although the usual remedy for this is to use variables in webCoRE to distinguish between the two events.

#36

It seems a very useful facility. I tried using it when I first started using webcore, but haven’t found any devices that support it. I’ve used variables since. I wish more devices would support it as it would lead to more elegant and simpler looking code.

#37

I agree 100%.

I am envisioning a future when hundreds of unique triggers will be added to handlers to alert us to all kind of events.

#38

As this happens, I wonder if we need an AI engine to take all these inputs and start determining what is going on?

e.g The AI could determine you are driving home from work, what time you’ll arrive and trigger a simple event “home from work” which you could then trigger light, heating, music etc

#39

I think that is the basis concept of the hub, and our logic programming.

  • The device reports something to the hub
  • The hub triggers webCoRE
  • webCoRE runs thru the code, and takes action if possible

Using your example:

  • My SmartHome is alerted when I leave the office
  • This executes a webCoRE piston

Depending on the time (and many other factors):

  • voice alerts may speak,
  • timers may be set,
  • lights may change,
  • thermostat may adjust
  • variables are set etc.

Likewise, when I am at Walmart, my SmartHome knows, and may remind me to pickup something…
Or it may tell me when a rain cloud is about to hit, so I know to hurry up and check out.

Surely I can not be the only one introducing AI elements in to their programming?

#40

I’m thinking an AI could do more. It could learn more about your travel from work, so it would know you are coming home, and you haven’t just left to fetch a coffee.

I have a piston that monitors where I’ve been, and using a state transition table determines the journey I have completed. However, updating the state transition table gets very complex. AI capabilities would be able to simplify this, and learn, amending the rules as appropriate.

I’ve no idea how this would work in reality, particularly training the AI engine, but think its an interesting thought about how things may develop.