[automower] Implementation of complete automower API

[MikeTheTux]

[automower] Implementation of complete automower API

References:

• [automower] Support of WorkAreas and write support of calendar-tasks #17246
• https://developer.husqvarnagroup.cloud/apis/automower-connect-api?tab=openapi Release 2024-10-14
• Bindings migration to use AbstractStorageBasedTypeProvider #14954
• [automower] planner-next-start does not reflect the correct offset to GMT #17147

Current Status / TODOs:

1. Implementation of Read Channels:
   1.1 DONE
2. Implementation of Write Channels:
   2.1 DONE /mowers/{id}/actions
   2.2 DONE /mowers/{id}/calendar
   2.3 DONE /mowers/{id}/errors/confirm
   2.4 DONE /mowers/{id}/settings
   2.5 DONE /mowers/{id}/stayOutZones/{stayOutId}
   2.6 DONE /mowers/{id}/workAreas/{workAreaId}
   2.7 DONE /mowers/{id}/workAreas/{workAreaId}/calendar
   2.8 DONE /mowers/{id}/messages
3. Dynamic Channels and Channel Groups
   3.1 DONE
4. Readme
   4.1 DONE
5. New Cut vs Search ratio channel:
   5.1 DONE
6. openHAB actions
   6.1 DONE
7. Better meta data (e.g. unit and state description) on channels
   7.1 DONE
8. Fix [automower] planner-next-start does not reflect the correct offset to GMT #17147
   8.1 DONE
9. i18n update
   9.1 DONE
10. upgrade instructions
    10.1 DONE

[MikeTheTux]

@lsiepel, do you have a good example how to implement dynamic Channels and Channel Groups? Esp. dynamic Channel Groups seems to be tricky.

[lsiepel]

@lsiepel, do you have a good example how to implement dynamic Channels and Channel Groups? Esp. dynamic Channel Groups seems to be tricky.

Interesting combination, don't have an example straight out of my head, let me check.

[MikeTheTux]

Except from dynamic channels and channel groups (which is an usability improvement only), I would consider the main part of the implementation is done.
I think it would be great that we bring this complex PR into the December release (which should be the winter break of the mower in the northern hemisphere). Therefore I would like to request an initial review round.

[MikeTheTux]

Implementation done - ready for review

[MikeTheTux]

In the meanwhile also dynamic channels are implemented.

The issue reported in openhab/openhab-webui#575 seems to be not fixed, when the channels are generated automatically. As workaround I'm adding dynamic Channel Labels as well. The Labels are then used to create unique channel uids:

newChannel = ChannelBuilder.create(channelUid, itemType).withType(channelTypeUID).withLabel(label).build();

@lsiepel, Is it worth creating an issue?

[MikeTheTux]

@lsiepel, will you find time to review this major change set as well? thanks in advance!

[lsiepel]

The issue reported in openhab/openhab-webui#575 seems to be not fixed, when the channels are generated automatically. As workaround I'm adding dynamic Channel Labels as well. The Labels are then used to create unique channel uids

Not sure if i understand the problem here. You should make sure the channelUID is unique, The label is just for display and while it woudl be very usefull, it is not constraint to be unique.

will you find time to review this major change set as well? thanks in advance!
Yes, i have holidays now, so might review this monday or tuesday, but if someone else has spare time, don't wait for me.

In the meantime, could you fix the conflict?

[MikeTheTux]

The issue reported in openhab/openhab-webui#575 seems to be not fixed, when the channels are generated automatically. As workaround I'm adding dynamic Channel Labels as well. The Labels are then used to create unique channel uids

Not sure if i understand the problem here. You should make sure the channelUID is unique, The label is just for display and while it woudl be very usefull, it is not constraint to be unique.

The channelUID is already unique due to the running index. The Label was not unique and repeating per message (channel.label was not set, channelType.label set, but the same type is used for all channels - therefore not unique)
This caused that the channel-wizard proposed Items using the same item name. As the item name is derived from the label, I added now the running index to the label as well ...

I think this is the code how the item names are proposed:
openhab-webui/blob/main/bundles/org.openhab.ui/web/src/components/thing/channel-list.vue

        let newItemName = this.newItemsPrefix || this.$oh.utils.normalizeLabel(this.thing.label)
        newItemName += '_'
        let suffix = channel.label || channelType.label || channel.id

It is using the thing.label + channel.label (if available), fallback to channelType.label, fallback to channel.id

As an improvement we could request that openHAB UI implements a duplication check at this stage.

Nevertheless the code works as expected / intended.
In the meanwhile I even think that adding the running index to the label makes sense. Otherwise we would produce 50 items using the same description and the user can differ them only via the channelID (but not the label).

This is how the current implementation using the workaround looks like:

I'm happy with that implementation in the binding. No need to change.