Announcement

Collapse
No announcement yet.

Light automation advice

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

  • Light automation advice

    I've had my setup up and running for a couple of months now and I was hoping by fiddling about with my light automation I could eliminate the delay I'm experiencing.

    Below is an image of my events and my aeotec Multisensor parameter configuration.

    I would appreciate it if someone could take a look and see if there's an issue with my logic or if its just an rf interference or process delay.

    I read you can link devices to remove a communication delay but with the events I have set I'm unsure as to how that would work.
    Attached Files

  • #2
    Where are you seeing the delay? What is the purpose of the parameter change like that? Aeotec devices seem to always be a little slower when configuring compared to others, but I would imagine that many changes is going to cause a delay.

    Comment


    • #3
      Sorry I ment to add specifics. The motion and event timing in the log is correct and occur at the same second yet the actual turning on of the light is sometimes spot on but mostly 2-3 second delay.

      The parameters are as follows

      Parameter 3 is the time in seconds that the sensor will report no motion after motion is detected so 10 is the lowest it will accept. I used to use this value to set the time my lights were on but decided to use a timer instead. I was hoping this would mean if someone walked past during that time it would reset the timer of 2 Minutes each time motion is detected. It sort of works but occasionally if I walk past just as the light goes off then it takes several motion changes to activate the event again. I've not analysed the log after this change yet.

      Parameter 4 is the sensitivity - motion detection range, 5 being the highest.

      Parameter 40 enables a threshold value for reporting, for example, if temperature changes by 1 degree then send a report.

      Parameter 41 is temperature report threshold

      Parameter 43 is luminescence report thresholds

      Parameter 46 enables a low temperature report when below -15 degrees.

      Parameter 101 is group report for battery and humidity

      Parameter 102 is group report for temperature

      Parameter 103 is group report for luminescence

      Parameter 111 is interval time in seconds for group report 1

      Parameter 112 is interval time in seconds for group report 2

      Parameter 113 is interval time in seconds for group report 3

      I can change which sensor reading is in each group by the value, this is just how I set it up so battery and humidity are not required regularly so I set them for the longest interval, temperature every hour and light for every half hour.

      Comment


      • #4
        Why are you setting the settings via an event instead of via the z-wave tab on the device? (just curious)

        Also note that the changing of the threshold for reporting of any of the sensors doesn't mean it will report when it hits that threshold. For instance, if Lux goes up 10 and your threshold is set to 5, it WON'T report immediately. What that setting does is tell it if it should report that value on it's next schedule report.

        If this is the Aeotec Multisensor 6, the most often it will report is 4 minutes. That means if your lux is 10 and your threshold is 5, it will only report on the next scheduled reporting if the new value is 15 or more (or 5 or less).

        I've requested that they add an option to send those reports when the threshold is met instead of waiting for the reporting time. I believe my fibaro does this and it's battery lasted almost 2 years. My Aeotec, with 2 twice the battery size of the fibaro doesn't last 6 months with a 4 minute reporting.

        I hope this helps in some way
        Thanks,
        Frank

        Comment


        • #5
          Thanks for your replies.

          I do it that way so I can quickly alter the parameters to suit and I just have to run the event manually, mainly because I was playing about alot and just found it easier.

          Ah I didn't realise that 4 mins was the most often although I don't require temperature and luminescence updates that often. I was trying to minimise zwave traffic by setting a threshold and an interval time thinking that traffic was interfering with the light timing. All my aeotecs are usb powered although it took great effort it was worth hiding all the wires in the walls to save me swapping batteries all the time. Also didn't realise the threshold report time you mention, good to know. It's a bit of a pain to analyse my logs as my tablet crashes when viewing them so I have to walk around with my laptop, need more time to try and nail it down.

          I do think there is some sort of interference with the data transmission as my entry Way sensor has the same line of sight as the hallway sensor yet the hallway Light will come on first despite being up the stairs. I'll try my best to describe it visually. As i exit my lounge I face my entry Way wall, to the right is my entrance door, to the left stairs. As I turn to face the stairs there is a section of wall to the left where my alarm panel is and above that my entry Way sensor. At the top of the stairs is my hallway sensor. What I'm getting at is both sensors are blind to me until I step into the entry way, and the entry Way should have a headstart on the hallway ( milliseconds probably) one due to the slight positional offset. This is not the case and the hallway will light up first. I've tried lowering the sensitivity of the hallway to avoid this data clash and it has improved somewhat.

          I'm aware radio frequencies don't always take the same path and even if a sensor is closer to the controller doesn't mean it is quicker. Alsomaybe my alarm is also interfering causing this delay but it would delay all the time not just occasionally.

          My raspberry pi with aeotec usb is in the lounge 2 metres from the entry way sensor.

          Comment


          • #6
            My experience with the multi sensors is they are slower to report vs other zwave motions (ecolink is the best I have found), and just the inherent nature of battery motions, they have to wake and send). That being said, I still have over a dozen of them running in the house, but I am slowly going to start changing them out for wired PIR from my alarm system.

            Comment


            • #7
              How long is the delay? Z-wave only does 1 device at a time and waits for a confirmation (I believe). It could be that HS does that, but I really think it's a z-wave thing (Unless you use all on/all off, which i believe is network wide). I have events that turn off whole rooms and you can see each light/device turning off one at a time.
              Thanks,
              Frank

              Comment


              • #8
                Originally posted by sirmeili View Post
                How long is the delay? Z-wave only does 1 device at a time and waits for a confirmation (I believe). It could be that HS does that, but I really think it's a z-wave thing (Unless you use all on/all off, which i believe is network wide). I have events that turn off whole rooms and you can see each light/device turning off one at a time.
                Nevermind.....I need to work on my reading comprehension.


                So, I don't use timers like that. I actually use virtual devices for determining "occupancy". For instance in my guest bathroom, the motion sensor will turn on the Occupancy device to Occupied if it there is motion for more than 10 seconds (the aeotec on mine has a 10 second timeout, which isn't accurate, likely due to network traffic). Then, I have rules for setting it as unoccupied. One rule is that there is no motion for 10 minutes (Our daughter will go in and out of the room while getting ready) and that the door is open. Once that happens, there is an event that sets the Occupied device to "unoccupied" and that triggers the lights to turn off.

                This way, there is a not a direct tie to the motion sensor. I've done this with all my z-wave motion sensors even if the time between no motion and unoccupied being set is only seconds. This way there is time for a motion to come back in and prevent the occupied device. from switching to unoccupied.
                Thanks,
                Frank

                Comment


                • #9
                  Originally posted by waynehead99 View Post
                  My experience with the multi sensors is they are slower to report vs other zwave motions (ecolink is the best I have found), and just the inherent nature of battery motions, they have to wake and send). That being said, I still have over a dozen of them running in the house, but I am slowly going to start changing them out for wired PIR from my alarm system.
                  Yeah that's why I went wired this time. I used to use smartthings and their battery operated sensors and they would sometimes not work at all, although I did get a slight delay from time to time it was less frequent than now. That was cloud based so I considered that a factor. I moved on as the creator of rule Machine which turned smartthings terrible platform into a work of art pulled his support and I could see the writing on the wall. One update away from making rule Machine unusable so I got rid.


                  The delay is about 1-2 seconds. I know my positioning of the sensors isn't ideal but that was the only plausible way of wiring them in and hiding wires plus aesthetical reasons. I have an event for each light individually on and off. I only automate my entry Way, hallway and bedroom. Each only have one lifx bulb. I was hoping wired in would eliminate the delay. Just find it a little frustrating after forking out again to eradicate the previous systems annoyances.

                  Comment


                  • #10
                    here are my WIAB (Wasp In A Box) events for my guest bathroom. Not that in this case, they are not foolproof. I do get some false triggers, but they should not affect your use case. That other benefit to this is I can define multiple ways to determine "occupancy" besides just motion and have the lights react the same way in all instances.

                    As you can see here, there is a 1 minute timeout from when there is no motion to it being set as unoccupied. Then there is 10 minutes to turn it off. You could just change that to 1 minute and keep your 2 minute timeout.

                    let me know if you have any questions.
                    Attached Files
                    Thanks,
                    Frank

                    Comment


                    • #11
                      Originally posted by sirmeili View Post
                      Nevermind.....I need to work on my reading comprehension.


                      So, I don't use timers like that. I actually use virtual devices for determining "occupancy". For instance in my guest bathroom, the motion sensor will turn on the Occupancy device to Occupied if it there is motion for more than 10 seconds (the aeotec on mine has a 10 second timeout, which isn't accurate, likely due to network traffic). Then, I have rules for setting it as unoccupied. One rule is that there is no motion for 10 minutes (Our daughter will go in and out of the room while getting ready) and that the door is open. Once that happens, there is an event that sets the Occupied device to "unoccupied" and that triggers the lights to turn off.

                      This way, there is a not a direct tie to the motion sensor. I've done this with all my z-wave motion sensors even if the time between no motion and unoccupied being set is only seconds. This way there is time for a motion to come back in and prevent the occupied device. from switching to unoccupied.

                      Yeah this is my next step using a virtual device for occupancy, just putting the time in is hard at the moment. Should get some time this weekend maybe. Thanks for the template, saves me some head scratching!

                      Comment


                      • #12
                        Originally posted by Steaktastic87 View Post
                        Yeah that's why I went wired this time. I used to use smartthings and their battery operated sensors and they would sometimes not work at all, although I did get a slight delay from time to time it was less frequent than now. That was cloud based so I considered that a factor. I moved on as the creator of rule Machine which turned smartthings terrible platform into a work of art pulled his support and I could see the writing on the wall. One update away from making rule Machine unusable so I got rid.


                        The delay is about 1-2 seconds. I know my positioning of the sensors isn't ideal but that was the only plausible way of wiring them in and hiding wires plus aesthetical reasons. I have an event for each light individually on and off. I only automate my entry Way, hallway and bedroom. Each only have one lifx bulb. I was hoping wired in would eliminate the delay. Just find it a little frustrating after forking out again to eradicate the previous systems annoyances.
                        From what I understand, and what I will eventually move to, is to get an alarm panel (like a DSC) and use wired sensors. They are immediate. They have the added benefit of being quite a bit cheaper as well.
                        Thanks,
                        Frank

                        Comment


                        • #13
                          That's exactly what I had been looking into but they don't exist in the UK yet and I'm not a fan of the pir sensors that come with alarm systems, been looking for a more modern contemporary look like the aeotecs in the recessor. Nothing I've currently come across looks any different to the classic pir sensor.

                          EDIT - they do exist just not the touch panel I liked the look of

                          Comment


                          • #14
                            I have the DSC panel and went with the normal keypads (previous alarm had touch and it sucks if you need to type in the code quick to disable alarm). That being said, since I have it integrated with HS now, the keypads never even get touched anymore.

                            Comment


                            • #15
                              Originally posted by sirmeili View Post
                              From what I understand, and what I will eventually move to, is to get an alarm panel (like a DSC) and use wired sensors. They are immediate. They have the added benefit of being quite a bit cheaper as well.
                              Well, not quite immediate. Regular alarm zones typically need to be faulted for around 400ms before reporting. Some panels allow that to be configured shorter on some of the zones. I think it's up to 8 zones on the DSC. I went with Elk because they support fast loop response configuration on all zones allowing it to be as short as 10ms.

                              John

                              Comment

                              Working...
                              X