Saving enum value using name()
I like rolfl's approach, but I have one thing to add which would make it more compact and flexible:

Use a private constructor to provide a custom save value.

The biggest benefits of using either my or rolfl's approach is that you don't need to remember to add new enum values to the HashMap. In my approach especially, it gives you a clear overview of the enum values with their corresponding save values. As long as you only use one constructor (which I highly recommend) it is impossible to forget to give a save value for the enum. 

This approach also allows you to customize their save-values much easier. You can rename your enums all you want, all you need to remember is to not change the saveValue, unless you want incompatibility issues.

enum ComponentState {
    TURNED_OFF("off"),
    TURNED_ON("on"),
    SUSPENDED("susp"),
    TO_REPAIR("repair");

    private final String saveValue;

    private ComponentState(String saveAs) {
        this.saveValue = saveAs;
    }

    private static final Map&lt;String, ComponentState&gt; FUZZY = buildMap();

    private static Map&lt;String, ComponentState&gt; buildMap() {
        Map&lt;String, ComponentState&gt; mapto = new HashMap&lt;&gt;();
        for (ComponentState state : ComponentState.values()) {
            mapto.put(state.saveValue, state);
        }
        return mapto;
    }

    private static final ComponentState fuzzyValueOf(String name) {
        return FUZZY.get(name);
    }

    public String getSaveValue() {
        return this.saveValue;
    }
}




If you want to have multiple possible save values for the same enum, then use a String... parameter: (However, in this case you need to make sure that you don't use an empty constructor for a field, as that wouldn't give it a specified save value)

    private final String[] saveValues;
    private ComponentState(String... saveAs) {
        this.saveValues = saveAs;
    }
    public String getSaveValue() {
        return this.saveValues[0];
    }




I really can't recommend using the .ordinal approach as ratchet freak suggested, even though it is nice and tidy, consider this enum:

Suit {
    DIAMONDS, HEARTS, SPADES, CLUBS;
}


Now what if you'd like to re-order them?

Suit {
    CLUBS, SPADES, DIAMONDS, HEARTS;
}


Congratulations, spades has become diamonds, clubs is hearts. Down is up and up is down. Logic goes on ski vacation with it's buddy reason.

If you use the .ordinal approach, remember to never ever ever switch places of them. (Me, talking from experience? What makes you think that?)