Problem with ConfirmedEventNotification in BACpypes Sample

[IrfanULLAH97]

Hi Joel,

First of all, thank you for your great work on BACpypes. I'm relatively new to BACpypes and I'm currently trying to send and receive ConfirmedEventNotification messages.

I've attempted to use the provided sample 'EventNotification.py' on two different PCs. However, when I tried to use the 'writerl 192.168.1.105 0' command (where 192.168.1.105 is the IP address of the other device), I encountered some issues. After resolving those issues, I encountered an 'object: unknownObject' error.

I have a few questions and requests:

1. Could you provide some guidance on how to use the Sample Applications effectively?
2. Do you have any reference materials or documentation related to handling Event Notifications with BACpypes? Any additional resources would be greatly appreciated.

Thank you in advance for your assistance.

[bbartling]

Am not the expert here... but think object: unknownObject results from your trying to find a point in a device where the point doesn't exist.

Does that sound about right? If I under stand your approach you have 2 different PC's on a LAN and your trying to send an event notification but the point may not exist in the other device?? I am not super familiar with Event Notifications or the EventNotification.py.

Do you have a BACnet device on a test bench or what are you using? if it comes down to it you can simulate a BACnet device on a like a raspberry pi or something and then use bacpypes to read and write to it...

1. For me in this journey run mini_device.py on one device which is BACnet server with simple simulated values.
   https://github.com/JoelBender/bacpypes/blob/master/samples/mini_device.py

2. Use a free BACnet scanner (like YABE or contemporary controls BACnet discovery tool) and confirm you can interact with mini_device from another computer on your LAN and then maybe try:
   https://github.com/JoelBender/bacpypes/blob/master/samples/DeviceDiscovery.py

3. Then tinker around with ReadWritePropertly.py and see if you can interact with mini_device.py running on the other computer:
   https://github.com/JoelBender/bacpypes/blob/master/samples/ReadWriteProperty.py

Just some suggestions but there is a section in the ReadTheDocs as well:
https://bacpypes.readthedocs.io/en/latest/#getting-started

[JoelBender]

I'm relatively new to BACpypes and I'm currently trying to send and receive ConfirmedEventNotification messages.

The sample application that you referenced is a recipient of an event notification, it doesn't initiate them. It uses the WriteProperty service to tell the server "when there is something that needs to be sent with notification class 0, send a notification to 'me' and I'm giving you my device identifier". Note that this request completely re-writes the recipient list, so if this is acknowledged then the old recipients will be obliterated and won't get notifications.

If you think you can successfully update the recipient list, try reading it back and make sure it was actually updated. Then trigger a notification of some object that references notification class 0 and you will probably see:
(a) some Who-Is and I-Am traffic while the server is "binding" to your client and/or (b) a confirmed event notification (because issueConfirmedNotifications=True) that your client will acknowledge.

There is a chance that the device you are talking to doesn't support device identifiers as a recipient (see Recipient), in which case the WriteProperty should fail and you can try to fill in the DeviceAddress which is a bit tedious.

Do you have any reference materials or documentation related to handling Event Notifications with BACpypes?

What you do with the notification is up to your application. It's common to at least log the event and if it's an "alarm" then notify the user in some way.

It's also common to disconnect the event recipient from this other activity by forwarding it to an MQTT broker, AMPQ middleware, or other streaming protocol so your application doesn't spend a lot of time before acknowledging the event. When thousands of events arrive in a few seconds (think campus-wide power spike or other utility distribution failure) it's important to process them all before any of the APDU timeouts expire (usually around 3 seconds) or you'll get repeat notifications (assuming they are confirmed), and you want to drain the operating system's UDP socket buffer as quickly as possible (notifications get dropped before you have a chance to see them).