Предлагаю добавить подпиточные(подпитка/сброс) магистрали в точки учёта Теплоснабжение и ГВС.
Также дополнить схемы вариантами : 2-х Трубная с подпиткой, 2-х Трубная с подпиткой и сбросом.
2 лайка
поддерживаю, это бы упростило систему
Про подпитку понятно, а что такое сброс? Насколько я понимаю, это предохранительный сброс от котла. В каких случаях вам надо его учитывать?
И хотелось бы больше информации о том как это упростит систему? Чем подпиточная магистраль отличается от отдельной точки учёта подпитки?
Подпитка домовой сети осуществляется с ввода ЦСО с помощью насоса. Механизм инертен, потому происходит перенасыщение сети. Далее срабатывает предохранительный клапан, и сбрасывает лишнее давление в обратку ЦСО.
Эта процедура автоматизирована, учитывать эти расходы нужно всегда.
П.С. речь не о котлах, а о закрытых системах с теплообменниками.
Логика “Секций”(которую я пытался обсуждать в других темах) не позволяет адекватно закрыть вопрос учёта этого расхода.
Добавление таких магистралей выглядит более простым и понятным решением без серьёзных изменений.
Прошу уделить внимание этой теме. Очень хочется увидеть в 3.52
Вопрос неоднозначный, реализация крайне сложная, и в 3.52 точно не попадёт. Для меня пока неочевидно в чём преимущество такого подхода перед отдельными точками теплоснабжения на подпитку. Текущий механизм гораздо более гибкий, так как, например, позволит измерять тепло на подпитку отдельным прибором. Подпиточная магистраль внутри точки будет однозначно привязана к тому же прибору.
Если подпитка подключена к тому же вычислителю, я укажу её в магистрали. Если к другому, я создам дополнительную точку учёта.
Текущая ситуация с отчётностью перед РСО выглядит как 1 отчёт = 1 прибор учёта. Нет у них точек и объектов.
В принципе, если воспринимать Объект учёта = один ИТП, а не отдельный дом, тогда всё удобно. Но начинает кусаться стоимость лицензии.
П.С. быть может, тогда, стоит изменить иерархию? Добавить над объектами учёта ещё 1 уровень “адрес/строение”, и считать 1 лицензия = 1 “адрес”(10 точек учёта)?
П.П.С. С вариантом в П.С. вся мозаика складывается на место, и все инструменты работают как планировалось.
1 лайк
@achi Дайте пожалуйста комментарий. Вопрос стоит довольно остро. Раньше удавалось решать эту проблему горой костылей, сейчас уже не выходит.
Текущий механизм не позволяет затолкать подпитку в отчёт по точке учёта.
Нужно ли периодически поднимать тему?
Я могу сразу сказать, что объём работ огромный. За более чем 20 лет развития, в системе “гвоздями прибит” постулат, что в точке учёта может быть только подающая и обратная магистрали. Ещё одна труба только по беглым прикидкам затронет:
- Все модули службы опроса. Кроме того, придётся проверить работу нескольких десятков драйверов, которые могли полагаться на привязку подачи и обратки.
- Механизм привязки датчиков
- Блоки расчёта. Нужно будет убедиться, что подпитка не просуммируется с обратной магистралью.
- Блоки анализа балансов.
- Источники данных для отчётов.
- Модули диагностики. Нужно будет делать рабочие режимы, суточные режимы, подстановку констант, и т.д.
- Таблица с данными в АРМ оператора
- Таблица с данными в веб-интерфейсе
- Таблица с данными в мобильном приложении
- Интерфейсы редактирования привязки каналов и ячеек в вебе и АРМ оператора придётся переделывать очень серьёзно, так как сейчас они “считают”, что кроме подачи и обратки ничего быть не может.
Это только наши беглые прикидки. Сейчас сезон отпусков, и оперативно собрать информацию не выйдет до сентября. Самое “интересное”, что делать, скорее всего, нужно будет всё сразу, без этапов. А это значит, что после того как система придёт в более-менее рабочее состояние, будет длительный этап тестирования и отлавливания всевозможных ошибок. И я практически гарантирую, что некоторые ошибки увидят только наши пользователи.
В любом случае эти работы не на один месяц, и делать их срочно нельзя, так как такое решение предопределит нашу работу на десяток лет вперёд. Так что здесь, к сожалению, не может быть срочного и быстрого решения.
тогда так? самый удобный вариант получится.
в таком виде мы превратим объекты учёта в ИТП1, 2, 3… и отчёты будем делать по удобным объектам
А что вам мешает сделать такие группы в текущей системе ирархии?
примерно в 5 раз вырастет количество объектов. Я не смогу обосновать такие расходы.
ну и позиция разработчика 1 объект = 1 дом нарушится же.
опять же, нельзя создать 2 объекта с одинаковым адресом.
собственно и объект учёта встанет на своё логичное место. Так как по договору объектом учёта является ИТП/ГРЩ/ВУ, а не дом.
1 лайк
Не знаю, подойдет ли мое предложение. Но мне видится решение в расширении функционала “секция”.
Сейчас секция - это про группировку внутри отчетных форм. Преимущество неочевидно, даже для меня, хотя отчетов мы делаем множество. А пользователю вообще не объяснить по что это. Хотя для домов, где реально много секций - разделение на секции нужно.
Предложение:
- Секции позволить назначать отчет. Отчеты будут примитивные и простые.
- Подпитку так и оставить однотрубной системой, в зависимости от ситуации: отопление, ГВС и ХВС.
- Название секции показывать в отдельной колонке в точках учета и объектах. Ну или добавлять префиксом через точку к названию точки, например: “Секция1. ГВС”
- В секции видимо потребуются атрибуты
Можно ли передать ресурсников на уровень секции сразу - вам решать, в части случаев это не потребуется, достаточно будет хранить данные РСО в атрибутах секции.
Но для объектов где много ИТП/секций: 2/3 поставщика по теплу, по ГВС поставщики пересекаются отоплением, но не полностью и при этом это одно ТСЖ, например нужно придумывать возможность управления РСО. Может позволять их иметь в объекте более 1 и привязывать точки/секции
Это набросок.
Предложения которые тут обсуждаются по реализации выглядят страшно
предложение добавить уровень иерархии “адрес” кажется вам неудобным?. Такой путь выглядит самым простым. С ним весь существующий функционал будет работать как планировалось.