Ambiguous Attribute Naming

[Meatballs1]

As per conversation in #45

We currently name attributes by the last value after splitting on .:

hcpy/HCDevice.py

Lines 98 to 99 in 1935feb

	# trim everything off the name except the last part
	name = re.sub(r"^.*\.", "", name)

However, this can lead to ambiguous names such as Power for Cooking.Oven.Setting.Light.Cavity.001.Power.

This could easily lead to incorrect status events, for example if there were two cavities they would both write to the same attribute.

Fixing this will be a breaking change as all the templates currently rely on just the shortened name instead of the fully qualified name.

We could also look at moving to a more complex message structure at the same time, to perhaps include the uid numeric value at the same time.

An alternative could be to parse the devices.json file for duplicate names and have a lookup table to expand those items to their fully qualified names?

[Tharit]

Just to provide an example of where this is actually happening: I have a hob, that has 10 zones. For each zone, theres a couple of status values.

"8201": {
                "name": "Cooking.Hob.Status.Zone.100.ActiveProgram"
            },
"8219": {
                "name": "Cooking.Hob.Status.Zone.120.ActiveProgram"
            },
"8345": {
                "name": "Cooking.Hob.Status.Zone.121.ActiveProgram"
            },
... and so on ...