Motion Sensor Update

[Teken]

I have asked about this feature in the past but thought it worth while to affirm this request again. I would like to see the ISY support the ability to wake up the motion sensor by walking by. Have an option to select the MS of choice and have that unit update any new settings. Houselinc has supported this feature for ages and works great.

 

This is how I envision the system would operate in practice. If anyone has a more refined method please do add your idea's and support for this feature.

 

1. All MS units can be selected to be placed in a ready state for upload. A box or option to select the MS would be preferable.

2. The user would go to the MS in question and wake it up by what ever method of waving their hand or walking past it.

3. The user would then select the MS that is queued for upload and this would be with in the MS four minute window etc.

 

Having this feature would assist those who have MS units in areas that are hard to get to because of elevation or physical obstructions etc.

 

Teken . . .

[bleepblorp]

That would be an awesome feature for ISY. It is literally the only thing I miss about Houselinc.

[Teken]

That would be an awesome feature for ISY. It is literally the only thing I miss about Houselinc.

 

Its clear this task can be done with the MS. I am not sure what the barriers are for the ISY to complete this task. I have to gather its the lack of care from the masses or low ROI to implement this feature. If this is already on the list then great! If not lets put it on there!

 

Teken . . .

[TJF1960]

 I have to gather its the lack of care from the masses or low ROI to implement this feature.

I do not believe it is either one. As I recall from Michel postings on the subject that it has to do with not wanting the ISY to randomly "program" any devices. If they were to implement this feature you would have no exact control over the timing of when the MS received its programming. As it is now in order to program any device, MS or otherwise, it requires manual intervention so that you can make sure your Insteon network is "quiet" during the programming process.

 

I may be wrong but I thought I heard that HL removed that feature in one of their later releases.

[Teken]

 I have to gather its the lack of care from the masses or low ROI to implement this feature.

I do not believe it is either one. As I recall from Michel postings on the subject that it has to do with not wanting the ISY to randomly "program" any devices. If they were to implement this feature you would have no exact control over the timing of when the MS received its programming. As it is now in order to program any device, MS or otherwise, it requires manual intervention so that you can make sure your Insteon network is "quiet" during the programming process.

 

I may be wrong but I thought I heard that HL removed that feature in one of their later releases.

 

I believe my suggestion of having the power to select the MS and when the update would occur would take care of the above issue. It comes down to the logistics and the willingness to do this.

 

Teken . . .

[LeeG]

There are some technical differences between the HL world and the ISY world. HL assumes it is running 24/7. The Admin Console is not normally up 24/7. There is a command that stops the MS from sleeping. Once issued the update process must run to completion and another command issued to allow the MS to go back to sleep. If the Admin Console has an issue and cannot complete the process the MS will run down the battery quickly. Of course HL could have the same issue but it will continue to retry. The design of Admin Console is to queue the remaining items. Don't know if this is the issue that UDI is concerned about but Michel has been absolute indicating this cannot be implemented with the ISY/Admin Console.

[Michel Kohanim]

Hello everyone,

 

LeeG is 100% correct.

 

Teken, you already have that capability in the PRO. Just disable Automatic Write to Battery Operated devices, make your changes, walk in front of your MS, and then enable auto write. In all likelihood you can get a few commands in while the sensor is awake. This said, unlike programming mode, MS will not stay awake for 4 minutes when you walk past. So, you may end up with half programming. Of course, you can have someone dance in front of it till all the programming is done.

 

This is the reason that we do not wish to make this process automated. i.e. as long as you have PRO, you can do it through the Admin Console and the success rate of this approach is dependent on the level of dancing in front of it!

 

With kind regards,

Michel

[bleepblorp]

Thanks for the clarification on Automatic Write. I thought this feature didn't work. I now see I just didn't understand how it could be used. I will put on my dancing shoes and give a go.

 

Much appreciated!

[Teken]

Hello everyone,

 

LeeG is 100% correct.

 

Teken, you already have that capability in the PRO. Just disable Automatic Write to Battery Operated devices, make your changes, walk in front of your MS, and then enable auto write. In all likelihood you can get a few commands in while the sensor is awake. This said, unlike programming mode, MS will not stay awake for 4 minutes when you walk past. So, you may end up with half programming. Of course, you can have someone dance in front of it till all the programming is done.

 

This is the reason that we do not wish to make this process automated. i.e. as long as you have PRO, you can do it through the Admin Console and the success rate of this approach is dependent on the level of dancing in front of it!

 

With kind regards,

Michel

 

