DooMotion Dusk/Dawn and Motion w/HSM100

[Cheat]

Greetings All,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" /><o></o>
<o></o>
I'm using:<o></o>
- Several HSM100's<o></o>
- All Z-wave devices<o></o>
<o></o>
I've setup all my HSM100's with additional shadow/virtual devices in order to get them to work correctly with HS.<o></o>
<o></o>
I purchased DM in hopes that it would simplify the events that I would have to create; however, I'm finding that after creating the virtual devices things don't seem to be much different than if I had just used the HSM100 w/triggers changing from "no motion/motion".<o></o>
<o></o>
For example:<o></o>
- Two story family room w/six windows, plenty of sun light<o></o>
- HSM100's set to send no motion/vacant at 30
- Do NOT want lights on when luminance is > 67%<o></o>
<o></o>
Now consider:<o></o>
1.) Time is: day and Luminance is: 95% (9500)<o></o>
2.) At least one family member and/or your pets are in and out of this room several times every 30 minutes.
Therefore, motion sensors will stay in a constant state of occupied/motion.<o></o>
3.) Condition that luminance is 0...6700 (below 67%) to be on; the lights are NOT on because current level is greater.<o></o>
4.) Dusk is approaching. The motion sensor in step 2 has remained occupied/motion and will continue to be so until late evening.<o></o>
5.) Luminance is now 34% (3400) the motion sensors still indicate occupied/motion; however, the lights never come on...<o></o>
<o></o>
I think this is because DooMotion never re-evaluates the event until the motion sensor sends a "motion/no motion" and in our active home this may not happen until bed time... so much for HA.<o></o>
<o></o>
I started thinking maybe DooMotion was not considering light changes because a dusk/dawn was not directly configured with DM. Therefore, I've attempted to configure the HSM100's luminance as a DooMotion dusk/dawn device. I've attempted this directly and also using a virtual device pointing back to the actual HSM100 luminance device and using the trigger code of the actual device in the virtual device. I've also followed some of Mr. DooLittle's suggestions on VALUE<X, VALUE>X, VALUE=X (using both 67 and 6700 to represent 67%); however, these don't seem to work. Status page for device remains Unknown.<o></o>
<o></o>
Anyway, I'm to the point of having four (4) events for each light.<o></o>
1.) Device Value Change<o></o>
Lights ON - HSM100 Luminance<6700<o></o>
Condition of motion on HSM100 (actual device)<o></o>
2.) Device Value Change<o></o>
Lights OFF - HSM100 Luminance>7000<o></o>
3.) DooMotion Trigger<o></o>
Lights ON - DooMotion V-Motion - Motion Detected<o></o>
Condition of HSM100 (actual device) Luminance<6700<o></o>
4.) DooMotion Trigger<o></o>
Lights OFF - DooMotion V-Motion - No Motion Detected<o></o>
<o></o>
I would have thought that DooMotion could have handled all of this, at least in two events.
Am I missing something here or does everyone have to create at least four (4) events for every light they want to control?

Any thoughts/suggestions welcome...<o></o>
<o></o>
If I'm hitting the pipe and being stupid, please correct me <o></o>
<o></o>
Thanks,<o></o>
- Chad<o></o>
<o></o>

[heatvent]

Chad, not sure this helps but here is how I use DooMotion for lighting control. I have my motion detectors (Insteon) set to send the off command after 1 minute and setup occupancy sensors for each room with various OET times for each motion sensor depending on how frequent the room is used. When occupied ON is triggered, DM checks if the light in the room is already on and if not it turns it on. When occupied OFF is triggered, DM checks if the light is on and turns it off. I did it this way so that DM wouldn't have to check if the light is on/off every time motion goes off.

You could do a dual layer approach where the motion sensor continuously evaluates the ON (i.e. checks luminescence and if below 67% turns on the light) and have an occupancy sensor turn off the light after the OET time has elapsed. This way the sensor will continue to trigger a check of the current luminescence.

As far as DM goes as a plugin, no I don't think it will do anything that couldn't be done with events. But it is a lot neater and easier to maintain that 2-4 events per motion detector.

ADDED: BTW, as I noted above, I always have DM test the status of the light before turning on/off. I don't know if this is common practice but I think it alleviates additional traffic on the network when it is not necessary.

[Cheat]

Hey HeatVent,<?xml:namespace prefix = o ns = "urn:schemas-microsoft-comfficeffice" /><o></o>
<o></o>
Thanks for the reply...<o></o>
<o></o>
When I bought my motion sensors I did consider the Insteon version and liked the idea of a 9v vs the dbl A's that are in the HSM100's. Currently, my HSM100 wakeup every 30 mins for status and/or when it detects motion. From what I understand in the HSM100 documents and the forum is only one "motion" is sent when it first detects motion. Another "motion" message is not sent until it has sent a "no motion", which then completes that cycle. This is a feature to save on battery life and network traffic.<o></o>
<o></o>
I also went the HSM100 route to keep a pure Z-Wave environment. I'm not sure what it takes to saturate the bandwidth of a mesh z-wave environment and/or the plug-ins within HS. For now I think I'm ok if DM is being tasked with checks; HS is running on a Quad 1.3G box.<o></o>
<o></o>
With current setting of 30 mins my battery life is around 3 months; starting to wish these had 9v batteries. I'm hearing on the board, if I drop to 6 min wakeups my battery life can be as little as 2 months; sort of painful on buying/stocking/replacing batteries across 10 of these devices.<o></o>
<o></o>
I'm still new to the HA stuff and trying to learn the pros/cons and do/don't. I'll consider trying the lowest cycle time, which I think is 6 minutes to see how that works.<o></o>
<o></o>
Was just hoping the technology was built into DM to recall a motion was in an X state and to retest conditions every X mins. Might need to put in a DM feature request. :: shrug ::<o></o>
<o></o>
Thanks for your time and suggestions.<o></o>
<o></o>
- Chad<o></o>

