HouseBot

Can I read/write Ocelot variables?

When HB starts, does Ocelot driver update current status of x-10 devices?
I mean when HB starts x-10 devices could be in ON or OFF states.
It looks like c-max software could show current status of x-10 devices in x-10 monitor window.

Nope... I asked this a while back and was hoping Scott would be kind enough to code into v3. But alas it did not appear.

I gather the issue is that info such as x10 received, IR and status change of an input are pushed to the serial port. But info such as parameters and variables need to be polled. We weren't exactly sure how often to poll and what to poll. Polling the entire Ocelot can take quite a while, so isn't really feasible.

I suggested having some properties in the HB Ocelot interface where you could set what you want polled and how often.

I am pondering writing my own plugin or the Ocelot to replace the standard one that comes with HB. I just have't gotten around to it since it's pretty low down on my list.

But I agree, it would alot more power to the HB/Ocelot combination. Even at a basic level the ability to read variable and parameters such as light, temp, humidity or any other analogue data your ocelot might be generating.

Tim

Also for x-10, status... I'm not sure... All of my devices are one-way. So when I turn on a light manually, the Ocelot has no way of knowing the status. But I believe this is not the case with two-way x10 devices which the Ocelot will pick up. I also believe their are some limitations with the ocelot knowing the status of devices that use x10 extended codes, but I believe this has more to do with your Ocelot/X10-powerline device.

That being said, it would be useful to read the parameters and variables of the Ocelot when HB starts.

Tim

I might still look into this. It just got misplaced.

Actually... the more I look into this, the more confused I get. Exactly what parameters are you wanting to get?

There is the Ocelot parameter data. But this just has configuration type settings that I don't think you would want to query or change.

Then there's 'module' parameter data. But this is NOT on the Ocelot. It is on network modules and is specific for each.

Then there's realtime data in the Ocelot. It contains the states of of the relays and even analog states.

But I don't know where, if at all, X10 states are stored.

1. I asked about variables at least.
I think Ocelot doesn’t inform external device when variable is changed, at least I can’t find this in Ocelot docs.
So I think we need to have something like HB device (in HB hierarchy) connected to Ocelot driver. In this device we can setup variable number in Ocelot list and property to load value from ocelot. Something like .ReadValue = Yes/True, when we set Yes/True HB reads/loads value from Ocelot once. So we poll Ocelot for variable value when we need it only.
We could write variable back to Ocelot when we change it value.

Maybe we also need to read parameters this way.

2. Yeah, some/many x-10 devices don’t support status request.
When Ocelot works it monitors x-10 states itself. When c-max software connects to Ocelot it seems to me it loads all monitored states and shows them in x-10 monitor window.
So I consider when HB starts it could do same way and loads collected x-10 states from Ocelot memory.

Yes... I did add some confusion to the the entire parameter variable thing. I'm under the impression that all variables, timers, etc are stored in undocumented parameter locations on the Ocelot. But we can forget about that for the sake of simplicity.

Looking at the Ocelot protocol, here's what I would like to see and might cover off bisoft's needs to.

1) Implement the Ocelot "Get Unit Parameters". This is top of my list since it would allow me to read the analog values of my inputs. I believe "Initiate Get Unit Parameters" is also tied into this. These parameters I would like to be able to poll at a fairly slow rate... Something like once a minute.


2) Implement "Write Unit Parameter Data". Not absolutely necessary, but would be useful. The Secu-16 units actually determine if a device is on or off be comparing the value on the input against a threshold value between 0-255. It would be nice to be able to adjust these threshold numbers directly from HB.

3) "Write CPUXA Variable Data" for controlling the variables in my ocelot. I would like to be able to match the "house mode" of my ocelot to my "house mode" in HB. A variable would be a good way of depicting this. Plus the many many other ideas I have on my list.

4) "Read Variables" for the same reason as above. This is not actually in the Ocelot protocol pdf which I saw, but can be found at
http://www.appdigusers.com/forum/showfl ... Post187542

5) Same for read and write timers. I'm working on a little tidbit right now that calculates my runtime of my HVAC components. I can either use HB to time when the input is ON or do it natively in the Ocelot and then read the timer into HB.

Not so sure about reading the x10 states from the ocelot. I know exactly what you are referring to in cmax. The only thing I could find was the "Get Received X10" but I suspect that will only return the last item, not all the x10 states the Ocelot knows about.

