Fix Aqara FP1 Human Presence Sensor

[ebaauw]

Changes:

• Rename DDF to reflect modelid;
• Add config/sensitivitymax and normalise config.sensitivity from 0 to sensitivitymax;
• Add (hidden) config/allowtouchlink to set 0xFFC0/0x0155 to 1 to receive attribute reports for 0x00F7 with the raw grid data. Note that this isn't yet exposed by the API;
• Replace scripts by inline JavaScript eval; simplyfy eval expressions;
• Add missing attribute names to general.xml.

The device is weird. It advertises Manufacturer Code 0x1234 in the Node Descriptor, but uses 0x011F for the 0xFC00 cluster. The Aqara M1 hub sends Read Attributes and Write Attributes commands to 0xFCC0 with Manufacturer Code 0x011F set, but the device doesn't always includes the Manufacturer Code in the responses or Report Attributes. Hence the inconsistent inclusion of "mf": "0x001F" across parse vs read / write of the same item. Most attributes are parsed from the Xiaomi special attribute report anyways.

[SwoopX]

Can we please revert the renaming of the DDF file and the changes on the swversion? Almost all files are named after their product ID and the swversion code will fail on numbers higher than 0x63.

And why add that additional attribute if that isn't used anyway?

[ebaauw]

The swversion code will fail on numbers higher than 0x63.

Damn, you're right. I must have mixed hex vs decimal number strings. I'll change that, also for the other devices. I do prefer an inline eval over an external script, as long as it's a simgle statement.

Almost all files are named after their product ID

Keyword being "almost". Personally, I don't know these product numbers (I don't keep the boxes for my devices), and prefer to use the Model Identifier for easy recognition.

And why add that additional attribute if that isn't used anyway?

In preparation of exposing the raw grid data data. I can remove it for now, if you think it's harmful.