Problems with TOU Tariffs

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problems with TOU Tariffs

lea_jaentgen
Hey everybody,

I'm experiencing some issues using time of use tariffs. The broker is not doing anything, when I run it with TOU Tariff. The Subscriptions and cash will stay at 0. I think it might be due to a wrong set up of the tariffs.

Can you take a look?

TariffSpecification spec = new TariffSpecification(broker.getBroker(), PowerType.CONSUMPTION);

Rate rate1 = new Rate().withDailyBegin(0).withDailyEnd(6).withValue(-0.2);
Rate rate2 = new Rate().withDailyBegin(6).withDailyEnd(21).withValue(-0.5);
Rate rate3 = new Rate().withDailyBegin(21).withDailyEnd(24).withValue(-0.2);

spec.addRate(rate1).addRate(rate2).addRate(rate3);
                               
customerSubscriptions.put(spec, new HashMap<CustomerInfo, CustomerRecord>());
tariffRepo.addSpecification(spec);
broker.sendMessage(spec);



Would this work? If yes, do you have any other ideas on why it might not work? All the other tariffs work fine.

Cheers,

Lea
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with TOU Tariffs

grampajohn
Administrator
Hello, Lea -
lea_jaentgen wrote
I'm experiencing some issues using time of use tariffs. The broker is not doing anything, when I run it with TOU Tariff. The Subscriptions and cash will stay at 0. I think it might be due to a wrong set up of the tariffs.
I believe you have raised an exception and not realized it. Have you looked at the logs? The problem is that the hour value runs from 0 to 23. The correct way to specify this tariff would be

Rate rate1 = new Rate().withDailyBegin(6).withDailyEnd(21).withValue(-0.5);
Rate rate2 = new Rate().withDailyBegin(22).withDailyEnd(5).withValue(-0.2);

This would give you 16 hours at -0.5 starting at 6:00, and 8 hours at -0.2 starting at 22:00. Note that you can wrap the times around past midnight, and the times should be read as "the hour starting at x".

However, this error should result in a TariffStatus rather than an exception. I have created Issue #939 to track this problem. I will try to get it fixed before the final round, but it probably won't be until sometime next week at the earliest.

Does this help?

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with TOU Tariffs

lea_jaentgen
Hi John,

this worked! Thanks so much.
I'm not sure about the Exception, since I don't have the log files anymore.

I was only offering TOU Tariffs, so I guess if they were configured wrongly no customer would subscribe to them. Therefore, I'm not sure if an exception was the reason.

Cheers,

Lea
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problems with TOU Tariffs

grampajohn
Administrator
lea_jaentgen wrote
I was only offering TOU Tariffs, so I guess if they were configured wrongly no customer would subscribe to them. Therefore, I'm not sure if an exception was the reason.
It's very unlikely that the customers ever saw your mis-configured tariffs, because the exception would have prevented them from being published. Your broker can check for this by looking for the PUBLISH tariff transaction. Until that arrives, customers will not have access to your new tariff.

I'm glad it's working for you now. Best of luck in the competition.

John
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Update changes behavior for TOU Tariffs with bogus Rates

grampajohn
Administrator
In reply to this post by lea_jaentgen
Dear colleagues -

As a result of fixing Issue #939 there is a slight change in behavior when composing rates with daily and/or weekly start and end times. Previously, an out-of-range value for the day of week or hour of day would not generate an error in the broker, but would raise an exception in the server. In a tournament situation this is quite disruptive.

The behavior now is that out-of-range values are not accepted as input when composing the Rates, which means the fluent setters for those values can return null, after logging an ERROR to the trace log. If the bad value was not the last setter in the chain, you can now get a NullPointerException in the broker in the code that's composing the rates. If you see this, take a look in the log to see what the offending value was. If the bad value was the last setter in a chain, then your broker may not crash, but the ERROR message will be written to the trace log, and the Rate will fail the isValid() test when it's unpacked in the server, and most likely the tariff will be rejected (you will get an invalidTariff back in the TariffStatus message). Of course, you can avoid this by checking validity of Rate instances before sending a new tariff to the server. Validity tests are run when you create and init() a Tariff; the return value of Tariff.init() is true just in case all the Rates are valid.

I believe the updated behavior is much better than the original behavior, because bad input is caught in the broker rather than in the server. If you disagree, I would be interested in your thoughts. In general, you should always check for ERROR entries in the trace log the first few times you run your broker after you've made a change.

As always, please let us know if you encounter problems with this.

John
Loading...