Pull to refresh

Comments 23

Из документации он работает на «Windows 10 UWP 1511+». Какой смысл его использовать, если есть стандартное решение от Microsoft на том же UWP?
Была идея найти решение для .Net Core, но как выяснялось — это проблема.
Был неправ, поторопился. Практически всё, что нашёл, если под Винду, то UWP. Аж странно.
В этом и фокус. Ну да ладно, не оценили сути статьи, так не оценили. Тоже опыт в копилку.
Смысл в том, что бы иметь как можно меньше общего с криворукими программистами из МС. UWP багованный в доль и поперек. Плюс ко всему имеет кучу подводных камней. Попробуйте получить доступ к устройству из консоли на Win10. Ну и да на Win7 тоже. А еще почитайте эту ветку social.msdn.microsoft.com/Forums/en-US/58da3fdb-a0e1-4161-8af3-778b6839f4e1/bluetooth-bluetoothledevicefromidasync-does-not-complete-on-10015063?forum=wdk&prof=required
Смысл в том, что бы иметь как можно меньше общего с криворукими программистами из МС
Вы всё ещё говорите про библиотеку для .NET?
С BT от UWP засада в том что все взаимодействие должно идти в UI потоке. Т.е. чисто гуишное применение, на что собственно весь UWP и рассчитан. Если нужно сервисное приложение\сборщик данных — лучше в сторону линукса смотреть.
UWP умеет в фоновые процессы и сервисы, в консольные приложения, в обработку событий от драйвера.
«Сути статьи», действительно, "… не оценили".
Я, безусловно, приветствую старания автора привнести что-то новое и осознанно-заключенное, но первое что я подумал при прочтении заголовка (а особенно при упоминании .Net Core) — это кросс-платформенный доступ к Bluetooth с использованием C#.
Потому как, ИМХО, подключению к ГолубомуЗубу через UWP (читай, «более-менее классический Виндовз») — извините, ни на секунду не новинка. UWP, действительно, был задуман как «новый шаг на встречу к мобильным устройствам», и поддержа (в т.ч., довольно удобная) Bluetooth в нем не вызывает удивления.
Что же, действительно, очень «exciting» — это потенциальное кросс-платформенное обращение к такого рода девайсам из C#. Такое на данный момент (с точки зрения спецификации) выглядит возможным только через Xamarin.



Но если ближе к делу, то одной из главных непоняток цели статьи для меня стало вот это:
Hello World для получения данных с Bluetooth (BLE) устройства через C#

C# — это спецификация языка программирования. Конкретная же его реализация уже определяет, что доступно на этой платформе, а что — нет. (Вы знали, что C# используется в Unity-движке, что не имеет никакого отношения к .Net?)
Так какова Ваша целевая платформа?

И…
Сразу скажу, что решения по взаимодействию библиотек UWP с .Net Core отыскать не удалось и проект пришлось переключать на 4.7.1., благо это не сложно.


Цели «взаимодействия» UWP и Core в данном контексте я не понимаю: если у нас имеется УВП, значит мы — на Виндовсе, значит нам Кор не нужен для такого рода операций.
Более того, спецификация .NET Core и не предусматривает непосредственное общение с такого рода устройствами. Это все равно что пытаться написать статью «Генерация веб-страниц с использованием .NET Core» (для этого есть, снова таки, ASP.NET Core).

Или это я что-то не понял?
Или это я что-то не понял?

И да и нет. Сейчас поясню.:)

(Вы знали, что C# используется в Unity-движке, что не имеет никакого отношения к .Net?)

Знаю:) Более того я экспериментировал с разработкой под Unity с учетом портации кода на отображения в браузере. Там тоже много чего интересное всплывает, но об этом хотя бы есть одна нормальная или пара коротеньких статьей. А вот с Bluetooth для .Net была полная засада.

но первое что я подумал при прочтении заголовка (а особенно при упоминании .Net Core) — это кросс-платформенный доступ к Bluetooth с использованием C#.

Данная статья писалась скорее не для минутного хайпа на habr, а для её индексации на яндекс или google поиске.
Я пытался вспомнить, что я искал в поиске и какие ключевые слова использовал, чтобы найти хоть какую-то информацию. И после уже использовал их в данной статье, для людей, которые также будут искать хоть какую-то информацию в сети по Bluetooth 4.0.

Всё, что сейчас выдается при попытке поиска «Bluetooth .net», на русском или англиском языке, датировано 3 — 5 годами ранее. А самое страшное, что если вопрос о bluetooth и имеет хоть какой-то ответ, то поголовно ведет на библиотеку 32feet.NET.

Кстати о 32feet.NET. Я не стал это описывать в статье, т.к. старался сделать её максимально лаконичной, но вот Вам пара интересных фактов об работе 32feet.NET.
В сети в основном имеется два подхода к написанию watcher-а на 32feet.NET. И если самый распространённый из них не ищет устройство вовсе
client = new BluetoothClient();
devices = client.DiscoverDevices();
if (devices.Length > 0)
{
    foreach (var device in devices)
    {
        lstBTDevices.Items.Add(device.DeviceName);
    }
}
else
{
    MessageBox.Show("Unable to detect any bluetooth devices");
}

то со вторым все не так однозначно.
BluetoothAdapter localComponent = new BluetoothAdapter();

localComponent.DiscoverDevicesProgress += new EventHandler<DiscoverDevicesEventArgs>(component_DiscoverDevicesProgress);
localComponent.DiscoverDevicesComplete += new EventHandler<DiscoverDevicesEventArgs>((s, e) =>{
        Console.WriteLine(">>>");
        localComponent.DiscoverDevicesAsync(255, true, true, true, false, null);
});
localComponent.DiscoverDevicesAsync(255, true, true, true, false, null);


Второй также не ищет устройство (которое находится в режиме обнаружения), но до тех пор, пока не включишь стандартный windows поиск… Как только включается windows поиск происходит магия и я вижу устройство N. Но только пока идет windows поиск… Естественно я матерился, но пытался понять, что я делаю не так с устройством, тем более пресловутый OnePlus 5T виделся с 32feet.NET стабильно.
Потом я копался в исходниках самой библиотеки 32feet чтобы найти решение. Нашел там кучу костылей и unsafe кода или кода который просто лезет в реестры и прочую магию. Но всё это я решил «опустить» в статье дабы облегчить её восприятия, для человека, который будет «быстро» искать решение.
Я, так же, как и Imbecile, не мог поверить, что на C# нет решения, но правда оказалась суровей чем я ожидал.
Более того я сторонился любого упомненная об UWP, т.к. считал, что это уведет меня сторону от решения мой задачи.

значит нам Кор не нужен для такого рода операций.

Тут ответ простой. Проект относительно новый, а Core дает больше возможностей, а как следствие создавать его под устаревающие технологии смысла не было.

Как-то так
Потому как, ИМХО, подключению к ГолубомуЗубу через UWP (читай, «более-менее классический Виндовз») — извините, ни на секунду не новинка.

Возможно. Но все сталкиваются с чем-то в первый раз и пытаются найти решение.

Я сильно постарался чтобы статья не воспринималась как «мега открытие», а скорее, как подсказка — что именно делать.

Написал полноценный пример кода дабы полностью оправдать фразу «Hello World» в заголовке. А не просто текст — «ребята, не получилось, можете и не пробовать.».

Более того найти официальный и нормальный пример работы с устройством через UWP-шный BluetoothLEAdvertisementWatcher без знания ключевых слов — целая проблема.
Например, на эту ссылку, официального msdn, выйти по запросу BluetoothLEAdvertisementWatcher практически не реально

А даже если и выйдете, то примера для случия Indicate characteristic там нет. И опять же в инете только пара (а может вообще всего одна годная ссылка) с адекватным примером по этому поводу.

это кросс-платформенный доступ к Bluetooth с использованием C#.

Именно по этой причине я не стал выносить вразу .Net в заголовок.
При всем уважении к Вашим стараниям, я б, все же, Вам посоветовал хорошенько разобраться в терминах и .NET-related технологиях.

Говорить…

Именно по этой причине я не стал выносить вразу .Net в заголовок.


