have you tried sandboxing with the new version? is it working with your scenario?
Rooms Manager: Smarter Rooms: Personalized home automation with Occupancy
I have a problem with one of my motion sensors stuck in âmotionâ. But even though it is stuck and registering motion, my lights are going off. My Basement Room is saying that it is vacant but if one of the motion sensors that it is subscribed to is reading motion, shouldnât it stay on?
when using devices it does not check state rather events. since your motion sensor is not generating motion events the lights are probably turning off. i think ⌠not run in to stuck motion sensor before.
It is strange because I am right in front of the motion sensor and it stays in motion which should be correct because I am working in front of it. However, I noticed that the Basement Room would change from âOccupiedâ to âVacantâ. There wasnât an âEngagedâ stage. Then the lights would just turn off when the Room went to âVacantâ. When I left the room, the motion sensor did detect no motion and the Basement Room went into âEngagedâ and then âVacantâ and then the lights turned off.
I had mixed results. So I went ahead and setup the sensor on the door. playing with the settings a bit. It seems to work best when I do not have the set immediately to vacant, and no motion timer on for engaged for some reason.
This may have to do with the motion sensor I am using it seems to have a 15 second reset after detecting motion to go back to inactive and depending on where it is in the active/not active state and when the door re-opens and when you walk out and close the door behind you it sometimes goes back to engaged and sometimes accurately goes to vacant as needed.
Not sure if there is some logic on your checking timer that could be tweaked to help with the multitude of sensors in the market. I have a mix, of aeon gen 5 multis, eco link motion, and monoprice multis zplus sensors. The gen5s with the dth I am using have a 15 second response the ecolinks are in test mode and have about 10 secs the monoprice are 20 seconds. So with zwave latency and sensor trip resets the checking portion of the room app might be benefited by either being configurable if possible by the user or I just need to finish setting up sensors and configure the adjacent rooms and setup the engaged status for all rooms not just select ones.
so that when they change they force the previous room to checking but in high traffic areas or shared rooms I could see this also causing problems because if you leave someone sitting at a table and walk out and into another and close the door it will force the other room to reset to vacant if they donât move within the current short checking interval. unless I am not understanding the logic.
this is often though not always the result of test settings. almost all motion sensors have a blind window for motion. some longer than others. when testing it folks tend to set to it 10, 20, 30 seconds for timeout settings and that ends up conflicting with the motion blind window. if set to some reasonable real life settings things usually work well because that avoids this sort of conflict. learnt that from personal experience.
the dim timer is used for the checking state. so if you set timeout to say couple of mins and dim timer to 30 seconds (double the blind time of the motion sensor) usually it works consistently 99% of the time in real world usage.
this helps with your next question as well where the dim timer can be setting for the room can be set to double the blind time of that motion sensor. doesnt need to be always double but always a bit higher.
yes you are right. but unless that motion requirement is there, in a situation where there is no one in the room it ends up keeping the lights on which folks dont like as well. but there is always the option of using a switch or a presence sensor to keep the room on. these are also in the engaged settings.
a quick note on occupied and engaged states. think of occupied as a transient state and engaged as a persistent state.
occupied is you go to a room are in there for a few minutes then leave the room. lights come on when you enter the room and turn off after a couple of minutes of your leaving the room.
engaged is when you stay in a room for an extended period of time and may be motionless for some or all of the time. since we cant depend on the motion event for engaged state there are different options to set the room to engaged for extended occupancy. these are all under engaged settings and there is more coming. but these help make sure the switches you set to on stay on even if there is no motion in the room.
when in engaged state you have a different and longer timeout state than the occupied state. so there is still a motion requirement but a much higher time threshold than transient occupied state.
happy to answer any questions.
The Dim timer is likely my missing piece. Since I was using webcore for the light rules I never configured the dim timer. I was not aware that is itâs purpose. Might want to add a blurb about that unless I missed it in all the posts. Will setup and see if it fixes my false positives and let you know.
thank you. yeah i was thinking the same as i read your post. probably going to create a vacant settings section and put it under there with some different text so its clear.
Ok, just in my basic quick tests I was running. I can tell you that eliminated all false positives in my testing routines. Leave it be for the next few days and will let you know how it works out. I am thinking this was my missing link.
One other note : the setting for adjacent rooms if motion then check the adjacent room for motion. Is this working properly?
I do not see it go into checking status when playing with this option and moving from room to room. - or does it only start the countdown interval for the âengagedâ motion config? What I expected is the dimmer (checking) motion config not the engaged motion config. Hopefully this makes sense.
The room configured if it goes engaged is working based on what I see and it appears to use the dimmer (checking) motion config. At least this is what I am seeing and why I thought the above.
Which is why I am asking about this.
are you using the latest code? see thread above this post. it seemed to be working:
when in engaged state it should use the motion timeout in engaged settings for the motion config and not the dimmer (checking) config.
I was not. missed the update somehow. I had the latest dth but the childapp was outdated. updated now will see how it goes.
thanks for sharing. there are 3 motion sensors. the code waits for the motion inactive event to trigger setting the room vacant timer. every time a new motion inactive event is received the room vacant timer is restarted.
little puzzled at why the light would be turning off. would you be able to share a little more details of the steps leading to the light getting turned off?
also could you please turn off the toggle to reset room from engaged directly move to vacant state and check if that makes a difference?
thanks.
OK, I changed the engaged directly move to vacant off. I will have to see what that does. What was happening is that I have three motion sensors in the basement rec room. One at the top of the stairs, one in the TV room and one in my office area. I was about a foot away from the motion sensor in my office and it was staying on âmotionâ. The other two were âNo Motionâ. However, the lights would turn off. It was like it was ignoring the one that was still in âMotionâ. And it seemed that because the one was in constant âMotionâ (it stayed in Motion I guess because I was right in front of it) that it was stuck but it wasnât because once I left the room the lights eventually went off. But the one that stayed in motion didnât have the usual âMotion has stoppedâ and âMotion Detectedâ in the Recently log. It just had âMotion Detectedâ until I left.
cool. ok.
got it. making a change that will hopefully address this constant motion scenario. should have it out tomorrow.
thanks for your patience.
UPDATE: updated version 0.08.3 to github with the following changes:
* Version: 0.08.3
*
* DONE: 12/12/2017
* 1) added support for wake and sleep times to calculate level and color temperature.
* 2) add support to process rules every 15 minutes so switches state/level/color temperature is updated.
* 3) fix for continuous motion with motion sensor.
if using âALâ (auto level) and also turn on auto color temperature control the settings curve looks like this:
where as if you use AL with out auto color temperature feature the auto leveling looks more like a triangle.
these are not static settings but are calculated based on the âALâ settings but the âwaveâ will kind of look like that based on those settings.