Missed event trigger (and other off-topic ramblings)

#5

No it isn’t used in any other pistons. It’s a trigger for a couple smart lighting rules, arriving home and away.

We have had a few minor issues recently with life 360. I have my life 360 presence device trigger a simulated presence (this piston) and use the simulated presence in the smart lighting rules. This allows me to manually the “flip” the presence if life 360 gets confused. This morning life 360 worked but webCore didn’t flip the virtual presence device.

I can’t duplicate this particular piston in Smartthings so I’m going to use Tasker to ping our phones and then use those results for presence. If this still proves problematic then the bride and i will need get in the habit of using the keypad at the door when we come and go. Definitely first world problems.

I’ve had a couple other pistons give me issues too. They have run fine since December until the last week. One has multiple triggers because I am too lazy to change it. The other I did change so that there were no multiple triggers, Starting the last week I can walk into my bathroom and the light won’t come on. Walk in 1 minute later and it will. Other than being 1 minute later in the day, nothing will have changed.

If I was younger and more energetic, I would dig into the rules.api. But I’m not young and energetic so I’ll probably slowly start adding the virtual switches and rules back using the native apps but keep better documentation this time. :grin:

At some point, this V1 hub will die and I’ll have to rewrite everything for a new hub anyway. For now, I’ll just piece it together so the wife doesn’t say “this isn’t working, again”

Thanks again @WCmore. Your contributions to this community are above and beyond.

#6

I just arrived back home and webCore either isn’t seeing the life360 presence or isn’t triggering the virtual presence as it failed to work again. This worked on Sunday but not today. No programming changes over the weekend. The exact same piston and virtual presence for my wife is still working perfectly. Just plain odd.

#7

I have never been super impressed with life360 presence…

Oftentimes, presence gets out of sync with ST… The usual “solution” is to reboot your phone, although sometimes, you can get away with simply opening the app to resync…

#8

Sorry, that was my bad. I should have asked:
Is “Presence Sensor 3” a trigger in another automation…??

For what it’s worth, when a simple piston fails, that is usually the culprit.

#9

We have been using Life 360 since 2015, first in Michigan and now in Florida. It has actually been quite solid up until IOS 13.x on my brides phone. We did so the “stuff” for IOS 13 but it still doesn’t work like it did before the last major update. ST presence was never solid for us in Michigan and I haven’t tried it on Florida as we like benefits of life 360.

Anyway, like everything, what works for one, doesn’t always work for others. Life 360 works well for us. webCore works well for you. I’m glad that we have the choices to find what works best for each of us.

It does makes sense that the single piston decided to stop working. I can’t test that since I’ve already deleted the virtual presence devices and pistons. I moved the keypad closer to the door and told my wife that we are going to start using it to signal our arrival and departures. I’ll create a reminder for now that sends a text if everyone leaves and the alarm isn’t set. Fortunately, it didn’t affect the WAF. :grin:

#10

Ah yes… My apologies. Thank you for the reminder.

I guess all I was trying to say was:

Lots of activity in one smart home device / component will assuredly affect other devices nearby.
(most commands are being sent wirelessly; and many are hopping between devices a couple of times across a Mesh network, etc)

Here is a good laugh at what not to do…
(IE: My thoughts, exaggerated)

Voice Request - Alexa SceneA

A specific phrase will run Alexa SceneA, which will:
    Do a bunch of stuff, including flip SimulatedB

Smart lighting rule

IF SimulatedB's switch changes
    Then Do a bunch of stuff, including set BulbC to 80%

Piston 1

IF BulbC's level changes
    Then Do a bunch of stuff, including run RoutineD

RoutineD

Do a bunch of stuff, including Lock DoorE

Piston 2

IF DoorE's lock changes
    Then Do a bunch of stuff, including Set @globalF

Piston 3

IF @globalF changes
    Then ...

… oh… You get the idea, LOL

I just wanted to point out:
Even though each automation above has only has a single trigger, in the big picture, a single event will trigger multiple automations.

