Announcement

Collapse
No announcement yet.

Problem with Device value and Time (Sunrise and Sunset) event

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by sclin View Post

    How often does HS3 event engine run in the background?
    About once a second. Or I should say that HS3 is always running but all events are evaluated about once a second.

    What is the prefer way to write event? (Check Time first then Check device value?)
    If I use "Device having its value set" does the event engine query the device value and process it accordingly?

    If you want an event to trigger at a SPECIFIC EXACT TIME then you can you the device changing or the time as you're trigger. If you want the even to operate within a certain time range then you need to use the device value changing as the trigger because a trigger needs to be a single action.

    Check out Randy's event clinic posts. They are very clear and explain all of this stuff in detail.
    Originally posted by rprade
    There is no rhyme or reason to the anarchy a defective Z-Wave device can cause

    Comment


      #17
      Originally posted by sclin View Post
      I think you hit the point about the device value. If I use "changing and becoming" statement then it would work, but I need an event to check the device value and time constantly. It would be very helpful to understand how HS3 event engine's handling to check "device value set". I don't see much of documentation about this.
      See my post above, it make the triggers function more clear

      How often does HS3 event engine run in the background?
      About once a second.
      What is the prefer way to write event? (Check Time first then Check device value?)
      If I use "Device having its value set" does the event engine query the device value and process it accordingly?
      No. As I stated above the event will only trigger if a command is sent to the device is sent to it through the Device Manager, an event or manual control. A trigger will not continually evaluate the value of a device except for the few that are outlined in the posts about triggers in this thread. Look at post #2 for some examples. If you want to continually check for a set of conditions to be true, a recurring trigger would likely be the best bet. I have to leave the house now, but I will post an example in a few hours.

      Thank you for your suggestion for using virtual device for lighting control, but I still think there should be an easier way to handle this type of event. HS3 should be able to process it from a single event.
      You might need a virtual device, but it also might work without one.
      Last edited by randy; January 23, 2015, 08:39 PM.
      HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

      Comment


        #18
        so, I change my event to the following still does not fire my action

        I might have to go into the virtual device route.
        Attached Files

        Comment


          #19
          That event will only trigger if sunrise and sunset occur at the same time which (hopefully) will never happen.

          Cheers
          Al
          HS 4.2.8.0: 2134 Devices 1252 Events
          Z-Wave 3.0.10.0: 133 Nodes on one Z-Net

          Comment


            #20
            This is interesting. Why there is no Day time or Night time option under the first IF statement. The Day or night time option only shown in the second IF statement.

            Comment


              #21
              Because the time being daytime or nighttime aren't specific instances in time. If you had a trigger for nighttime it would fire every second from the moment the sun set until the sun came up. Now, you could have "the sun sets" as a trigger for example.
              Originally posted by rprade
              There is no rhyme or reason to the anarchy a defective Z-Wave device can cause

              Comment


                #22
                Originally posted by sclin View Post
                This is interesting. Why there is no Day time or Night time option under the first IF statement. The Day or night time option only shown in the second IF statement.
                The first IF statement is a trigger. It's something that happens at a moment in time. If you were able to select daytime or nighttime there, then it would continually trigger during the day or the night. If you want the event to trigger on a regular basis, select the recurring trigger option with appropriate conditions (the AND IF statements). Something like:

                Click image for larger version

