Adjust model_id for both LYWSD03MMC/MJWSD05MMC_PVVX_BTHOME

[plambrechtsen]

Adjust model_id for both LYWSD03MMC/MJWSD05MMC_PVVX_BTHOME frames removing the _1 and _2 to match to resolve issues with OpenMQTTGateway

Description:

When testing the updated LYWSD03MMC/MJWSD05MMC_PVVX_BTHOME decoder with OpenMQTTGateway there is an issue as the model_id is used in the device name. Since I mistakenly had different model_id's for the different frames then OpenMQTTGateway flip flops between the two names and that then flows into Home Assistant.

I am working on adding Encrypted BTHome support to OpenMQTTGateway as well. What it should be doing is checking for the acts so it will know there is additional frames that need to be supported.

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[DigiH]

Thanks @plambrechtsen

I am working on adding Encrypted BTHome support to OpenMQTTGateway as well. What it should be doing is checking for the acts so it will know there is additional frames that need to be supported.

You might want to have a look at the code internal BM2 decoding, where decryption is already in place in OMG.

https://github.com/1technophile/OpenMQTTGateway/blob/development/main/gatewayBLEConnect.cpp#L272-L296

There with a static bindkey however, applicable to all BM2s. For BTHome decryption, as well as the other two Decoder implemented encryption schemes, you will need to come up with a nice way to pass and store the MAC and Bindkey pairs.

The acts property is not really relevant to decryption, or for any additional frames. It's only important for the different spassive and active canning intervals in OMG and the related adaptivescan functionality. The encr property scheme number is important to indicate the correct decryption out of the three currently implemented in Theengs Decoder.

You might have already looked at how these are implemented in Python for Theengs Gateway

https://github.com/theengs/gateway/blob/development/TheengsGateway/decryption.py

I. e. all the decryption schemes do send the decrypted payload to Theengs Decoder again for final decoding.

[plambrechtsen]

Thanks @DigiH my current approach has been to add logic in process_bledata and checking for the BLEdata["encr"] tag, then decrypting the payload, replacing the BLEdata["servicedata"] with the decrypted payload and then calling decoder.decodeBLEJson(BLEdata) again where I update model_id with the new value.

It seems to all work and I am adding in configuring the ble_aes key in the UI and clean up all the debugging I added and a few other things to sort out. But hope to have a PR ready in a day or two.

[DigiH]

Sounds great @plambrechtsen ! My reference to gatewayBLEConnect.cpp above was really only to show that AES decryption was already implemented in OMG,Decoder related decryption however will need to be implemented as you described above.

I'll be looking forward to this addition to OMG :) As I don't have any encryption capable devices myself I will also ask the user who asked for, helped with and tested the Victron Energy decryption with me, to verify its OMG implementation.

[plambrechtsen]

Just finished my first PR for OMG fixing up some UI issues. 1technophile/OpenMQTTGateway#2218 now building a new branch based on those changes for BTHome encryption.

[plambrechtsen]

And a separate PR adding BTHome support. It's not pretty but it works. 1technophile/OpenMQTTGateway#2219