Additional CGG1 devices not discovered (Existing ones work fine)

[peletiah]

I already have three CGG1 devices and one LYWSD02 working just fine with ble_monitor, receiving current statuses throughout.
I've recently bought three additional CGG1-sensors but can't figure out why they are not discovered by ble_monitor. I added them in the MiHome-App, they are discovered and report their status.

I've tried to sync them by pressing the button on their backs, restarting integrations, HA and rebooting the hardware itself (Pi 3). The devices are immediately next the to Raspberry Pi, so reception should not be an issue.

I've also tried to add them manually through the gui based on the mac-adress, but they don't appear in the devices-list.

The devices also show up in btmon, I've attached logs from btmon --write hcitrace.snoop | tee hcitrace.txt. Debug-logging from HA however only shows the existing four devices.

The existing device's MACs are:
58:2D:34:10:F7:29
58:2D:34:10:F8:88
58:2D:34:10:F8:7F
E7:2E:01:71:94:AD

According to the btmon-trace the new one's appear to be:
58:2D:34:11:C0:56
58:2D:34:11:C0:02
58:2D:34:11:BF:F0

Any idea what else I could try?

home-assistant.log
hcitrace.snoop.gz
hcitrace.txt

[Ernst79]

I don't see anything strange in your configuration. You could try to enable report_unknown option and send your log file again.

Second thing you need to check, are you sure you have bought CGG1 sensors and not CGG1H sensors. They look the same, but the last has homekit support and seems to use a different protocol.

[peletiah]

No, they are definitely CGG1, says so on the packaging and inside the door/stand/bracket on the back. The only difference to the previous batch is that the "Qingping"-brandname is now molded into that bracket and it has a "CE"-sticker. Also they now work with the european server in MiHome, whereas my first batch was only discovered a few weeks ago when switching to the chinese server.

By activating report_unknown they show up in the logfile as BLE ADV from UNKNOWN (See attached hci-trace and log). I guess this is a newer batch were they changed something in the transmitted data. Happy to provide further information if I can help out!

hcitrace.zip
home-assistant.log

[Ernst79]

@peletiah, I think you are right, we need to add a new device. We have seen this with the kettles as well, slightly different versions that look the same. @Magalex2x14 normally adds new devices, as he understands how to decode this. But I would like to take this opportunity to also learn how this works.

@Magalex2x14 Can you show me how you 'decode' these messages. I assume we just need to add a new line in const.py, but I would really appreciate if you could show me how you do this, step by step. Hopefully, next time, I can help you with this.

But I will make a start to understand, by sorting messages per device.

58:2D:34:11:C0:02

043e2a0201000002c011342d581e0201061a1695fe5858480b6a02c011342d58ac3ff6224e1500008c3caf74d3
043e1f0201000002c011342d58130201060f1695fe3058480b6b02c011342d5808d3
043e2a0201000002c011342d581e0201061a1695fe5858480b6c02c011342d58b2d4ba67ff150000aa9342d0d2
043e2a0201000002c011342d581e0201061a1695fe5858480b6d02c011342d585231e60898150000de46d12ed3
043e1f0201000002c011342d58130201060f1695fe3058480b6e02c011342d5808d4
043e2a0201000002c011342d581e0201061a1695fe5858480b6f02c011342d58e6fd29f16c15000052ab9508d4
043e2a0201000002c011342d581e0201061a1695fe5858480b7002c011342d58330980d591150000b57ce79fd2
043e1f0201000002c011342d58130201060f1695fe3058480b7102c011342d5808d3
043e2a0201000002c011342d581e0201061a1695fe5858480b7202c011342d58d48587bc7b150000f6174f93d3
043e2a0201000002c011342d581e0201061a1695fe5858480b7302c011342d58e84fbcf4bc150000ab4c61a6d4

58:2D:34:11:C0:56