Not sure why, if there is such a *bit / flag* to turn on the four minute programming, why this feature is not utilized. Maybe this is being lost in translations but this is how I envision it to operate. Please add in what ever idea you believe would make it more robust and fault free.

 

1. An option box is available in the device tree when you right click to expand the option for that MS sensor(s).

2. Selecting this lone sensor would enable the four minute window to the MS.

3. The user would then go to the MS and wake it up my walking by etc.

4. The delay write option would be selected, and process the request.

5. Once the update was completed the MS would be selected from the list again to turn off the 4 minute flag so the sensor could go back to sleep.

 

The user would continue on the above steps until it was completed. Pop up messages would prove helpful to guide the user as to how this process is supposed to work. I don't see how this would cause anymore complications. The only difference in my idea, is that this it does not require reaching for the MS, opening up the device, and pressing the blasted button.

 

Its up to UDI to implement the idea or not. My job as a user is to present the idea in the dedicated Product Request Forum. I see value in this feature and so do many others.

 

Teken . . .

[Michel Kohanim]

Hi Teken,

 

Thanks so very much for the feedback and I would love that feature. Except that it must be requested from SmartHome and not UDI. i.e. in order to save battery, only during programming mode (press and hold the set button till it blinks and then click it again) does it stay awake for 4 minutes.

 

Thanks again and with kind regards,

Michel

[Teken]

Hi Teken,

 

Thanks so very much for the feedback and I would love that feature. Except that it must be requested from SmartHome and not UDI. i.e. in order to save battery, only during programming mode (press and hold the set button till it blinks and then click it again) does it stay awake for 4 minutes.

 

Thanks again and with kind regards,

Michel

 

Hello Michel,

 

The manual does state how to complete this task via manual methods. It does not address that HouseLinc has, and can, process this same request via their HL software with out the user opening the MS, pressing the set button, successfully etc.

 

It is well documented that this feature does exits in the product natively. It comes down to implementing the process to flip the bit that forces the MS to stay awake for *what ever duration* that is required for the MS to complete the update.

 

Please clarify any of the listed facts below:

 

1. The v2.0 Motion Sensor has the ability to be updated by one of two methods. One is via pressing the set button which forces the MS to stay awake for 4 minutes. The other method is via software where a flag / bit is remotely sent to the MS, once motion is detected. After the four minutes the MS goes back to the sleeping state.

 

2. Houselinc can perform this action as indicated in point 1.

 

3. The ISY can enable the flag / bit to allow the four minute window to be present via motion. But, this bit / flag is not enabled because of differing views and possible negative impact to battery life of the MS.

 

Teken . . .

[Michel Kohanim]

Teken,

 

Based on their API docs, there are the only parameters we can set:

LED brightness - Controls the LED brightness of the unit. Default value is 0x64

Timeout - Defines the timeout after motion detect. Each value increments the timeout by 30 sec. Default value is 0x01 (=1min).

Sensitivity - The unit only uses the intensity value when in night-only mode (JP-4) to determine if it is "night". The higher the value, the darker it needs to be for the unit to see night.

Default value is 0x23

 

If you would like to capture HL packets we will certainly take a look and investigate feasibility.

 

With kind regards,

Michel

[LeeG]

"The other method is via software where a flag / bit is remotely sent to the MS, once motion is detected. After the four minutes the MS goes back to the sleeping state."

 

The Motion Sensor does not go back to sleep on its own. Another command is needed to turn Off the stay awake mode. Miss this command and the MS runs down the battery quickly. I know this because I wrote a Powerhome Macro to update the MS sensor using these commands. The Macro had a bug and missed the command to put the MS back to normal operation. I killed a few batteries before realizing the problem.

[Teken]

"The other method is via software where a flag / bit is remotely sent to the MS, once motion is detected. After the four minutes the MS goes back to the sleeping state."

 

The Motion Sensor does not go back to sleep on its own. Another command is needed to turn Off the stay awake mode. Miss this command and the MS runs down the battery quickly. I know this because I wrote a Powerhome Macro to update the MS sensor using these commands. The Macro had a bug and missed the command to put the MS back to normal operation. I killed a few batteries before realizing the problem.

 

As stated: The MS has the ability so this isn't the question of if, or can. Since its clear, SmartHome / Insteon knows how this feature operates, then UDI needs to engage them directly to identify how to best incorporate this feature. UDI has direct relations and contacts to determine what the missing puzzle is. My goal is to identify a feature that many people believe has value, and in turn makes the ISY platform even more feature rich.

 

As always, I thank you both for the insight and the endless support you both provide.

 

