Extend genBasic support

[kennylevinsen]

Currently fails on coverage as we do not have any tests with frames containing productCode, productLabel or productUrl so the setters do not get exercised. The latter is quite common though.

[Nerivec]

We should limit this to update cluster.ts only (the missing properties) for reference.
There is no use case for any of these properties, and most manufacturers don't set them at all (or worse, set to long null strings). They would bloat database/payloads for no reason.

[kennylevinsen]

Why would unused properties bloat the database? It would be undefined and therefore not written, so it doesn't seem like something that we need to worry about.

Generic device type and product URL are generally set, but indeed I have (sadly) yet to see e.g., productCode.

[Nerivec]

It would be undefined

In cases where the fields are filled with dummy/null characters that would not be the case, and could represent long useless strings of data. In cases where the fields are left to the firmware builder's defaults by the manufacturer, some values could be all wrong on top of it. Additionally, URLs could become (or already be) defunct, not to mention could since have been hijacked, etc., so, providing them to the end-user is a non-starter (I'm not even sure why the ZigBee spec bothered with these... 😕).

More importantly, they just have no use (they bring no actual value and are rarely even set -properly-), but they add code to maintain/cover with tests/be executed.

[kennylevinsen]

I don't agree that the fields don't have value, but I do agree that when the fields are rarely if ever set that the gain is minimal and as such not something I plan on spending a whole lot of energy defending nor something I feel like crafting packets for. :)

I'll leave it at the cluster changes so that users at least get access to the attributes in the dev console.

[Koenkk]

Thanks!