Ocelot Plugin Beta Release

[hoox]

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]

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]

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]

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]

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]

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]

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]

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]

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]

sorry hoox, which one is the ocelot 1.0.7, that I've to update?
thanks in advance.
regards.
Rik