Shelly BLU H&T- Update logic and battery lifetime in beacon mode

[Oliver Linden]

Hello,

I have two questions:
 

1. Does the device automatically send updates if either the temperature or humidity does change within a threshold frame, e.g. change of t > 0.5°C, and if so, are there different thresholds that can be defined for temperature and humidity?
2. If the device is set to beacon mode, how frequently is it sending updates and what does this mean in terms of battery lifetime?

Best, Oliver

[Heinz]

Hi @Oliver Linden

From what I know the device sends a status check every 11 seconds. It then updates the log when a change is found. See the below example. 

This device does not have a beacon mode like the other devices. 

[Jochen]

I've also some trouble with Blu H&T I've bought couple of days ago. First I wasn't sure if the bluetooth performance is really poor because device sometimes doesen't send values for couple of hours - also if there were changes in temperature or humidity...but if pressing the button value was received immediately. 

I moved the H&T couple of times and activated bluetooth gateway function on other Shellys in the area - situation doesn't improve much. In my actual test-setup a Shelly 2PM is 2 meters from the H&T with only one window between. Also in this setup sometimes no values although temperature and/or humidity is changeing. 
Next thing I've tried is to reflash sensor firmware 1.0.16 with the Shelly BLE Debug-App - this I did yesterday and I'd i have no longterm experience, but I'd say stability improved...I can't see a pattern if device is sending values on a fixed timebase or when temperature and/or humidity are changeing - but since yesterday values are present latest within one hour.

In the official datasheet it is written that sensor is sending values each 11 seconds - in the official Shelly API documentation you can read "the device emits BTHome data packets every 1 minute with the currently measured sensor values" - as well as "There are no device specific settings. Beacon mode is always active. It is the main function on the device". 

I my assumption maybe initial firmware 1.0.16 is somehow litte kind of "buggy" - looking forwared for potential improvements

 

[Oliver Linden]

On 6/3/2024 at 12:00 PM, Heinz said:

Hi @Oliver Linden

From what I know the device sends a status check every 11 seconds. It then updates the log when a change is found. See the below example. 

This device does not have a beacon mode like the other devices. 

Hi @Heinz 

thank you for your reply. Your module is a WiFi enabled one that - indicated by your log file - obviously sends updates on any change of the measured values.

But I'm unsure about the behavior of the Bluetooth only version. Sending updates on a fixed interval of 11 seconds doesn't sound energy efficient. Therefore I'm keen to understand the logic/methodology. With the ability to set thresholds energy consumption could be massively influenced and with this battery lifetime.

[Oliver Linden]

On 6/3/2024 at 7:27 PM, Jochen said:

I've also some trouble with Blu H&T I've bought couple of days ago. First I wasn't sure if the bluetooth performance is really poor because device sometimes doesen't send values for couple of hours - also if there were changes in temperature or humidity...but if pressing the button value was received immediately. 

I moved the H&T couple of times and activated bluetooth gateway function on other Shellys in the area - situation doesn't improve much. In my actual test-setup a Shelly 2PM is 2 meters from the H&T with only one window between. Also in this setup sometimes no values although temperature and/or humidity is changeing. 
Next thing I've tried is to reflash sensor firmware 1.0.16 with the Shelly BLE Debug-App - this I did yesterday and I'd i have no longterm experience, but I'd say stability improved...I can't see a pattern if device is sending values on a fixed timebase or when temperature and/or humidity are changeing - but since yesterday values are present latest within one hour.

In the official datasheet it is written that sensor is sending values each 11 seconds - in the official Shelly API documentation you can read "the device emits BTHome data packets every 1 minute with the currently measured sensor values" - as well as "There are no device specific settings. Beacon mode is always active. It is the main function on the device". 

I my assumption maybe initial firmware 1.0.16 is somehow litte kind of "buggy" - looking forwared for potential improvements

 

Hi @Jochen
interesting observations. Please keep us posted about new findings!

[Heinz]

The device i linked is the https://kb.shelly.cloud/knowledge-base/shelly-blu-h-t

The name confuses me a few times knowing there is the other H&T that also has Wifi. This Blu H&T only has the Paired option to a Bluetooth gateway 

[Dani]

Hello,

the sensors sends update every 1 minute and don't have any beacon mode to be activated, it is its standars functioning mode (see https://shelly-api-docs.shelly.cloud/docs-ble/Devices/ht/).

