есть котельная на Viessmann Vitotronic 333 из 3-х 100, в самом простом варианте.
есть желание удаленно смотреть ее состояние, но нет возможности тратить деньги на нормальный метод решения задачи... это скорей всего первая и последняя такая котельная у меня.
что сделал - посмотрел осциллографом что там бегает по витой паре, быстренько соорудил на 20МГц AVR микроконтроллере, импульсном трансформаторе и еще кучке подручного мусора преобразователь LON FT10 в RS-232 (с дальнейшим переводом на 485+модбусрту). написал программку-логгер, по логу и SNVT.PDF и тошибовской доке на 3150 написал разбор пакетов - получил темпратуры котлов и их состояния (вкл/выкл), и обработку SNVT_alarm (по списку кодов из Viessmann пдф по ЛОН-протоколу)
результат почти достигнут...
но остались насосы и и подобное...
так как софта (лонменеджера и подобного) у меня нет, и нет адаптера для лонсканера - получился некий тупик...
по сети там бегают еще некие неопознаные мной стандартные переменные, и всякие nvoFDMConsDmd (UNVT_Demand) и nviLFDMProdState (UNVT_ProdState).
может кто по ним что подскажет?
еще просьба - может есть возможность лонсканером лог снять с любой Viessmann котельной и мне его прислать?

По теме ничего не подскажу, не сталкивался. Наоборот возник вопрос как соотносятся понятия "посмотрел", "соорудил", "написал" и "нет возможности тратить деньги на нормальный метод решения задачи"? Работаете за еду что ли??? Или вы в штате и просто решаете производственную задачу?

простая арифметика: потратил на работу пару вечеров, один раз подъехал на объект. материальных затрат - менее 500р (потраченное время - вопрос отдельный, но на освоение нормального софта явно меньше не уйдет...)
заказчику абсолютно все равно, что я там поставлю, и на сумме это не отразится.
остальня часть диспетчеризации делается отработанным методом - свободнопрограммируемый ПЛК, датчики и связь с имеющимеся теплосчетчиком и корректором.
на работу имеющийся лон-сети я не повлияю (я просто слушаю, с гальваноразвязкой и входным импедансом "слушалки" на 2 порядка большим чем рядом стоящий терминатор).
чем отдавать работу на сторону, или покупать инструментальные средства для разовой задачи - я лучше "на еду" и прочие приятности деньги потрачу. а деньги там (именно для разовой задачи) совсем не копейки...
ну это отмазки, чтоб сильно не ругали...

а по делу - про Viessmann nvoFDMConsDmd (UNVT_Demand) и nviLFDMProdState (UNVT_ProdState) кто может подсказать?
а то на насосы релюшки вешать некрасиво получится...

Эти переменные тебе врядли помогут, за состояния DO отвечает nvoNodeRlyState типа SNVT_state - Control output status: logical status of control signals of device: structure in which logical signals of the control unit are being exported. If corresponding signals are available for each control unit (see below), the following applies: 1=on, 0=off or not available.
Logical signals of control units in nvoNodeRlyState:
bit Logical Signal
0 DHW tank loading pump
1 Re-circulation pump
2 Heating circuit pump 1
3 Heating circuit pump 2
4 Heating circuit pump 3
5 Night-time contact HKP 1
6 Night-time contact HKP 2
7 Night-time contact HKP 3
8 Supply pump - not available for Vitotronic 333
9 Primary pump heat exchanger set for DHW tank loading
10 Boiler circuit and distribution(common supply) pump
11 Shunt pump
12 Flue gas heat exchanger pump - not available for Vitotronic 333
13 ThermControl switching contact - not available for Vitotronic 333
14 Burner 1st stage - not available for Vitotronic 333
15 Burner fault - not available for Vitotronic 333

Описание переменных на сайте висмана есть на английском, напиши на ganev.dmitriy@santa.com.ua, если что

Локальное устройство управления запросами (Local Flow Demand Manager Object) предназначено для обмена данными между регулирующими устройствами фирмы “Viessmann”; оно не является необходи-мым для присоединения внешних компонентов.
Локальное устройство управления запросами (Local Flow Demand Manager Object) собирает в одном регулирующем устройстве, не имеющем собственное устройство управления производ-ством тепловой энергии (регуляторы отопительного контура “Vitotronic 050”), все запросы, от-носящиеся к температурным параметрам, и передает их дальше в аппарат, который управляет производством тепловой энергии. На обратном пути локальное устройство управления запро-сами (Local Flow Demand Manager Object) передает дальше к внутренним потребителям тепло-вой энергии (отопительные контуры и водогрейные устройства) сообщения о состоянии, полу-ченные от устройства управления производством тепловой энергии.
Переменные величины сети всех объектов LFDM какой-либо установки объединяются с соот-ветствующими переменными величинами сети объекта CFDM установки.

nviLFDMProdState (UNVT_ProdState) - Состояние установок: структура данных (4 байта) для передачи данных состояния производства тепловой энергии к потребителю тепловой энергии.

