I can confirm the latest change has fixed the issue with known_devices. Thank you very much, this was quick :-)

Hmm - I can't see why that'd happen. If you could add some console.log statements to find out if config.known_devices is set correctly that could help I guess.

Thanks, this is once again working as expected. The only odd thing that is now happening is within presence, it seems to ignore the first item listed in only_known_devices and never publish the topic in /presence/. As a workaround, I put in a fake address in the first position and now all my items appear as expected.

thanks!

On Thu, Dec 3, 2020 at 9:00 AM Gordon Williams [email protected] wrote:

Ok, I'm not 100% sure so feel free to reopen this if it doesn't fix it, but looking at it:

There's a 'safety' in EspruinoHub that restarts EspruinoHub in case Advertising messages stop getting received. This was needed because it earlier versions of Noble (I think it might be ok now) it could get confused and the only fix seemed to be a restart.

However when you set only_known_devices that safety check required that EspruinoHub could always see a 'known device'. If it didn't always see one it'd keep restarting. That was definitely the wrong behaviour since all we care about is that we can see any BLE advertising - so I changed it so as long as it can see some advertising messages it won't restart.

Doesn't explain the issue with the new bluez though

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/espruino/EspruinoHub/issues/59#issuecomment-737733673, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH5UIHSUGBFODXG6MQZKP3SS5ASHANCNFSM4SDXZFNA .

Ok, I'm not 100% sure so feel free to reopen this if it doesn't fix it, but looking at it:

There's a 'safety' in EspruinoHub that restarts EspruinoHub in case Advertising messages stop getting received. This was needed because it earlier versions of Noble (I think it might be ok now) it could get confused and the only fix seemed to be a restart.

However when you set only_known_devices that safety check required that EspruinoHub could always see a 'known device'. If it didn't always see one it'd keep restarting. That was definitely the wrong behaviour since all we care about is that we can see any BLE advertising - so I changed it so as long as it can see some advertising messages it won't restart.

Doesn't explain the issue with the new bluez though

Hi,

Firstly, thank you for this software. It really allows me to do some cool stuff at my home.

I started noticing some gaps in messages published to my MQTT server which was impacting some automations. I played around the the config file, uninstalled/reinstalled the service, restored my Pi to a previous backup, tried it directly installed and via docker and yet the issue persists. Each time I installed fresh using the stock config, it worked perfectly, but as soon as I edited my config, the problem returned.

I noticed that if I set "only_known_devices" back to the default state of false, all of the problems disappeared.

I am running a raspberry pi 4 on buster arm64. Everything is up to date. I am currently running this via the docker container.

Below is my config. As I said, I only change only_known_devices from true back to false and it works fine. What am I doing wrong? If you need any further info, please let me know. Thanks!

{
  "// If a device's address is here, it'll be given a human-readable name":0,
  "known_devices" : {
    "xx:xx:xx:xx:xx:xx": "keys1",
    "xx:xx:xx:xx:xx:xx": "keys2"
  },

  "// Set this to true to only publish MQTT messages for known devices":0,
  "only_known_devices": true,

  "// How many seconds to wait for a packet before considering BLE connection":0,
  "// broken and exiting. Higher values are useful with slowly advertising sensors.":0,
  "// Setting a value of 0 disables the exit/restart.":0,
  "ble_timeout": 20,

  "// How many seconds to wait for emitting a presence event, after latest time polled":0,
  "// Default is 60 seconds":0,
  "presence_timeout" : 30,
  
  "// Number of simultaneous bluetooth connection the device can handle (PI Zero=4)":0,
  "max_connections" : 4,

  "connection_timeout": 20,

  "// MQTT path for history requests and output. Default is Empty (to disable).":0,
  "//history_path": "/ble/hist/",

  "// We can add our own custom advertising UUIDs here with names to help decode them":0,
  "advertised_services" : {
    "ffff" : {
      "name" : "level"
    }
  },

  "// Make this nonzero to enable the HTTP server on the given port.":0,
  "// See README.md for more info on what it does":0,
  "http_port" : 1888,

  "// Set this to enable the HTTP proxy - it's off by default for safety":0,
  "// since it would be possible to spoof MAC addresses and use your":0,
  "// connection":0,
  "// NOTE: Some Bluetooth adaptors will cause the error: Command Disallowed (0xc)":0,
  "// when trying to connect if http_proxyis enabled.":0,
  "http_proxy" : false,

  "// If there are any addresses here, they are given access to the HTTP proxy":0,
  "http_whitelist" : [
    "e7:e0:57:ad:36:a2"
  ],
  "mqtt_host": "mqtt://localhost",
  "//mqtt_options": {
    "username": "user",
    "password": "pass",
    "clientId": "clientid"
  },
  "// Define the topic prefix under which the MQTT data will be posted. Defaults to /ble which is not adviced. For new installation, please activate the option below.":0,
  "mqtt_prefix": "occupancy"
}

I can confirm that I, too, am running bluez 5.50.

On Thu, Dec 3, 2020 at 5:39 AM Plague doctor [email protected] wrote:

Ok. I have more on this issue. This happens with the latest version of bluez, bluez-firmware and bluez-hcidump (5.50-1.2~deb10u1+rpt2). The previous version works fine with known_devices set to true. The version 5.50 does not. I hope this will throw some light on the issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/espruino/EspruinoHub/issues/59#issuecomment-737660907, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH5UIF7QDIX2KAHO4NMKIDSS4JA5ANCNFSM4SDXZFNA .

onAdvertisingStart() expects error to be passed as the first parameter, but it never is.

Thanks!

Ok. I have more on this issue. This happens with the latest version of bluez, bluez-firmware and bluez-hcidump (5.50-1.2~deb10u1+rpt2). The previous version works fine with known_devices set to true. The version 5.50 does not. I hope this will throw some light on the issue.

Yeah, go for it. Might be good to add a commit with some background information if you've got the time, potentially with info about a YT Music plugin.

I have been kissed with the same issue. I haven't pinpointed that to the known_devices list, but have observing huge number of errors:

<Discover> BLE broken? No advertising packets in 20 seconds - restarting!,

Also presence were flapping like crazy causing my garage door open and close all the time...

@belak Are you okay with me going ahead marking this extension as deprecated and archiving the repo?

attribute json format in mqtt

Thanks! In future for stuff like this please could you add a note to the README, otherwise others won't know it's there.

I'll add something to https://github.com/espruino/EspruinoHub/blob/master/README.md#advertising now

attribute json format in mqtt

add support https://github.com/atc1441/ATC_MiThermometer#advertising-format-of-the-custom-firmware

add support https://github.com/espruino/EspruinoHub/pull/64/files

support ATC_MiThermometer advertising format of the custom firmware https://github.com/atc1441/ATC_MiThermometer#advertising-format-of-the-custom-firmware

Great - thanks!

Help parse argument options

https://www.npmjs.com/package/minimist

support ATC_MiThermometer advertising format of the custom firmware https://github.com/atc1441/ATC_MiThermometer#advertising-format-of-the-custom-firmware

add support https://github.com/atc1441/ATC_MiThermometer#advertising-format-of-the-custom-firmware

Would be nice to just have one card per radio station to keep it simple. The configuration would be done at setup, where the user would supply the URL of the stream and a name for the radio