The whole reason for creating the generator tool is to make it easier, quicker, and less tedious, and reduce the possibility of errors. You only need to pay attention to the .items and .things format once, when creating the template.
Because I have lots of similar devices, using a template makes sense. For example all Tasmota based lights have similar .things and .items, so one template to create them and you can have as many devices defined in your yaml that use the same template. I also have a lot of Zigbee2mqtt sensors, so just one template for that to create 20+ sensors.
This results in a consistent, and less error-prone output. And when I wanted to tweak my .things or .items, for example, adding an extra metadata common to all my items, I just edit ONE thing: the template, and regenerate, and voila, my 100+ items / things are changed. It beats doing a mass search/replace and I cannot even begin to imagine how this can be achieved using UI.
To make it even easier for me, I created a rule that watches for a change in the yaml file. So whenever I need to add or remove a device, I just edit my yaml file, save it and my .items and .things are automatically updated.
Maintaining the YAML file is far simpler than maintaining the .things and .items file or the MainUI’s YAML, because it only holds the high level data in it. The repetitive stuff is stored once in the template files.
I’d suggest you give it a try. It has made dealing with .items and .things easier for me.
It isn’t a 100% commitment. I still have quite a few unique .items and .things files that I manage manually without the generator. I only use the generator to maintain items / things that are highly repetitive.
Furthermore, if you want to stop using it, just take the generated .items and .things file and throw away the generator, and continue maintaining the generated files the old way.
Example, if I wanted to add another motion sensor, all I needed to do is add this into my yaml:
ToolCupBoard_PIR:
template: aqara-pir
groups:
- gHallway
motion:
groups:
- gMotionSensors
Then the corresponding .things and .items will be generated for me automatically. I don’t have to think about the nitty gritty details of things channels and linking them to the multiple items that I need. If I decided I want to rename it, just rename ToolCupBoard_PIR to GarageCupboard_PIR. If I want to remove this device, just remove that block and I’m done. How can it be easier than this?
When I decided that ALL my motion sensors need to have an additional item, say XXX_SignalStrength that belongs to a gSignalStrength group, I would add that to the template, and regenerate, then voila, all the motion sensors now have an extra Signal Strength item associated with them.
Lastly, if you don’t like my generator, you can write your own. The main thing is the idea to invest the time upfront to make it easier in the future.