Slow HS response to HSM100 events

[Mark42]

Cross posting here from Hometroller hoping for some feedback.

I have an HSM100 in a stairway to the basement and another HSM100 in the basement itself. Each device has its own Device Value Change event to turn on the basement overhead light. Turning the corner to walk down the steps is normally enough to set off the first HSM100 and turn on the light within 1 second.

Occasionally, it can take 10-30 seconds for the light to come on, yet a hour later it will be back to 1 second. When examining the log file, I normally see the Temperature and Light reports for the triggered HSM100 followed by the Overhead Light ON entry followed by the Temp and Light entry for the 2nd HSM100 as I enter the basement.

Last night, I walked down the stair and into the basement (in complete darkness) and the light finally came on after 20-30 seconds. On examining the log file, there were no entries for either HSM100, just the entry for the Overhead Light ON event. There were no corresponding entries in the Windows Envent Viewer so it doesnt look there was any sort of OS issue. The HT2 was restarted < 36 hours earlier.

This morning the light came on in < 1 second and the expected log entries were present.

I know others have reported similiar problems, but I wonder if they also had missing log entries? Under what circumstances would HS correctly detect Motion and fire the event but fail to make a log entries for the HSM100? Perhaps this is a hint as to why the event takes so long to fire.

Best Regards,

Mark

[dmurrle]

I can see 2 reasons for that. The first one is that your modules are not very close from the z-troller and your network needs to be optimized or that you need more modules in the path of your hsm100 to get your mesh more reliable.

Also the HSM100 will stay awake about 2.5 seconds when it detects a motion to
1- report the motion to the device
2- being polled for light level, temperature, battery level

Sometimes the software (for different reasons) is not fast enough to poll the HSM100 and the HSM100 go to sleep before being polled. When the software request for the temperature, if the HSM100 is already asleep it will not receive the request. The software will wait extra seconds (timeout) and go to the next steps after that. - light level, temperature, battery -. Once the work on the HSM100 is done, then your switch will be send an order to turn ON. Also if in the same time there is other z-wave events happening in your house that's also extra seconds lost. Everything added would explain this 30 seconds delay... On my side the mesh network is dense and all the lights power on in less than a second when I enter in a room (it is possible with some work). Some rooms you will have to add more than one HSM100 to catch all the angles in ther room.

What you can do on your side is to densify your mesh with more device and be sure your network is "healty"

I would say that the HSM100 is from far the best z-wave device on the market but if it could stay awake a little bit longer to prevent transmission delay, that would be nice For sure that will use more battery so an optional integrated 5V power would be required...

[BootsC5]

I've seen the slow response as well. I never tried to watch the log on real time as I tripped the sensor. Next time my set up gets into that state I'll take a look.

Running ZHealth regularly has greatly improved my latency times, and some times it seems if you unplug the ztroller for a few minutes it also helps (items in a queue either on the hardware device or software finally get removed).

[Mark42]

Thanks for the replies.

Just so I'm clear, it sounds like when the HSM100 detects motion under normal circumstances:
1. HSM100 detects motion
2. HSM100 wakes up and sends a motion detected msg to Z-Troller/HS, the HSM100 will stay awake for 2.5 seconds.
3. HS polls HSM100 for temperature, light level, and batt level; this must complete with the 2.5 second window the HSM100 is awake.
4. After step 3 is complete or timed out, HS will fire the HSM100 Device Value Change event and turn the light On.

The working hypothesis is then that there is more than 2.5 seconds from the start of Step 2 to the start of Step 3. In this case, HS will poll, and get no response since the HSM100 has gone back to sleep. After all the retries have been exhausted, HS finally fires the Device Value Change event based on the original motion detected msg from Step 2. The sum of 2.5 seconds and all the retries/timeouts would then add up to the large delay time observed and possibly explain why there was no Light Level and temperature information in the log.

I have only observed this maybe 3-4 times in as many months, normally its <1 second. The HSM100 is no more than 20-25 feet from the Z-Troller with other nodes in-between. The network seems fine.

I know HS logs communication failures to 'regular' Z-Wave devices. I would have thought if there had been a failure to retrieve the information from the HSM100 within the 2.5 second window, HS would have logged this?

I wonder if the same mechanism is used for HRDS1 devices?

Mark

[BootsC5]

If that is the case, an option to toggle the polling on motion would help the perceived slow down on motion.

I have the HSMs report every 18 minutes, I don't need to get an update on motion.