PDA

View Full Version : Ocelot Plugin Beta Release



hoox
June 20th, 2006, 12:59 AM
This is the ADI Ocelot/Leopard plugin for Girder 4/5, from Todd and I.

Any questions or suggestions are welcome.



Version 1.0.17: last Girder 4 plugin


The 1.0.5 manual from the Girder/manual folder still apply for the configuration and the actions.



Version 1.1.x: Girder 5 Component


Check the examples GML for Lua functions or ASCII messages usage.

Promixis
June 20th, 2006, 02:15 PM
Mind if we include this with the G4 distribution?

hoox
June 20th, 2006, 08:10 PM
Of course you can, Mike.

Actually, we could do it because of your substantial upstream work.
Thanks again for all the help.

Promixis
June 20th, 2006, 08:45 PM
thanks!


will

Promixis
June 20th, 2006, 08:45 PM
thanks!


will add

Todd Reed
June 20th, 2006, 11:51 PM
Yes, thanks Mike and Hoox!

Now I can turn on my Spa from my remote computers using Webserver and Ocelot plugin!!

Now, on to the ADI Device manager, to enter and use IR, Relays, Timers and Variables - by name!

:)

rpal
July 28th, 2006, 01:32 AM
Hi Todd, I'm trying your Ocelot.
Just a question. How to control the inputs from SECU-16 SECU16I connected to the Ocelot? on your manual is mentioned (1st page) that supervised inputs are managed. I've to control for security some switches connecetd to these inputs.
I'd like to avoid any polling of variables from G4 (if possible). So I expect that Ocelot can send an event (I hope not thrugh ASCII Message Module) and G4 can be informed of this.
thx in advance.
Rik

hoox
July 28th, 2006, 08:37 PM
Rik,