Can you imagine the chaos every time that “SimulatedB” changes…?!?
How reliable would you expect any one of those automations to be?

I know this example may sound a bit crazy, but honestly, I’ve seen much worse… Nearly all of the automations mentioned above can create triggers for nearly all of the other “Rule Engines”. This means, without proper planning, (and dare I say note-taking), even the simplest of logic can totally bog down your network.

Just to clarify, I am not saying that you have done any of this…
I am just saying that it is quite common (when expanding out) to hit that wall saying, “Oh crap, why didn’t I document this better?”… LOL

*whistles innocently, and nudges a pebble with his toe*

Pistons based on switches not working properly
#11

Thank you for the chuckle this morning! It was needed this AM. There is very little cascading going on. I really don’t have a super complicated setup like I’m imagining you minions do. My biggest hurdle has been the fact I have many conditions that determine when a light can turn on/off and at what intensity (off the top of my head the main bath has a dozen give or take). Most all of my rooms are like this. Fairly easy to setup in webCore, harder with the native tools. Other than my away and good night rules that turn off all the lights, I really try not to do “a bunch of stuff” at one time either. I think the old limit was 20 devices at a time before routines would have a hard time executing and I’ve always followed that. They are now handled by smart lighting.

I do have a little “old school” programming experience using BASIC when that was all the rage. I started tinkering using Radio Shack TRS-80’s and saving code to cassette tapes. I’m revealing my age here. And then later programmed industrial machines using RELAY LADDER LOGIC on PLC’s. It’s been a lot of years but I remember how bad code could mess you up. On the PLC’s we used to have scan time issues. The code executed top down and at times, a switch on the machine might be actuated and released before the PLC cycled back to the section of code that looked for the switch being actuated. Great fun to troubleshoot those problems. Using webCore is reminiscent of programming in BASIC to me.

That’s not to say I haven’t written my share of garbage code on ST to get something done quick though. My biggest problem anymore is lack of documentation. I have a really bad habit of not documenting what I’ve done. Makes it tough to change later.

I might be wrong here, and probably am, but am wondering if part of the problem might be caused by using “all” of the tools. I have extensive rules in all 3 tools, webCore, smart lighting, and Automations. As well as a fair number of scenes. I have seen, and been able to replicate, timing issues between the three tools when using seudo momentary switches. The switches flipped fast enough that they weren’t seen by all the tools. Maybe that has something to do with missed events.

What made me think of this is when I had everything set up without using webCore, I didn’t see dropped events. I didn’t start seeing them until I added webCore. Maybe if everything was in webCore there wouldn’t be any? I really don’t understand the back end architecture enough to know how everything is interacting behind the scenes. I’m not even sure how WebCore takes the information we enter on the console and converts it to groovy.

I had another piston (first time for this one) drop a “light on” event from motion last night. It was a first time for this piston. So what I’m seeing is very random in nature.

I do have some outside accent lights that change color and intensity often and the piston does flood the network with traffic. A LOT of traffic. They are running using the piston created by one of the minions. These have been in use since the beginning of the year without issue. Based on what your saying, maybe they aren’t playing well with other pistons. It would be a recent problem but who knows what changes might have occurred in the backend that could be affecting our systems.

The piston in my main bath is the worst so, as an experiment, I’m going to move that back to ST native tools and just see what happens. I think I’ve worked out how to do it without all of the virtual switches (or at least most of them). It would be a lot easier if smart lighting allowed more than one switch as a condition.

Enough rambling, coffee is getting cold. I’ll update the post if I can pinpoint anything in case someone else stumbles onto this rambling thread.

#12

For what it’s worth, I am a big fan of cascading long complex pistons… One after the other.

but…

I am strategic, and I only trigger part two in the very last line of code in part one.
(so, at most, a single command may overlap between automations)

Just to clarify in case others are reading this too…

I try to limit each piston to a single trigger, but I may have dozens of conditions beneath.
Multiple triggers can cause issues, but there is no limit on conditions.

