From: George F. <fa...@sh...> - 2012-08-28 03:27:01
|
Hi all, I recently updated my PLM to a new dual band (DB) unit and also bought a DB Lamplinc. This will probably apply to the earlier thread which I just found, about appliancelincs. BTW I am using Gregg's Insteon branch so this won't apply to the trunk I expect. All new devices that are i2cs MUST be linked to a controller before it will respond to a command. What does this mean? Well from a practical stand point, if you want to control a device, say $test_lamp, it must be linked to the PLM with a scene first. I wasn't successful linking it manually. so you must have this: INSTEON_ICONTROLLER, 14, test_scene, scenes SCENE_MEMBER, test_lamp, test_scene, 100%, 1s Of course the scene number and name can be anything you want but now you can control the lamp either from the button on the web page or via perl as in: $test_lamp->set(ON) and $test_lamp->set(OFF) This of course was all discovered mostly trial and error thanks to the incredible piece of s*it Smarthome are about support. I mean why on earth would you develop a product and the restrict people from developing software for it. They need fire a few people at Smarthome. Hope this will help someone. Cheers George |
From: Marc M. <ma...@me...> - 2012-09-03 05:28:57
|
On Mon, Aug 27, 2012 at 07:25:11PM -0700, George Farris wrote: > > The insteon branch is indeed looking for one or more people interested in > > taking it over to continue its support and finish the few things that are > > missing. > > Marc can you outline what is missing? I am using the Insteon branch and > it seems to work very well. I am interested in updating the Insteon > documentation. 0) See the InsteonRedux wiki from Greg on our wiki for a few notes from him. 1) scan all links, sync all links, delete orphans are all unstable for me and can stop in the middle, causing insteon scans to stop working until I restart mh (there are likely several sub bugs there) 2) lamp update onlevel/ramprate kills mh This still fails: 18/06/2011 17:11:22 Running: lvr lamp update onlevel/ramprate 18/06/2011 17:11:22 [Insteon::ALDB_i1] $lvr_lamp accessing memory at location: 0x0032 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e505280006 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=set_address_msb; extra=00 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212800 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e5052b3206 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=peek; extra=32 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212bfe Can't locate object method "local_onlevel" via package "Insteon::ALDB_i1" at ../lib/Insteon/AllLinkDatabase.pm line 534. On Mon, Aug 27, 2012 at 08:27:04PM -0700, George Farris wrote: > Hi all, > > I recently updated my PLM to a new dual band (DB) unit and also bought a > DB Lamplinc. > > This will probably apply to the earlier thread which I just found, about > appliancelincs. > > BTW I am using Gregg's Insteon branch so this won't apply to the trunk I > expect. Wise choice. The old code is not as modular, and dead for maintenance. > All new devices that are i2cs MUST be linked to a controller before it > will respond to a command. What does this mean? Well from a practical > stand point, if you want to control a device, say $test_lamp, it must be > linked to the PLM with a scene first. I wasn't successful linking it > manually. Thanks for that info. Just to make sure, what do you mean with "link with a scene"? Does 'link to plm' option not work? > This of course was all discovered mostly trial and error thanks to the > incredible piece of s*it Smarthome are about support. I mean why on To be fair, they only support their windows software. MH is not really their problem, starting with the fact that MH does not support the lastest I2 protocol from what I understand. > earth would you develop a product and the restrict people from > developing software for it. They need fire a few people at Smarthome. Don't they provide programming info? They not super good at doing so, but they do AFAIK. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Alan W. <arw...@we...> - 2012-09-03 13:49:48
|
>From reading the Smarthome insteon forums it sems they don't really answer questions, you have to pay to get access to the developer information and sign their nda, which might be problematic for an opensource program such as MH to use what you discover depending on their NDA. The forum members complain it's pretty much a user supported programming effort. > > Don't they provide programming info? They not super good at doing so, > but they do AFAIK. > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: George F. <fa...@sh...> - 2012-09-03 23:41:41
|
On Sun, 2012-09-02 at 22:01 -0700, Marc MERLIN wrote: > On Mon, Aug 27, 2012 at 07:25:11PM -0700, George Farris wrote: > > > The insteon branch is indeed looking for one or more people interested in > > > taking it over to continue its support and finish the few things that are > > > missing. > > > > Marc can you outline what is missing? I am using the Insteon branch and > > it seems to work very well. I am interested in updating the Insteon > > documentation. > Okay I'll back up on that. It doesn't all work specifically the new i2cs devices. > 0) See the InsteonRedux wiki from Greg on our wiki for a few notes from > him. > > 1) scan all links, sync all links, delete orphans are all unstable for > me and can stop in the middle, causing insteon scans to stop working > until I restart mh (there are likely several sub bugs there) > Yes after playing with it for longer you are right there are some issues here. > 2) lamp update onlevel/ramprate kills mh > > This still fails: > 18/06/2011 17:11:22 Running: lvr lamp update onlevel/ramprate > 18/06/2011 17:11:22 [Insteon::ALDB_i1] $lvr_lamp accessing memory at location: 0x0032 > 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e505280006 > 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=set_address_msb; extra=00 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212800 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e5052b3206 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=peek; extra=32 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212bfe > Can't locate object method "local_onlevel" via package "Insteon::ALDB_i1" at > ../lib/Insteon/AllLinkDatabase.pm line 534. > Haven't seen this yet because I haven't tried it. > On Mon, Aug 27, 2012 at 08:27:04PM -0700, George Farris wrote: > > Hi all, > > > > I recently updated my PLM to a new dual band (DB) unit and also bought a > > DB Lamplinc. > > > > This will probably apply to the earlier thread which I just found, about > > appliancelincs. > > > > BTW I am using Gregg's Insteon branch so this won't apply to the trunk I > > expect. > > Wise choice. The old code is not as modular, and dead for maintenance. > > > All new devices that are i2cs MUST be linked to a controller before it > > will respond to a command. What does this mean? Well from a practical > > stand point, if you want to control a device, say $test_lamp, it must be > > linked to the PLM with a scene first. I wasn't successful linking it > > manually. > > Thanks for that info. > Just to make sure, what do you mean with "link with a scene"? > Does 'link to plm' option not work? I could not get it to link to the PLM without a scene. Obviously more testing of i2cs devices is required. They won't link scan either and it looks like Gregg's code does peek and poke which according to this: http://www.madreporite.com/insteon/i2cs.html > To be fair, they only support their windows software. MH is not really > their problem, starting with the fact that MH does not support the lastest > I2 protocol from what I understand. > > > earth would you develop a product and the restrict people from > > developing software for it. They need fire a few people at Smarthome. > > Don't they provide programming info? They not super good at doing so, > but they do AFAIK. >From what I know you have to be part of the developer program $$$ and even then it seems their support is not good. So Gregg's code does NOT support any of the I2 protocol? Is this true? George |
From: George F. <fa...@sh...> - 2012-09-04 00:09:55
|
On Mon, 2012-09-03 at 16:41 -0700, George Farris wrote: > >From what I know you have to be part of the developer program $$$ and > even then it seems their support is not good. > > So Gregg's code does NOT support any of the I2 protocol? Is this true? > Okay ignore most of that I had a look at the code and it does look like there is I2 stuff in there but the comments in the code are few and far between so it will take a long time to figure this out. I have no idea how this stuff works at the moment. If we can get Gregg to give us some pointers so we can document the code as part of his hand off, that would be awesome. George |