Can you check that "Auto Receive I/O Events" is enabled in the plugin configuration?
The Ocelot will notify Girder if an input status changes.
The plugin updates ADI.Module[#].IO table, and triggers Events like "Module#1 I/O#0 = true" or "Module#1 I/O#0 = false" if it changed.
So, the status should be visible in the variable inspector, and the changes in the logger.

The ASCII messages don't need any module. You must send them to "Master Unit 0" with C-Max.
By using them, you can avoid almost any recurrent polling.
For example, it can be useful for relays status changes, as there's no built-in notification when the change comes from the C-Max program.
After setting the relay, the Ocelot can send a message like "Event:UpdateIO pld:" (prefered message syntax even if you don't want to pass a variable)
The Event "UpdateIO" can trigger a script holding "Ocelot:GetIO()" (not documented, sorry) to update the I/O table.
Obviously, these messages can help in many other situations...

rpal
July 29th, 2006, 02:30 AM
ok Tedd, this is fantastic. So Ocelot will notify me about an input status change (I forgot that it can do this...). I agree difeerent is about the status change of relays, but I should program the ocelot to instruct it, in case of relay chage, to send the ascii message you suggested.

fine with me.

now another question: I'm going to purchase 2 bobcat temp to monitor inside and outside temp and I'd like to show it on my girder wesite.

I assume that I should program the ocelot to read the temperature ftom the bobcat (an example is provided in the last ocelot manual on the adicon website) and send an ascii message to G4. Is it this correct? if yes, which frequency is correct? every minute (or five), probably is ok, but it is very difficult (too many if statements) to check if one (or five) minutes have been passed and the ascii message can be send. any suggestion on this?

thanks in advance.

Rik

hoox
July 30th, 2006, 12:30 PM
I agree difeerent is about the status change of relays, but I should program the ocelot to instruct it, in case of relay chage, to send the ascii message you suggested. Girder will automatically update the I/O status when you use 'Ocelot:SetRelay' or the 'Set Relay' Action.
A C-Max program will only set a relay.
It's something you should be aware of, when you'll choose how to program C-Max to notify a relay status change.
Also, Ocelot Parameter 25 value is important with ASCII messages. What's your's?


I assume that I should program the ocelot to read the temperature ftom the bobcat (an example is provided in the last ocelot manual on the adicon website) and send an ascii message to G4. Is it this correct? You're right, it could be done with a timer and ASCII messages with C-Max.
However, I would use the ASCII messages only for things like threshold notifications.
Reading the Ocelot variables would make more sense here, as you can find the Bobcats data among them (they can be changed with Ocelot Parameter 1).
Girder can load all the Ocelot variables and parse them in a snap, with a single script.
This way, you would'nt need to add code in C-Max for this monitoring. That's also nice if you want to add more Bobcats/variables later.
IMHO, that seems faster and could make refresh your web page easier.
There are numerous time and schedule options available in Girder to set the update interval (five minutes suffice if you only want the temperatures).

hoox
August 27th, 2006, 03:47 PM
Posted Ocelot Plugin beta 1.0.6.

It works only with Girder 4.0.6 or newer versions, and is not a minor update indeed.
Some Lua functions changed to fit with the new serial plugin.
See GML for details, as the manual is not yet updated.

rpal
October 12th, 2006, 12:44 AM
Hoox,
I've this need.
My house has 2 floors with 2 different power cabling and 2 different measuring devices. in other words they're completely separated one each other.
On one floor, I'm using the plugin with one ocelot connected and I'm able to send / receive x10 cmds for this floor.
Now, I've to connect a second ocelot to manage x10 on the other floor, but the pc running the girder is the same.
I'm able to do this because ocelot devices are connected via remote virtual serial ports managed by tibbo devices.
The question is does your plugin manager more then one ocelot device connected to it? if not what could I do to satisfy my requirement to manage x10 comds on 2 separate power networks?
thx in advance.
Rik

Todd Reed
October 12th, 2006, 02:51 PM
Hoox, Mike, correct me if I am wrong...

Since the plugin uses the default X10 device manager, It will send X10 to whatever X10 interface is enabled. It will not distinguish between controllers.

As for Ocelot specific commands, if the two Ocelot controllers are set up master/slave then you can choose which unit to send IR to, and set relays for, but other things like getting a variable or timer defaults to the primary Ocelot.

If you have an ADI Master/Slave configuration, then the ADI Master can request a Slave variable or timer, and then read this using the plugin.

But, I am not sure how safe it is to manage X10 remotely, and not be able to see what is going on! :)

hoox
October 12th, 2006, 05:12 PM
Since the plugin uses the default X10 device manager, It will send X10 to whatever X10 interface is enabled. It will not distinguish between controllers.
Actually the X10 and Ocelot/Leopard treescript actions should send only to the first Ocelot (lowest Com port probably), but if it's ok for Rik to handle the second from Lua, it should be doable.


As for Ocelot specific commands, if the two Ocelot controllers are set up master/slave then you can choose which unit to send IR to, and set relays for, but other things like getting a variable or timer defaults to the primary Ocelot.
Ok, then the plugin needs some changes to have all functionality with more than one master Ocelot.
Rik, is this what you need (2 master Ocelots)? If so, can you please give a first try with the attached file?
When you add another Ocelot instance, the global name has the com port number suffixed.
Can you tell us if the following works? (for an Ocelot on Com4):

Ocelot4:SendX10('A',1,'ON') And, as both Ocelots will share the same Girder/X10 device manager, I guess that you use distinct housecodes for each floor?

Note:
I may have missed something, so LogLevel is maxed.
For now, all Ocelots have the same settings (parameters)
ADI table content is also inside the Ocelot object itself (modules, timers, variables, clock). ADI table is only for the first Ocelot.
The default Events are the same as the first Ocelot, but the Ocelot's name is in payload 1 (or pld2).
So you can use the source object in a script with e.g:


local thisocelot = _G[pld1]
if pld1 == 'Ocelot' and thisocelot then
thisocelot:SendX10('A',1,'ON')
print(thisocelot.Var[1], thisocelot.Module[1].Data)

elseif pld1 == 'Ocelot4' and thisocelot then
thisocelot:SendX10('B',1,'ON')

end

rpal
October 13th, 2006, 01:02 AM
Actually the X10 and Ocelot/Leopard treescript actions should send only to the first Ocelot (lowest Com port probably), but if it's ok for Rik to handle the second from Lua, it should be doable.


I' using Lua in complex tasks (e.g. heating), but for simpler one, it is very useful for me to have x10 devices defined with treescript and UI and manage them in this way ...


Ok, then the plugin needs some changes to have all functionality with more than one master Ocelot.
Rik, is this what you need (2 master Ocelots)?

2 masters is the ideal for me, because they're on 2 different floors and it's very difficult for me to wire them as master / slave.


... If so, can you please give a first try with the attached file?
When you add another Ocelot instance, the global name has the com port number suffixed.
Can you tell us if the following works? (for an Ocelot on Com4):

Ocelot4:SendX10('A',1,'ON') And, as both Ocelots will share the same Girder/X10 device manager, I guess that you use distinct housecodes for each floor?

In principle this could work for me. I'm not able to test it before next week, becuase I'm currently working abroad. In lua script, I've to manage the com port number (adding it to my xml ini file) and compose the ocelot# name ...

... but anyway I can use treescript / UI only for the first ocelot, so the second one can be manageable only from lua ...

... it seems that what is missed in the current plugin, is the capability to configure and manage more then one ocelot ... the ideal whould be to have another field in the x10 device to select the available ocelots (so the name of the device should be (ocelot + location + name or something like this). But I understand that this UI dialog is for all X10 devices, not only for ocelot. Is it impossible to associate the ocelot name to a specific device elsewhere?

Yes, I use distinct housecodes for each zone / floor.



Note:
I may have missed something, so LogLevel is maxed.
For now, all Ocelots have the same settings (parameters)
ADI table content is also inside the Ocelot object itself (modules, timers, variables, clock). ADI table is only for the first Ocelot.
The default Events are the same as the first Ocelot, but the Ocelot's name is in payload 1 (or pld2).
So you can use the source object in a script with e.g:


local thisocelot = _G[pld1]
if pld1 == 'Ocelot' and thisocelot then
thisocelot:SendX10('A',1,'ON')
print(thisocelot.Var[1], thisocelot.Module[1].Data)

elseif pld1 == 'Ocelot4' and thisocelot then
thisocelot:SendX10('B',1,'ON')

end

Ok to get the ocelot source name. But, if I rightly understood, the ADI Table is only for the first Ocelot. This could be an issue for me, becuase the 2 Ocelots manage 2 different heating systems, one for each floor (and probably in the near future more then this), and I use 2 BOBCAT to read the temperature for each floor (???).

thanks for all your support.

cheers.

Rik

rpal
October 13th, 2006, 08:50 AM
Hoox, I've noted with the last plugin and the last girder, when you try to create a new action from the Ocelot/Leopard Group, or when you try to open examples in the Group 'Ocelot UI Tests' of the 'ocelot examples.gml', the girder always terminate in abnormal mode.
I've this error on 2 different pcs, where I come from the previous version of the plugin (1.02?).
thx.

rpal
October 13th, 2006, 08:53 AM
I'm not sure, but probably this error comes from the last girder version, because I was able with previous girder beta to access to the UI Tests you provided....

rpal
October 13th, 2006, 09:23 AM
Hoox, I did a quick test about the above abnormal gireder termination.
4.0.8.1 and 4.0.9.0 Beta works fine. the issue is in the last 4.1.10 definitively.
cheers.

hoox
October 13th, 2006, 05:48 PM
The last Girder version is 4.0.12, please try with it, there had a DUI bug in 4.0.10 apparently.
When you install Girder, Ocelot.lua is overwrited to 1.0.5. Make sure that you replaced it in plugins/serial directory with the file attached above (1.0.7).

The X10 manager and X10 UI doesn't allow to choose the interface for sending, but it could be relatively easy to assign some housecodes to a specific Ocelot. Would it be ok for you?

But, if I rightly understood, the ADI Table is only for the first Ocelot Yes, but ADI table is just kept to not break things, now each Ocelot has his variables, modules data etc in his Object.
For example when executing Ocelot4:GetVariables(), Ocelot4's variable 3 value should be in Ocelot4.Var[3]

rpal
October 15th, 2006, 12:24 PM
sorry hoox, which one is the ocelot 1.0.7, that I've to update?
thanks in advance.
regards.
Rik

rpal
October 15th, 2006, 01:11 PM
Hoox, 4.0.12 works properly. I need only to know which is the properly ocelot version to install now, as per my previous message.
rik

hoox
October 15th, 2006, 04:25 PM
Please try with these files.
Ocelot.lua is for plugins/serial directory.
OcelotSettings.lua goes in luascript/startup folder. Edit in it the Ocelots names according to your setup.
When sending X10 from Girder, the plugin should use the matching Ocelot(s).

rpal
October 15th, 2006, 04:50 PM
Hoox, does this means that I associate an hous code with one or more ocelot and when I'll send to this hc, girder will execute the x10 cmd on one or more ocelot?
In this case, do I have to specify different ocelot names (e.g. Ocelot4:send()), as we discussed in previous messages? or do I have to specify simply Ocelot:Send() and the plugin will read the table in the startup directory and will address the appropriate ocelots?
Rik

hoox
October 15th, 2006, 05:40 PM
Hoox, does this means that I associate an hous code with one or more ocelot and when I'll send to this hc, girder will execute the x10 cmd on one or more ocelot?
Yes.
This was intended to be used by the X10 Actions (UI).
From Lua, using Ocelot:SendX10(...) will have the same behaviour.

Of course, you can still make another Ocelot than the one named 'Ocelot' send any housecode if you use it directly e.g Ocelot3:SendX10('F',1,'ON')

rpal
October 16th, 2006, 12:43 AM
Sorry for this further question Hoox, but I'm not at home, so I need few days before to test the new plugin.
If I use from Lua simply Ocelot:SendX10() (without specifying Ocelot3: or Ocelot4:), due to the table in the OcelotSettings.lua, it will works anyway, sending x10 cmds to the proper ocelot(s)? and the same should be from UI.
this is very important for me, because, this is the easiest way to manage more then one ocelot from Lua, as well as, from UI.
cheers.
Rik

hoox
October 16th, 2006, 03:22 AM
That's exactly how it should work.

hoox
November 4th, 2007, 02:53 PM
Version 1.0.17 is available in first post.

It has lots of bug fixes.

An existing GML should not need modifications unless that it uses the Ocelot:Get... Lua functions.
Also, to improve the ASCII messages reliability, their syntax has changed.
Details are in the examples GML.

hoox
November 4th, 2007, 02:55 PM
Ron,

for many reasons it is preferable to use these files instead of those currently installed with Girder.
Is it possible to make a refresh in the Girder 5 installer?

jwilson56
January 11th, 2008, 04:06 PM
Is this plugin working for Girder5?

John

Todd Reed
January 12th, 2008, 11:34 PM
Yes, I have it working, but I still have problems with G5.

I get G5 stalling periodically, and a "que full" message once in a while, when sending Ocelot data via com port.

The Ocelot plugin is very powerful, give it a try. I download internet data like stocks, weather, then display on my Leopard screens!

hoox
January 13th, 2008, 04:37 AM
Is it stalling when you download the Internet data or randomly?

You must do pretty intensive stuff to see the 'Que Full' message! Or is there anything unusual in the log before that?


@ John,

As mentioned previously, I would simply not recommend using the version that comes with the Girder installers: It's the first G4's version and does not work well, particularly with the latest Ocelot firmware.

Actually, it may be better if the plugin was removed from the G5 installer, as those who want to use another version currently have to replace the files after each Girder installation.

jwilson56
January 14th, 2008, 07:24 PM
Ok I don't have an Ocelot yet. I am looking to get the Ocelot and the SECU-16IR for IR use and the SECU-16I or SECU-16 for digital input/output.

Could you post the functionality for the G5 plugin.

For instance:

Can I have an analog input monitor a voltage and have an event triggered when the voltage goes to zero or some other threshold value I specify?


John

hoox
January 15th, 2008, 05:31 AM
The features are in the Ocelot Plugin.pdf in your Girder5/manual folder. Only some Lua commands changed slightly.

Just be aware that the Ocelot operation (e.g. IR) is not very fast. It's ok to get things done though.


There are several ways to monitor an analog input...

The simplest would be to set the module's analog threshold parameters, the events should then be triggered automatically. But these parameters seem to apply for all analog inputs, and these can't be changed dynamically from Girder.

Alternatively you could add a few lines in the C-Max program to send a custom event to Girder depending on variables conditions, including the analog value.

jwilson56
January 23rd, 2008, 07:08 AM
Ok I have the Ocelot installed with the SECU-16IR and have it all tested out fine. I am now going to install the SECU-16I module. I would like some help in setting up a an input that will monitor a LED light. I would like to see an event in Girder when the light goes off. The light is normally off and then will go on but I want the event when it goes back off. Could someone help me with the CMAX code and the Girder code to get me moving in the right direction.

Thanks

John

hoox
January 24th, 2008, 12:24 AM
Normally this plugin only supports supervised inputs, but I guess it is possible to do.

So, your analog input will have a source that will be either 0V or 5V?

jwilson56
January 24th, 2008, 05:30 AM
I read on page 7 that you can us an ASCII message to trigger an event. I would presume you write a CMAX routine to watch the analog into and then send the message "Event:LEDOFF" when the light goes off (sending it once). It this not a correct assumption?

John

hoox
January 24th, 2008, 07:16 AM
Yes, you could do something like that...
Remember that the latest plugin version has another syntax for these messages, so it would be ">>LEDOFF<<" (see the examples GML).

I'll try to setup a generic example for analog inputs (with 2 states) shortly.

hoox
January 24th, 2008, 06:24 PM
Well, here is a start. It's a bit complicated, but then you should be able to read the analog input value and change the thresholds all from Girder.

In your C-Max program add code like:

IF Module #2 -SECU16I Analog #1 is < 512 --always true (max = 256)
THEN Load Data to: Variable #1 --you can read it from Lua

IF Variable #1 becomes < Variable #2 --Low threshold (0..256)
THEN Send Ocelot Message 0 w/ Variable #1 --the message could be ">>LED OFF pld:%u<<" (not "Event:LEDOFF")
IF Variable #1 becomes > Variable #3 --High threshold (0..256)
THEN Send Ocelot Message 1 w/ Variable #1 --the message could be ">>LED ON pld:%u<<"- In Comms->Attach to the controller->Module Utility->Retrieve Module Parameters:

You could set the module's parameters 2 and 3 to 0, so that the Ocelot will not send notifications that are useless for analog inputs.

The Ocelot Parameter 16 will then have no effect for this module (you will use ASCII messages instead).

So, if you want to use supervised inputs at the same time with this module later, you'll have to consider them as analog inputs (using in C-Max: 'IF Module / Param'...'Analog #' instead of 'IF Module / Point')
Of course, before changing any module parameter with C-Max, take note of the current value.
And to change any module parameter, you will have to type a password... It is the module#1 parameter#6 value.

- With 'Debug Timers and Variables', set variables #2 and #3 to 128 and 127 for a start.

- Define and download your ASCII messages.

- Download the C-Max program.


Then, the Events should work in Girder, and you should be able to easily adjust the threshold variables (here #2 and #3) with Ocelot:SetVariable().

To read the analog value you could do:

Ocelot:GetVariables(function(v)

local analog1 = math.round(v[1] * 5/256, 3)
local lowthreshold = v[2]
local highthreshold = v[3]

print('Analog Input1 =', analog1, 'Volts', 'Low='..lowthreshold, 'High='..highthreshold)

end)

jwilson56
January 28th, 2008, 09:18 PM
Will the respective Event message repeatedly be sent so long as the value remains above or below the thresholds? Still trying to get a handle on the flow and operation of the CMAX code.

John

hoox
January 29th, 2008, 01:19 AM
They will be sent only one time because the 'IF ... becomes ...' test will be false on next pass.
Most of the time you should use conditions with 'becomes ...' or 'Turns ...'.

The 'IF/AND/OR ... is ...' test must be used carefully, as the condition can be true several times per second.
It is generally used with other conditions (AND) that cannot produce continuous events.
Loading modules data into work variables is a common exception to this.

jwilson56
January 29th, 2008, 11:00 PM
Well I started simple with a Phone Hook Status project that uses a supervised input with an optocoupler coupling the phone hook circuit from the Ocelot. Everything worked great using this program.

IF Module #2 - SECU16 Input #0 Turns ON
THEN Send Ocelot Message 1 w/Variable #0
IF Module #2 - SECU16 Input #0 Turns OFF
THEN Send Ocelot Message 0 w/Variable #0
END Program

Girder now knows when the phone is picked up and when its hung up. I can now un-pause any of my 5 zones of music that might have been paused when the CallerID paused them.

Thanks for a nice plugin and your help.

John

hoox
January 30th, 2008, 01:17 AM
Really great!

That's probably the best way for this application.

jwilson56
September 13th, 2008, 11:02 PM
Has anyone tried the Bobcat Humidity sensor with the Ocelot and read it with the Ocelot plugin?

http://www.comm4all.com/media/products/0620323001105668343.pdf

hoox
September 14th, 2008, 10:31 AM
To read it, let's suppose that it is the module number 1, you would use:

Ocelot:GetModules(function(m)

local humidity = m[1].Data - 100
--your code

end)Try table.print(m) to see all the modules.

Also, if you are a courageous tester, you can try with the version 1.1.0 that is a G5 Component.
It will create DM devices for the Bobcats (not all tested). Updates are automatic if you enable 'Poll Modules' in the settings.
But I have to warn you that a few things changed... In particular most of the Events are now Device Manager Events.

jwilson56
September 21st, 2008, 05:11 PM
Ok thanks for your reply... I got side tracked this past week but I am hoping to hook up my Bobcat this week and try this. I will backup Girder and try your 1.1.0 and let you know what I find.

Right now I have:

1 - SECU-16
1 - SECU-16I
1 - SECU-16IR

I have two Bobcat Humidity sensors I need to hook up.

I will get back to you.

harleydude
September 22nd, 2008, 11:17 PM
Hoox,

How do you handle IR with the new version? Is there a way to enter meaningful info about what IR codes are?

1 = Receiver Off
2 = Receiver On
etc..

hoox
September 23rd, 2008, 01:54 AM
It still works with numbers.
Do you mean in the GML Actions? If so, that could be easy to do (I don't think that we can export this to the Device Manager).

hoox
September 24th, 2008, 02:37 AM
Ok, that was simple. The IR names can be changed in version 1.1.1.
The DM 'Send' controls are only using the custom names.
To remove an item from your list, just set it to an empty string.
These names are simply saved in the Ocelot.cfg file.

jwilson56
October 8th, 2008, 09:10 AM
I need to get back to my Ocelot now that I have the Elk online.

I have a question about the IR receiver. Can the Ocelot be used to receive an IR code from a remote and then run an event? Does this require any CMAX code? Will the plugin handle this?

Thanks

hoox
October 8th, 2008, 09:41 AM
You can learn the IR code with C-Max, and enable the 'IR Events' option in the plugin config.
Do not learn to IR#0, there's a bug in most Ocelots, so the plugin doesn't trigger Events for this one.

Todd Reed
October 9th, 2008, 10:06 AM
I use this all the time.

I have my IR codes "learned" in CMAX but I also have my Ocelot hardwired to a Xantech IR system. So, from anywhere in the house I send IR to a Xantech IR receiver, which also sends it to the Ocelot, then using Girder I trigger an event.

You can trigger a Girder event with any Ocelot IR, X10, or I/O change.
I will get some samples posted tonight!

jwilson56
October 27th, 2008, 05:09 PM
You can learn the IR code with C-Max, and enable the 'IR Events' option in the plugin config.
Do not learn to IR#0, there's a bug in most Ocelots, so the plugin doesn't trigger Events for this one.

Anyone know of a way to copy IR codes from 0 to 10... I used 0 and it was working fine but the new plugin will not allow me to use it. Its a discrete code I had learned from my Slink-e before I sold it so it will be hard to get it again.

Also I could not seem to get the Disconnect from Ocelot to work with the new version of the plugin


Edit: Found IR-MAX utility and was able to copy the IR code. Also the newer version lets you shorten the IR list down so it doesn't take all night to download.

jwilson56
October 28th, 2008, 03:07 PM
Tod

How did you hardwire your Xantech IR into the Ocelot?

jwilson56
October 29th, 2008, 03:08 PM
Well I am loving this new version of the plugin... great job!!!

hoox
November 2nd, 2008, 12:19 PM
Thanks for trying it!

It appears to be stable enough for us. We will update the manual as soon as we can.

jwilson56
November 2nd, 2008, 02:30 PM
Well I am close to getting my power monitor status box done. It will let me know for sure what amps are on. I will also have a Ocelot based watchdog for my Girder server using the Ocelot SECU-16 relays


Also I look forward to seeing the manual.

jwilson56
December 4th, 2008, 01:46 PM
Hoox have you updated the manual for the latest version? I have a guy with an Ocelot that is looking to use Homeseer and I was telling him about this great plugin.

freezer
January 25th, 2009, 08:20 PM
I am having trouble getting the ocelot plugin (V1.1.4) working under G5;
I am using a serial-ethernet bridge (with virtual com port installed on the computer running Girder); under G4 it works fine - both X10 and IR commands are handled just fine. However, when I upgraded to G5 it seems there might be a timing issue - When I go to define the ADI/Ocelot in component manager, I get a message saying "Ocelot found (initializing)"....but nothing else; When I look in the log I get:
Ocelot connected to Com 3 (v1.1.4)
Ocelot command failed after 5 attempts......(this is repeated multiple times)

Any suggestions ? thxs.

hoox
January 26th, 2009, 09:32 AM
Hoox have you updated the manual for the latest version? I have a guy with an Ocelot that is looking to use Homeseer and I was telling him about this great plugin.
Unfortunately the manual is not finished yet, but we can always help here.


I am having trouble getting the ocelot plugin (V1.1.4) working under G5;
I am using a serial-ethernet bridge (with virtual com port installed on the computer running Girder); under G4 it works fine - both X10 and IR commands are handled just fine. However, when I upgraded to G5 it seems there might be a timing issue - When I go to define the ADI/Ocelot in component manager, I get a message saying "Ocelot found (initializing)"....but nothing else; When I look in the log I get:
Ocelot connected to Com 3 (v1.1.4)
Ocelot command failed after 5 attempts......(this is repeated multiple times)

Any suggestions ? thxs.
Yes, that looks like a timing issue.
You can see more details during the connection in the Lua console if you enable the 'Log All Serial' option.
Then open the plugins/serial/Ocelot.lua file and change IncompleteResponseTimeout at line 226 to higher values (e.g. 100).
Save it and reset the scripting engine. Please post the Lua console output here.

freezer
January 26th, 2009, 04:10 PM
Hoox - thxs for the suggestion; still no luck -
I set IncompleteResponseTimeout to a value of 150

Attached is the console log

freezer
January 26th, 2009, 06:22 PM
Hoox - did some more testing and I think the problem is solved;
I changed applications I was using to create the Virtual Serial Port (from Lantronix Device Com Manager to EterLogic VSPE) which seemed to solve the problem.

Thxs for giving me some clues...

hoox
January 27th, 2009, 08:22 AM
Good to know that it works with these adapters. I have to admit that the many commands failures didn't seem promising.

hoox
January 27th, 2009, 10:06 AM
Version 1.1.5 is uploaded in first post.

Fixes/changes:

- The DM devices were not updated after a reconnection.

- The 'Switch COM Port with C-MAX' feature from this examples GML should noticeably reduce the CPU time for all events, as it doesn't use any Window Conditional.

- The 'Ocelot Lua' group in the GML shows how to do custom devices handlers.
They are primarily useful to limit the number of Girder Events for devices that have a value changing frequently (e.g. analog values).
So you can define any conditions before triggering the default Girder Events, or not use them at all. The CPU usage is then lower, as there are less GML lookups, etc.

hoox
February 8th, 2009, 01:35 PM
Version 1.1.6:

- Fixes the behaviour with incomplete responses. They generated false events in some circumstances.

- Added the licensing terms (LGPL).

splashdwn1
November 13th, 2009, 08:52 AM
I see several references in the forums to an Ocelot plugin manual, but so far have been unable to locate one. Is this available anywhere?

I'm having an issue where for some reason when I click on learn for IR codes Girder never recognizes a code. I actually created a GML on another computer where it worked fine, but when I moved to my HTPC there seems to be no learning. If I use CMAX, it learns the code and Girder also recognizes the codes learned from the other PC and fires events as usual usign that GML - just won't learn any - no log entry or anything.

I could very well have some setting wrong somewhere which is why I thought if there was a manual somewhere I could reference I may be able to figure it out.

jwilson56
December 4th, 2009, 10:47 AM
Anyone have any idea as to how to slow down the polling for the Bobcat Humidity sensors? I use two of them and they fill up my logger screen with updates every few seconds. I am trying to optimize my setup and looking at what each function is taking in resources.

Thanks