Missed event trigger (and other off-topic ramblings)


#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:

I also provide fairly extensive descriptions in each pison:

and label each code block for clarity:

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.


#25

I am reminded of this 1 minute clip from the Matrix movie…


That link died… Here is the updated link that still works.


#26

A little off topic, but this brings up a question. Is there a way to see the overall operation of our pistons. Something similar to the statistics for a single piston, but for the entire account?


#27

If there is, I’m not aware of it. Would be nice.


#28

This sounds good, but if a combined log existed, I bet most households could easily log tens of thousands of lines in a single hour… (With Logging Level set to Full)

Talk about a nightmare to wade through…


#29

Thanks for posting ideas for documentation. It gives me ideas at what I may want to do for everything, whether in webCore or ST.


#30

@Oldcomputerwiz, sorry for hijacking your topic. :sunglasses:


#31

I changed the topic to (and other off-topic ramblings) and moved it from bugs long ago. I pushed this off topic long before you did. :smiley:. I personally don’t mind threads that ramble off topic as long as it’s labeled.