Now, lets badger SH / Insteon and find out how this MS operates and what needs to be done via the ISY to make it happen.

 

Teken . . .

[Michel Kohanim]

Teken,

 

LeeG was kind enough to provide us with the details. We will investigate.

 

Apart from technical feasibility, we do have to worry about tech support and unhappy customers whose batteries drain. Also, the question is how important is this feature compared to all others that we have to develop.

 

In all cases, I must posit my extreme reluctant to develop against something that has not been documented and especially when it might drain batteries and thus the analogy of trying to fix the eyebrow and instead blinding the eye.

 

With kind regards,

Michel

[kaphely]

Just chiming in to say that I'd love such a feature as well as my motion sensors are only accessible using a small ladder. So climbing the ladder to remove the sensor, remove the battery screw and pushing the button is quite complicated. So hopefully, my post will make this request move a step up in the priority list!

[Teken]

Teken,

 

LeeG was kind enough to provide us with the details. We will investigate.

 

Apart from technical feasibility, we do have to worry about tech support and unhappy customers whose batteries drain. Also, the question is how important is this feature compared to all others that we have to develop.

 

In all cases, I must posit my extreme reluctant to develop against something that has not been documented and especially when it might drain batteries and thus the analogy of trying to fix the eyebrow and instead blinding the eye.

 

With kind regards,

Michel

 

Hello Michel,

 

I would like to suggest a few ideas, and perhaps the ISY community would be able to refine them. As it is, having others provide an alternate view may ease the process.

 

Right now I am simply spit balling and throwing out ideas.

 

I envision for those who wish to update the MS the old way there be a simple on / off selection next to the little battery icon. Or you could have a pop up with the option to enable the secondary mode as outlined in my previous reply once the battery icon was selected.

 

What ever is cleaner and easier to implement for UDI.

 

Once the secondary mode has been selected, the option in the device tree would appear for that MS when a user right clicks the mouse. Once the selection has been selected another pop up box would appear detailing the methodology. The next steps would alert the user to the amount of time and the actions that needed to be completed before the next MS could be updated.

 

As stated by you, there are countless feature request pending development which many would like to see. In no way am I asking UDI to bump a high priority request from the list. What I am affirming here today is that this one lone feature would bring parity with House Linc.

 

Why let the competitor have a feature which is proven to work and ease a persons life and not include it?

 

Having it, would bring value to the ISY platform, and ultimately would reduce the amount of time a user must perform these silly tasks. In my personal experience, sometimes that *one lone feature* has made all the difference to the masses.

 

While making the whole user experience a positive one.

 

I see the ISY as a clean slate that has continued to grow, expand, and empower the Insteon user. I know you have reluctance in developing this offering. I know if we allow the community to provide the critical feed back of how it should work and what safety's need to be in place.

 

Perhaps, this will meet all the criteria you must balance from a support perspective vs development. As always your consideration and insight in all matters are greatly appreciated. As I have stated over the years its rare to have the *ear* of the developer and help grow the product.

 

I know I speak for many, that this is one of many reasons we have purchased and supported the ISY product.

 

Teken . . .

[Michel Kohanim]

Hi Teken,

 

Thank you for the details and noted.

 

As far as competitors: if we were to do everything all our competitors do, then we would have been bankrupt a long time ago. The feature you are requesting is not like the one requested by shannong whereby everything was clear cut (turning off the backlight button) as a) it had no adverse impact and it would not cause tech support issues.

 

With the motion sensor - and unless we don't care about the outcome - we basically have to a bullet proof process by which we know for a fact the motion sensor is not going to stay awake indefinitely. This is not an easy task.

 

With kind regards,

Michel

[Brian H]

From personal observations.

 

Smartlabs changes things. Like adding or changing features and does not tell anyone of the changes.

Developer documentation rarely gets updated.

 

Keeping a Motion Sensor awake sounds like a disaster waiting to happen and may not even be in a newer revision Motion Sensor Firmware.

 

Has anyone used the latest HouseLinc and does it still support this feature?

[LeeG]

HL 2.10.29 uses that approach for motion sensors.

[Brian H]

Thank you LeeG for the information.

[Xathros]

I would like to add my support for adding this feature. I have quite a few motion sensors and this feature would prove useful to me. Granted, I probably change batteries more frequently than I change the options but I still see the value. As for the possibility of leaving the sensor awake and causing battery drain, I think alerting the user to this possibility with an initial pop up when enabling the feature should suffice. Similar to the warning when using MUTEX buttons on a KPL.

 

-Xathros

 

PS: If you could also add a checkbox for AutoBatteryChange, that would be appreciated as well