043e1f0201000056c011342d58130201060f1695fe3058480bc456c011342d5808d3
043e2a0201000056c011342d581e0201061a1695fe5858480bc556c011342d584adb6733ee150000a2c2a975d3
043e2a0201000056c011342d581e0201061a1695fe5858480bc656c011342d58b160beb3c11500001bc6d69cd3
043e2a0201000056c011342d581e0201061a1695fe5858480bc856c011342d58a6fd9bfd5b150000e361eaecd1
043e2a0201000056c011342d581e0201061a1695fe5858480bc956c011342d58eb48d921c015000013d911b7d1
043e2a0201000056c011342d581e0201061a1695fe5858480bcb56c011342d58b7a4e0e08115000051a6054bd1
043e2a0201000056c011342d581e0201061a1695fe5858480bcc56c011342d5890e8682d98150000200a647cd1
043e1f0201000056c011342d58130201060f1695fe3058480bcd56c011342d5808d1
043e2a0201000056c011342d581e0201061a1695fe5858480bce56c011342d58d1c090c9bf150000dc47c84ad3

58:2D:34:11:BF:F0

043e2a02010000f0bf11342d581e0201061a1695fe5858480b6df0bf11342d581efd66ce73150000341bec24ce
043e1f02010000f0bf11342d58130201060f1695fe3058480b6ef0bf11342d5808cd
043e2a02010000f0bf11342d581e0201061a1695fe5858480b6ff0bf11342d588f1f6a83cd150000db20b1bdcd
043e2a02010000f0bf11342d581e0201061a1695fe5858480b70f0bf11342d58a9a2ded1341500009bc87cafcd
043e1f02010000f0bf11342d58130201060f1695fe3058480b71f0bf11342d5808ce
043e2a02010000f0bf11342d581e0201061a1695fe5858480b72f0bf11342d5874b4d6d768150000f7fee135cd
043e2a02010000f0bf11342d581e0201061a1695fe5858480b73f0bf11342d5882e91e4c1515000047c5896ecd
043e1f02010000f0bf11342d58130201060f1695fe3058480b74f0bf11342d5808cd
043e2a02010000f0bf11342d581e0201061a1695fe5858480b75f0bf11342d5888650e052b15000083b17b63ce
043e2a02010000f0bf11342d581e0201061a1695fe5858480b76f0bf11342d58069cdf5da2150000925e734ace
043e1f02010000f0bf11342d58130201060f1695fe3058480b77f0bf11342d5808ce
043e2a02010000f0bf11342d581e0201061a1695fe5858480b78f0bf11342d58e62cdf38111500000ccb4472cd

I do recognize the mac address (reversed per two). Short messages

043e 1f  02010000 02c0 11342d58 13 020106 0f 1695fe3058480b 6b 02c011342d58 08d3
043e 1f  02010000 56c0 11342d58 13 020106 0f 1695fe3058480b cd 56c011342d58 08d1
043e 1f  02010000 f0bf 11342d58 13 020106 0f 1695fe3058480b 77 f0bf11342d58 08ce

long messages

043e 2a 02010000 02c0 11342d58 1e 020106 1a 1695fe5858480b 6d 02c011342d58 5231e60898 150000 de46d12ed3
043e 2a 02010000 56c0 11342d58 1e 020106 1a 1695fe5858480b cb 56c011342d58 b7a4e0e081 150000 51a6054bd1
043e 2a 02010000 f0bf 11342d58 1e 020106 1a 1695fe5858480b 75 f0bf11342d58 88650e052b 150000 83b17b63ce

So, what I can make of it

043e constant, for all devices the same
1f always 1f (short message 31 char) or 2a (long message 42 char)
02010000 constant, for all devices the same
02c0 type of measurement???
11342d58 constant, for all devices the same
13 always 13 or 1e ????
020106 constant (adv_index)
1a always 0f (short messages 15 char) or 1a (long messages 26 char)
1695fe Constant (AD type + xiaomi_index)
3058480b (Frame Ctrl + device type)
6b (frame count (packet_id))
02c011342d58 (mac reversed per two)

Payload Short message
08d3 ??? + RSSI

Long message
5231e60898 measurement ???
150000 constant
de46d12ed3 measurement + RSSI

