ADICON Ocelot/Secu/Relay Driver

[beelzerob]

This is a cut at a driver for the Ocelot, and attached Secu16, Secu16i, or the Relay8.

If you install this driver, it should be able to determine what devices you have and create fields for them automatically.

If you want to give names to the various inputs/relays, so something more meaningful than "Secu16I_0_Input5", then you can create a name file.

The name file must go in the MacroFileRoot\Drivers\Ocelot directory, and the name of the file must be <Moniker>_names.txt. So, if the moniker for the driver install was "Ocelot", then the file would be named Ocelot_names.txt

The format of the file is this:

<DeviceType_Address>,<Input/Relay Num><Name>
etc etc etc
END

So, here is an example file:
Secu16_2,Input6,2ndFloorSmBedroomSmoke_Alarmed
Secu16I_0,Input7,MasterBedroomSmoke_Alarmed
Secu16I_0,Input8,GarageWorkshopDoorClosed
END

There is an IP and a Serial driver. The driver file itself is the same, just the .manifest files are different. So you can download and install both if you want. When installing the driver, they are listed as "Ocelot (Dev)" and "Ocelot IP (dev)".

[znelbok]

Is it possible in a Manifest file to ask for which version is to be used, serial vs IP and go from there instead of having two separate manifests.

Well done though on this driver - the more the better

Mick

[beelzerob]

That would be great, as I'm about to add the same IP/Serial option to the datanab, RCS, and other drivers. I agree, it is a pain having multiple manifest files. Thank goodness at least the CML itself is the same.

Dean...????????

[Dean Roddey]

Right now, no, it requires separate manifests, so that the correct initialization method can be called.

[beelzerob]

well, I think we know the *right now* case , but I'm more interested in the *sometime soon* case. Is this likely to change at some point?

[jrlewis]

It looks like you are providing the ability to custom name fields. In general this is a poor idea for portability of interface templates. For a single integrator every installation requires mucking with fields in the interface. I have been looking at all the lighting drivers and I think all of them are offenders on this point and it makes it difficult at best to generalize/abstract the user interface from the underlying drivers. Unless the underlying hardware supports the same type of functionality of renaming i/o then I would shy away from it. You are better off just including an extra field for each i/o group that is the name that can be used as a human readable field in the interface. The new "uber driver" may mitigate some of this, but having a systematic naming of fields is a better way to go.

[beelzerob]

I guess I fail to see the threat to uniformity, given that it is merely an option, and probably strictly of use for the DIY crowd. I've lobbied for some time for a better means of naming fields in a meaningful way, but nothing appears on the horizon.

You're encouraged during driver load to name your monikers in a meaningful way, and "easily recognizeable". While I know that Ocelot.Input3, Ocelot.Input4, Ocelot.Input5, etc might be very standardized, it is a burning poker in the eyeball when it comes to using them in interfaces, actions, events, etc as I'll have to constantly look them up to remember what they were. With 32 inputs from the datanab and 16 from the ocelot...I see no reason to put myself through ambiguous hell when I don't have to.

I dont put the option for custom-naming fields in all my drivers. Obviously in the audio receivers category, it'd be stupid to name "Volume" as something else. Those are all self-naming as to their purpose. But the I/O and lighting categories just present too much hassle to me when it can so easily be avoided...if I *choose* to. None of my drivers require a naming of fields (though the datanab requires a config file, or else it wouldn't know what types of sensors those are), and it'll provide generic names in the absense of such.

Perhaps I'm misreading what you mean....but if the issue is the portability of templates, then Im the one shooting myself in the foot, right? If I find that my custom naming of fields is making it impossible for me to make use of some REALLY snazzy templates....then I'm probably going to stop the behavior. But I'd still be glad to have the option.

And as always, a CQC-native solution would of course be better.

I had asked before how the integrators handle having, say, 10 Datanab32's at a project. How do you keep track of 320 generically named inputs? I never got an answer.... So I answered myself.

[jrlewis]

I have a driver that I have done for a bloke over in the UK I'm working on the html file for a very similar situation as this. The way you handle 10 ocelots is to make up a sheet that has all the mappings in it. Same goes for lighting. A lot of times i/o devices and lighting in particular are purposed for specific functionality. If the field naming is done in a systematic manner and you include the ability to do some custom mapping you can create a set of templates and that can be moved from installation to installation with only a need to change a few configuration files, but the templates remain the same. I have written custom drivers that handle the mapping and sorting out of names to provide a consistent field space for lighting in particular, but it is better if it can be handled in the driver itself.

For the DIY having custom named fields isn't an issue so you only have to worry about 1 system. For the CI's doing multiple installations it becomes more of an issue. There are a lot of new integration partners coming on board and they likely wouldn't be aware of the pitfalls of using custom named fields. Just so you know the way I tend to approach these types of things is how do make a core system that can be easily configured in 100 installations, 1000 installations, etc. even if I am just doing it for myself.

[beelzerob]

Originally Posted by jrlewis

The new "uber driver" may mitigate some of this, but having a systematic naming of fields is a better way to go.

I guess I'm still not seeing the gotcha here, since my drivers *do* have a systematic naming of fields. With no config file, they'll be named as generically and consistently as possible.

However, if you don't want to carry around a sheet of paper with your magic markings all over it, then I simply have the option of naming them something useful, which in my book makes any kind of interface or action logic immensely easier.

If you're an integrator, then you're probably not going to use the naming option.

In reality, i think my naming option in these drivers where field names are redundant and carry no useful info, is something that CQC should be doing, and hopefully in the future will. There should be a "real" field name and a "pseudo" field name, or at least someplace to put info on what the field is for. IMO.

[jrlewis]

For basic i/o devices you are going to have analog outputs/inputs and digital outputs/inputs. There may be some other special functionality, but that is the basics. If the driver only supports one device then no need for a device identifier. Analog outputs and inputs should be AOValue## or AO##Value and AIValue## or AI##Value. Digitals would be DIState## and DOState##. I prefer the numbering where the number follows the base name as it makes sorting in the field browser and other places better. The thing is for basic i/o analog and digital signals are basically the same whether its on an ocelot or an elk. Regardless of where it is they really should be named with a basic naming pattern I have shown or something someone else comes up with. If everyone followed that pattern and people called them on it when they were first publishing drivers it would make intermixing various i/o devices a non-issue as well as being able to transport templates from one system to the next. The uber driver may mitigate this, but if everyone followed a more uniform naming of fields for basic devices it would make things easier. Similar to the work that was done on the russound/nuvo (can't remember which) to bring the distributed audio more in line or at least have a common field space.