Easier measurement process for new device

Ideally I would want an easier way to add new equipment. The perfect speaker flow in my mind would look like this (after running the docker command):

• Submit address of Home Assistant instance
• Submit long-lived token
• Select type of equipment:
  • Light
  • Smart speaker
  • Smart switch
• if more than one manufacturer in device registry: Select smart speaker manufacturer:
  • Google
  • Sonos
  • Amazon
• if more than one model of the chosen manufacturer in device registry: Select model:
  • One
  • Move
• if more than one entity of the chosen model in device registry: Select entity:
  • Bathroom
  • Living Room
• Select power measuring entity or type in manually:
  • sensor.tp_link2_current_consumption
  • sensor.shelly_power

Then the script could play a test sound from a web address, turn the volume up in cycles, mute it all the while measuring power. In the end it could create the model.json file. This would be a standardized way securing consistency as well! Potentially one could also try out the different attributes available on the device automatically, like loudness, bass levels etc and also incorporate that in the model.

[bramstroker]

@knudsvik I have worked for a few hours to completely refactor the measure tool to cleanup the measure main script and move logic to respective places for less cohesion and to adhere to single response principle. See #1286

Few things I have done:

• Introduce a runner component which executes the measure flow for respective device types (light or speaker). In utilts/measure/runner
• Moved all config related stuff to utils/measure/config.py
• Main measure script has been cleaned up a lot and only contains the generic logic which applies to both device types
• Standby power is now measured at the end of the session for both lights and speakers
• Introduced a media_controller package which can be used by the speaker runner to control the speaker
• speaker runner now automatically sets the volume, streams the pink noise, records the measurement and finally writes to model.json.
• More code cleanups.

Are you able to give this a test run by checkout out this branch (fix/measure-code-standards)? See if this works correctly for you (particularly the streaming part). Let me know what you think.

[bramstroker]

Yes, there can definitely be a lot improved upon the speaker measurement.

I have chosen to keep it simple now, because I didn’t know if a lot of smart speakers were being provided to the library yet, and it would take a significant amount of work and refactoring to facilitate two different measurement flows (light and smart speaker). I see you want to have a go into developing the measure script. Here are some pointers. I would suggest to take it small steps at a time.

We need to somehow extract the light measurement logic into a separate class. So we can also introduce smart speaker logic. Then some questions / answers could be asked in the main measurement class (i.e. select power measuring entity, generate model.json yes/no etc.). And depending on equipment selection we can dispatch the actual measure logic to the respective class.

I am not sure if the HA API exposes device information (pretty sure it doesn’t). So I suggest to just keep that the same as the light selection, where just all the entities of domain light are listed. Smart speakers can just list all entities of domain media_player. It won’t be hundreds of them, so selection of manufacturer/model would be overkill.

Not sure how to play a test sound using HA service which works for alle media players and HA installations.

For the submittion of HA address etc. I would leave it to the env approach right now, which works fine for all users now. We can maybe improve upon that in a future iteration, but for now keep it lean and mean.