OpenLEADR / openleadr-python

Python library for OpenADR
https://openleadr.org/docs
Apache License 2.0
133 stars 51 forks source link

Cannot use multiple events #42

Closed michal-kowalczyk closed 3 years ago

michal-kowalczyk commented 3 years ago

I want to create a few events where one will get active after the other becomes inactive. I created a list of events that I populate into server:

for event in events:
  server.add_raw_event(ven_id, event, event_callback)

That causes VTN to send events one at a time. When EPRI VEN receives the second event, it cancels the first one. I've checked that in the second oadrDistributeEvent there's only the second event.

I found in OpenADR documentation that there should be both the first and the second event in there:

Note that for both PUSH and PULL operations, an oadrDistributeEvent payload will always contain all events applicable to the VEN it is communicating with. Events are conveyed in the oadrDistributeEvent payload using one or more oadrEvent elements.

Also, the documentation says that VEN must implicitly cancel the first event if it is not present in the second oadrDistributeEvent (and that's actually what EPRI VEN does):

VEN, EiEvent Service, oadrDistributeEvent Payload If the VTN sends the oadrDistributeEvent payload and it does not contain an event for which the VEN is aware (i.e., in its list of known events) then the VEN MUST delete it from its list of known event (i.e., implied cancel). Exception: A VEN that has an active event that cannot be immediately stopped for operational reasons MAY leave the event in its data store until the event expires or the event can be stopped.

I believe the server needs a new method to send many events at one shot. Also, add_*event should have caveat note that it cancels out previously send events which are not yet active. Alternatively, the server could keep track of all events added and push them all when a new oadrDistributeEvent is sent.

stan-janssen commented 3 years ago

Thanks for the report. You are correct, the behavior of queuing up multiple events is not yet as it should be. I noticed this myself when running through the requirements. The fix will require some re-architecting of the internal event state handler, which I will try to get to sometime next week.

stan-janssen commented 3 years ago

This should now be fixed. If you have a chance, could you try to install the version on the main branch and let me know?

michal-kowalczyk commented 3 years ago

@stan-janssen , I've just verified that your fix works. Thank you!

stan-janssen commented 3 years ago

Great, thanks for letting me know. This will be released in the next version later this week.