Add Shelly BLU H&T #22
Conversation
|
Wow. This is outstanding. Great work! (Better than my own!) Thrilled to add support for BTHome devices. Haven't had a chance to review or test but so long as the static identify method doesn't misidentify a currently supported device, the new BTHome/Shelly class(es) should be good to pull in and distribute with the next release. Can I assume you're ready to take on responsibility for any bugs that arise in the plugin with the BTHome family of devices? |
I don't expect the Shelly class to interfer with other devices. It checks for both the local name as well as the existence of the BTHome service.
I will be able to spare some time, yes :) |
|
Thank you for merging this so quickly! |
|
I figured it was safe to pull in and commit after taking a look at the
identify function.
FWIW it the plug-in with the class installed, starts up without a hitch.
Hoping to get a new release out this week. Just need to update the readme
and create an announcement. BTHome support (albeit preliminary) is a big
deal!
One of these fine days I'm going to figure out a way for sensor class
developers like yourself to package and update your classes without going
through me. If you have any ideas in this direction, please share!
…On Sun, Mar 9, 2025, 8:25 AM sebastianhaas ***@***.***> wrote:
Thank you for merging this so quickly!
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALTAIRBNBCIAKAGVEXB3VSL2TQXNJAVCNFSM6AAAAABYSEYNXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYHAZTCMZSHE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
[image: sebastianhaas]*sebastianhaas* left a comment
(naugehyde/bt-sensors-plugin-sk#22)
<#22 (comment)>
Thank you for merging this so quickly!
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALTAIRBNBCIAKAGVEXB3VSL2TQXNJAVCNFSM6AAAAABYSEYNXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMBYHAZTCMZSHE>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Don't see any reasonable way to do this without adding another plugin layer to this plugin. Accepting a few MRs now and then will most likely be the cheaper option. You can also add maintainers to this project to balance the workload. Two things I'd recommend:
I might be able to contribute on both. |
|
I'll open a thread on github on how to make the plugin more maintainable
and contributions more reliable.
FYI I returned to programming after a hiatus of about 15 years. Web 2.0/
Nodejs /github are all fairly new to me so I'm happy to take your input.
Your code looks very professional!
…On Mon, Mar 10, 2025 at 9:57 AM sebastianhaas ***@***.***> wrote:
Don't see any reasonable way to do this without adding another plugin
layer to this plugin. Accepting a few MRs now and then will most likely be
the cheaper option. You can also add maintainers to this project to balance
the workload.
Two things I'd recommend:
- Adding a linter and formatter, making code style more uniform and
therefore much easier to maintain and review.
- Adding tests. If you make a test for the identify function
compulsory for adding a new device, you can offload the burden of having to
check that manually.
I might be able to contribute on both.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALTAIRFRAXZY3L5ZFZOXIW32TW77DAVCNFSM6AAAAABYSEYNXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJRGI2DKMRZGY>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
[image: sebastianhaas]*sebastianhaas* left a comment
(naugehyde/bt-sensors-plugin-sk#22)
<#22 (comment)>
Don't see any reasonable way to do this without adding another plugin
layer to this plugin. Accepting a few MRs now and then will most likely be
the cheaper option. You can also add maintainers to this project to balance
the workload.
Two things I'd recommend:
- Adding a linter and formatter, making code style more uniform and
therefore much easier to maintain and review.
- Adding tests. If you make a test for the identify function
compulsory for adding a new device, you can offload the burden of having to
check that manually.
I might be able to contribute on both.
—
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ALTAIRFRAXZY3L5ZFZOXIW32TW77DAVCNFSM6AAAAABYSEYNXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOMJRGI2DKMRZGY>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
|
Not sure how to reach you but there's an issue that's cropped up with the Shelly HT. User isn't getting any data unless they press the button on the device -- and then they only get it once. I suspect they're connecting to the device through the Shelly app and the the app is making a GATT connection for device configuration and as a result ServiceData packets aren't being broadcast. Awaiting confirmation but wondering if you encountered anything like this along the way. |
|
This is due to de-duplication of BlueZ. If we somehow get this merged upstream, that would resolve the issue. Why is this even required? Because BlueZ's documentation mixed up the default on/off state of the advertising de-duplication (my issue on BlueZ is linked in the node-ble PR). Anyways, for this application, you cannot have BlueZ ignore adv packets. No GATT is required, the shelly app does not do anything differently. You can try to run node-ble with my PR included and see if it fixes the issue for you as well. |
|
@sebastianhaas The solution is as simple as telling Bluez via node-ble to turn off de-duplication. The code to do this is in the latest push on main and 1.2.0-beta branches. I don't love this solution. It's too broad-based (affects updates from all devices) and doesn't represent the real problem. Sensors like the Shelly are broadcasting their data and even when changed that data is not surfacing on DBus (and therefore in my plugin). |
|
Bought a Shelly H&T. I believe I found the root cause of the issue. Bluez > 5.65 has a config parameter in /etc/bluetooth/main.conf called TemporaryTimeout which defaults to 30s. The logic for TemporaryTimeout is if a device has no new data after the TemporaryTimeout value passes, Bluez stops monitoring the device and therefore doesn't report property changes (RSSI is the only exception). After changing the TemporaryTimeout value to > 60s, the plugin started receiving ServiceData updates from the Shelly. Please give it a try and report your findings here. Note: Turning off duplicate-data will also solve the problem but the TemporaryTimeout solution is more direct and preferred. |
|
So the problem isn't a problem after all. The user just needs to pair the darn device first. Pairing ensures that Bluez keeps the properties for the device in memory. No timeouts. No dropped packets. |
2 participants
As discussed, here is my sensor class for the Shelly BLU H&T.
This device is based on the open source BTHome data format, so I created a base class to facilite adding more BTHome-based devices later on. Also, since parsing binary data that arrives in arbitrary order and different sets of properties (which is the case for the device at hand) is hard, I used Kaitai, a binary struct parser. Conveniently, there is already a declaration file for the BTHome v2 format which, according to my research, originates from and is used in the HomeAssistant community.
The main additions are:
sensor_classes/BTHome/AbstractBTHomeSensor.js- A base class for any future BTHome-based sensor classes.sensor_classes/BTHome/BTHomeServiceData.js- The compiled Kaitai struct based on the binary struct definition. This file is auto-generated and therefore not formatted nicely.sensor_classes/ShellySBHT003C.js- The actual sensor class.Looking forward to hearing your feedback.
Further references
https://www.shelly.com/uk/products/shelly-blu-h-t-mocha
https://shelly-api-docs.shelly.cloud/docs-ble/Devices/ht
https://bthome.io/format/
https://kaitai.io/
https://github.com/koenvervloesem/BTHome-Kaitai-Struct