Samples use old ServicesSupported about bacpypes HOT 3 CLOSED

It seems like there should be a way to go through the classes in the bacpypes.apdu.confirmed_request_types dictionary items and see if the application has a matching method, then build the protocol services supported bit string from those. The same mechanism should also work for unconfirmed request types.

The twist on this is that there is no mapping between the class and the enumeration values of ServicesSupported. For example, if WhoHasRequest is the class and do_WhoHasRequest is an implemented method, there needs to be something like this:

class WhoHasRequest(UnconfirmedRequestSequence):
    serviceChoice = 7
    serviceSupported = 'whoHas'
    sequenceElements = \
        [ Element('limits', WhoHasLimits, None, True)
        , Element('object', WhoHasObject)
        ]

Nemine contradicente.

from bacpypes.

Rather then adding those statements to the confirmed and unconfirmed request classes, I decided to use the serviceChoice to look up the correct bit name.

When building an application stack, the Application class needs an instance of a DeviceObject (usually a LocalDeviceObject in the sample applications), and the device object doesn't know what services the application supports. So there is a new function get_services_supported() of the application and the output of that is given to the device object.

I briefly experimented with the idea of modifying the device object inside the Application.__init__() method but that seemed too intrusive. What if the application developer doesn't want that bit list created, but wanted the application to operate on just the information that it put in the device object?

The first iteration of the sample code is b54610f, and the next step is to update and test the rest of the samples.

from bacpypes.

I'm happy with the results, so I'm closing the issue and merging it into stage.

from bacpypes.