Insteon: Catch Low Battery, Dusk, Dawn Messages from Devices

[krkeegan]

The following devices broadcast special messages that are not currently enabled in MH:

• Remotelinc (possibly low battery warning)
• MotionLinc (low battery, dusk, dawn)
• LeakSensor (low battery)

It would be nice if these were caught by MH so that users could be notified of these events.

[peloy]

Hi Kevin,

On 04/29/2013 04:26 PM, krkeegan wrote:

The following devices broadcast special messages that are not currently enabled in MH:

• Remotelinc (possibly low battery warning)
• MotionLinc (low battery, dusk, dawn)
• LeakSensor (low battery)

It would be nice if these were caught by MH so that users could be notified of these events.

Sorry, I have been testing this but forgot to provide an update...

I have this in my items.mht:

INSTEON_MOTIONSENSOR, xx.yy.zz, garage_motion, Motion_Sensorsv2.0 INSTEON_MOTIONSENSOR, xx.yy.zz:02, garage_motion_photocell, Motion_Sensors INSTEON_MOTIONSENSOR, xx.yy.zz:03, garage_motion_lowbatt, Motion_Sensors

And the following user code:

if ($state = $garage_motion_photocell->state_now() ) { print_log "\$garage_motion_photocell changed state; new state: $state"; }

if ($state = $garage_motion_lowbatt->state_now() ) { net_mail_send to => 'xxx@yyyy', subject => "Garage motion sensor low battery message. State: $state"; }

I have yet to see a low battery message, but the photocell message I do see often:

04/29/13 03:29:42 PM $garage_motion_photocell changed state; new state: off 04/29/13 03:33:17 PM $garage_motion_photocell changed state; new state: on 04/29/13 03:52:22 PM $garage_motion_photocell changed state; new state: off 04/29/13 03:58:27 PM $garage_motion_photocell changed state; new state: on

In fact, I'd love to find a way to prevent the sensor from sending them since they cannot be good in terms of battery life.

I don't know if the above is the right way to set things up but it seems to be working for the photoresistor, and I hope it'll work for the low battery as well (which is more important to me).

Cheers,

Eloy Paris.-

[krkeegan]

You might be able to disable them by turning off the night only mode, I think if you mode jumper 4 to the off position.

[peloy]

On 04/29/2013 04:47 PM, krkeegan wrote:

You might be able to disable them by turning off the night only mode, I think if you mode jumper 4 to the off position.

Hmmm. I'll check that. There are actually a couple of sensors that are not sending the dusk/dawn messages and I have been wondering why. I'll check their jumpers.

Cheers,

Eloy Paris.-

[pork13]

Eloy, Are your changes to the motionsensor object anywhere I can see? I'm interested in supporting the FanLinc which uses xx.yy.zz:02 to control the fan. This is not allowed by any objects in mh at the moment, so I'm curious where you made changes to allow it. Cheers, Jeff Findlay

[peloy]

Hi Jeff,

On 04/29/2013 05:20 PM, pork13 wrote:

Eloy, Are your changes to the motionsensor object anywhere I can see? I'm interested in supporting the FanLinc which uses xx.yy.zz:02 to control the fan. This is not allowed by any objects in mh at the moment, so I'm curious where you made changes to allow it.

I actually did not make any changes anywhere -- I am just running Michael's merge_i2_aldb_support branch with no modification.

Since the motion sensor is just sending (not expecting to receive) some information (dusk/dawn and low battery indicators) via groups different than 1, it seems like there is nothing else to do beyond properly declaring the correct items. For example:

INSTEON_MOTIONSENSOR, 14.19.e9, garage_motion, Motion_Sensors INSTEON_MOTIONSENSOR, 14.19.e9:02, garage_motion_photocell, Motion_Sensors INSTEON_MOTIONSENSOR, 14.19.e9:03, garage_motion_lowbatt, Motion_Sensors

I don't know if things would work if the motion sensor sent any data via those two extra groups (for example, if in addition to using group 3 for sending a low-battery alarm, if the sensor also sent the voltage level as part of the same message). I guess code changes to Insteon::MotionSensor would be required in that case, but fortunately, that's not the case.

For sending data to an INSTEON device that expects to receive data on certain groups (like the case of the FanLinc) I'd expect that code changes (a new class in a file under lib/Insteon/) would be required.

It would be a good idea to open a new Github issue to track an enhancement to add support for the FanLinc.

Sorry I don't have better news.

Cheers,

Eloy Paris.-

[pork13]