… (т.е., обобщать .NET) — все равно что говорить «напишу что-то на C#».
Давно прошли те дни, когда говорилось «С#», подразумевалось ".NET", и наоборот.
И про Unity я упоминал не для того, чтоб «расширить» область применения Вашей статьи, а наоборот. Я это к тому говорил, что на месте C# сегодня можно было бы подставить что угодно другое: F#, VB.NET или даже Python for .NET. Они все (в той или иной мере) используются для .NET, но в то же время .NET — это слишком широкое понятие.

Данная статья писалась скорее не для минутного хайпа на habr, а для её индексации на яндекс или google поиске.


Мне кажется, Вы этой статьей наоборот усложнили поиск решения. Потому как я до сих пор не могу до конца понять, что именно Вы хотели этим решить: сначала велось про .NET Core, потом оказалось, что это не сработает, и закончили тем, что «ну да, попробуем стандартное UWP».

Но возможность реализации той или другой функциональности в наши дни исходит, в первую очередь от платформы (фреймвока), который что-то поддерживает или нет.
Я б еще понял, если б статья называлась «Попытка подключения к BluetoothLE-устройству средствами .NET Core», но… см. выше.

Ко всему этому, можете объяснить, чем вот эта библиотека Вам не подходит?
Там есть и .NET Standard (следовательно, и .NET Core), и всякие другие платформы.
Разве что, Вам нужно это на Линуксе, и там поддержи ее нет, да. А все остальное — пожалуйста.
Ко всему этому, можете объяснить, чем вот эта библиотека Вам не подходит?

Ну например, по заголовком
Easy to use, cross platform, REACTIVE BluetoothLE Plugin for Xamarin
Более того на Windows платформе приведенная библиотека использует «Windows UWP 16299+».

Мне кажется, Вы этой статьей наоборот усложнили поиск решения.

Усложнил? Я вроде именно написал, что единственное, на данный момент решение использовать UWP. И рассказал как это сделать, если уже есть готовый проект на .Net Core или 4.7.1

И опять же это не переписывание какого-то одного ответа с другого форума, а объединение разрознены поисковых результатов в единый совет на простой вопрос
— «Как получить данные с Bluetooth 4.0 LE c .Net Core?»
Формально — никак, но есть описанный мной обходной путь.
Статья о том, как человек искал BLE для net core и не нашёл. Вот и вся суть.
всё друг с другом взаимодействует, холодильник с плитой, утюг с пылесосом и т.д.
Даже так бывает?
Пример хотелось бы.
Модуль Wi-Fi позволяет следить за процессом приготовления со смартфона и настроить взаимодействие плиты с другими бытовыми приборами Samsung.

www.iguides.ru/main/accessories/flex_duo_umnaya_elektroplita_samsung_s_podderzhkoy_wi_fi

То есть, холодильник управляет освещением, температурой, камерами наблюдения и тому подобными штуками.

wylsa.com/samsung-family-hub

В удобном приложении Ready for Sky вы можете включить или отключить SkyIron RI-C250S, отследить статус работы утюга и даже его положение в пространстве.

redmond.company/ru/products/umnye-utyugi/utyug-redmond-skyiron-c250s
У меня недавно была схожая задачка, только девайс был просто bluetooth 4.0 (не LE): ловить нажатия кнопок на девайсе windows service'ом. Happy end не наступил. 32feet девайс (и его сервисы) видел, но подключаться не хотел. Winmd вообще никакой реакции не проявлял (событие Received никогда не наступало). К сожалению LE девайса под рукой не оказалось (чтобы уточнить кто виноват).

Кстати, вопрос по представленому коду:
if (!service.Uuid.ToString().StartsWith("serviceName"))

if (!characteristic.Uuid.ToString().StartsWith("characteristicName"))

Как это? Ведь оба Uuid'a (1, 2) имеют тип Guid.
Да, там guid-ы. Но тут я уже перестраховался исходя из API устройста. В ней, в описывалась только стартовая часть guid-а как «якорь», то решил проверять не весь его, а только первую часть. Фиг знает, как там производитель мудрит с ними. В нормальном коде там часть guid-а
К сожалению я так и не смог запустить ваш код. Он банально не компилируется. Когда приводите сорцы целого класса неплохо указывать using, которые в нем использовались. Я нашел все что смог тем не менее, ругается на все асинхронные функции. Которых просто нет. i.imgur.com/RMroWpi.png
Sign up to leave a comment.

Articles