Announcement

Collapse
No announcement yet.

Ocelot Plug-In for HS3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bbowser
    replied
    Originally posted by grp View Post
    I have just embarked on the migration from HS2 to HS3. I have been using the MCS ADIOcelot PI for 6 years without any issues. I have 13 IR Zones, and over 200 actual learned codes. The MCS plugin created a set of files, IR-Zones.x and IR-Labels.x, where x ranges from 0 (actually blank) to 5. I am assuming that these files contain the IR codes for all the equipment that I have previously trained. Will your plugin be able to import these codes, or will I have to repeat the arduous task of learning IR codes for all my devices? Is there any way to take advantage of all the previous work done learning this large number of IR codes?

    Also, I do use Bobcat sensors in my home, so do you have any idea as to when you might be adding support for Bobcat environmental sensors?

    Any assistance would be greatly appreciated, as I seem to be finding more pitfalls and roadblocks everyday in this HS2->HS3 migration.
    Hi grp,
    At this point there is not a way to import info from the MCS Ocelot plugin. Not sure what the IR-Zones.x and IR-Labels.x actually contain but I do know this for sure. The IR codes you have learned are stored in the Ocelot. Changing to the HS3 GTS CPUXA plugin will not cause you to have to relearn the locations. The Ocelot has 1024 IR locations that you can learn to. In your case you have over 200 locations occupied which can be sent out the Ocelot's IR Emitter port or any Secu16IR(s) port(zone) with the GTS plugin. If you know the names of the IR locations, you will be able to create IR devices in the GTS Plugin and name them as you go. Yes, still an arduous task but again, no relearning needed.

    I have not tested it, but the Bobcats should be able to be used with the plugin now. The Ocelot's parameter 1 is kind of a "move Bobcat data into a variable offset".

    An example:
    Ocelot parameter 1
    0 = Off
    15 = Bobcat at address 5 and data will display in variable 20, Bobcat at address 6 and data will display in variable 21, etc. So basically, take the Bobcat's unit no, add it to Ocelot parameter 1 and the data will be in the sum/variable number. The GTS plugin can read and set Ocelot variables, so it should work. In this example, you would create a variable device for variable 20 and the Bobcat at address 5 would populate it.

    Direct support for Bobcats may happen if we can get our hands on one cheap In the end, the above method may actually be the best way to get Bobcat data.

    Let me know if you need further clarification.
    Bruce
    Last edited by bbowser; March 30, 2016, 12:29 PM.

    Leave a comment:


  • grp
    replied
    Upgrading from the MCS ADIOcelot PI with HS2.....

    I have just embarked on the migration from HS2 to HS3. I have been using the MCS ADIOcelot PI for 6 years without any issues. I have 13 IR Zones, and over 200 actual learned codes. The MCS plugin created a set of files, IR-Zones.x and IR-Labels.x, where x ranges from 0 (actually blank) to 5. I am assuming that these files contain the IR codes for all the equipment that I have previously trained. Will your plugin be able to import these codes, or will I have to repeat the arduous task of learning IR codes for all my devices? Is there any way to take advantage of all the previous work done learning this large number of IR codes?

    Also, I do use Bobcat sensors in my home, so do you have any idea as to when you might be adding support for Bobcat environmental sensors?

    Any assistance would be greatly appreciated, as I seem to be finding more pitfalls and roadblocks everyday in this HS2->HS3 migration.

    Leave a comment:


  • Michel
    replied
    Ocelot in HS3

    Good job to the peoples behind the plug-in.

    Since there is finally a plugin for HS3 some of you might be interested in additional components including (1) Ocelot, Bobcat, RLY8 etc..

    Take a look at :

    http://board.homeseer.com//showthread.php?t=180632

    Michel

    Leave a comment:


  • bbowser
    replied
    Originally posted by BeePee View Post
    Hi thanks for a plugin that has held me up making the transition to HS3.

    I am however having a issue with the computer resources the plugin is using.

    My system.
    HS3 3.0.0.258
    Win7
    Ocelot + 3 SECU16 + 1 Bobcat all connected via USB to Edgeport Serial box.

    My system slowed down to the extent that I had to run taskmanager to check what was going on.

    I noticed CPU at around 100% and Network also at 100mbs.

    GTS was using more CPU than HS3 around 30% each. but the interesting thing was the Network.

    When I disabled the CPUXA plugin CPU load returned to 16% and network back to 10mbs.

    I tried rolling back from .30 to .18 but it made little difference. I'm really scratching my head as to why the network went so high as ocelot coms is serial.

    Has anyone else experienced this issue?

    Any help appreciated.
    Yes BeePee, there is another user with a similar issue. I am looking into the problem now and hopefully will have an answer later today.
    Bruce

    Leave a comment:


  • BeePee
    replied
    Resource hungry

    Hi thanks for a plugin that has held me up making the transition to HS3.

    I am however having a issue with the computer resources the plugin is using.

    My system.
    HS3 3.0.0.258
    Win7
    Ocelot + 3 SECU16 + 1 Bobcat all connected via USB to Edgeport Serial box.

    My system slowed down to the extent that I had to run taskmanager to check what was going on.

    I noticed CPU at around 100% and Network also at 100mbs.

    GTS was using more CPU than HS3 around 30% each. but the interesting thing was the Network.

    When I disabled the CPUXA plugin CPU load returned to 16% and network back to 10mbs.

    I tried rolling back from .30 to .18 but it made little difference. I'm really scratching my head as to why the network went so high as ocelot coms is serial.

    Has anyone else experienced this issue?

    Any help appreciated.

    Leave a comment:


  • mterry63
    replied
    I've been having some serious issues the past few days with the new version. I started a new thread in the upper level forum.

    Any help is appreciated.

    Leave a comment:


  • bbowser
    replied
    Originally posted by mterry63 View Post
    Some feedback after using a couple of days, mostly related to X10.

    Creating devices:
    You select the type (appliance/normal/extended, etc) when creating the device. It would be great if you could change this type without deleting the device and re-adding it. I picked the wrong type a couple of times (sometimes it was just a guess, some times I forgot there were 2 devices sharing the same device code). Deleting/re-adding is OK, but it breaks any events the device has been included in. If you could change the type on the fly you wouldn't have to fix events.

    Event options:
    You can trigger on arbitrary House/Device codes, but you can't send them. It would be great to be able to send "B" "All Off" for example. I have a "Goodnight" event that has to shut down multiple devices, and with the HS2 plugin or the HS3 X10 plugin you can send "All off" to an arbitrary house code. Currently I have to send off to every device.

    This would also be helpful for multiple device commands like B1, B2, B3, B/On. You could do that in the HS2 plugin.

    These are constructive, however. Great plugin so far!

    Those observations make good sense. I will add them to the list. Can't guarantee timing but the plan is to add capability in phases to end up with an HS3 plugin that surpasses what the HS2 plugins could do.

    I believe I have a fix for the occasional start up errors.

    We'll see what we can do to get something in the updater before the weekend is over.

    Leave a comment:


  • mterry63
    replied
    Some feedback after using a couple of days, mostly related to X10.

    Creating devices:
    You select the type (appliance/normal/extended, etc) when creating the device. It would be great if you could change this type without deleting the device and re-adding it. I picked the wrong type a couple of times (sometimes it was just a guess, some times I forgot there were 2 devices sharing the same device code). Deleting/re-adding is OK, but it breaks any events the device has been included in. If you could change the type on the fly you wouldn't have to fix events.

    Event options:
    You can trigger on arbitrary House/Device codes, but you can't send them. It would be great to be able to send "B" "All Off" for example. I have a "Goodnight" event that has to shut down multiple devices, and with the HS2 plugin or the HS3 X10 plugin you can send "All off" to an arbitrary house code. Currently I have to send off to every device.

    This would also be helpful for multiple device commands like B1, B2, B3, B/On. You could do that in the HS2 plugin.

    These are constructive, however. Great plugin so far!

    Leave a comment:


  • randy_h
    replied
    Thanks Bruce. Not a huge deal, I am not that far along. Understandable issue.

    When trying to update the plugin I kept getting this in the log:


    Updater Install/Update of package GTS CPUXA Ocelot failed.
    Updater Error Installation of package GTS CPUXA Ocelot failed. Try disabling the plugin first, then re-try the update.

    I had disabled the plugin with same result. Finally I had to rename the installed version to HSPI_GTS_CPUXA_OLD.exe in order to get a successful update. I suspect this is related to permissions on my server as opposed to an issue with the plugin or its updater technique.

    Anyway, back to adding in IR codes. Thanks for this plugin.

    randy

    Leave a comment:


  • bbowser
    replied
    Originally posted by randy_h View Post
    I am in the middle of learning all my remotes into the plugin and the Ocelot. I don't right now have plans for externally accessing the plugin, but if I did in the future, are you saying I would have to rebuild all my IR devices? (not necessarily re-learn codes but create new HS devices pointing to the correct Ocelot IR slots).

    If I understand correctly, I should stop right now, update the plugin, then start fresh to future proof myself against ever wanting to access externally. If this is correct, any chance of a updater script alternative?
    Unfortunately yes Randy... I apologize for the inconvenience. I don't anticipate this kind of issue in the future. Thanks again to mterry63 for finding this.

    And yes you won't have to relearn IR locations.

    Edit: Sorry I was on the road Would be faster for you to recreate rather that wait for me to come up with a script or internal function.

    Bruce
    Last edited by bbowser; March 6, 2016, 03:30 PM.

    Leave a comment:


  • randy_h
    replied
    Originally posted by bbowser View Post
    There is a new version (3.5.16065.18) in the updater that fixes remote plug-in access to device data. You will have to delete any devices created with 3.5.16059.1 if remote plugins will be accessing GTS CPUXA devices. I apologize for the inconvenience.

    Bruce
    I am in the middle of learning all my remotes into the plugin and the Ocelot. I don't right now have plans for externally accessing the plugin, but if I did in the future, are you saying I would have to rebuild all my IR devices? (not necessarily re-learn codes but create new HS devices pointing to the correct Ocelot IR slots).

    If I understand correctly, I should stop right now, update the plugin, then start fresh to future proof myself against ever wanting to access externally. If this is correct, any chance of a updater script alternative?

    Leave a comment:


  • mterry63
    replied
    In case it's helpful, my Ocelot is connected to an 8 port Comtrol RocketPort PCI serial card. It's been in the system for years.

    I've recreated all my X10 devices to this plugin, one thing I noticed was that the default button/slider layout is different than the standard X10 plugin. This plugin creates the control widgets as On/Off/Slider, where the X10 plugin creates control widgets as Off/On/Slider. Not a big deal, just different.

    Leave a comment:


  • bbowser
    replied
    Originally posted by mterry63 View Post
    Switched to the new version last night and I've seen a few errors in the log that I hadn't seen with the previous version. From the log:

    (Occurred early morning, so no changes to the system were being made)
    Mar-06 2:09:00 AM GTS CPUXA Error in FindDevice: Object reference not set to an instance of an object.
    Mar-06 3:57:07 AM GTS CPUXA Error in FindDevice: Object reference not set to an instance of an object.
    Mar-06 5:28:15 AM GTS CPUXA Retrying to connect to Ocelot in 4 seconds. This is 1 out of 5 tries.
    Mar-06 5:28:15 AM GTS CPUXA Error, GTS CPUXA Plug-in, Ocelot/Leopard not available.

    During this time I have the Homeseer X10 plugin with most devices configured through it, and a couple of test devices on the Ocelot plugin.

    In spite of the errors I'm going to take the plunge and migrate all my X10 devices today. Hope it works.
    Thanks!

    That is a com port communication issue I have seen when the plug-in is starting. I have seen that a few times but had not been able to pin it down. Restarting the plug-in has always worked. That is still on the list but haven't seen it in quite a while. I thought it may be an issue with the Quatech QSE-100 I'm connecting from on the Windows machines. Haven't seen that issue on Linux connecting from a PCI or USB serial port. I'll schedule some time to see if I can reproduce the problem and find a better way to establish the connection if it gets confused on startup.

    Bruce

    Leave a comment:


  • mterry63
    replied
    Switched to the new version last night and I've seen a few errors in the log that I hadn't seen with the previous version. From the log:

    (Occurred early morning, so no changes to the system were being made)
    Mar-06 2:09:00 AM GTS CPUXA Error in FindDevice: Object reference not set to an instance of an object.
    Mar-06 3:57:07 AM GTS CPUXA Error in FindDevice: Object reference not set to an instance of an object.
    Mar-06 5:28:15 AM GTS CPUXA Retrying to connect to Ocelot in 4 seconds. This is 1 out of 5 tries.
    Mar-06 5:28:15 AM GTS CPUXA Error, GTS CPUXA Plug-in, Ocelot/Leopard not available.

    During this time I have the Homeseer X10 plugin with most devices configured through it, and a couple of test devices on the Ocelot plugin.

    In spite of the errors I'm going to take the plunge and migrate all my X10 devices today. Hope it works.

    Leave a comment:


  • bbowser
    replied
    Originally posted by mterry63 View Post
    I did run into one odd thing that appears to be a problem. I use Tenholde's tenscriptaid utility, and it won't run after creating a device with this plugin. He created a tool called findbadeviceref listed here http://board.homeseer.com/showpost.p...6&postcount=19 and when I run it it hangs on the first device id created by this plugin.

    Oddly enough, that was also one of the issues with the Homeseer Ocelot plugin that only did I/O.

    It seems like something isn't being created that expected in the device object?
    I think I found the issue. Might be the PED (PlugExtraData) info I have in the devices causing tenScriptAid to lockup. It's a new feature introduced in HS3 and comes in very handy for plug-ins that have different device types doing different things. I use it extensively. I wrote a quick Sub that I can run with scripting to strip the PED from one device at a time. When I remove the PED from a device, tenScriptingAid runs as it should with the GTS CPUXA devices showing up. That's probably why the devices in the HomeSeer plug-in wouldn't work as they have PED info also. If you look at a device's config/advanced tab you can see if they have PED info in the Extra Data Store entry. You can see there that GTS CPUXA devices have 6 Named entries.

    Edit: More on PED here


    I have a PM into Ed to see if he has seen this before and if we can, between the two of us, get it resolved. I'll keep you posted

    Update: Ed got back to me and pointed me in the right direction. For now, if you can, put a copy of the HSPI_GTS_CPUXA.exe in the folder where tenScripAid runs and in a future update I will change the way I store PED data so remote plug-ins have access.

    Update2: There is a new version (3.5.16065.18) in the updater that fixes remote plug-in access to device data. You will have to delete any devices created with 3.5.16059.1 if remote plugins will be accessing GTS CPUXA devices. I apologize for the inconvenience.

    Bruce
    Last edited by bbowser; March 5, 2016, 11:21 PM.

    Leave a comment:

Working...
X