[heatvent]

Another option is did you setup your dawn/dusk sensors in DM? If so, you could have the DD sensor trigger to check if the motion sensor is currently in motion mode and if so turn on the light. This way you could stay with you current setup. Now this kind of gets back to you need multiple events to make this happen but I think it's because you have multiple triggers for a light to go on. The only other thing I can think of is a while loop in the CAC code. But can't say what this will do to your system to have constant evaluation of a condition.

Not sure if you looked at this but DM has a fail safe time on motion sensors to send an off after X minutes if not already received. You probably want this to be blank for your motion sensors.

[Cheat]

Yes, I've tried going into DM, selecting the device, and configure as a Dusk/Dawn device. The problem then becomes DM states "Darkness Detected" 24/7; however, prior to selecting Dusk/Dawn the HSM100 Luminance reported the brightness level at 95% (pretty bright).

This is where I attempted using Mr. DooLittle's suggestion of creating a virtual device, followed by pointing the virtual to the trigger code of the actual device, followed by configuring the virtual as the dusk/dawn, followed by entering the VALUE's that would be considered bright/dark. I've tried using VALUE<67, VALUE>67, VALUE<6700, VALUE>6700, and vis versa, for each, to indicate bright/dark. Neither setting appears to change DM from reporting "Darkness Detected".

Something appears to be really messed up between DooMotion and HomeSeer and/or maybe DooMotion was created specifically for the older x10 technology. It shouldn't have to be this difficult :: shrug ::

Mr. DooLittle mentioned that he keeps the DM plug-in in sync with HS releases; however, the version of DM on the HS updater is older than the version on the doosoft site. Maybe the version on the doosoft site (2.4.0.0, 4.96M, 5,206,708b) is more of a beta and the version on the updater (2.3.5.0, UNK Size) is supposed to be more of an approved stable version. However, I've tried both and they both seem to have real issues that require work arounds... but for some reason, I can't seem to find my 2.3.5.0 download.

Just curious, if anyone knows the size of the 2.3.5.0 version I'd like to compare if version numbers are simply changing to keep the numbers in sync or if the actual size of the file is changing to accommodate for HS and/or DM feature changes/fixes.

I'm not having any issues with the multiple events to turn the lights on/off. It just seems to be overkill. Maybe I was expecting DM to be more advanced in the area of simply handling a light, motion, and luminance... together.

- Chad

[manxam]

Having just gone through this myself (my thread is just below yours) I used a virtual device triggered by the HSM100 light sensor device:

ON (darkness) Value<3000
OFF (light) Value>=3000
UNKNOWN>10000

and it works perfectly.

as a note, if you don't specify an "unknown" then Doomotion will always show darkness.

[Cheat]

Manxam,

Thanks for the suggestion...

Since the HSM100 can actually provide a valid status of 0 and 100 I did my values a little different.

Status Value
ON: VALUE>=0<6700
OFF: VALUE>=6700
UNKNOWN: VALUE<0

So far, this is the closest I've been to having the Luminance portion actually display a value for the virual lum devices. Currently it displays "Darkness Detected"; however, the current value sent by the device is 5800... so, it would make sense.

Even though I'm tired, I had to test...
I tested it by changing the 6700 to 4000 and triggered the HSM100 by using it's wakeup button. It sent status information to HS and DM detected it as... "Light Detected".

Very cool

Now, when I get some more time...
I'll rewrite my DM Events to see if they work any better.

I don't think theres many more things that really burn my butt than to dump alot of money into some thing and then not have it work.

Thank you all for taking the time to read and make suggestions.

- Chad

[Jim Doolittle]

...Mr. DooLittle mentioned that he keeps the DM plug-in in sync with HS releases; however, the version of DM on the HS updater is older than the version on the doosoft site. Maybe the version on the doosoft site (2.4.0.0, 4.96M, 5,206,708b) is more of a beta and the version on the updater (2.3.5.0, UNK Size) is supposed to be more of an approved stable version...

No, I failed to "update the Updater". DM 2.4. from my site should be stable and was changed for HS 2.4.

The real issue is my understanding of what I can do to support HSM100 devices. DM is "X10-centric" but only because HS started that way. That is the reason the use of status/value relationships to account for devices that deviate from the original status/value of the old-X10 devices. For some reason HSM100 devices seem to have some other facet that I need to understand to make them work well with DM.

I think we will find that the biggest benefit of getting the HSM100s working with DM is the ability to assign them as one of several motion sensors assigned to an occupancty sensor.