Ah-ha, the i2_aldb_support thing was definitely part of my problem! I can chat with I2CS devices now, so thanks for that tip. :) I was fiddling last night and came to the same conclusion as you; I need a new class. Sadly, mine crashes mh when I send a message to group (2) of my Fanlinc, so it's not quite ready to post, but I'll make an issue for sure.
Thanks for the tips. J

[peloy]

Hi Kevin,

On 04/29/2013 04:49 PM, Eloy Paris wrote:

On 04/29/2013 04:47 PM, krkeegan wrote:

You might be able to disable them by turning off the night only mode, I think if you mode jumper 4 to the off position.

Hmmm. I'll check that. There are actually a couple of sensors that are not sending the dusk/dawn messages and I have been wondering why. I'll check their jumpers.

I have not had a chance to change jumpers but I did read the manual and think that night only mode is not the setting that needs to be tweaked to prevent the motion sensor from generating the dawn/dusk messages.

Instead, there's a potentiometer that controls the "Day/Night Threshold". The manual says that moving it all the way in one direction will cause the sensor to read "day" no matter how dark it is, and vice-versa in the other direction (read "night" no matter how bright it is).

Night-only mode is to have the sensor operate only when dark, which is not what I want (I want the sensor to operate at all times, just not sending those dark/bright messages).

Cheers,

Eloy Paris.-

[krkeegan]

So I tinkered with a remotelinc 2 revision 1.4. It is listed as having the ability to periodically wake up and send a heart beat message, but for whatever reason I can't enable it. It acknowledges the commands, but none of the necessary bits ever change. Other comments online suggest I am not alone with this issue.

But on the upshot, it looks like the remote stays awake for 4 seconds after sending a command. During this time we can send it a request for the battery level.

[krkeegan]

It also appears I can change the amount of time that the device stays awake after sending a command.

[krkeegan]

Ok, so I finished the code for the Remotelinc. I had to kinda guess as to what the battery level number meant, but I think I got it right. Time will tell.

I also found that there is a "Set Battery Low Level Trigger" command, which the device will allow me to change. Unfortunately nothing seems to be sent when the set threshold is crossed. I sent a question to insteon since their documentation says that the device supports a low battery warning in houselinc but I see no record of it.

[krkeegan]

I added a basic generic item that if used, will display the battery voltage as its state. It is very similar to the child objects that I created with the thermostat for tracking temperature. I think that concludes my updates to RemoteLinc.

I have started looking at the motion sensor, it seems much more straightforward.

[krkeegan]

MotionLinc Notes: A Blank Extended Get Command works on V2 devices. The Data1-14 returned is:

00010300ff1c00ff0e01d14700d1
D1D2D3D4D5D6D7D8D9D0D1D2D3D4

D1 = 00 = Get Cmd 00 D2 = 01 = This is a response packet D3 = LED Brightness D4 = Motion Timeout D5 = Light Intensity D6 = ?? D7 = ?? D8 = ?? D9 = ?? D10 = ?? D11 = Current Light level, 0x00 = dark, 0xFF = Bright (Not documented) D12 = Battery Voltage * 10. (Not documented) D13 = Empty D14 = Checksum spit back at me.

D6-D10 Remain a mystery to me. They appear to be settings, rather than data points as they don't change with light, battery level, motion, or link table changes. Bizarrely I am out of known settings, maybe they represent the states of the dials on the device? One of them may represent the firmware version of the device, but none match the reported firmware.

But it looks like we can do similar battery level tracking and even light level tracking. This is all in addition to simply relying on the trigger events sent by groups 2 & 3.

[peloy]

Hi Kevin,

On 05/11/2013 02:03 PM, Kevin Robert Keegan wrote:

MotionLinc Notes: A Blank Extended Get Command works on V2 devices. The Data1-14 returned is:

[...]

And this get command can only be sent to the sensor within some time after the sensor sends a message?

What's LED brightness, BTW?

Cheers,

Eloy Paris.-

00010300ff1c00ff0e01d14700d1 D1D2D3D4D5D6D7D8D9D0D1D2D3D4

D1 = 00 = Get Cmd 00 D2 = 01 = This is a response packet D3 = LED Brightness D4 = Motion Timeout D5 = Light Intensity D6 = ?? D7 = ?? D8 = ?? D9 = ?? D10 = ?? D11 = Current Light level, 0x00 = dark, 0xFF = Bright (Not documented) D12 = Battery Voltage * 10. (Not documented) D13 = Empty D14 = Checksum spit back at me.

D6-D10 Remain a mystery to me. They appear to be settings, rather than data points as they don't change with light, battery level, motion, or link table changes. Bizarrely I am out of known settings, maybe they represent the states of the dials on the device? One of them may represent the firmware version of the device, but none match the reported firmware.

