Premise Supported I/O devices

[beelzerob]

Just looking to see what general I/O type devices are currently supported by Premise, as I'm thinking I'm probably going to try Premise for monitoring my cousin's boiler. I'll need lots of I/O for that. The secu16 is a good choice, as it gives the digital inputs and relays. But does the secu16 or other ADICON devices handle reading temps (which takes analog inputs, right?)?

If I went with a Datanab, then I guess I'd have to write my own driver for it, right? From the looks of it (c++) that wouldn't be so bad.

 

[123]

I don't know much about ADI devices so I've attached a screenscrape of all the devices supported by Premise's ADI driver. You'll need an RS-232 to RS-485 converter to work with these devices since Premise talks to them directly and not through an Ocelot. A Lantronix UDS-10 can convert Ethernet to RS_485 or RS-232.

 

[123]

Attached is the associated page from Premise's reference manual.

BTW
I learned that the BOBCATT device measures temperature but it may not be suitable for the temperatures encountered in your application (max temp = 170F).

 

[beelzerob]

Interfaces with the secu directly eh? Well, that's kinda handy! Although I thought the scripting ability of the ocelot would be useful in this application....

RS485 to 232 interfaces are cheap and easy to get. The 170 deg F max temp might not be an issue, as I'm primarily talking about water temps, and I'm pretty sure his water doesn't get that hot. However, the datanab water temp goes from -70C to 150C...now that's some margin!

Interestingly the datanab would also need a 485 to 232 interface....can multiple 485 devices be accessed through that single 232 adapter (do you know?)

Otherwise, if I went with the datanab also....adding a new driver for Premise isn't rocket science, is it? I mean, it's just code and programming, right? Is there a helpful community for figuring it out, or will it be mostly DIY.

 

[BraveSirRobbin]

Before deciding on any system take the entire picture into account. For instance, what accuracies are required for the application? If you are looking say, for small temperature differences a sensor with a wide dynamic range matched to a lower "bit" A-D recorder may not suffice.

 

[beelzerob]

Quite true. Accuracy isn't much of an issue for this particular application, but what you say has merit. I plan to put together the whole system on paper first and make sure it'll do what's required...and I just wanted to know if I went with Premise, what kind of I/O devices would be supported out of the gate.

 

[BraveSirRobbin]

Gotcha. For those who might be playing along at home, HERE is a Guide on Analog to Digital conversions that may be of interest with this topic.

 

[123]

...Otherwise, if I went with the datanab also....adding a new driver for Premise isn't rocket science, is it? I mean, it's just code and programming, right? Is there a helpful community for figuring it out, or will it be mostly DIY.

You'll need the HSDK and Visual Studio Pro 2005 to create a native Premise driver in C++. HSDK installs templates into VS 2005 and refuses to do this for VS 2008.

Other options include writing a Module using VBscript. Premise provides a serial communications class accessible to VBscript. You can also write a .NET application that communicates via the MiniBroker COM object. Something for everyone ...

Let me know if you intend to follow the HSDK route and I'll direct you to some sample source code. The HSDK comes with a six-step tutorial to build a simple driver but seeing more complex drivers is useful.

 

[beelzerob]

Well dang...probably the most straight-forward way for me to get into it would have been C++, but Visual Studio 200x I have not.

Does VBScript and/or .NET not require an environment in order to develop them? Or at least, is it free?

 

[123]

Premise Builder has an integrated development environent for creating Modules (in VBscript). You can use VS 2008 Express to write .NET apps that communicate with Premise via Minibroker.

I've written several Modules and one native driver but nothing using .NET and Minibroker.

 

[beelzerob]

What are "modules"? Are those basically macros? Or do modules communicate with devices?

 

[123]

What are "modules"? Are those basically macros? Or do modules communicate with devices?

Modules are program code developed in VBscript. A Module can be a new device driver, a functional enhancement, a new web-interface, etc.

Premise has an object-oriented framework that defines core classes and their methods. Everything in Premise is an object. If I want to build a collection of all Lights in my Premise Home, I'll use the Home object and its GetObjectsByType method and specify what kind of object (schema) I want.
set oLights = Home.GetObjectsByType(Schema.Device.Lighting.Lighting.Path)

Consider an ELK M1 driver. The classic way of handling its Zones is to create an array and have each element represent a zone. That's not how you'd do it in Premise. You'd define a new "M1 Zone" class that inherits from an existing, core Premise class called "Security Zone" and define new properties like Status, LogicState, PhysicalState, Area, Trouble, etc.

Consider an IR receiver driver. The classic way is to create a text property that holds the received IR command as a text string. In Premise, you'd define a new "IR Receiver" class that inherits from the existing "Infrared Input" class and use the inherited "RxData" property.

Modules can also call on Premise services such as serial communications, web services, e-mail, etc and external COM objects. The one thing you cannot do with a Module is create a multi-threaded application. Native drivers, and external apps that use the MiniBroker interface, can be multi-threaded.