Insteon: Add Support for TriggerLinc Device #245
Comments
|
I have no problem working on this. I don't own one, which adds some level of difficulty. But to further complicate things, I hacked a "fake triggerlinc" device into the HouseLinc software and I do not see any options for setting the NO/NC behavior. Nor do I have any command tables or documentation on the commands used by the triggerlinc. As for the battery level and "deaf time," maybe try setting the device as a RemoteLinc. If that works, it might be possible to set the NO/NC state with the set_operating_flag command. |
|
I'm guessing that no special commands are supported for this device if nothing like that shows in HouseLinc. As far as a battery-level indicator, as I stated above, it looks like this is also not supported: http://www.power-home.com/forum/forum_posts.asp?TID=2272 You would think that since the TriggerLinc and MotionLinc have such similar functions, that they would support similar features as well, but perhaps these features were lost in the attempt to create a smaller device... I don't own a MotionLinc, but have heard that they are quite large as far as motion sensors go. If necessary, I could always send you a TriggerLinc to test with, but so far it looks like this may be the simplest Insteon item that SmartHome sells (funny then that they charge so much for them; I got a deal on eBay, otherwise I probably wouldn't own any). I would be glad to help code if necessary, but would probably need some hints as where to start since I've never edited any public code in MH. Thanks for your help! (P.S.--I couldn't find out how to label this "issue" as an 'enhancement.' Guessing that it's a permissions issue.) |
|
I would be surprised if you could not change the NO/NC option using commands. I wouldn't read too much into HouseLinc, it is clearly designed by a different department and it often lacks many features. I will keep an eye on it, maybe they will update it soon. As for the battery situation. There are three ways in which Insteon devices provide battery information. The oldest method is a group broadcast, usually group 3. The second is a direct request to the device asking for a battery level, if the device is awake, it will respond back with a battery level message. The third is a heartbeat, essentially the heartbeat is broadcast every X minutes, I believe that message contains the battery level, but additionally if you do not receive a heartbeat in X*2 minutes you know something is wrong. The first method was used on older devices and seems to be less favored by Insteon now. The second method seems to be on nearly all devices, but is often overlooked by other software and as a result is not generally used. The third method is very new and I have not seen it on a device yet. The RemoteLinc's were supposed to have it, but they do not actually do it. I believe the Leak Sensor does use a heartbeat though. Try the following:
Hopefully the device remains awake the whole time for all of this. I would expect all of these commands to work. |
|
On closer inspection, I am not sure what you mean by NO/NC. I don't see any reference in the product manual that the device can be switched between these states. I see that the device can be used in "mulit-scene" mode in which it will issue on commands on group 1 whenever the device is closed and on group 2 when it is open (I may have that backwards). It looks like the multi-scene option may be a hardware only setting. |
|
Kevin, You are correct; I was remembering the instructions incorrectly. I was thinking that the setting switched between sending an ON when open or an OFF when open; whereas like you said, it appears that the difference is that the setting activates a secondary group instead. Reviewing the manual, since the setting only appears adjustable via the jumper, it probably cannot be remotely set... I will still run the tests for engine version, extended_info, and set_awake_time. |
|
INSTEON_REMOTELINC, 14.8A.8F:01, Test, All_Devices 08/13/2013 23:17:26 Running: Test get engine version 08/13/2013 23:17:26 [Insteon_PLM] DEBUG3: Received PLM raw data: 0262148a8f0f0d0006 08/13/2013 23:17:26 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$Test; command=get_engine_version 08/13/2013 23:17:26 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 0250148a8f 08/13/2013 23:17:26 [Insteon::BaseInterface] DEBUG3: Message received with 1 hops left, delaying next transmit by 150 milliseconds to avoid collisions. 08/13/2013 23:19:31 Running: Set awake time. 08/13/2013 23:19:31 [Insteon_PLM] DEBUG3: Received PLM raw data: 0262148a8f1f2e00010204000000 08/13/2013 23:19:31 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 0262148a8f1f2e00010204000000 08/13/2013 23:19:31 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$Test; command=extended_set_get; extra=000102040000000000000000000000 08/13/2013 23:19:32 [Insteon::BaseInterface] DEBUG3: Message received with 1 hops left, delaying next transmit by 150 milliseconds to avoid collisions. 08/13/2013 23:20:09 Running: Get extended info. 08/13/2013 23:20:09 [Insteon_PLM] DEBUG3: Received PLM raw data: 0262148a8f1f2e000100 08/13/2013 23:20:09 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 0262148a8f1f2e000100 08/13/2013 23:20:09 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$Test; command=extended_set_get; extra=000100000000000000000000000000 08/13/2013 23:20:10 [Insteon::BaseInterface] DEBUG3: Message received with 1 hops left, delaying next transmit by 150 milliseconds to avoid collisions. 08/13/2013 23:20:10 [Insteon::BaseInterface] DEBUG3: Message received with 1 hops left, plus ACK will take 3 to deliver, delaying next transmit by 850 milliseconds to avoid collisions. Looks like it's an I2 device. I started with a new TriggerLinc that was previously unlinked to my PLM. Let me know if the results show that this is causing issues. Not sure if the set_awake_time did anything. Should there be any other response than "Extended Set/Get ACK Received for $Test"? Looks like the get_extended_info is causing a crash because it can't find the method "_is_battery_low" Before the crash, I do see a report of 0V, so it looks like no luck with this test at least... :( |
|
Well done, thank you for that. Yes, I apparently forgot to include a function in the RemoteLinc code, not sure how that happened, it should be an easy fix. Even without that, we still get some data back from the TriggerLinc. The D1-14 response from the Get_Extended_Info command is as follows: This looks promising. For the RemoteLinc D3 is the awake time. Here it looks to be set to 4 seconds, which matches the command you sent. So far so good. The contents of D4 and D5 will have to be an educated guess. D4 may define the Jumper state inside of the device. 1 being a single scene and maybe 0 being multi-scene?? D5 could be the battery level. The decimal value of this data is 35. The TriggerLinc takes a AA with a nominal voltage between 1.2 and 1.5 volts depending on the type of battery used. I am guessing you used a brand new Alkaline battery, so it should be about 1.5 volts. On other devices, I have seen Insteon multiply the battery voltage by 2, 10 and 50. Based on the data returned here it looks like in this case it may be 25?? This would result in a voltage of 1.4. The only way to know is to keep watching it. If you are still willing to be a guinea pig, you can test the following for me to confirm my assumptions:
Hopefully we will see the D3-D4 settings change appropriately. If we are lucky, we may even catch a new reading on D5 which would help identify the battery value. |
|
Some good news, but mostly disappointing news... Like you said, the awake time setting does indeed seem to be working--I tried setting it to 5 and then 10 and received the following responses respectively: 0001050123000000000000000000 Once, I held the button too long and I believe that it reset it to factory defaults, which produced this: The bad news is that nothing that I did changed the values of D4 or D5... I tried half a dozen old batteries that I had just changed out from dead TV remotes and the like. I was barely able to get the TriggerLinc to send even one response on most of them, but when it did, D5 still showed 23 each time... Is it possible that the internal firmware only "checks" the voltage every so often and I didn't leave the bad batteries in long enough? The jumper did not seem to have any effect on D4--it always responded with 01 no matter what position it was in... I removed the battery for 10+ seconds between each change. The only other controllable variable is the reed switch, so I tried closing it with the magnet and running the test, but this also did not seem to have any effect. There are terminals on the board for connecting a custom Open/Close type sensor, but I would assume that this just patches directly into where the existing reed switch connects... Let me know if you have any other ideas to test; otherwise, I think that as far as MH is concerned, the code will only need to support group 01, group 02 as well if the jumper is removed (I do not plan to use this feature), and possibly the 'stay awake' functionality once implemented. |
ghost
assigned 
Basically just a copy of code for RemoteLincs, however, TriggerLincs support even fewer commands so much of the code was cut down. I put the code in the Security.pm file as these are ostensible security devices, however as noted above, these are very similar to RemoteLincs. Although, they are not that dissimilar from Motion sensors which are also in this file. I don't own a TriggerLinc so this coding is all done blind. Thanks to @JaredF for his testing work. Closes hollie#245
|
When I was running these tests as discussed above, I ran into a missing function in the RemoteLinc code: "Can't locate object method "isbattery_low" via package "Insteon::RemoteLinc"" Just checking: did this ever get fixed or entered as an open issue? If not, I can add it; it is definitely not a high priority, but I wanted to make sure that it doesn't get forgotten. |
|
ok, the is_battery_low issue is solved and the solution has been merged with master |
|
Excellent! |
The Insteon TriggerLinc will be coded similarly to the MotionLinc, but does not seem to support some of the more advanced features that the MotionLinc does, for example, reporting low batteries, ambient light level, et cetera via different Insteon group numbers. I have not tested for any of these features, but Internet searches and the instruction manual do not mention any support for this.
If undocumented, the features to check for would be to see if it would be possible to detect battery level, remotely change the NO/NC behavior, and adjust the time before the device returns to "deaf" mode.
The text was updated successfully, but these errors were encountered: