[Bug] or [enhancement]?: repeated Shelly BLU button events without having pressed button repeatedly

[stefan-3r]

I'm sure that

• This issue is still present in the current beta version of this adapter
• There is no other (open) issue with the same topic (use the search!)
• This issue is not described in the adapter documentation / FAQ (read the docs!)

Shelly device

Shelly BLU button in combination with Shelly Plus 1

Shelly firmware version

20240430-105743/1.3.1-gd8534ee (plus 1) and 1.0.16 (BLU button)

Protocol

MQTT

The problem

I used the experimental feature to communicate the BLE-device-messages via MQTT to iobroker. It works fine in general but I have one problem with the Shelly BLU button:

After the button is pressed (1x, 2x, 3x or long), the appropriate message is sent. Every abot 5 1/2 hours later the same message is send again ... and again .... I can't determine if the button is pressed again or if this is a repeated message since every value remains the same (except maybe rssi if I'm lucky - and of course pid; therefore the script doesn't filter it out as duplicate).

First thougt was that the BLU button is in beacon mode and sends new messages but it isn't. And the button defininetly isn't pressed again - as I can see, because it's always the same value in the "button"-field as in the first (really pressed) event.
In the changelog of shelly BLU firmware it says for v1.0.15: "Send firmware version on device boot/reboot and 4 times a day" - maybe this is the source of the message? Can you sort that out?

I used your script-version v0.2. I use the shelly-adapter in version 6.9.0 (didn't upgrade to nodejs v18, so I couldn't switch to v7.0.0 yet. If this bug (or maybe a feature to react to a bug in the shelly-firmware!?) is suppodes to be fixed in v7.0.0, please tell me - and I am going to update).

I experienced the bug with v1.0.12 and v1.0.16 of the BLU button firmware, both included in the debug.log. You can't see the second instance of the message unfortunately since I just activated the debug mode for this report and am not patient enough to wait 6 hours. I'll atach it later if neccessary for debugging...

Thanks for your great work and yout advice.

iobroker.current.log (in debug mode!)

debug.log

Version of nodejs

16.20.2

Version of ioBroker js-controller

5.0.12

Version of adapter

6.9.0

[github-actions]

Thanks for reporting a new issue @stefan-3r!

1. Please make sure your topic is not covered in the documentation
2. Please attach all necessary log files (in debug mode!), screenshots and other information to reproduce this issue
3. Search for the issue topic in other/closed issues to avoid duplicates!

---

Otherwise this issue will be closed.

[klein0r]

You can't see the second instance of the message unfortunately since I just activated the debug mode for this report and am not patient enough to wait 6 hours.

Well, me neither (since I don't use the blu buttons in production). I will not setup a dev environment and let it run for 6+ hours

[stefan-3r]

Hi Matthias,

point taken ;-) - meanwhile the error occured again two times, every about 6 hours. I added the second orccurence at the end of the log (see down below). You can see the altered pid:

2024-05-09 17:11:47.841 - debug: shelly.0 (3027106) [MQTT] Publish: 192.168.178.79 (shellyplus1 / shellyplus1-a8032abc32a8 / shellyplus1#a8032abc32a8#1) - topic: shellyplus1-a8032abc32a8/events/ble, qos: 0, payload: {"scriptVersion":"0.2","src":"shellyplus1-a8032abc32a8","srcBle":{"mac":"f4:b3:b1:82:a6:e2"},"payload":{"encryption":false,"BTHome_version":2,"pid":3,"battery":100,"button":4,"rssi":-87,"address":"f4:b3:b1:82:a6:e2"}}
2024-05-09 17:11:47.843 - debug: shelly.0 (3027106) [MQTT] State change 192.168.178.79 (shellyplus1 / shellyplus1-a8032abc32a8 / shellyplus1#a8032abc32a8#1): shellyplus1-a8032abc32a8/events/ble -> state: shellyplus1#a8032abc32a8#1.BLE.Event, value: "{\n \"encryption\": false,\n \"BTHome_version\": 2,\n \"pid\": 3,\n \"battery\": 100,\n \"button\": 4,\n \"rssi\": -87,\n \"address\": \"f4:b3:b1:82:a6:e2\"\n}"
2024-05-09 17:11:47.849 - debug: shelly.0 (3027106) [MQTT] Publish: 192.168.178.79 (shellyplus1 / shellyplus1-a8032abc32a8 / shellyplus1#a8032abc32a8#1) - topic: shellyplus1-a8032abc32a8/debug/log, qos: 0, payload: shellyplus1-a8032abc32a8 411152 1715267507.835 1|shelly_bluetooth_rel:81 ADV f4:b3:b1:82:a6:e2: mfd={}, svc={"fcd2":"RAADAWQ6BA=="}

[...]

2024-05-09 23:12:26.946  - debug: shelly.0 (3027106) [MQTT] Publish: 192.168.178.79 (shellyplus1 / shellyplus1-a8032abc32a8 / shellyplus1#a8032abc32a8#1) - topic: shellyplus1-a8032abc32a8/events/ble, qos: 0, payload: {"scriptVersion":"0.2","src":"shellyplus1-a8032abc32a8","srcBle":{"mac":"f4:b3:b1:82:a6:e2"},"payload":{"encryption":false,"BTHome_version":2,"pid":4,"battery":100,"rssi":-83,"address":"f4:b3:b1:82:a6:e2"}}
2024-05-09 23:12:26.947  - debug: shelly.0 (3027106) [MQTT] State change 192.168.178.79 (shellyplus1 / shellyplus1-a8032abc32a8 / shellyplus1#a8032abc32a8#1): shellyplus1-a8032abc32a8/events/ble -> state: shellyplus1#a8032abc32a8#1.BLE.Event, value: "{\n  \"encryption\": false,\n  \"BTHome_version\": 2,\n  \"pid\": 4,\n  \"battery\": 100,\n  \"rssi\": -83,\n  \"address\": \"f4:b3:b1:82:a6:e2\"\n}"
2024-05-09 23:12:26.976  - debug: shelly.0 (3027106) [MQTT] Publish: 192.168.178.79 (shellyplus1 / shellyplus1-a8032abc32a8 / shellyplus1#a8032abc32a8#1) - topic: shellyplus1-a8032abc32a8/debug/log, qos: 0, payload: shellyplus1-a8032abc32a8 422391 1715289146.944 1|shelly_bluetooth_rel:81 ADV f4:b3:b1:82:a6:e2: mfd={}, svc={"fcd2":"RAAEAWTwAQLxABAAAQ=="}

If additional infos will help please give me a hint. Thank you
Stefan

debug.log

[stefan-3r]

Hi Matthias,
do you think you can find a solution with the attached log above? Or do you need additional information that I should provide? Thanks in advance for your support!
Greetings
Stefan

[klein0r]

The problem is, that even the pid changed in the second message:

• "pid": 3
• "pid": 4

I don't know how to distinguish between a "real" payload and a "status payload".

[stefan-3r]

That‘s the problem, right … :(. Somehow Shelly itself must be able to distinguish between both, but we don‘t see it in the payload. So only hope is to wait for firmware-update!?