Tomorrow, I'll continue by looking into the code and further understand what is what. For now, it's bedtime.

[Ernst79]

I think if you add this line in const.py in XIAOMI_DICT_TYPE, it should work

b'\x48\x0B': ("CGD1", False),

[Magalex2x14]

@Ernst79 I'm a little busy right now - there are a lot of cases at the end of the year. I think tomorrow evening or Sunday I will be able to devote time to this.

In short, I’ll say a couple of things:

• this is another encryptor
• yes, the id of this device 480b, and adding it to the dictionary will be enough

I think it's best to avoid duplicate names in this dictionary (this may become important later in data processing).
It is necessary to clarify how it differs from the previous model.
@peletiah can you take a photo of the markings on the packaging or the device itself?

@Ernst79 in my repository there is a parsing of LYWSD03MMC messages - the essence is the same for all encryptors (I think this is enough for a start, if there are questions, we will clarify them at any time).

[Ernst79]

Thanks, take your time. No hurry.

Your link was really helpful. I’ll make a PR for this after we get more info from @peletiah . I’ll make a different name for it, If it doesn’t come clear what the difference is, I will add v2 or something like that and include it in the other dictionary as well.

[peletiah]

Thank you guys! Here's a photo of the packaging:

By adding b'\x48\x0B': ("CGG1", False), the devices are immediately detected. After 10 minutes values are still "unknown" however, guess they are differently encoded.

[Ernst79]

Could you try it by replacing const.py with the following file.

https://github.com/custom-components/ble_monitor/blob/CGG1-qingping/custom_components/ble_monitor/const.py

If that doesn't work, can you comment out both CGG1 and CGG1 in XIAOMI_DICT_TYPE in that file and enable report_unknown again and post the log. We can than check the differences.

[peletiah]

That change was not sufficient unfortunately, still no values after 10minutes. Here's the logfile with both CGG1 and CGG1-V2 commented out, hope there's enough data you can work with.

home-assistant.log

[Magalex2x14]

@peletiah The previous version sensor did not encrypt messages.

New - encrypts. To get the data, you need to extract the encryption key.
Our FAQ describes methods. Easiest one - MiHome mod by vevs.

[Ernst79]

Ah, sorry, missed that in @Magalex2x14 previous respons. Those Chinese makes thing complicated, same sensor name, some have encryption, some don’t. So, yes, you need to find the encryption key.

For the differences between the sensors CGG1 and CGG1-V2, I see the last one is from Qingping. For the first one, we now have Xiaomi as the manufacturer. I will do some search on the internet to see what is the actual manufacturer of the CGG1. But perhaps you (@peletiah) still have the package or you can find something on the old sensors?

Edit. I did found CGG1 sensors from Cleargrass, but the website cleargrass.com leads to qingping.co

[peletiah]

I think Cleargrass and Qinping are essentially the same company. Unfortunately, I've thrown the old packages away already.
The main difference is that the new one has the Qinping-name molded into the bracket. Inside the bracket, the old ones had a "Clearglass"-logo, the new one doesn't. IDs and Model are identical, the identifier in the old one says "Temperature and Humidity Monitor" while the new one says "Temp & RH Monitor M Version".

I've had no luck with the Android mod by @vevsvevs v.9.5.19, I've created internal-storage/vevs/logs on my Android device but no pairings.txt-file has appeared after pairing the devices. I'll try to figure out the other options.

Giving the app storage permission was necessary, as pointed out by @Krojack here. Will give additional feedback once I've made some progress.

[peletiah]

After adding the bind-keys gathered by the modded MiHome-app, all sensors are reporting! Thank you for your quick support! I'll leave this open, in case you need additional information on these devices! If not, I don't mind if you close it!

[Ernst79]

Thanks, I'll create a PR with change and will add some explanation in the docs about the different versions. It will be included in the next release, till then, keep the code like you have it now.

[Ernst79]

I renamed it to CGG1-ENCRYPTED in the code. Docs are added.

[Ernst79]

0.9.4-beta is released, which includes support for encrypted CGG1