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

krkeegan · 2013-04-29T20:26:45Z

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 · 2013-04-29T20:39:01Z

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 · 2013-04-29T20:46:58Z

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 · 2013-04-29T20:50:24Z

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 · 2013-04-29T21:20:25Z

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 · 2013-04-30T12:41:36Z

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 · 2013-04-30T14:07:06Z

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 · 2013-04-30T19:11:54Z

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 · 2013-05-10T03:41:29Z

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 · 2013-05-10T03:48:37Z

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

…ttery Status The following likely only works for i2cs devices, I think all Remotelinc 2 devices are i2cs? It at least works on rev 1.4. - set_awake_time sets = sets the time in seconds that the remote will remain awake after sending a command. The default is 4, it can be set up to 254 seconds, with 255 being always awake. - get_extended_info = is primarily added to get the battery level. Battery level is returned as a byte, but the number does not immediately make sense. I will have to let the batter run down some to better understand what it means. At the moment, I have the code set to call get_extended_info whenever the all_link_report is received. This report represents the last message sent by the device before the awake time begins to run. In the future, an additional function can be added to only call get_extended_info if it hasn't been called in x hours. N.B. in order for set_awake_time to work properly, the engine version of the device must be known. hollie#172

krkeegan · 2013-05-11T02:05:46Z

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 · 2013-05-11T16:34:02Z

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 · 2013-05-11T18:03:20Z

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 · 2013-05-11T21:50:11Z

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 · 2013-05-13T21:16:07Z

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 · 2013-05-16T04:50:03Z

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 · 2013-05-16T08:00:04Z

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:

Do these changes require installing jumper added an authentication dialog to the iPhone UI #5 (Remote (Software)
Management)? I believe the sensor comes from the factory without this
jumper installed.
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 added an authentication dialog to the iPhone UI #5
is installed)?

Cheers,

Eloy Paris.-

peloy · 2013-05-16T12:33:56Z

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:

Do these changes require installing jumper added an authentication dialog to the iPhone UI #5 (Remote (Software)
Management)? I believe the sensor comes from the factory without this
jumper installed.

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 added an authentication dialog to the iPhone UI #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 · 2013-05-16T20:34:02Z

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.
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.
Will the MH settings affect the group 2 light level object?
Yes, I believe they will.
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.
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 · 2013-06-11T22:53:21Z

Closing as support for this feature has been merged in.

krkeegan closed this as completed Jun 11, 2013

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

krkeegan commented Apr 29, 2013

peloy commented Apr 29, 2013

krkeegan commented Apr 29, 2013

peloy commented Apr 29, 2013

pork13 commented Apr 29, 2013

peloy commented Apr 30, 2013

pork13 commented Apr 30, 2013

peloy commented Apr 30, 2013

krkeegan commented May 10, 2013

krkeegan commented May 10, 2013

krkeegan commented May 11, 2013

krkeegan commented May 11, 2013

krkeegan commented May 11, 2013

peloy commented May 11, 2013

krkeegan commented May 13, 2013

krkeegan commented May 16, 2013

peloy commented May 16, 2013

peloy commented May 16, 2013

krkeegan commented May 16, 2013

krkeegan commented Jun 11, 2013

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

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

Comments

krkeegan commented Apr 29, 2013

peloy commented Apr 29, 2013

krkeegan commented Apr 29, 2013

peloy commented Apr 29, 2013

pork13 commented Apr 29, 2013

peloy commented Apr 30, 2013

pork13 commented Apr 30, 2013

peloy commented Apr 30, 2013

krkeegan commented May 10, 2013

krkeegan commented May 10, 2013

krkeegan commented May 11, 2013

krkeegan commented May 11, 2013

krkeegan commented May 11, 2013

peloy commented May 11, 2013

krkeegan commented May 13, 2013

krkeegan commented May 16, 2013

peloy commented May 16, 2013

peloy commented May 16, 2013

krkeegan commented May 16, 2013

krkeegan commented Jun 11, 2013