I've just committed a fix for Manufacturer ID. It got switched to"Google" in the SQLCVS number shuffle, and was corrected to "Universal Devices". Fix committed on Dec. 8 @ 0:18 EST via anonymous SQLCVS.

I've noticed that the code got tied to the Google manufacturer ID, which meant it wasn't working with the driver the way it should. I've figured out how to fix it locally by modifying the database tables directly. I'm not sure if doing a SQLCVS commit now will make things better or worse, so I'll wait on your advice.

I modified the template first to re-associate it with Universal Devices (#1163). That's what I committed early this morning. Later, I noticed the code wasn't associated, so I started looking into the tables.

I modified table 'InfraredGroup_Command.FK_InfraredGroup' for all affected rows to match the relevant row from 'infraredGroup.PK_InfraredGroup'. The old value was 6143 (which matched the Google ChromeCast values), and I changed it to 6102 for the ISY. I noted the behavior for LMCE creating new command groups, deleted the new (blank) rows, and changed the FK_InfraredGroup value for the pre-existing ones.

I'm guessing that no news is good news, and that I'm on the right track. I've done another anonymous SQLCVS commit. Would you be able to review it and let me know if it looks OK? Dec 12th @ 22:20 EST, against Trac #1999.

My first thought is that you need to go through the web admin, Advanced -> SQLCVS -> Update and then wait a while. When it says success, you can either reload the router, or reboot the core to have all the auto detection stuff happen via dhcp. It should detect the ISY, then create the device as a child of the core. You'll need to change your ISY credentials to match via the web admin, and reload the router. After that, things should just work as per the wiki page.

If you're still having problems after that, can you pastebin or post the log files here as attachments? I'll need the <dev#>_Generic _Serial_Device.log and <dev#>_ISY-994i-GSD.log. Both are located in /var/log/pluto, and can be found using

ls <dev#>_*

Mine are 189_Generic_Serial_Device.log and 189_ISY-994i-GSD.log (as an example).

I'll look at them tonight if you're still having problems. I think you just got bit by the misaligned code (it got attached to a different device in the SQLCVS number shuffles...

I'm querying the pluto database to look up the IP address of the device; I couldn't figure out a way to find it via device data. If you can point me in the direction of that, I'll be able to remove the mysql requirement. I thought the Ruby mysql drivers were installed as a LMCE dependency (which is why I was using them), but it could be that they are on my system due to some other products I'd installed.

The reader's digest version is that the conn_ method is used with the ISY's subscription channel (which is a one-way feed of events from the ISY to the "client", in this case the LMCE driver). Commands have to be sent asynchronously as a separate REST call, and I have a function to do that. The function hits the IP address, which I'm presently scraping from the DB, after first parsing the pluto.conf file to find the connection information. The relevant DB scrape code is in the 355_Process_Initialize, and the REST command function is in 373_Private_Methods. I can't establish the conn_ subscription until I've executed some REST calls to connect to the ISY and gather Child Device and other config data. This was all done to make things work "automagically".

Chris,

Please stand by... based on Thom's assessment, your system is missing the ruby-mysql packages. I suspect we'll have a way forward after Thom thwacks me upside the head...

This is one of those cases where a C++ device would do this easier... I've been looking through GSD and don't see the NetworkIOConnection class exposed sufficiently enough to get its IPAddress member..

-Thom

edited: Basically, GSD _SUCKS_ when you need to maintain more than one socket. Full stop.