- В этой теме 45 ответов, 3 участника, последнее обновление 8 лет назад сделано
.
-
Сообщения
-
Пока никакая 🙂 все, что добился, это в своем варианте изменить имя корня на нужное мне.
Нашел вариант в нете с иерархией, но там корень называется ArrayOfPerson (Person это один из классов сериализации) и это имя явно формируется в недрах System.XML или его Сериализации.Но там в примере использовались для построения дерева вызов одного класса из другого, а у меня есть кусочек кода, где это может оказаться недопустимым, но возможно обойду.
Плюс похоже для сериализации надо еще и подготовку делать в коде программы и с этим я еще не разобрался. А примеров просто НЕТ толковых даже без комментариев, не говоря про них.
Я так бегло почитал про mbus. Насколько я понял, изначально мы понятия не имеем, что вообще получим от прибора. Делаем запрос получаем список тегов, которые он может отдать. Сохраняем их в конфигурацию после опроса, останавливаем опрос. Опять открываем конфигурацию КП и снимаем галочку инициализировать. Запускаем опрос с готовыми тегами. Примерно так Вы планируете?
Да, примерно так, но возможно не придется останавливать опрос, если драйвер сможет самостоятельно проверить при следующем опросе наличие в xml сохраненных тегов и сформирует список.
Можно и руками все набрать, но там есть много НО.
Хоть протокол и открытый, производители лепят что хотят. У меня сейчас на руках два устройства и оба работают по разному. Вообще планировал делать универсальный драйвер платным, но нужно больше устройств для тестирования. Так же планировал делать отдельно драйвера устройств в бесплатном варианте, но там будет прописана жесткая логика под конкретный прибор согласно данным от производителя.Мне кажется универсальный драйвер не получится. Всё время будут вылазить какие-нибудь грабли с каждым новым прибором, а то и с его версией прошивки.
Лучше клепайте на заказ под каждую модель, а на этих потренироваться :).
Я так понял даже всякие коммерческие утилиты и девайсы не гарантируют стопроцентную работоспособность со всеми устройствами.Если производитель сделал вариант обмена по протоколу, но использовал ту его часть, которую посчитал нужным то универсальный драйвер будет работать с любым устройством.
Есть там пакость конечно, но не смертельная, при созданной мной структуре xml думаю смогу этого добиться.
Если же где-то отступил от протокола, то может работать не все или не так, но опять же, в универсальном драйвере я это учитываю изначально.В простом драйвере устройства не будет вариантов изменения запросов, все будет четко по документации производителя.
Как например счетчик тепла Wesser Heat Meter не опрашивается по адресу (он его просто не имеет), а только по ID счетчика. И вроде от протокола не отступили, ну просто не доделали 🙂Универсальный драйвер планируется делать вариативным, запросы можно будет формировать вручную.
aburakhin@bk.ru присылайте свой вариант.
Я вроде победил путем организации классов и использования списков классов внутри другого класса (родительское дерево) но может ваш вариант будет лаконичнее?Ещё не смог победить запись всех атрибутов и их значений в список не вникая в количество атрибутов и их имен. Не смог разобраться с IEnumerable или с ICollection. Пока только явно копируя значения атрибутов. Но тогда при изменении количества придется править это и в коде.
Что-то Вы меня озадачили. Если не большой секрет, бросьте на rsp @ bk.ru . Я не пойму про что Вы говорите. У меня класс DevTemplate в котором реализована вся структура.
Я наверное сделаю именно КП, а не пример exe, просто не понимаю, что должно быть на выходе.На выходе должен быть мой xml, который приводил.
Но есть проблемы
1. Секции Telegram будут появляться только после опроса прибора, количество секций Val заранее неизвестно — это может вызвать проблему десериализации потом, хотя можно будет дописывать в файл отдельно, но если будем менять xml в части команд, то придется как-то сохранять готовые секции Telegram и после очередной сериализации возвращать их обратно
2. Что касается чтения коллекций, это избавило бы от лишней работы при создании новых драйверов, где количество атрибутов будет отличаться от нынешнего, просто более универсальнее было бы.В понедельник с работы отправлю, на домашнем компе нет исходников, да и студии тоже.
Вот, уже интереснее, как вы обошли создание разного количества вложенных секций SndGroup и CmdGroup ? именно по этому у меня списки классов. ну и сам класс проще редактировать
Получил, спасибо. В целом похоже, просто видимо я лепил на основе того, что у меня было уже… На работе изучу и скину свой тестовый пример.
Мне бы еще с List разобраться, чтобы все атрибуты ветки читались как коллекция, при этом могла сериализоваться и десериализоваться. Чтобы не зависеть от количества и их имен.В данном примере все сериализуется, без разницы сколько переменных Вы добавите.
KPTag в коммуникаторе это Ваши Val?
- Для ответа в этой теме необходимо авторизоваться.