This change breaks the compatibility with NILMTK's Disaggregator class and with all implementations of nilmtk_contrib.
What is your rationale for such a big breaking change?

The reason behind such change is the fact that when using appliance activations, the periods of readings for one appliance are different from the other appliances.
This requires identifying which aggregated readings are relevant for the given appliance as we are not using the entire period and instead only some subsets.

I knew that the changes would break the Disaggregator class, but I decided it was better to make a pull request and debate the best way to add such changes to the API and Disaggregator class.

Happy to discuss a technical solution with you! My goal here is to allow nilmtk to evolve and fit the needs without breaking for everyone else.

I am still not sure to understand everything. Could you please update your PR description with a picture showing how you change segmentation from the current sliding window?

So the need to use a dictionary is directed by the fact that the different appliances will have different activations.
With different activations, the relevant readings of the mains data will also be different ,
The figure below might help explain the proposal and why we need to change methods' signatures.

In my implementation, I also divided the training data into train and cross-validation data,
allowing the user to specify, for example, different houses for training/cross-validating the model.
But I was only going to propose it later.

Thank you for the explanation. I understand you want a different resolution for each target appliance.
A few questions:

1. Why not just using a different sequence_length for each disaggregator?
2. Do you want to omit windows with no activation of the target appliance while training?
3. For segmentation (event detection), do you use the input (aggregated) signal or the output (disaggregated) signal?
4. How would your method be applied to an unseen home, without knowing the ground truth?

1. By using a different sequence_length, we are not solving the problem where the microwave, for example, is off 98% of the day. So, our models will be biased towards the off category instead of correctly learning to detect.
2. Yes, exactly. The idea here is to follow what was proposed in NeuralNILM and some other papers.
   3/4. This new method aims to obtain a balanced training/testing set to evaluate the models so we can use the ground truth of the appliances. In a real-life scenario, we would disaggregate every timestep in the time series

Electric.activation_series() is deprecated. Please replace all instances by Electric.get_activations()!

Sure thing!

What you put in appliance_df here is the same data as in your period variable. Why loading the data once more?

I believed that the period variable only contained the beginning and end of the activation, not the actual data.

Instead of the very complicated logic above involving set_window, why don't you load the mains data before the for loop and use index-based selection?
Something like:

mains_df = next(train.buildings[building].elec.mains().load(...))
for event in activations: # note that period is a very confusing name, event would be better.
    mains_event = mains_df.loc[event.index]
    if not mains_event.empty:
        # the code goes on, using mains_event instead of mains_df.

Like with partial_fit, this change is breaking the Disaggregator API.

As mentioned before, I do believe that we need to change the Disaggregator to enable getting the appliance activations.