Adicon Bobcat temperature sensor

[derek]

Hi Scott,



Please send to [email protected]

Thanks

[derek]

For those watching this topic please see below latest message from Scott re this item.





Well it seems that my suspicion was right. The Leopard won't send a notification for analog changes, so the current approach won't work. I guess I will need to poll the Leopard and continually test the realtime data for changes. Seems a little stupid to have to do this, since they send notifications for other events.



I'll let you know what I come up with.

[JonFo]

...
Well it seems that my suspicion was right. The Leopard won't send a notification for analog changes, so the current approach won't work. I guess I will need to poll the Leopard and continually test the realtime data for changes. Seems a little stupid to have to do this, since they send notifications for other events.

...

The lack of notifications on analog changes is not too surprising, as it could result in a flood of useless notifications. Assuming they digitize to 8 bits, the values must be changing by a bit or more every time the input is scanned by the internal sampler.

Therefore, forcing the Ocelot user application to poll for current values is probably the best use of communications bandwidth.



For instance, I really don't need to know what variance in temperature might be with any frequency greater than 60 seconds. So That's what I'd poll the temp analog input at from HB.

[Timoh]

Hi folks,
Just wondering if any had made any advancement on get analog values from the ocelot into Housebot?
Thanks
Tim

[ScottBot]

Since polling is required to get the values, I have put this on hold for now.

[Timoh]

OK... I get it. Maybe I'll dust off my programmers hat... Just maybe. I was going to write something for my caddx panel so maybe it'll be a two in one project.

It did occur to me though that once we can poll ocelot "parameters" we should be able to use it for all sorts of things such as timers and variables too. Of course we will also need the ability to set parameters from HouseBot.

All of my lighting control is done from my ocelot. I would like to be able to set a variable in the ocelot from HouseBot to overide some lighting routines if I'm home. Or if a PIR from my caddx is tripped when not armed, be able to pass that info to the ocelot. Or set a temperature into a parameter and use my ocelot as a thermostat.

I think a device per ocelot parameter would be ideal. We feed in which ocelot/module parameter we would like to retrieve and the polling interval. For setting, maybe something like an interval of "0" would mean don't poll, but instead set the ocelot parameter to the value in HouseBot.

Thanks
Tim

[ScottBot]

Can you read the analog values from the Ocelot "parameters", or do you have to grab it straight from the real-time data?

[Timoh]

I believe you can read the values straight from the params. So for the Secu16, param 2 & 3 are used to determine whether an input is On or Off. The actual analog input data for inputs 1-8 is stored in param 10-17 of the module.

You actually need to issue two sets of instructions to the ocelot to get it. The command that sends the param to ocelot...
~~~~~~~~~~~~~~~~~~
Initiate Get Unit Parameters

->Send 8 binary bytes: <200> <31> <pnum> <0> <0> <0> <0> <csum>
<-Receive 3 byte header: <6> <0> <6>
Note: This command instructs the CPU-XA to retrieve parameter <pnum> from every unit

Data Explanation:
pnum = the parameter number to get
csum = the 8-bit sum of 200 + 31+ pnum + 0 + 0 + 0 + 0
~~~~~~~~~~~~~~~~~~

Followed by the command to dump the data to serial port....
~~~~~~~~~~~~~~~~~~
Get Unit Parameters

->Send 8 binary bytes: <42> <0> <0> <139> <180> <0> <164> <120>
<-Receive 6 byte header: <n> <n> <n> <n> <n> <n>
<-Receive 256 bytes data: <unit 1 Param LSB> <unit 1 Param MSB> <unit 2 Param LSB> <unit 2 Param >MSB> etc…
Note: this data is what is stored at parameter <pnum> in each unit
<-Receive 2 byte CRC <n> <n
~~~~~~~~~~~~~~~~~~

So if we had a device that we entered the module number, parameter number, and poll time, we'd be set. Send the first command with the parameter number, send the retrieve data command, strip off the header, count your bytes, et voila! We have our number.

You could code in the parameters of the inputs, bobcats, light sensors, etc for use friendliness, but not a requirement for me. In fact, I think it's a whole lot more flexible be able to grab any parameter I want from the ocelot modules.

I've tried it in realterm so I know it works! In fact I could do it with a generic serial device except the com port is tied up with the ocelot device. Which brings me to another (simpler???) idea in lieu of this...

A generic ocelot interface! Works the exact same way as the generic serial interface the data goes to the ocelot. This way, anyone can send strings/receive data to/from the ocelot. If it is an x10 or IR command, pass it off to the existing routines. If it is something not recognised by HouseBot, pass it off to the generic ocelot interface!

Tim