naugehyde - Hi all. I'm looking for Beta tester...
Hi all. I'm looking for Beta testers for a substantially revised version of my bt-sensor-plugin-sk plugin. The latest revisions are here: https://github.com/naugehyde/bt-sensors-plugin-sk/tree/1.1.0 (Docs are NOT up to date as of this writing)
I'm looking for mariners with Victron equipment as well as Inkbird and Xiaomi sensors on their boats. If your boat has a Bluetooth-enabled sensor not currently supported by the plugin that you'd like integrated into the SK data model, just let me know and I'll do my best to code it for you.
Thanks!
34 Replies
Have you tried to run this plugin from dockerized SK?
I tried earlier version but gave up as it did not run correctly. I got it half way running by adding needed dependecies to docker, but it never showed any devices. There was no errors which would have guided to next step.
Any thoughts is it even possible?
Noble based BLE is working fine from docker. I did some basic testing and was able to see my Victron devices and receive data, but I did not add the decoding part for trial codes. It worked parallel with RuuviTag pluging.
@naugehyde the good people in #victron should be able to provide you with a lot of packet captures from different devices, as well as a link to the official victron "instant readout" datasheets for decoding the (encrypted..) BLE advertisements
@tobias_r I've reached out through public channels and have yet to hear back. If you have any insider contacts, I'll take them!
another thing i personally would be interested in is simple "presence detection", i.e. set/change/delete a certain path whenever a specific MAC address shows up as discoverable.
there was a little thread about BT/BLE presence detection over in #hardware... https://discord.com/channels/1170433917761892493/1285512236806176861
@Karl-Erik Gustafsson I haven't tried it dockerized but it should work nonetheless. Can you send the debug log and/or open an issue on github? Note: there was a bug in the 1.0.2 version that should be fixed in 1.0.3.
the protocol specification can be found here: https://communityarchive.victronenergy.com/storage/attachments/48745-extra-manufacturer-data-2022-12-14.pdf
@Karl-Erik Gustafsson note: the plugin is system-d dependent and therefore mostly linux-only. FWIW, I had more reliable results from node-ble than Noble.
@tobi42 thank you. I'm well familiar with that doc and used it to get where I am right now. it's about two years out of date and doesn't cover all their latest devices and protocols. 😦
i don't know if there's a more recent version of the instant readout specs, but I guess @mpvader would know
the data layout for the orion xs was posted in another thread on the victron community forums: https://community.victronenergy.com/t/orion-xs-12v-12v-50a-bluetooth-advertising-data/2183/3
Running on linux system-d already available from docker, so starting point was kind of verified.
I'll check the new version during this weekend and let you know results.
@Karl-Erik Gustafsson thanks. likely a version issue. plugin 1.0.3 is still relatively primitive compared to the upcoming beta and only supports the Victron SmartShunt and a handful of BT thermometers I happened to have available.
I would be interested in getting the Renogy BT-2 supported! There is some info on extracting info from it here: https://github.com/cyrils/renogy-bt
I'll look into it this weekend!
The best I can do for presence detection in my current framework is a last-seen path -- alternatively I could implement an RSSI path for all sensors. The timestamp on the RSSI path could act as a last-seen indicator for you.
RSSI would be great
not just for presence detection, but in general
I'll look into it!
Out of curiosity, what's your application for a BT presence detector?
maybe we could extend the SK spec for sensors.<regexp>.* at https://signalk.org/specification/1.0.0/doc/vesselsBranch.html#vesselsregexpsensors with stuff like MAC, RSSI, firmware-version, etc.?
turn certain devices/subsystems on/off depending on whether someone is on the boat or not, mostly
one of the easiest examples is an anchor alarm: if there's someone on the boat, sound the alarm over a speaker at the nav desk or at the helm. if there's nobody aboard, send a text message or something.
no need to go all whoop whooooop and wake up half of the anchorage late at night when the crew is out for drinks at a bar or whatever
or safety features like switch off power to all USB charging ports when the last person leaves the boat.. so if someone leaves their tablet connected to the charger all the time, there's less chance of the battery catching fire
I get it. I like it! Very cool. The only wrinkle is that the plugin is currently dependent on the accessibility of its BT devices at startup. I'll look into making it more flexible -- the scanner is always on by necessity after all.
i'm still thinking about restarting my esp32-ble-presence-detection-thingie project
then you could simply have a few ESPs around the boat, and even do fun stuff like "where on the boat is the tag with id X?"
either just by checking which receiver sees the highest rssi for a specific mac, or even by doing basic triangulation 😄
that'd be remarkable. and a lot more sophisticated an application than my plugin would handle.
sure, the location feature would be a lot of work.. but simple presence detection would already be enough for a lot of "comfort features"
what do you use for a "tag?" your phone? or an actual smart tag?
right now, i'm using my 20€ el-cheapo "fitness bracelet"
not unwise. a phone is likelier to be left behind accidentally than something around your wrist.
couple days of battery runtime, waterproof, and doubles as a wristwatch and a vibration alarm for notifications on my phone (which might be on my desk, or in my backpack, or wherever..)
yeah, or even left behind on purpose, e.g. when hopping in the dinghy to go for a swim at the other end of the anchorage...
let me know if you need testing with an Orion
I do need an Orion XS tester. Thank you! Since there isn't a GATT protocol for the Orion so you'll need to get the device's advertisement key. Let me know if you need instructions for that.
The code is still cooking but if you're feeling moderately adventurous, you can git clone the code from github @ https://github.com/naugehyde/bt-sensors-plugin-sk/tree/1.1.0 Install instructions are here: https://github.com/naugehyde/bt-sensors-plugin-sk/blob/1.1.0/README.md#linux
nb:
1) docs have not been updated but the install instructions above should work, just be sure to adjust the clone location to the above 2) baseline Victron code has been tested with only two Victron devices (SmartShunt, Solar charger) 3) not sure about the Orion XS's charger error codes. If you have intel, please share. 4) Any problems, just shout
1) docs have not been updated but the install instructions above should work, just be sure to adjust the clone location to the above 2) baseline Victron code has been tested with only two Victron devices (SmartShunt, Solar charger) 3) not sure about the Orion XS's charger error codes. If you have intel, please share. 4) Any problems, just shout
looks like the orion error codes are the same as the solor charger: https://github.com/victronenergy/venus/wiki/dbus
GitHub
dbus
Victron Energy Unix/Linux OS. Contribute to victronenergy/venus development by creating an account on GitHub.
(assuming bt code match what's on d-bus)
got an RSSI update working today. what platform are you running on? Noticed some weirdness with my RPI 4B that might result in false negatives.
i'm running SK on a pi4b...
okay. in that case something you'll want to look for when monitoring RSSI signals with the plugin is whether the minimum discovery timeout for your device increases over time after restarting the plugin. iow, the first time through the plugin should find your device and report its RSSI when the value is beaconed after that it's a dice throw.
when the plugin is restarted either by submitting changes to its config thru the plugin config interface or disabling and re-enabling it, I've noticed that some devices that bluez reported to system-d are not available the second time around-- even with generous timeouts. no idea why this is the case but as a result -- since presence of a BT device in your application is determined by the timestamp of the most recent RSSI value -- you could get a false negative (non-presence) reading from the plugin.
UPDATE: problem may well be randomized macs -- plugin currently doesn't support randomized mac clients. not sure if it ever can.
@Jason_SV.Apres|Hunter336|WI
Took a look at the Renogy code. The protocol as divined by the coder is a little messy (not surprising considering he hacked the protocol with WireShark).
Rumor has it that Renogy is releasing specs for their BT protocol some time soon. I'm going to wait on this before proceeding with implementing my plugin. Are you in contact with anyone at Renogy who I could contact and maybe get a preview of their BT-spec release?
No, I am not in contact with anybody at Renogy, but could reach out and try to find out
Thanx. I'd appreciate that. Will expedite matters if I could get their official specs-- especially since I don't have a device to test with.
I contacted Renogy support and they had an internal discussion and come back with an email address for somebody in the technical department looking for information on requirements and intended usage. I will send them an introductory email, but might need some more details from you. if you want to be copied on the email, PM me your email address
feel free to join the thread over in #Bluetooth Sensors for Signalk over in #plugins-and-webapps