pd event callback

[jb-quantus]

On the pd hardware we have leds to signal the communication state.

For that we would need an event for:

• communication for other pds started. So we know the pd is properly connected. But no polling for this pd.
• communication for other pds stopped.
• polling for this pd started.
• polling for this pd stopped.

Something like this. So we would signal red with no communication, signal orange with communication for other pd, and signal green when polling for this pd.

[sidcha]

communication for other pds started. So we know the pd is properly connected. But no polling for this pd.
communication for other pds stopped.

I don't understand what you mean by other PDs? OSDP supports the notion of PDs connected to PDs but LibOSDP does not support this.

polling for this pd started.
polling for this pd stopped.

These are too low level OSDP stuff that application should not care about. LibOSDP already produces Online Offline events for this purpose.

[JuergenBuschle]

This is a lot of years of experience of what can go wrong in practice. But does the pd get the offline and online events?

[sidcha]

The PD does not have the notion of being “online”, it is expected to be up and operational. The PD implementation is pretty much stateless except for the secure channel state as it treats each command individually. We could notify the SC status to the application if needed.

[JuergenBuschle]

Perhaps it would be easy to call a cb function when a poll for the pds address came in and another one when a poll for another pds address comes in. That would be a good solution for us. And the rest could be done outside the libodsp.

[sidcha]

To me, this seems like a very specific use case and does not represent the general PD application development workflow. I also don't know when you would stop sending these callbacks. Sending them always is definitely a bad decision.

So my suggestion is to try implementing this feature and then come up with a PR. If it looks reasonable (less invasive) we can merge it here. If not, you can keep it downstream in your fork.

[JuergenBuschle]

Yes that's fine.