Adding get_all_location_uids()

[nestorix1343]

The existing get_device_locations() exposes the link between devices and locationuid.

However, I was missing something from the Actuator class. The location of the Actuator might the Fuse Box, but its channels control something usually in a room in the house. There was also an Effective Location UID of the channel of the Actuator but this name was not available with get_device_locations().

I added get_all_location_uids() to map every location with its UID. This are used for the actual actuators locations and the actual sensor location but also for certain channels which can be configured to be in another location (and are also shown like this in the eNet App for smart phones).

[nestorix1343]

I did not add the location_uids of the sensor channels, because they can not be somewhere else "used" or "seen" than the location of the sensor itself. The actuator can be in one place but its usage can be in another room. If necessary, we can also add locations for all sensor channels although quite redundant. I believe there is no way of changing the location of one button of a sensor in the eNet configuration webinterface.

Adding it would only create a more orthogonal result. I think not necessary right now.

Also, I created a new method because expanding get_device_locations() could break something perhaps.

[mnordseth]

The way I read this, what you return is a superset of the current get_device_locations, so I think we should just change that one.

[nestorix1343]

Yes, you are right.

However, now I think about it. In your get_device_locations() basically only deviceUIDs are stored with a location name.

My get_all_locations_uids(), I also store locationUIDs with a location name (because the actuator channels use the locationUID for their "effective" location").

So although it does the trick for me, it might be conceptually wrong to combine these in one result, although it does the trick right now for me (i.e. getting the location names of the actuator channels). If someone would traverse the result, you basically get two "types" of UIDs back, deviceUIDs and locationUIDs. In hindsight that is a bit nasty perhaps.

Maybe it is better to expand the Channel class to include sensors (as you indicated earlier) and then have the effective location in the class attributes for both.

So maybe ditch this change for now? I will be using it for my own eNet2MQTT project until we find something better.