nvoFDMConsDmd (UNVT_Demand) - Запросы данных температуры в подводящих трубо-проводах регуляторов отопительных контуров: структура данных (10 байтов) для передачи за-просов потребителей тепловой энергии к устройст-вам, производящим тепловую энергию.

проблема в том, что nvoNodeRlyState типа SNVT_state сам по себе в такой простой конфигурации по сети не передается, так как (может я и ошибаюсь) живет исключительно внутри 333-го контроллера. а nvoFDMConsDmd (UNVT_Demand) и nviLFDMProdState (UNVT_ProdState) есть в сети раз в минуту или чаще, и меняются в такт с работой котлов. но разбираться с ними по совпадениям с состоянием оборудования совсем нехочется, больно процесс медленный.

может возможно переконфигурировать всю систему для передачи nvoNodeRlyState, но я не уверен в безопасности этой процедуры, и хочу обойтись уже имеющимся трафиком.

трафик в сети совсем маленький - пара десятков пакетов в минуту примерно.

Я же написал где можно взять описание, неужели так трудно скачать???
По умолчанию переменные бегают раз в минуту.
Если будете менять конфигурацию, может сбится переменная nciNetConfig (SNVT_config_src) - Tool-/Self-binding: see “LONMARK Application Layer Interoperability Guidelines”, version 3.2, chapter 3 (determines if self-binding or tool-binding), 0 = CFG_LOCAL (Factory default setting, self-installed) 1 = CFG_EXTERNAL (tool-installed)

тогда, возможно, придётся покупать что-то для конфигурирования сети. Можете скачать трииальную версию Excelon от Honeywell в сети. У неё много ограничений, но для просмотра переменных сгодится. И не меняйте состояний узлов с её помощью.

nviLFDMProdState (UNVT_ProdState) - System status: data structure (4 bytes) for transmitting heat production status to heat consumers
Byte [0]: output reduction by 0.5 % increment (e.g. for TSA function) as requested by consumers, 0 = default setting
Byte [1]: reduction/request for heat consumption:
bit 0: output reduction critical
bit 1: DHW tank load active
bit 2: DHW request to central DHW storage tank
bit 3: unused
bit 4: heat consumption requested due to critical amount of excess heat (overheating)
bit 5: ditto for non-critical amounts of excess heat (boiler water temperature clearly above setpoint value)
bit 6: residual heat in boiler (after request for heat completed)
bit 7: unused
0x00 = default value
Byte [2]: production status: at least one …
bit 0: boiler is logged off (hard lockout or shut-down)
bit 1: boiler received log-off request (soft lockout)
bit 2: boiler fault
bit 3: boiler set to economy mode operation
bit 4-7: unused
Default value: bit 0 = 1 (off), bit 1..3 = 0
Byte [3]: central functions:
bit 0: central control activated
bit 1: central holiday program activated
bit 2: central operating mode “continuous off operation“
bit 3: central operating mode “DHW production only“
bit 4: central operating mode “space heating and DHW
production”
bit 5 – 7: unused
0x00 = default value


nvoLFDMConsDmd (UNVT_Demand) - Supply temperature request by heating circuit controls:
transfer of consumer request to heat production:
Byte[0], Byte[1]: supply setpoint temperature (Temp_p)
Byte[2], Byte[3]: attributes for heat request (State): bit 0: temperature request is maximum value
bit 1 – 7: unused
bit 8: DHW request to storage tank in central device of heating system (independent of temperature request )
bit 9 – 15: unused
Byte[4]..Byte[9]: neuron-ID of sender (6 Bytes)

Вообще есть такой девайс http://www.anybus.com/support/support.asp?...%20Communicator - шлюз лон-модбас, порядка 600уе, и лицензия на Excelon около 500уе. Думаю, это разумно использовать. А Excelon ещё пригодится.

Посмотрите тему "Опрос: Что лучше LonMaker, NL 220, Alex3... ". Там пишут, что можно скачать демки конфигураторов лоновской сети, функционал которых ДОСТАТОЧЕН для конфигурирования сети.

Огромное спасибо!
у той пдф-ке по висмановскому лону, что уже есть у меня, именно эти переменные описаны небыли
попробую найти правильный вариант.
может ссылочкой прямой на англоязычный вариант подскажете? с немецким у меня почти никак...
может и номера переменных стандартны, а не при инсталяции задаются?



проще говоря - как я и предполагал, лучше не имея полного понимания процесса и опыта работы пока в сеть ничего не передавать.
пока пойду "неправильным" путем... в принципе весь требуемый функционал уже (с учетом этого сообщения, еще раз спасибо), достигнут.

сделано так: около одного из терминаторов на сети висит коробочка, в ней развязывающий трансформатор, на всякий случай с резисторами на входе, для исключения влияния на сеть, после трансформатора дискриминатор и rs422 передатчик, далее витая пара метров 10 и 422-й приемник. потом attiny13, преобразует манчестер в SPI с разбивкой на пакеты, далее мега88 - разбирает пакеты и формирует список переменных, доступный через модбус-рту на 485-м канале, воткнутом в эту мегу с другой стороны.
минусы - надо сперва по логам посмотреть номера переменных, потом подправить данные в меге88, но для разового применения - нормально.

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