Name:	Capture.PNG
Views:	1
Size:	12.1 KB
ID:	1176100

                Cheers
                Al
                HS 4.2.8.0: 2134 Devices 1252 Events
                Z-Wave 3.0.10.0: 133 Nodes on one Z-Net

                Comment


                  #23
                  Originally posted by sclin View Post
                  My intend of the event is to use a virtual device (Alarm state arm or disarm) with time condition to do the following:

                  When I am away from my home and set my alarm system to away (arm) mode and when it's night time then I want to create some random lighting with Zwave light control.

                  When I disarm and it's night time then I want to turn off all the Zwave random light devices.

                  Please keep in mind if I set my alarm duringthe day time, I would still want to have random lighting in the night time; therefore, I use "Device value set to arm" instead of "Device has value has become to arm"

                  My posted example is a test event and the email action just help me to trouble shoot this test event. It seems to me my event requirements are pretty basic and HS 3 event engine should be able to do it.

                  Either the event engine has a bug or I misunderstand how the event engine works.
                  I'm a little late getting back to this, went to the movies with my daughter and son-in-law. You have already gotten some good suggestions, hopefully the following is very concise and will help you grasp the difference between a trigger and a condition as well as one way you could construct your event(s).

                  I think you only misunderstand the nature of a trigger. While there are a few triggers allowed that violate the basic rule of a trigger, a trigger is always supposed to be a one shot or as I like to refer to it "a moment in time". A trigger should never be constantly true, so the best ones are based upon the change in value of a device to a specific value or a timer or counter becoming a specific value or a time of day. Here is an example of an event based upon a recurring trigger that would work.



                  Just to quickly explain the logic: Once every 5 minutes the event looks at three conditions 1) is the alarm armed, 2) is it nighttime and 3) is the virtual device controlling random lighting off. If all three conditions are met, the event will run. The value of the Random Lighting device is used to keep the event from running once every 5 minutes when it is night and the alarm is armed. The action of the event turns on the virtual device, beginning the random lighting sequence. Once the device is on, its condition becomes false and the event will no longer run. I don't know how you plan on randomizing your lights, but you would use this virtual device to control your random lighting program.


                  The event to turn the random lighting off would be the opposite.





                  The logic would be that if it either becomes daytime -or- you disarm the alarm, the Random Lighting virtual device would be turned off. Again you use the value of a device changed by the event to prevent repetitive running of the event.


                  Here is an example of an event that would directly control a single light.




                  You could even include a Random Lights virtual device as a condition in all of the events to enable/disable random lighting.





                  This event could be repeated for several different lights, each one with a different value for the recurring trigger timing and the amount of time the light stays on and each one controlling a different light. This event would also stop randomizing lights after sunrise, once the final Delayed Device action runs and turns the last light off.

                  Just use the "Copy Event" icon





                  to create an exact duplicate of the event with "- Copy" appended to the event name.






                  Then edit the name of the copied event, edit the controlled devices, the recurring trigger time, the limiting condition device and the Delayed Device action timing turning the light off. Note the timing of the Delayed Device action would make it skip every other Recurring Trigger because the light would still be on when it came around again.





                  You could do this several more times to create a group of random lighting events.
                  Last edited by randy; January 23, 2015, 09:26 PM.
                  HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                  Comment


                    #24
                    Originally posted by rprade View Post
                    hopefully the following is very concise and will help you grasp the difference between a trigger and a condition as well as one way you could construct your event(s).

                    Damn!
                    Originally posted by rprade
                    There is no rhyme or reason to the anarchy a defective Z-Wave device can cause

                    Comment


                      #25
                      Originally posted by S-F View Post
                      Damn!
                      Thats what I said when I set out to create the post. You know me, why use 5 words when 100 would do just as well
                      Last edited by randy; January 24, 2015, 01:55 PM.
                      HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                      Comment


                        #26
                        As you say a trigger is a "moment in time". I am struggling with more ways to express this to people. Honestly I wish that more people would look at your event clinic threads. For me, the event creation process became clear after a few days, for whatever reasons. But I do completely see how this can trip people up. If you just think of a pile of things you want to be true for an event to fire you will overlook the trigger. I think that the way things currently work is pretty sensible and I for one can't suggest a better way.

                        With Vera (which has absolutely no conditional logic for creating "scenes", otherwise known as events) you need to use a plugin if you need conditions. It involves learning a rudimentary scripting language and is really a PITA compared to HS. BUT. It has a "NOW" function which is evaluated once per minute, which is handy. I have a few events which I have set to run every minute and not to be logged. They are for checking the status of personal phone presence in order to flip a virtual switch.

                        It seems to me that many people who stumble with the trigger Vs. condition scenario are expecting the trigger to act like the Vera "NOW". Let's just cut to the chase and call a spade a spade. If it's something that can "trigger" something then it's a trigger. Otherwise it's a condition.

                        The key is to think with discipline about what's happening with the event creation engine.
                        Originally posted by rprade
                        There is no rhyme or reason to the anarchy a defective Z-Wave device can cause

                        Comment


                          #27
                          Originally posted by S-F View Post
                          As you say a trigger is a "moment in time". I am struggling with more ways to express this to people. Honestly I wish that more people would look at your event clinic threads. For me, the event creation process became clear after a few days, for whatever reasons. But I do completely see how this can trip people up. If you just think of a pile of things you want to be true for an event to fire you will overlook the trigger. I think that the way things currently work is pretty sensible and I for one can't suggest a better way.
                          I agree. The logic in the event engine is very clear to me and was within just a few days of starting with HomeSeer. I also have purposely taken the position that I want to do everything possible without scripting. That was HomeSeer's goal in the design of the HS3 event engine. That is also why I offered to create the threads and Mark created the Event Clinic forum. I wish I could come up with better descriptions to help people see the logic more clearly.

                          I also think the concept of a "trigger" is the crucial element of this understanding. It is easy to see that I want my lights on at night when I come home and that the trigger would be my coming home and the condition would be that it was nighttime. Unfortunately if I come home in the daytime, but want the lights on when I AM home at night, the trigger no longer works. That is why I would urge everyone to look at all of the goals of an event structure as well as the elements of an event in their entirety, before deciding on an appropriate trigger or triggers. I would also urge everyone to throw away their desire to consolidate too many different things into a single event. Creating several small concise and aptly named events is much easier to understand, manage and control.
                          HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon

                          Comment


                            #28
                            Thank you everyone for the suggestion and explanation. I was confused about the how event engine handle the trigger and condition. I hope Homeseer can update the online documentation, so other user can better understand how to properly design their own event. Also, changing the UI text would clear up trigger vs condition confusion.

                            Comment

                            Working...
                            X