WebCoRE Logging Level vs effeciency

#1

I originally had left WebCoRE logs off thinking that they were not needed except when I had a development issue. However, I’ve found that they are useful for just learning how your pistons react to different inputs, etc. Therefore, I’ve upped the logging levels on my pistons from Off to Minimal and then to Medium. My tendency to be anal, makes me want to turn the logging level to Full so I’m ready for something going wrong with all the details already available. However, I worry about the impact on storage and more importantly, piston execution times.

So, here’s my questions:

  • Do increased logging levels have an impact on storage requirements and piston execution times?
  • If so, what’s best practice for setting the levels?
#2

The oldest logs will just get purged as space is needed. 100,000 bytes per piston.

I don’t think efficiency plays a role in logging level.

#3

I don’t want to hijack the thread but these questions are very similar to one I’ve had for a long time…

  • How many pistons is too many pistons?
#4

OK Thanks for your response. I understand about he storage requirements and overwriting of logs as needed to stay within the limit. This does mean that over use of full logging will limit the availability of some possibly more important, older log entries. This suggests that a somewhat selective approach to use of ‘Full’ logging might be needed.

On the efficiency side of my question, it seems to me that there might be some amount of overhead needed to capture and then write full logs (vs a lower level). It may indeed be relatively unimportant WRT piston throughput though.

#5

The important part here is to not have several pistons pinging off the same devices. E.g. Is when a front door opens. Don’t make that the trigger for 15 pistons.

@lflorack
You shouldn’t keep logging level at full. Only when you have an issue with a piston.

#6

OK Sounds reasonable.

#7

I don’t think I did this but let’s say I did, what would be the best course of action to fix it? Having a piston subscribing to the device and making it trigger other pistons on event?

#8

Logging does come with an overhead, so full debug should only be used while debugging. The Log to console task will output to the log regardeless of its level.

#9

Just combine the actions. So instead of a piston to turn on a light when the door opens and another to do something else which also triggers based on the door opening. Put those into the same piston. Does that make sense?

#10

Depending on the amount of different pistons someone has, that would make for 1 very complex piston (for some…ok, me).

For example, I have some for general lighting (when door opens, when motion starts) but the same sensors are also used for security features (contact, motion) to turn on lights, after a certain time.

Im not fully into WebCoRE yet, but Im making the transition, one piston at a time. Id like to do it right the first time and the comment about combining them sounds like the right way, but Im not sure Im capable of doing that.

Once piston, for example, uses a motion sensor throughout the day to turn on a headboard light for ambient lighting. At a certain time it stops just using itself and adds either the motion from my sons room, or daughters room, to set the lights to 10% and color red. Then at a different time, it uses any exterior facing contact sensor and a motion sensor in the kitchen AND formal dining room, to set the cabinet lights to “Police mode” AND the headboard lights to “Police mode”

Those same motion sensors do other things throughout the day, as do the contact sensors.
Kids room, motion activates light for X minutes
Kitchen and living room motion sensors activate the under cabinet lights
MBR motion does the ambient lighting
Window contact sensors turn off Ecobee when any are open, set it to auto when all are closed
Doors open, chime the Aeon siren upstairs

So, are you recommending combine all the pistons that share a sensor as the trigger? If so, my brain will probably melt out of my head trying to figure this out.

#11

I will try and dig up a post from @ady624 about the sequence of events that happens when your device triggers.

But in essence I am sure that how you described your pistons is reasonable to me. I can’t say an exact number is too many or not.

#12

I’m struggling making sense of the log, when debugging piston. What are condition #X or condition group#Y referring to? The conditions in the piston are not numbered as far as I can tell. How do i corelate the log info with my piston code? Thx.

#13

Make sure you enable trace. You will see the numbers next to things once it’s been turned on

#14

Ah ah that’s the trick! Thanks!