The Blu devices communicate via BT only and even within the Shelly ecosystem need a gateway. Many Gen3 and Gen4 devices, especially those with BT and WiFi support, have this functionality. They forward the BT transmissions to the Shelly cloud by default.
Anyway, they can be picked up inside the scripting, and this is the main function of the oh-blu-scanner script - do this locally in the network.
And your assumption is right, as the buttons are low power battery operated devices, they only transmit any data on physical button events. They even go as far as to never transmit anything by themselves even on the long term.
My gut feeling tells me that this may well be a communication issue between OH and the oh-blu-scanner script.
Which might be related to the OOM issue of the script on the Plug S Gen3. At least itâs the same subdomain of the functions.
But itâs also inherently linked to the socket communication between the Shelly and the binding.
So it seems to me it might make sense to first wait until you are through with your numerous respectable PRs, and when that runs stable, take a deeper dive into the gateway script.
That sounds terrible. Why would people buy such devices? I thought the Shellys worked locally.
Iâm guessing that they are using BT to allow a reasonable lifetime for the battery, as Wi-Fi can eat a lot of battery.
Is the protocol not publicly documented, or is it just that nobody has made a âShelly BT bridgeâ that can communicate with them directly using a BT dongle - removing all the cloud BS?
You can turn off all cloud stuff by mostly one click. And yes, they do run locally, but with limitations.
They encourage linking their devices up to smart home ecosystems to overcome the limitations in local operation. They offer support for this, but they donât write software. Understandable so far.
Public API documents are available but their quality fluctuates, and keeping the overview over the many generations and API (breaking) changes is something prone to overwhelming any dev or LLM
The Blu series use BLE for battery reasons.
Meanwhile they even have series supporting Zigbee as well, but for whatever reason they decided it do it with BLE when they started to set up their battery powered portfolio.
The Shelly BT bridge is exactly what the OH scanner script does. It bridges the Shelly BT into the OH ecosystem.
I donât know how this works, but it sounds to me like itâs a script that you run on the device, that somehow lets OH âdiscoverâ it. Thatâs fine I guess, but what I was thinking of was that OH did the BT communication itself, so that there were no need for a gateway.
There are other bindings that use BT communication, if you have a BT dongle on the OH server.
That said, BT have horrible range, so I donât quite get how thatâs useful. I assume BLE is an improvement range-wise over ânormalâ BT, or it would be pointless to use at all (5 meters âif youâre luckyâ). I see that they claim 10-30 meters range for BLE, I guess that somewhat comparable to Zigbee?
The reason for not going with Zigbee might be licensing fees. I think there are licensing fees both for Z-Wave and Zigbee devices.
Anyway, weâre drifting - the point is that, as of today, OH doesnât communicate with them directly using BLE, but communicates via IP with a gateway that has both Wi-Fi and BLE, and then acts as a bridge. On top of this, there are scripts⊠that does something that is unclear to me, that allows the binding to discover and control these devices. Did I get it somewhat right?
Itâs very easy to pair the Blu devices with an appropriate gateway inside the Shelly ecosystem.
My coarse understanding of the setup is:
Once linked up, there are listener services in Shelly scripting which can react on received data and call a registered callback function.
The callback does some processing (filter, deduplicate, number and type conversions, etc) and publishes the results of such event via, drumroll, websocket. Here is where I feel the ends could meet.
Of course, but any such âgatewayâ, if commercial, is a security risk - since they share your data with others. Thatâs why, to me, itâs a point to make all communication local, so that nobody can buy/sell your data. Likewise, anything you do in a phone âappâ is compromised, Google have made it so that just to allow an app to use notifications, they must share the user data - and now they have announced that they will stop supporting open source âappsâ completely soon. Only âGoogle approvedâ software will be possible to install in the near future, and being âGoogle approvedâ means that you agree to let them dictate what happens to your data - and of course that you pay them for âcertificatesâ and whatever else they decide to come up with.
The whole reason I invest time in OH is to have an alternative to these very questionable practices, so to me, anything that opens up to stealing your data defeats the whole purpose of using OH
This is still something you can absolutely achieve with Shelly. The pairing process BT-wise is rather easy, thatâs what I meant.
If the gateway device has cloud access disabled, itâs still a (required) gateway between BT and local WiFi, with no data leaving the LAN.
If you isolate this LAN from the Internet inside the router âto be really sureâ, youâll see it continues working.
And regarding the current issues here, the crucial point might be the WS (or HTTP? Not 100% sure) connection between the gateway device running the oh-blu-scanner and the OH instance itself. This might surely be affected by the recent updates.
Itâs a bit stupid that I have to ask this here, since @markus7017 certainly knows this, but does this âOH scriptâ run on the gateway or the BLU devices themselves? Where can I find this script? If it runs in the gateway, it makes more sense to me, and the script itself might reveal some interesting details about the communication.
I canât see any network communication in the script, so there must be parts here that are handled by the Shelly or in some other way that Iâm not aware of. I was most interested in looking at how the network communication code looked. But, from what I can see, itâs not unthinkable that details in this script could cause problems with certain devices, as it seems to be tailored to specific âsupportedâ devices.
Can the:
..actually be a custom version of this script? But, since the script is installed by the binding, it still ends up being tied to a specific version of the binding?
Yes, I am familiar-ish with that part. The Java code uses Jetty for the actual WS communication. I was looking for the network/WS handling âon the other sideâ/in the Shelly. But, Iâm guessing thatâs âautomaticallyâ handed by the Shelly firmware in some way.
Shelly.emitEvent()
This method creates an event which is broadcasted to all persistent RPC channels.
Shelly.emitEvent(name, data) â undefined
Thatâs the magic involved here
I am unaware of the possible versions of this script. But when it publishes over RPC, the handling may have changed on the OH side as well.
Anyhow. This is the script which drives the Plug S Gen3 into OOM (but not the older generation hardwares).
The script seems have grown a lot with Shelly adding new Blu devices, so when I briefly looked over it, I was wondering why so much preprocessing is done on such limited devices, and whenever a new device is released by Shelly, the script as well as the binding needs to be updated.
Maybe historically grown. Maybe necessary for a reason I didnât stumble upon yet.
Or maybe worth a refactor such that the script only does some basic prefiltering and forwards valid but raw data, while the actual parsing is done in the binding. This would unload the Shelly gateways from much work, simplify updating and adding new devices.
Thereby maybe even fixing the OOM.
I use the officially merged Shelly binding 5.2.0.202603030411. Am happy to confirm that the following warning message which appeared very often in the log has gone with this update.
Before this update, the message disappeared only if the Shelly binding was disabled.
2026-01-27 00:35:31.521 [WARN ] [e.jetty.util.thread.QueuedThreadPool] - Stopped without executing or closing
thatâs correct, there are still 2-3 PRs on the way before I move to WS90. The is a jar in the myfiles repo having this support, but not the latest fixes