One way to do this if it can't be done with the Ocelot protocol, would be to write your x10 states to variables in the ocelot and then read the variables into HB.

We should ask the question over on the Ocelot board and see what they say. I believe it is do-able/readable since cmax behaves that way.

Tim

Scott,
Is this good/enough info for you?
Has it tickled your enthuiasm to add the features to the Ocelot?
Thanks
Tim

Timoh wrote:Has it tickled your enthuiasm to add the features to the Ocelot?

Yea, I actually started working on it. Then when I went to hook up my SECU-16 to my ocelot to actually be able to read/write module parameters... something went wrong. My Comms led doesn't blink, so I think my comms chip is blown. I ordered a new one, since it was a quick and easy solution. Hope it fixes it.

So you'll just have to be a little more patient.

Just to give you an update, after replacing the comms chip in both my Ocelot and SECU-16, it still is dead. So it looks like I'll need to send it in for repair. No telling how long that will take.

ScottBot wrote:Just to give you an update, after replacing the comms chip in both my Ocelot and SECU-16, it still is dead. So it looks like I'll need to send it in for repair. No telling how long that will take.

I see, I'm looking forward to your results...

OK. ADI repaired my SECU-16, so now things can move forward again. I've just started on your wish-list, so there's still more to come.

To install the new plugins, unzip this fileand copy Ocelot.dll in your \HouseBot\Plugins\Interfaces directory over the old dll (you might want to backup the old one first). Then copy ModuleParameterDevice.dll in your \HouseBot\Plugins\Devices directory.

Start HouseBot and create a new device that uses the Ocelot. You should see a new "Module Parameter" Device in the list. Create one (or more) of these and play with it.

Basically you set the Module # and Parameter # properties and then change the "Get Parameter" property to Yes. That will poll the Ocelot and return the data value in the "Parameter Data" property. Seems to work with the little testing I have done.

You can also set the "Parameter Data" value to something and change the "Set Parameter" property to Yes. This is supposed to actually set the parameter. However, it doesn't seem to work for me. I've double-checked the data that I'm sending and it looks 100% correct. I haven't asked ADI about it yet, as I thought maybe you folks that actually understand what all the parameters are and how they are used could shed some light on it. Maybe they are read-only values in the SECU ?? Anyway, play around with it and let me know how it works.

The device design is very simple. I didn't add a 'poll interval' property to have it auto update the values. I may later, but you can achieve this very easily with a Sleep Timer and a Task if you want.

I also considered having property values for each Parameter instead of having a Parameter Number property and Parameter Data property. The problem is that to populate all of the parameter data values would take a long time, as each one is a separate call to the Ocelot. So I figured you would typically be interested in just one or two and this would be more efficient.

Also, right now the values only return values from 0 - 255. I think I can return from 0 - 65535, but I wasn't sure if this was actually correct.

Scott, if I understand this correctly, and it works as you describe, this will be great. I have trouble setting relays in my SECU device to switch speaker zones on/off. Its pretty much "send-and-pray". The delay seems to be in the Leopard/Ocelot, possibly due to the looping nature of its program/OS. I've gotten around it somewhat be setting the relay's value several times in succession when a HB control button is pressed. But of course, (until your development) it was an open-loop system - no way to verify relay closure. I'll start playing with this next week.

Continually impressed,

I guess I have no excuse to left to build my temperature sensors now I can read the params.

Seriously... Thanks! I haven't tested yet, but will probably do this weekend.

Steve, Another idea will be to set a variable in the ocelot that would indicate if you want the relay open or close. Then you could write the code in the ocelot in order to ensure the relay is in the appropriate state.

I think Scott has only done params so far, but hopefully more is on the way. So once we get variable read/write, it might be a more reliable way to go.

Tim

Tim, I've abandoned using any code in the Leopard/Ocelot (other than the basic OS). I originally had the Leopard set up (pre HB) to do basic HA stuff. But for some reason, it became unstable, needing to be restarted periodically. Along about that time, Scott posted something on the ADI forum about HB. And I never looked back. Now all the Ocelot does is hardware interface for the SECU relay mod, IR, and X10. No user program is running; it just sits there dark and rarely gives me a problem. Not so with Windows sadly.