Just an observation in case it will keep someone else from pulling their hair out (some of us cant spare it, lol) in UI4 if you do a “save” while a motion sensor is tripped it will reload the page with the “untripped” image even if sensor has not reset yet, then when you try to trip the sensor it will seem like it’s not responding when in fact it simply hasnt reset yet from the original motion, example: say you have sensor setup to reset after 20 min (the default in this case) of no motion you trip the sensor (image turns red for motion detected) then do a save, the image turns blue as if it has reset, now you are trying to test your sensor and it seems to be not responding, you have to wait out the 20 min without any motion in its range before it will show tripped again, if you keep trying to trip it (as i did) during this time it will keep starting over at 20 min and you might think your sensor is unresponsive
Makes perfect sense (after you find it!) ;D
After a year with Vera, I have much less to spare. :-\
I ran into the same thing. Once I understood how it worked though, it made sense. It was just not obvious and the UI4 dialogs and terminology didn’t help things. I think the keys to quickly understanding the HSM100 3-in-1’s are these concepts:
Motion
1] The motion sensor has two basic states Tripped and Not-Tripped - you can tell in UI4 which state it is in by the person icon, if it is a standing person then it is in “Not-tripped” and if it is a running person then it is in “Tripped” state. In iVera on iPhone it’s a little different: The word Tripped is the indicator, and if it is all grey then it is “Not-Tripped” and if it is red colored then it is “Tripped”
2] When it is tripped it will generate an event, and when it switches back to not-tripped it also generates an event - both of which you can set scenes for to turn on and then off lights etc in reaction to these events
3] You can set the amount of “still” time with no motion detected that it takes the sensor to switch from Tripped back to Not-Tripped. It defaults to 20min so the sensor will generate a not-tripped event after it detects 20min of stillness/no-motion. You can change this in the 3-in-1 device (not the motion device) settings under Device Options, Variable 2 (on time) in minutes.
4] While the sensor is in the “Tripped” state, it will not continue to fire off motion events (unless you custom configure it to do so continually)
5] The sensor has a special “test” mode (hitting the zwave button once) that lasts for 10min
6] You (or Vera) can communicate with the sensor directly to configure user parameters etc -only- while it is in test mode
7] The “motion” LED only lights up in response to constant motion while it is in the “Test” mode (for 10min) after which it only lights briefly when Tripped is fired off
8] When configuring an event for the motion sensor in UI4, the event parameter “Tripped?” is where you designate whether you are acting upon the Tripped state event or the Not-Tripped (aka idle or still) state from the sensor. In my opinion this should be called “State=” and the value options should be “Motion” and “Still”
also the manual that comes with the homeseer branded version of HSM100 isn’t very thorough. The express controls manual is much better and more complete http://www.expresscontrols.com/pdf/EZMotionOwnerManual.pdf
Light Level and Temp
1] To conserve battery these will not generate events when they change
2] They will report back their values to Vera periodically based on the sensor’s wakeup variable value (in seconds). It defaults to 1800 (every 30min) but you can change to shorter or longer values - just remember that the more often it sends updates to Vera the more battery it will use.
3] You may create scenes to react to the Light and Temp value changes, just remember that the scenes will be able to check and react to the values as only often as what the wakeup value is configured for.
That was a GREAT explanation from santakrooz. It really helped me when setting up this Motion Detector. There is still one thing that I don’t understand yet.
How does the “Wake-Up” time for the 3-1 Sensor,Temperature,Motion,Light relate to each other ? Can they all be set at different times ? What effect would there be if the 3-1 Sensor wake Up was longer or shorter time than say the Motion Detector Wake up time ?
I’m trying to understand this and have been struggling.
One more thing is how do I see the battery level ? Is it the battery Icon that changes ?
Running Vera 2 .1036
Thanks
it’s a good question and I asked it recently but no one seems to have an answer< since there is a field for setting that parameter in all three “sub devices” one would think they could be set independantly but from observation I dont think this is true, it seems to me that the setting in the “parent” device (3in1 sensor) is the one all others are controlled by
re: battery level: Some posters report that the battery level icon accurately portrays their battery levels. I have 3 of these little 3-in-1 monsters and none of them update battery level - either numerically in the advanced tab or visually on the battery icon. The number stays the same from the time the device is first configured. Of course this prevents them from sending a low battery notification before the batteries die. This is a major PITA for me, and I’ve reported it here many times in the past.
I have 7 of these and have the same experience as Ranch re: battery levels, on a broader subject there is still something fundamentally incorrect about the way these sensors work with Vera, I can’t blame vera offhand because I do not have this problem with my other battery sensor (Hm-TS001 temp/humid sensor) which maintains it’s list of neighbors and updates reliably, but the 3in1 sensors loose their neighbor list within a week or 2 of being added to network and updates from the light/temp readings become unreliable, one of the many mysteries is that the motion portion seems to still respond reliably (with rare exceptions), it may be a deficiency in the way the sensor records it’s neighbors or a combination between vera and the sensor, i dont have the technical knowlege to dope it out but it can drive ya crazy
I have 7 of these and have the same experience as Ranch … on a broader subject there is still something fundamentally incorrect about the way these sensors work with Vera, … 3in1 sensors loose their neighbor list within a week or 2 of being added to network and updates from the light/temp readings become unreliable, one of the many mysteries is that the motion portion seems to still respond reliably (with rare exceptions), it may be a deficiency in the way the sensor records it’s neighbors or a combination between vera and the sensor, i dont have the technical knowlege to dope it out but it can drive ya crazy
[/quote]
Ain’t that the truth!!
Same problem. They work for a few days and then you find yourself reconfiguring them/power cycling then, etc just to get back to where you were.
I have 5 which I have converted to mains powered in order to run them permanently awake.
They seem like such a nice product. It’s seriously annoying!
Please MCV - put us out of our misery and look into this.
what’s weird about this (sensors not reporting light/temp) is that it may hit all of the 3-in-1’s at once or randomly claim them 1 by 1, I have seen both, or maybe just 1 stops reporting and the others are ok for weeks, in any case I was experimenting to see if I could get a sensor name change to stick (because some are reporting that 3-in-1’s will revert back to their default name if changed), using a non reporting sensor, and the dashboard reported (below that sensor) “name change failed”, having recently added power cycle on demand capability I cycled and when it booted up the message changed to “waiting for wakeup to configure” and lo and behold the name did stick and the sensor started reporting light/temp again, I was never able to get a stuck sensor started remotely before (whoohoo!) always having to get onsite and reconfigure, though I dont think I ever tried to cure it with a simple power cycle.
have others restored these to function by simply power cycling? or did the name change force a reconfiguration as I noticed a number of neighbors (some innapropriate) present just prior to the change were removed leaving just one (appropriate) neighbor. Weird science my brothers 
After more wasted hours than I care to think about, I finally gave up trying to make these sensors work by using the “tripped” and “not tripped” event triggers in my HVAC application. There’s something wrong with Vera’s or the 3in1’s logic.
However, there is an option to set parameter 2 to zero which is in essence a “manual mode” whereby the sensor triggers an event every time it detects movement and you have to undertake a reset to the “not tripped” state according to your needs.
I should say at this point that this setting is not compatible with battery power so a conversion to mains power is a prerequisite. (I used a high frequency switching supply but I have since been told that a standard USB supply will work just as well).
All the logic now has to be written in Luup/Lua. As a novice coder, my code is not very elegant and it took some time to get it working but it now functions perfectly.
Terencec, I’m not familiar with the battery level or neighbor list issues you guys are having. Mine haven’t displayed any of those problems.
However, I am curious what you had trouble accomplishing with the event triggers in your application. The 3-in-1’s logic isn’t very obvious but I haven’t found it to fail. I’d be interested in trying to figure out how get it to work using the triggers.
santakrooz
I am using the sensors to trigger a scene to raise room temperature (typically from 18C to 21C) when someone enters as an energy saving exercise. When the person leaves the room it lowers the temp when there has been no movement for 15 minutes.
My main problem was that the sensors would work fine for a while and then simply stop responding. The leds never failed to flicker but the associated scene would stop firing. I could wave as much as I liked but the icon stayed blue. I tried everything from power cycling the sensor, reconfiguring it, excluding and re-including it and even rigging the "Tripped"and “Status” variables via the GUI. All to no avail (never did manage to work out the logic for these variables and why they sometimes differed between the parent and child devices).
Have since read a thread about the short up times of 1.1.1047. My Vera2 is proving to be unstable and may well be rebooting frequently too. It’s just possible (although I have no clear proof) that the reboot is sometimes leaving the Vera in an incorrect state relative to the sensors.
As now set up, the sensor trips every time it detects movement. This is used to refresh a timer which otherwise expires after 15 minutes. The sensor is then reset to “not tripped” state from a scene (using variable_set). With the new configuration, even if there is a reboot, the system will eventually correct itself. So that’s part of my problem solved but I’ll have to wait for MVC to deliver on the new release to overcome my rebooting issue.
As to the battery issue, there’s no problem from an operational perspective. It’s just that their life will be measured in days if parameter 2 is set to zero and (as is required for this set up) the “stay awake” parameter is set.
Interesting. Roughly how long did the scenes work for and roughly how many cycles before they stopped working?
Sorry I’ve not been on this thread for a bit.
Answer is from a few hours to a few days. That said, it may well be that this problem has gone away with the 1083 FW release. I can’t tell as the actions I took overcame my sensor problems before this upgrade.
Is it possible to change the “Still Time”/“On Time” when motion is detected as part of a script? I am thinking of using this to let me know when my son gets out of bed in the evening. The only thing I’m stuck on is the time before the unit will watch for motion again. Since he’s more prone to get out of bed (again) in the first few moments after motion stops, I’d like to have the unit begin notifying on motion again 1-2 minutes after motion ceases. At a certain time in the evening, I’d want to programmatically switch back to the default value (25 min?) to conserve battery.
Thx,
Brian
I haven’t installed one yet, but thank you for the heads up. It will save me a lot of grief! 
I'd want to programmatically switch back to the default value (25 min?) to conserve battery.
http://wiki.micasaverde.com/index.php/Luup_Scenes_Events#Set_Z-Wave_parameters
… but please note that the HSM100 must be listening to Vera, so there is a delay of less than or equal to the wakeup interval until the new settings take effect.
After trying to troubleshoot issues with these 3in1s with @flyboybob and reading issues that others have/had even after upgrading to 1.1.1245 my attention was drawn to this thread today and i thought it wise to bump the topic.
All who experience issues with the HM100, read the thread and maybe (partially) solve your issues.
Dont forget to provide feedback here!