This is a very good practice. My “Good Night” piston turns off some lights… waits a few seconds… turns off a few more… reads me the overnight weather… turns off a few more… waits a few seconds etc. It is a nice way to get a bunch of stuff done in a single piston, without bombarding the hub.

This is quite common, unfortunately, and was one of the reasons I was asking about other automations.

For what it’s worth, I try to use webCoRE for all of my SmartHome programming… (currently at about 98% here) and only look to outside logic when there is something that webCoRE cannot do. (which is rare)

It might be worth reading an older post of mine, which covers all errors I have ever seen.

#13

I’ve actually searched and read most of your best programmimg posts the last time there was activity here about dropped events in December 2019. That’s when I changed most of the pistons and everything started working. Even the pistons that don’t follow best practices. If I remember, ST made some backend changes too at that time. Everything has been working fine until this week.

I firmly believe something changed in the backend or something has become corrupt within the system on my end. Things don’t just work for a couple months and then go bonkers without some type of even. Unfortunately, we don’t have great tools to find intermittent errors. I’m leaning towards corruption since I did have that presence piston that just plain quit working.

The only issue I’m going to have moving things back ST native tools, in it’s current configuration, is the new guardrails on Automations and scenes. If they are still at 250 devices I’m going to hit that limit for sure.

Anyway, I have moved the main lighting piston for the bathroom back to native tools so we’ll see how it goes. I still have 5 small support pistons for the bathroom but I’m not going to move those until I know how things work out because of the guardrails.

Thanks again for the advice. :+1:

#14

I see it and raise you:))

10 Print "myname"
20 go to 10
RETURN

:joy::rofl::rofl::joy::rofl:

#15

Oh no, a goto statement. “Spaghetti” code here we come. :crazy_face:

#16

Personally, I would love for the new webCoRE to allow for GOTO statements… We could easily direct the logic flow. (overriding the default top-to-bottom execution)

I can already envision creating some beautiful monstrosities…

#17

Yes, goto statements make life so easy, until you have to figure out what you did a year later. I’ve traced my share of code with too many goto statemens.

My preference was usually gosub. I tried to put everything into subroutines and then call them as needed. If webCore worked like BASIC that would be a beautiful thing!

#18

I use a bunch of tiny (mini) pistons as subroutines.
Any piston (computer/phone) can call them at any time.

It works very well, as long as the multiple pistons do not step on each others toes.
(yes, another reference to note taking, LOL)

#19

Please give me an example of your note taking process.

#20

I know I’m not @WCmore, but thought I’d but in and provide some examples of my note-taking/planning:

image
image.png1370×996 162 KB

image
image.png1115×653 52.5 KB

I also provide fairly extensive descriptions in each pison:

image
image.png1348×79 7.08 KB

and label each code block for clarity:

image
image.png698×36 1.31 KB

For me, it seems to keep my pistons and events from running into each other while providing fairly clear information regarding the functioning, timing and other execution information of my pistons.

#21

I am impressed! Mentally, I know that I need to keep better track of my programming. But you have taken it to another level. :slight_smile:

#22

Thank you. I do it because my memory sucks! I write down everything (I’m anal!).

#23

@lflorack gave some fantastic examples above!

Essentially, I try to always document data that is hard to find later:

  • Which trigger (device & attribute) for which piston(s)
  • @globals (which piston(s) writes to, and which reads from)
  • Scheduled events (so I avoid overlapping)
  • Daisy chained pistons

I don’t often document conditions, but I will take note of triggers.
(or conditions that are acting as triggers)

I also keep track of which devices are Zigbee and which are Zwave…
(and which are battery powered, or AC powered acting as repeaters)

For this last tip, I use a rough blueprint of the house to mark the locations.
This makes it easy to get a solid Mesh Network with good coverage.

Where Used Cross Reference
#24

@lflorack, @WCmore. You guys make me look like an amature! :smile: Instead, I am just skipping along to the hum of my pistons, confident that everything is running (almost) perfectly.