But it looks like we can do similar battery level tracking and even light level tracking. This is all in addition to simply relying on the trigger events sent by groups 2 & 3.

[krkeegan]

I received a response from smarthome regarding the documentation for the RemoteLinc 2 saying that the device supports a low battery warning in houselinc.

Unfortunately the Remotelinc2 does not have the ability to send email alerts when the battery is 
triggered. (This was an error in the owner's manual, corrected in the new one found here 
http://www.smarthome.com/manuals/2342-x32.pdf)

So my next thought is that the Battery Level Trigger setting that I see refers to the level at which the red light on the remote is triggered. This wouldn't be very useful, but it would at least answer a nagging question.

[krkeegan]

OK, I finished a draft of the MotionSensor class with support for low battery and light level objects.

https://github.com/krkeegan/misterhouse/tree/insteon_motionsensor

For V1 devices, you are limited to using the group 2 and group 3 objects. But for V2 devices, you can create a child object that actually updates with the current voltage level not just a low level trigger.

[peloy]

On 05/16/2013 12:50 AM, Kevin Robert Keegan wrote:

OK, I finished a draft of the MotionSensor class with support for low battery and light level objects.

https://github.com/krkeegan/misterhouse/tree/insteon_motionsensor

For V1 devices, you are limited to using the group 2 and group 3 objects. But for V2 devices, you can create a child object that actually updates with the current voltage level not just a low level trigger.

Very nice, Kevin. I'll be giving this a try.

A couple of related question:

1. Do these changes require installing jumper #5 (Remote (Software) Management)? I believe the sensor comes from the factory without this jumper installed.
2. There's a potentiometer that controls the light level threshold -- since the light level can also be set through software, does this mean that the potentiometer is ignored in that case (perhaps when jumper #5 is installed)?

Cheers,

Eloy Paris.-

[peloy]

On 05/16/2013 03:59 AM, Eloy Paris wrote:

On 05/16/2013 12:50 AM, Kevin Robert Keegan wrote:

OK, I finished a draft of the MotionSensor class with support for low battery and light level objects.

https://github.com/krkeegan/misterhouse/tree/insteon_motionsensor

For V1 devices, you are limited to using the group 2 and group 3 objects. But for V2 devices, you can create a child object that actually updates with the current voltage level not just a low level trigger.

Very nice, Kevin. I'll be giving this a try.

A couple of related question:

1. Do these changes require installing jumper #5 (Remote (Software) Management)? I believe the sensor comes from the factory without this jumper installed.
2. There's a potentiometer that controls the light level threshold -- since the light level can also be set through software, does this mean that the potentiometer is ignored in that case (perhaps when jumper #5 is installed)?

Oh, so these are internal MisterHouse settings; nothing is being sent to the sensor itself (other than the query messages). I guess this mean that jumper #5 is not necessary, and that the sensor will continue to send group 2 light level events depending on potentiometer #2 setting.

It seems to me like if someone configures the query method then potentiometer #2 should be set all the way to the left or to the right so the sensor does not send group 2 light level events, saving battery.

One disadvantage of the query method is that if there is no motion detection then we get nothing, so it's a good idea to at least configure group monitoring for at least battery events.

One last question about this:

"To scan the link table, sync links, or set settings on the device, the Motion Sensor must first be put into "awake mode."

I thought that deaf devices are skipped when doing a link table scan -- is the scan skipped after an attempt to contact the device is not successful, or it's always skipped based on device category? Attempting to delete orphan links yields this:

05/16/13 08:30:33 AM [Sync all links] Ignoring links from 'deaf' device: $kitchen_motion

Cheers,

Eloy Paris.-

[krkeegan]

1. Is Jumper 5 Required I tried to document the settings that require jumper 5 to be enabled. Anything that requires actually setting an attribute on the device will require it. The battery level and light level can be queried from the device regardless of the jumper level.
2. Will the MH settings override the device settings. Yes. If you have jumper 5 enabled, and you set a light level or timeout time, that will override the dial settings on the device. I also believe that the night_only, and on_only modes will be overriden, but I haven't checked this for sure.
3. Will the MH settings affect the group 2 light level object? Yes, I believe they will.
4. Should the potentiometer setting be maxed out if I use the Query method? The query method just asks for data from the device. It does not itself require setting anything on the device from the software. Some people may want to use both, as the query method will only provide data when there is motion activity. If the device doesn't see much motion, you may want to use the group method as well.
5. Scan, Sync, Setting Bits You are correct, you cannot run delete_orphans. However, you can still run sync_links and scan_links from the device's, not the PLM's, voice commands. But the device needs to be awake.

[krkeegan]

Closing as support for this feature has been merged in.