All my items are the same except for 1 at the moment. Energy cannot be traded, it needs to be put in a battery first. Crafting is done with items and buildings/factories produce items.

• If I abstract energy out of the item class I need to abstract the power plant as well since factories produces an "Item".  Also, if an item needs energy to be produced I need to account for this change since currently I just iterate over the available "Items", subtract and produce. Although this feels like an elegant way to deal with the problem, due I'd really like to keep the energy as a Item.
• I could add a boolean to the item which tells me if it. All items get this extra boolean now just because energy is a mutant.
• I could add a extra item class that inherits the regular Item class. This feels like overkill for just one item.

Any other ways to handle this in a elegant way?

Not everything is clear to me: what class hierarchy (if any) you currently have; what programming language you use etc., but I will try to help.

1 hour ago, menyo said:

I could add a extra item class that inherits the regular Item class. This feels like overkill for just one item.

If you are talking about one type of item with several instances (I suppose a power plant doesn't create just a single Energy item and/or there may be multiple power plants) then I don't find this at all overkill; in fact this is what I might do.

2 hours ago, menyo said:

I could add a boolean to the item which tells me if it. All items get this extra boolean now just because energy is a mutant.

I wouldn't do this, especially if the Item class already has some abstract superclass or virtual functions (I'm assuming C++ or some similar language here). It may be a better idea to have a virtual bool isTradeable() or bool isEnergy() function, and override it in the Energy subclass (what you suggested in point 3) so that it returns false instead of true (or vice versa).

2 hours ago, menyo said:

If I abstract energy out of the item class I need to abstract the power plant as well since factories produces an "Item".  Also, if an item needs energy to be produced I need to account for this change since currently I just iterate over the available "Items", subtract and produce. Although this feels like an elegant way to deal with the problem, due I'd really like to keep the energy as a Item.

If by abstracting out the energy class you mean creating a separate Energy class (or some other entity) independent from the Item class, then imho this can be a sufficiently elegant solution in case you hadn't intended to subclass Item (or in general use some sort of common class hierarchy for both Energy and regular Items) in the first place. (At least right now I can't come up with something better.)

Perhaps have a "tradable" property?

Sorry for not being clear.  My item class at the moment is very simple. Just a data class with a string for the item type. I have a item stack derived from that that has an extra int for the amount. The value of the item depends on the supply/demand.

So since its just a trading/crafting system items don't need functionality. Later perhaps a category for better sorting. I have a template class with that holds the crafting data so that a factory pattern can use it to craft items. This way I can create items with json.

So except for energy all my current items are tradable. A battery for example can be crafted with energy and iron. The battery and the iron can be traded like any other item. 

I'm using Java but basic programming principles apply.

6 hours ago, menyo said:

I could add a extra item class that inherits the regular Item class. This feels like overkill for just one item.

Then why not make a class for the variable instead.

For example often when making a Health value for characters I use a class for that property.

Class VitalityVariable(){
  
  public float Max;
  public float Current;
  
  float Difference;
  float Volume = 0f;
  
  public VitalityVariable(float InMaxAmount, float InCurrentAmount){
    Max = InMaxAmount;
    Current = InCurrentAmount;
  }
  
  public void AddInAndCap(float InAmount){
    Current += InAmount;
	Difference = Max - Current;
    //Solves over full
	if (Difference < 0) {
			Current += Difference;
	}
  }

  //Gives the Volume as 0-1f. 1f means the limit has been reached.
  public float GetProgressToLimit(){
    Difference = Max - Current;
    Volume = (Current / Max);
    return Volume;
  }
  
}

Now I can use this class when ever I need a value that is capped to a max. It works for Health, Mana, Stamina , Ammo and anything really.

You can do the same with your energy and plant variables. 

7 hours ago, menyo said:

 

• I could add a boolean to the item which tells me if it. All items get this extra boolean now just because energy is a mutant.
• I could add a extra item class that inherits the regular Item class. This feels like overkill for just one item.

Any other ways to handle this in a elegant way?

Sort of the big-bad-wolf of programming there, particularly in games you'll often find scenarios where you have a lot of similar things where one or more have to be slightly different than the others.

If you need energy for one item then your only real options are to place it in the superclass, or make it a child class and access it that way. That property has to go -somewhere- after all.

9 hours ago, menyo said:

Sorry for not being clear.  My item class at the moment is very simple. Just a data class with a string for the item type. I have a item stack derived from that that has an extra int for the amount. The value of the item depends on the supply/demand.

Use an enum for the type instead. Add the name and whatever other property you need to the type.

As Satharis says, any exception to the regular rule ends up somewhere. In the code by special if-handling statements scattered all over the place, by splitting groups until all items of each group are really the same, or by lifting the entire group to a more general description that includes enough data to distinguish for all the relevant cases in a generic way.

"Elegance" is usually found in the latter 2 solutions, in my experience.