Re: [BACpypes-developers] Unknown Object types.

[Monson, K. E <Kyl...@pn...>]

Hey Joel,

This is pretty much what I figured was going on. Thank you for the clarifications. More than anything I needed an expert opinion before I told the user that realistically it might not ever work without customizing our software specifically to work with his stuff.

Thanks for the heads up on the optional argument to get_datatype(). I'll add that to the script. Are there currently any vendor specific object already in bacpypes? If so, where could I find them? (grepping the code has revealed nothing except an example of registering a new object type, I'm just making sure I didn't miss something.)

I'm going to add a few  more things to the debug output for our script, vendor ID being one of them.

"This is analogous to a meter manufacturer saying everything is available via MODBUS but not giving you the register map."

As the guy who did the MODBUS support for VOLTTRON this analogy resonates very strongly.

"Somewhere the device manufacturer has a list of these object types they are defining, then for each type the list of properties, and the data type.  Maybe they would respond to your saying "Hey, this is great!  Could you send me the EPICS please?" (Electronic Protocol Implementation Conformance Statement)."

Yeah, I might just do that.

Thanks for the help.

Kyle

-----Original Message-----
From: Joel Bender [mailto:jo...@ca...] 
Sent: Friday, January 22, 2016 16:56
To: Discussion about developing BACpypes
Subject: Re: [BACpypes-developers] Unknown Object types.

Kyle,



> I'm working with a user who is trying to scrape a configuration off of 
> a device using a utility I wrote that uses bacpypes. It can be found 
> here:https://github.com/VOLTTRON/volttron/blob/feature/ilc_agent/voltt
> ron/drivers/grab_bacnet_config_extra.py

Ah!

> When he runs the utility it is not finding any objects that have a present value property (not weird in and of itself) but I am seeing lots of object types that are referred to by number only like this (object_device_index is the positions of the object in the object list on the device object):
>  
> DEBUG:__main__:object_device_index = 19 DEBUG:__main__:obj_type = 150 
> DEBUG:__main__:bacnet_index = 4 DEBUG:__main__:This object type has no 
> presentValue. Skipping.

Up at the top of the ObjectType enumeration there is a tuple called 'vendor_range', these are the values that can be used by any vendor to build their own objects.  I'll have to check again in the standard, but I think the only required properties are objectIdentifier and objectName.

The device object has a property called vendorIdentifier, a unique value given to each vendor that registers with ASHRAE.  This value, along with the objectType for an object, are used to uniquely identify the specific type of object.

> We would expect to see something like this:
>  
> DEBUG:__main__:object_device_index = 5 DEBUG:__main__:obj_type = 
> 'notificationClass'
> DEBUG:__main__:bacnet_index = 3
> DEBUG:__main__:This object type has no presenValue. Skipping.
>  
> The user claims that there are Analog Input Output, and Value objects on the device but I'm thinking that this device does follow the BACnet spec.

I don't want to sound confrontational, but if the user could provide the object identifier for one of these objects, then in BACpypes syntax it would be (0, x) or (1, x) or (2, x).  BACpypes likes to make things friendly by also allowing ('analogInput', x) or ('analogOutput', x) or ('analogValue', x).  If the object type portion is anything else, then it's something else!

Now, if they are playing games with semantics (unintentionally of course), "Yea, our object type 150 is just like an Analog Input, but we added some additional features", then you can beat them with a printed copy of the standard and accuse them of muddying the waters and breaking the promise of interoperability.

The fact that get_datatype() returns None is because there are no object classes that have been registered with that value.  That function has an additional optional parameter vendor_id, which you should pass as a parameter whenever the object_type is in the range 128..1023, to make sure you get the correct type.  The default value is zero, reserved for ASHRAE types.

Let's say that Steve Karg and the BACnet Stack developers want to produce a new object type.  Their vendor identifier is 260 and the object type is 150.

    @register_object_type(vendor_id=260)
    class WizardObject(Object):
        objectType = 150
        properties = [
            ReadableProperty('wandLength', Real),
            ReadableProperty('action', ArrayOf(ActionList)),
            ]

This definition doesn't prevent them from using standard properties on their object like presentValue, in fact if the Wizard has a "present value" concept, then Steve is encouraged to use the standard property.

Now there needs to be a way for Steve to say that the Wand Length property has a specific enumerated value.  Notice that the PropertyIdentifier class also has a vendor range, so any additional properties they define have to have values in that range.

    ---( this doesn't work yet, but there are pieces )---

My INTENT is to have vendors provide a derived class of PropertyIdentifier with additional enumerations, like this:

    @register_property_identifiers(vendor_id=260)
    class BACnetStackDeveloperProperties(PropertyIdentifier):
        enumerations = {
            'wandLength': 590,
            }

Now BACpypes would magically know that reading 590 from (150, 12) when sent to a device made by 260 the response should be a Real.

> We're seeing numbers such as 181, 270, 278, and 142 (I'm sure there are others).
>  
> Is this device marching to the beat of a different drummer? Do you need any additional information?

They are beating their own drums! They are taking advantage of BACnet to shuffle data around, but hiding it behind proprietary properties.  This is analogous to a meter manufacturer saying everything is available via MODBUS but not giving you the register map.

Somewhere the device manufacturer has a list of these object types they are defining, then for each type the list of properties, and the data type.  Maybe they would respond to your saying "Hey, this is great!  Could you send me the EPICS please?" (Electronic Protocol Implementation Conformance Statement).


Joel


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
BACpypes-developers mailing list
BAC...@li...
https://lists.sourceforge.net/lists/listinfo/bacpypes-developers