About the missing trasmissions (for hours), the problem is not on the sensor side but instead the receiver (the gateway) side. Other guys experienced the same issues (see for example https://www.reddit.com/r/ShellyUSA/comments/1d26our/shelly_blu_ht_first_impressions/ and https://www.reddit.com/r/ShellyUSA/comments/1d7x4m5/shelly_blu_ht_missing_transmission/ that is me 😉)

I opened a ticket though the support, they told me that their are working on it.

 

Let us see...

 

 

Edited June 24 by Dani

[Lapu-Lapu]

On 6/24/2024 at 5:05 PM, Dani said:

About the missing trasmissions (for hours), the problem is not on the sensor side but instead the receiver (the gateway) side.

I confirm... I tested several Shelly types as gateway. All tested standard Gen 2 shelly showed these long gaps in receiving beacons from BLU H&T (and BLU Motion in beacon mode).

I tried Shelly Plus 1, 2PM, Plug-S, UNI and even the USB gateway. Now I use a Mini 1 Gen 2 and it receives continuously every 3..4 minutes in between, but at least no hours lasting gaps.

Edited June 27 by Lapu-Lapu

[ERGA]

Hello,

Are there any news on this topic?

I want to adapt a refrigerator with this BLU H&T inside, that controls the compressor with a Shelly Plus 1PM. If the connection is not stable, my goods will freeze or get too warm!

[Dani]

Not from my side. It's been two months and no news from support.

😒

[Heinz]

I put a Blue H&T and a flood in a freezer for testing. The signal was quite ok but I have a Shelly about 2m away for the shelly Blu H&T and the wifi is about 5-10 meters away from the router. 

below you can see the test I did. 
 

I would just make sure when you are turning on a compressor where the power will be pulled from is the shelly just a trigger to turn it on and off or will the power flow though the shelly ? 

[henol]

I also have these 253-ish minutes gaps (1 byte counter?) of no data on my BLU HT sensor when using a script capturing data (running on Shelly Plus Bluetooth Gateway).
The same script captures data from 2 MiFlora sensors and those work fine all the time.
I hope they get on top of this problem soon!
There is another thread about it here:

 

[tvbshelly]

Would it be possible for you to use a Bluetooth BLE scanner during these downtimes to check whether the Shellys are still sending the packets as expected?
E.g. for iOS with something like this:

LightBlue BLE Tool
https://punchthrough.com/lightblue/

BLE Labor Pro (a little bit old)
https://apps.apple.com/de/app/ble-labor-pro/id1436021089

Or have you already checked just that because you wrote:

On 24.6.2024 at 17:05, Dani said:

the sensors sends update every 1 minute and don't have any beacon mode to be activated

On 24.6.2024 at 17:05, Dani said:

About the missing trasmissions (for hours), the problem is not on the sensor side but instead the receiver (the gateway) side.

 

[henol]

I saw data from the sensor in "Lightblue", here are 2 examples below, but no data was seen in the script in the gateway, I added extra logging.
I did a reboot of the Shelly Plus Bluetooth Gateway, still no data.
Then I pushed the button on the sensor and got data: "flags": 6, "service_data": { "fcd2": "D\0n\1[.O:\1E�\0"}}

[henol]

It also seem to be some problem with logging, when logging several rows at the same time as the result object Eg. console.log("result: ", result); not all rows (mainly before the result row) are visible in the output, maybe the result object contains some chars that confuses the browser/html or node/espruino. Also the first data from the result object never shows.
if I only print the pbject property names all are visible. Eg:

  const ttt = Object.getOwnPropertyNames(result);
  console.log(JSON.stringify(ttt));

Outputs (which is correct):
 

 ["addr","addr_type","rssi","advData","scanRsp","flags","service_data"]

But
 

console.log("result: ", result);

Outputs ( Missing: { "addr","addr_type","rssi","advData","scanRsp" 😞
  

"flags": 6, "service_data": { "fcd2": "D\0n\1[.O:\1E�\0"}}

Also console.log() rows done before console.log("result: ", result); are lost, so something strange is happening with browser or buffers in node there.

[tvbshelly]

As I know it from Javascript, the console.log() function only has a single parameter. Maybe the error message comes because you pass 2 parameters?

Maybe you can try:

console.log("result: " + result);

 

Edited August 12 by tvbshelly

[henol]

Hi,I tested.
It's another result:
console.log("result: " + result); gives: result: [object Object]
And:
 

const ttt = result.keys;
console.log(JSON.stringify(ttt));
console.log("result: %O", result);

gives only (the whole array output from ...JSON.stringify(ttt)); and start of result object is missing):

"scanRsp": "",
"flags": 6,
"service_data": {
  "fcd2": "D\0p\1[.8E�\0"
  }
}

From the manual: console.log([data][, ...args])

const count = 5;
console.log('count: %d', count);
// Prints: count: 5, to stdout
console.log('count:', count);
// Prints: count: 5, to stdout 

 

[tvbshelly]

Oh, I see, then my suggestion wasn't very helpful, sorry.

[henol]

Hi again, however the main problem is not the console.log(), it's the lost sensor packages.
I hope you can find the problem.