Просмотр полной версии : Задача технического учета тепла. нужна помощь в разработке.
Здравствуйте уважаемые друзья! на одном объекте, из-за криворуких строителей, создавших этот бред 20 лет назад, появилась необходимость соорудить технический учет тепла. потребляемого линией циркуляции ГВС.
сама схема вроде обычная - теплообменник, насосы циркуляции ГВС.... но полотенцесушители сидят на ПОДАЧЕ ГВС. а линия циркуляции всего одна, в которую сходятся все подачи в подвале. а только потом уходит на котельную. по этой причине количество тепла, снимаемое с полотенчиков просто огромное, но поскольку никакого учета нет в помине, а котельная принадлежит ТСЖ, то они просто с потолка берут некоторый процент от количества тепла, потраченного котельной на получение ГВС.
меня же попросили реализовать технический учет, чтобы можно было:
1. определить количество воды в м3, ушедшее на непосредственно ГВС
2. количество тепла, потребленное линией циркуляции.
3. сделать это МАКСИМАЛЬНО ДЕШЕВО, поэтому теплосчетчик не используем, а пробуем сделать на ПР100 RS (при выборе счетчика учтем его вес импульса так, чтобы Прка успела посчитать)
задача вроде и простая, но интересная.
я вижу ее следующим образом:
1. ставим один классический водосчетчик ВСГ (СР_1) с импульсным выходом ДО точки присоединения линии циркуляции ГВС. рядом с ним ставим датчик температуры.
2. ставим датчик температуры на выходе ГВС в систему.
3. ставим еще один счетчик расхода ВСГ(СР_2) на линии циркуляции. и там же термометр.
4. облако овен на этом объекте есть, так что хранить данные будем в нем (не забываем это технический учет)
в итоге мы можем посчитать
1. по счетчику СР_1 - расход воды на ГВС - делаем на инкрементном счетчике. вот и потребление ГВС готово, оно нам нужно только 1 раз в месяц. тут мы просто раз в месяц вычитаем из текущего значения счетчика предыдущее и эту разницу видим в виде готового числа в облаке. число будет изменяться раз в месяц - на остальное плевать. можно конечно и разницу постоянно высчитывать и делать "пилу".
2. по счетчику СР_2 - мы можем получить расход воды в линии циркуляции ГВС (ведь он не зависит от объема потребленной воды) и это значение тоже достаточно стабильно.
3. вот тут начинается довольно серьезный вопрос, с которым я подвис и прошу помощи: чтобы перейти от расходов к теплу, нам необходимо добавлять к расходу перепад температур, но поскольку температура в контуре ГВС ощутимо плавает в зависимости от текущего расхода (я имею в виду время стабилизации регулятора после возмущения, кроме того там атмосферные котлы стоят и регулятор за счет из гистерезиса качает +- 2 градуса, но поскольку привод стоит быстрый (15с) то на конечном потребителе это не сказывается. я не знаю, как часто надо вычислять разницу температур и мгновенный расход. и как в итоге собирать все это дело в часовое потребление тепла, а потом в месячное.
та же проблема и с рециркуляцией, поскольку входная температура плавает.
4. по той-же причине я отмел варианты с теплосчетчиками. там время опроса датчиков очень редкое, потому может уплыть точность.
5. с передачей в клауд проблем нет. раз в час по синхре с текущем временем у нас изменяется число, которое потом можно вынуть через таблицы, поставив время опроса в 30 минут.
ПРОшу помочь как в проверке логичности моих решений, так и в написании кода.
не дешевле будет взять счетчик тепла с Modbus ? хотя не уверен, что есть такие из недорогих. У Пульсар вроде с собственным протоколом, а его к ПР не прикрутишь... Разве что в качестве шлюза использовать микрокомп типа Raspberry и передавать данные в ПР по второму интерфейсу. Опять тут ПР100 не катит, раз облако есть.
Мне кажется на простые счетчики и расходомеры и связывание всего этого на ПР вы убьете больше времени и денег.
Один счетчик тепла, один общий счетчик воды на ГВС (общедомовой), вдруг уже есть. Больше ничего и не требуется собственно.
Счетчик тепла вроде тоже кубатуру считает.
Сергей0308
10.05.2020, 20:53
Даже в теории, так как у Вас счётчик воды с импульсным выходом, а не расходомер, то мгновенный расход воды(м3/ч) Вы можете вычислять только по фронту поступления импульсов! Я делаю так, высчитываю время между импульсами с точностью до цикла программы и пересчитываю в расход(м3/ч)! Температуру думаю достаточно мерить раз в секунду, всё суммировать и поделить на количество измерений, то есть найти среднюю арифметическую температуру между импульсами, с приходом импульса среднюю температуру между импульсами умножить на весовой коэффициент импульса получится количество отданной энергии за время между импульсами, суммируете при каждом импульсе, а на обратке - вычитаете при каждом импульсе, всё!
Величина потребленной тепловой энергии определяется по формуле:
Q = M • ∆ t • Т
где:
Q – количество потребленной тепловой энергии,
M – масса теплоносителя прошедшего через систему отопления,
∆ t – разность температур на подающем и обратном трубопроводах,
Т - время теплопотребления (принимается интервал времени -1час).
Скажем так. Если строго по ГОСТ - то вычисление тепла задача не простейшая. Надо пересчитать кубы в тонны, в зависимости от температуры воды (напомню - плотность воды зависит от температуры) а теплоемкость/энтальпия - массовая, а не объемная величина. Более того, требуются согласованные пары термодатчиков и прецезионнве измерители минимум по 3-х проводной схеме подключения. Поэтому на ПР это можно, но сложно. А точно - невозможно.
Возможно, дешевле будет поставить стандартный тепловычислитель.
1. Решение с готовым теплосчетчиком выходит очень дорогое (он сам не. Менее 15 тыр,
2. датчиков нужно много, поскольку тепловой схемы штатной для этой задачи нет, значит надо циркуляцию и подачу разбить на 2 теплосети. Значит температурных датчиков нужно на 1 больше, а учитывая, что у меня уже есть на котельной регулятор на базе прки, то температуру подачи ГВС я могу считать по интерфейсу, то и на 2. Пр100 стоит совсем гуманно, ведь экран мне не нужен. Хотя пр100 не подойдёт для сетевого опроса температуры, но тогда все равно разница.между пр100 и 200 перекроет стоимость датчика
3. Время опроса датчиков температуры в расходомерах, даже самое маленькое великовата (что-то около минуты)
4. Хотелось бы разобраться с такой задачей, чтобы потом применить в каком-нибудь другом месте.
Сергей0308 замечание про фронты импульсов резонное, но тогда я подвисаю с вопросом как это правильно накапливать, учитывая, что импульс может и не приехать. В теплосчетчиках ведь идёт счёт импульсов за время между измерениями датчиков, и если оно меньше предела счётчика и импульсов не было совсем то подставляется ноль, а если меньше предела, но был хоть один импульс -то нижний предел измерения.
Так же недопонял с разницей температур. В какой момент времени что делить и куда суммировать.
Да нет большой суммы.
Берём стандартный "китайский" подход.
1. Покупаем любой теплосчетчик с импульсным выходом и одним расходомером, скорее всего электромагнитной системы. Может подойдёт ультразвуковой моноблок от тепловодохрана или подобный. Монтируем на первичный контур ТО ГВС.
2. Покупаем турбинный расходомер с импульсным выходом. Монтируем на подпиточный трубопровод.
3. Импольсный выходы заводим на модуль DI и отдаем его в облако. Модуль вполне м.б. в составе теплопункта.
Вот так, дёшево, сердито и метрологически точно.
Сергей0308
10.05.2020, 22:02
1. Решение с готовым теплосчетчиком выходит очень дорогое (он сам не. Менее 15 тыр,
2. датчиков нужно много, поскольку тепловой схемы штатной для этой задачи нет, значит надо циркуляцию и подачу разбить на 2 теплосети. Значит температурных датчиков нужно на 1 больше, а учитывая, что у меня уже есть на котельной регулятор на базе прки, то температуру подачи ГВС я могу считать по интерфейсу.
3. Время опроса датчиков температуры в расходомерах, даже самое маленькое великовата (что-то около минуты)
4. Хотелось бы разобраться с такой задачей, чтобы потом применить в каком-нибудь другом месте.
Сергей0308 замечание про фронты импульсов резонное, но тогда я подвисаю с вопросом как это правильно накапливать, учитывая, что импульс может и не приехать. В теплосчетчиках ведь идёт счёт импульсов за время между измерениями датчиков, и если оно меньше предела счётчика и импульсов не было совсем то подставляется ноль, а если меньше предела, но был хоть один импульс -то нижний предел измерения.
Так же недопонял с разницей температур. В какой момент времени что делить и куда суммировать.
Я же не знаю как часто у вас импульсы будут поступать, если часто, 0,2 Гц и выше, думаю для приблизительных расчётов(ваш случай) достаточно просто взять текущую температуру(разность температур), и объём не пересчитывать в массу!
Есть же такие сумматоры, по фронту импульса:
48930
ASO с проблемами двухпроводной цепи до датчика можно частично решить использованием PT1000 (тем более датчики все равно покупать, можно и согласованную пару купить), а перед установкой в трубопровод опустить их в один стакан с водой и внести корректировку в каждый из них (для компенсации сопротивления проводов, или их померить достаточно точным мультиметром. опять же мы говорим о техническом учете. на метрологию кладем.
1. Покупаем любой теплосчетчик с импульсным выходом и одним расходомером, не понял это как?
3. Импольсный выходы заводим на модуль DI и отдаем его в облако. - тут тоже не совсем понял, что выводить в облако то? импульсы? или счетчик какой?
Сергей. я посчитал примерно время одного импульса со ВСГ Ду20 на номинальном расходе - это грубо 1,5 секунды, а на минимальном это 37 секунд. отсюда вы совершенно правы, что надо при любых раскладах вычислять время между двумя импульсами и приводить их к расходу, но раз у нас так сильно плавает время, то что в этот момент делать с перепадами температур? как их сопоставить с разным временем между импульсами?
или выставить время периодического вычисления расхода, равное времени минимальной чувствительности счетчика (путем вычисления его через минимальный расход), а потом каким-то образом брать средний перепад температур за это время?
что-то я запутался,
а может вообще считать импульсы со счетчика за целый час, а в течение часа высчитывать средний перепад температур, только вот не совсем понимаю, как это правильно реализовать?
Сергей0308
11.05.2020, 17:15
ASO с проблемами двухпроводной цепи до датчика можно частично решить использованием PT1000 (тем более датчики все равно покупать, можно и согласованную пару купить), а перед установкой в трубопровод опустить их в один стакан с водой и внести корректировку в каждый из них (для компенсации сопротивления проводов, или их померить достаточно точным мультиметром. опять же мы говорим о техническом учете. на метрологию кладем.
не понял это как?
- тут тоже не совсем понял, что выводить в облако то? импульсы? или счетчик какой?
Сергей. я посчитал примерно время одного импульса со ВСГ Ду20 на номинальном расходе - это грубо 1,5 секунды, а на минимальном это 37 секунд. отсюда вы совершенно правы, что надо при любых раскладах вычислять время между двумя импульсами и приводить их к расходу, но раз у нас так сильно плавает время, то что в этот момент делать с перепадами температур? как их сопоставить с разным временем между импульсами?
или выставить время периодического вычисления расхода, равное времени минимальной чувствительности счетчика (путем вычисления его через минимальный расход), а потом каким-то образом брать средний перепад температур за это время?
что-то я запутался,
а может вообще считать импульсы со счетчика за целый час, а в течение часа высчитывать средний перепад температур, только вот не совсем понимаю, как это правильно реализовать?
Вычисление расхода(м3/ч) это дополнительная функция реализуемая для счётчика с импульсным выходом, для подсчёта потреблённой(отданной) энергии и объёма потреблённой горячей воды она не используется! Я вроде написал, точнее не придумаешь, как найти среднее арифметическое за период между импульсами, короче, считываете значение температуры каждую секунду(с периодом 1 секунда), суммируете все значения показаний и делите на количество измерений! С приходом импульса от счётчика умножаем на весовой коэффициент импульса и суммируем с преведущими вычислениями! На обратном трубопроводе аналогичный вычислитель, для подсчёта отданной энергии находим разницу между показаниями на прямом и обратном трубопроводе, всё! Это будут примерные вычисления, плотность воды зависит от температуры и давления!
ага. то-есть я правильно понимаю, что инициализируем цикл в 40 секунд (его высчитываем через минимальную чувствительность счетчика?), во время которого:
1. ожидаем импульса от расходомера
2. суммируем разницы температур по тактовому импульсу (показанный выше сумматор)
3. по истечение заданного времени приводим импульсы, посчитанные за это время с расходомера к расходу делением их сумарного веса на заданное время
4. далее умножаем текущий расход на полученную среднюю разницу температур.
5. а после этого, куда мы деваем полученное значение? суммируем с каким-то другим, или еще надо привести какому-то стандартному промежутку времени?
6. надо ли реагировать как-то по другому, если за время ожидания цикла пришел только 1 импульс?
я конечно покажусь слегка наглым, но нельзя ли набросать что-нибудь в ОЛ :o
Сергей0308
11.05.2020, 17:33
По каждому импульсу счётчика мы вычисляем количество энергии отданной(полученной) с момента преведущего импульса, вам же энергию надо получить не за период между импульсами, а за всё время измерений, поэтому и суммируем вычисленные значения по каждому импульсу!
Вообще теплосчетчики с импульсным выходом стоят не так дорого, тем более с ДУ20. Даже с интерфейсом. только это будет все в одном, в том числе и датчики в комплекте.
а теперь посчитайте ВСГ + датчики их стоимость..
https://teplovodokhran.ru/products/schetchik-tepla/schetchik-tepla-v-kvartiru/s-impulsnym-vykhodom.html/#all_har
есть модификация с 4-мя импульсными выходами. Не изучал доки но предположу что разные выходы показывают разное. Тепло, расход например.
На него регистратор импульсов их же производства - они точно есть с Modbus протоколом по запросу. и в ПР вы будете просто получать данные о тепле и расходе. Ну либо сами ПР-кой считайте....
В общем посчитайте разницу по затратам и поймете что пара-тройка тысяч сверху снимут массу геморроя...
а теперь посчитайте ВСГ + датчики их стоимость..
https://teplovodokhran.ru/products/schetchik-tepla/schetchik-tepla-v-kvartiru/s-impulsnym-vykhodom.html/#all_har
ухты! а вот это очень интересно! я прост не понял, о чем речь!
Если у вас уже есть Облако, а оно таки умеет работать с Modbus если правильно понимаю (вопрос скоростей и параметров линии).
нужно. Теплосчетчик с 2-мя выходами (энергия, расход - надо уточнить что у них там за модификации до 4-х имульсных выходов), счетчик воды с импульсным выходом, регистратор импульсов на 4 канала (Регистраторы они точно по запросу делают с Modbus протоколом). - Все, никаких ПР. Опрос Облаком, расчеты в Облаке.
А вот теплосчетчики я у них не видел с Modbus. Они свой протокол используют, а его ПР-кой не прочтешь к сожалению
Соврал, 4-х канальных у них нет простых. 6-ти канальный с экраном, дороговат. 2-х канального может не хватить, ну если пожертвовать вычислением расхода общего например.
По каждому импульсу счётчика мы вычисляем количество энергии отданной(полученной) с момента преведущего импульса, вам же энергию надо получить не за период между импульсами, а за всё время измерений, поэтому и суммируем вычисленные значения по каждому импульсу!
а, если этот импульс не появится достаточно долго? я к тому, что у счетчика есть минимальная чувствительность. которую надо учитывать? или в данном случае не надо? я просто не нужно ли в какой-то момент сбрасывать накопленное значение средней температуры?
Сергей0308
11.05.2020, 18:59
а, если этот импульс не появится достаточно долго? я к тому, что у счетчика есть минимальная чувствительность. которую надо учитывать? или в данном случае не надо? я просто не нужно ли в какой-то момент сбрасывать накопленное значение средней температуры?
У Вас счётчик воды с импульсным выходом, поступил импульс - значит прошёл через него объём воды, равный весу импульса, обозначен на корпусе, обычно 100(1000) литров/импульс, у Вас, я предполагаю, возможно 10 литров/импульс! Среднюю температуру вычисляем за время между импульсами, импульс пришёл, посчитали энергию между преведущим импульсом, всё! Эта средняя температура больше не нужна, далее продолжаем вычисления, начинаем высчитывать теперь среднюю температуру между поступившим импульсом и следующим(будующим) импульсом!
Спросим так - какова цель этих танцев с бубнами? Отделить отдельно отопление по полотенцесушитель и не теплоизолированным трубам от подогрева ГВС? Так и без этого понятно, что при таком бардаке летом выгодней отключить котельную и греть электробойлером и электросушкой на квартиру.
И у Вас есть общедомовой теплосчетчик или дом с блочной котельной и оплата по газовому счётчику?
Цель именно такая. Просто они не знают, сколько точно тепла потребляет линия рециркуляции. Они от нее отказываться не хотят, просто им надо разделить теплопотребление летом на нагрев ГВС и эту линию рециркуляции.
Но если она реально много жрет, то будут рассматривать вопрос о реконструкции схемы подключения полотенчиков
Разделили - дальше что?
Если Вы платите по входному теплосчетчику - то какая разница, из какого кармана какую часть платить? Или Вы хотите на лето отключить полотенцесушители?
Ну и цену подогрева куба ГВС устанавливает местная антимонополька, так что...
Ну и разделить... В моем доме это практически не возможно - нужна переделка внутри квартир с прокладкой доп. стояка, а этого ни один собственник не даст, и будет прав.
Насколько помню, полотенчики всегда сидят на ГВС в МКД, хочет этого кто-то или нет ?
В одном МКД (старая хрущевке) они сидят на отоплении, и летом не работают.
Сергей0308
11.05.2020, 22:47
Если у него это отдельная система для полотенцесушителей я так понимаю там разбора горячей воды не происходит, поэтому в такой системе достаточно одного счётчика(расходомера) для подсчёта затраченной энергии и двух датчиков температуры на прямом и обратном трубопроводе, всё! Подключаете эти датчики к ПР200 и всё, остальное и внучок первоклассник легко сделает!
У заказчика собственная крышная котельная. цель учета - это требование жильцов правильно указывать в квитанциях тепло на полотенчики и на непосредственно ГВС.
Да, в большинстве случаев полотенчики сидят на ГВС, но на линии циркуляции, а в этом доме они сидят на ПОДАЧЕ ГВС! смотрите эскиз во вложении.
со стороны управляшки им надо понять, стоит ли выделять полотенчики из ГВС фактически, или продолжать брать некий процент тепла, поэтому решение должно быть отвратительно дешевым.
с моей стороны я просто хотел бы разобраться, как это сделать на Прке, чтобы, если в каком-то другом месте возникнет аналогичная задача, то я смог бы ее реализовать уже по готовому алгоритму, поскольку в данный момент нет спешки, а есть Прка в запасе )
П.С. мне ответили из тепловодомера - типа тюти! протокол у нас по rs-485 проприетарный. сидите и курите со своими скадами бамбук.
Сергей0308
12.05.2020, 11:39
У заказчика собственная крышная котельная. цель учета - это требование жильцов правильно указывать в квитанциях тепло на полотенчики и на непосредственно ГВС.
Да, в большинстве случаев полотенчики сидят на ГВС, но на линии циркуляции, а в этом доме они сидят на ПОДАЧЕ ГВС! смотрите эскиз во вложении.
со стороны управляшки им надо понять, стоит ли выделять полотенчики из ГВС фактически, или продолжать брать некий процент тепла, поэтому решение должно быть отвратительно дешевым.
с моей стороны я просто хотел бы разобраться, как это сделать на Прке, чтобы, если в каком-то другом месте возникнет аналогичная задача, то я смог бы ее реализовать уже по готовому алгоритму, поскольку в данный момент нет спешки, а есть Прка в запасе )
П.С. мне ответили из тепловодомера - типа тюти! протокол у нас по rs-485 проприетарный. сидите и курите со своими скадами бамбук.
При такой схеме для подсчёта энергии затраченной на полотенцесушителях, Вам нужно счётчик(расходомер) и два датчика температуры(на входе и на выходе полотенцесушителя) для каждого полотенцесушителя, короче разоритесь такую систему делать, как я понимаю это на каждую квартиру придётся отдельный теплосчётчик ставить для полотенцесушителя!
Сколько у вас квартир?
нет ну не столько все плохо. все жильцы не против, если затраченная суммарная мощность на полотенчики будет поровну делиться между всеми (даже с учетом того, что не у всех они греют одинаково, исходя из схемы), но они против, чтобы часть тепла на эти нужды входила в стоимость куба воды ГВС. управляшка в свою очередь хочет знать долю этого тепла, и суммарный расход воды на ГВС (на данный момент общедомовых приборов учета объемов ГВС и ХВС нет.)
П.С. еще пообщался с пульсаром. их бюджетные решения, которые предлагал ASO есть только для Ду15, Ду20. у них на выходе или протокол M-bus или проприетарщина на RS-485. вроде все бюджетно, но городить шлюз между протоколами - это полный гемор, который еще больше, чем слепить на Прке "типо теплосчетчик"
Сергей0308
12.05.2020, 13:01
нет ну не столько все плохо. все жильцы не против, если затраченная суммарная мощность на полотенчики будет поровну делиться между всеми (даже с учетом того, что не у всех они греют одинаково, исходя из схемы), но они против, чтобы часть тепла на эти нужды входила в стоимость куба воды ГВС. управляшка в свою очередь хочет знать долю этого тепла, и суммарный расход воды на ГВС (на данный момент общедомовых приборов учета объемов ГВС и ХВС нет.)
П.С. еще пообщался с пульсаром. их бюджетные решения, которые предлагал ASO есть только для Ду15, Ду20. у них на выходе или протокол M-bus или проприетарщина на RS-485. вроде все бюджетно, но городить шлюз между протоколами - это полный гемор, который еще больше, чем слепить на Прке "типо теплосчетчик"
Разделите Вы эту энергию поровну между всеми жильцами или каждый будет по своему теплосчётчику полотенцесушителя платить, это уже другой вопрос, я написал как можно посчитать эту энергию затраченную на полотенцесушители, у Вас при такой схеме только суммирую показания всех теплосчётчиков, на каждый полотенцесушитель отдельный теплосчётчик, всё! Ну предложите свой вариант, только первоклассникам не показывайте, боюсь надорвут животики со смеху!
нет ну не столько все плохо. все жильцы не против, если затраченная суммарная мощность на полотенчики будет поровну делиться между всеми (даже с учетом того, что не у всех они греют одинаково, исходя из схемы), но они против, чтобы часть тепла на эти нужды входила в стоимость куба воды ГВС. управляшка в свою очередь хочет знать долю этого тепла, и суммарный расход воды на ГВС (на данный момент общедомовых приборов учета объемов ГВС и ХВС нет.)
П.С. еще пообщался с пульсаром. их бюджетные решения, которые предлагал ASO есть только для Ду15, Ду20. у них на выходе или протокол M-bus или проприетарщина на RS-485. вроде все бюджетно, но городить шлюз между протоколами - это полный гемор, который еще больше, чем слепить на Прке "типо теплосчетчик"
Сергей0308
12.05.2020, 13:18
нет ну не столько все плохо. все жильцы не против, если затраченная суммарная мощность на полотенчики будет поровну делиться между всеми (даже с учетом того, что не у всех они греют одинаково, исходя из схемы), но они против, чтобы часть тепла на эти нужды входила в стоимость куба воды ГВС. управляшка в свою очередь хочет знать долю этого тепла, и суммарный расход воды на ГВС (на данный момент общедомовых приборов учета объемов ГВС и ХВС нет.)
П.С. еще пообщался с пульсаром. их бюджетные решения, которые предлагал ASO есть только для Ду15, Ду20. у них на выходе или протокол M-bus или проприетарщина на RS-485. вроде все бюджетно, но городить шлюз между протоколами - это полный гемор, который еще больше, чем слепить на Прке "типо теплосчетчик"
Вы как с Луны упали, вообще-то для большинства тепло(электро)счётчиков существуют ОРС-серверы для скад-систем, минус в том что они обычно платные!
П.С. еще пообщался с пульсаром. их бюджетные решения, которые предлагал ASO есть только для Ду15, Ду20. у них на выходе или протокол M-bus или проприетарщина на RS-485. вроде все бюджетно, но городить шлюз между протоколами - это полный гемор, который еще больше, чем слепить на Прке "типо теплосчетчик"1. Пообщайтесь еще раз - я говорил про ультразвуковые ТС, они чуть дороже, но есть на больший Ду. https://teplovodokhran.ru/products/schetchik-tepla/obshchedomovoy-schetchik-tepla/s-tsifrovym-vykhodom-odt.html/
2. Зачем шлюз - я писал про импульсный выход.
3. Какая разница - где подключены сушилки, если на конечном кране в стояке кране температура не падает ниже нормы? Ну переключили на обратку - дальше что, что изменилось? Как известно, от перемены мест слагаемых...
4. В принципе, если регулятор держит Т подачи достаточно стабильно - достаточно только водомера в линии подпитки. Примите Т ХВС летом в 12°С и считайте с погрешностью не более 10%, для Ваших целей вполне достаточно.
1. Пообщайтесь еще раз - я говорил про ультразвуковые ТС, они чуть дороже, но есть на больший Ду. https://teplovodokhran.ru/products/schetchik-tepla/obshchedomovoy-schetchik-tepla/s-tsifrovym-vykhodom-odt.html/
их ответ:
Теплосчётчик ультразвуковой "Пульсар" Ду15; qp=0,6м3/час; с импульсным выходом; прямой; Тmax=105°С Н00003372 - 9 345,49 руб.
Теплосчётчик ультразвуковой "Пульсар" Ду32; qp=6,0м3/час; с импульсным выходом; прямой; Тmax=105°С Н00003378 - 24 694,55 руб.
2. Зачем шлюз - я писал про импульсный выход.
а количество теплоты как по импульсному выходу передавать?
3. Какая разница - где подключены сушилки, если на конечном кране в стояке кране температура не падает ниже нормы? Ну переключили на обратку - дальше что, что изменилось? Как известно, от перемены мест слагаемых...
очень даже падает. на 5 этаже ГВС - 70 градусов из крана, а на 1 - 55. просто все к этому привыкли.
а это говорит об очень больших потерях тепла с полотенчиков. если бы они стояли на обратке, как это везде делают, то тогда расход через них задается насосами рециркуляции, а в случае такого монтажа, как у меня - расходом на излив из крана, а это уже совсем другой объем тепла..... ээээ ... пока я это писал я залип... это чо-ж выходит, мы не можем посчитать количество тепла через эти полотенчики полностью, а только когда нет расхода ГВС.... а на расходе ГВС что тогда делать?! вот засада...
4. В принципе, если регулятор держит Т подачи достаточно стабильно - достаточно только водомера в линии подпитки. Примите Т ХВС летом в 12°С и считайте с погрешностью не более 10%, для Ваших целей вполне достаточно.
по учету объема ХВС на ГВС, вы тут совершенно правы. это вполне допустимо.
остается вопрос рециркуляции.
а количество теплоты как по импульсному выходу передавать?Как обычно - 1 импульс = Х кДж.
это чо-ж выходит, мы не можем посчитать количество тепла через эти полотенчики полностью, а только когда нет расхода ГВС.... а на расходе ГВС что тогда делать?! вот засада...Можете. Но нужно 2 теплосчетчика или 1 теплосчетчик и один водомер.
тогда я не совсем понимаю формулу расчета. как учесть теплоотдачу с полотенчика, когда через него идет не расход циркуляции, а расход излива гвс. тут я что-то недопонимаю.
Вычитаете из общей потребляемой мощности по первичному или вторичному контуру на ТО и мощности на подогрев.
bayk по поводу протокола это относительно именно теплосчетчика ответили ? если так, то скорее всего да, он у них протокол Пульсар. Только ничего проприетарного там нет, документация на протокол у них на сайте. Просто ПР не умеет ничего кроме Modbus. А так, если именно в Scada, я же его читаю...
Сергей0308 да не нужен там на каждый полотенце сушитель блин.... Еще раз. Меряем общий расход прокачанной воды, общие затраты на нагрев. не важно куда вода слилась, в раковину или прошла сквозником по рециркуляции. Потом от общего отнимаем показания счетчиков воды ГВС поквартирные.
Учет то технический.
bayk любой из двух, M-Bus или Пульсар читается при помощи Raspberry Pi (в качестве шлюза), проще Пульсар (RS485), так как M-Bus потребует еще конвертер физических сред. Правда вот чтобы завести вам в облако, придется где-то OPC развернуть, пока разработчик RapidScada не выпустит драйвер Modbus Slave. А когда выпустит, можно будет напрямую в облако пихать. (сам жду с нетерпением Modbus Slave на эту Scada)
Пообщайтесь с эээ... руководством, если их устроит чтение Теплосчетчика с протоколом Пульсар и временно (до появления режима Modbus Slave в RapidScada смотреть графики и сливать данные вы будете не из облака) а потом заведете в облако... Только нужна Rasberry c 2Гб памяти... с 1Гб тоже работает, но я по своей сужу... Хотите прикручу квартирный Теплосчетчик Ду15 к системе и дам посмотреть ? правда без подключения к нему воды, а то он мне как собаке пятая нога :)
з.ы. ночью обычно горячей водой никто не пользуется. спят потому как. чистая рециркуляция полотенчиков если что. банальный коэффициент, который определяется за пару тройку ночей для расчетов...
bayk по поводу протокола это относительно именно теплосчетчика ответили ? если так, то скорее всего да, он у них протокол Пульсар. Только ничего проприетарного там нет, документация на протокол у них на сайте. Просто ПР не умеет ничего кроме Modbus. А так, если именно в Scada, я же его читаю...
да, именно по поводу теплосчетчика. у них только регистраторы импульсов с модбасом есть. нет, полноценной скады на этом объекте нет. только Клауд.
Сергей0308 да не нужен там на каждый полотенце сушитель блин.... Еще раз. Меряем общий расход прокачанной воды, общие затраты на нагрев. не важно куда вода слилась, в раковину или прошла сквозником по рециркуляции. Потом от общего отнимаем показания счетчиков воды ГВС поквартирные.
тут есть один нюанс. так не прокатит, поскольку воду могут открыть как на 5 этаже, и тогда пролив пойдет через один полотенчик, а может и на 1, тогда тепло потребят уже все 5 полотенчиков.
bayk любой из двух, M-Bus или Пульсар читается при помощи Raspberry Pi (в качестве шлюза), проще Пульсар (RS485), так как M-Bus потребует еще конвертер физических сред. Правда вот чтобы завести вам в облако, придется где-то OPC развернуть, пока разработчик RapidScada не выпустит драйвер Modbus Slave. А когда выпустит, можно будет напрямую в облако пихать. (сам жду с нетерпением Modbus Slave на эту Scada)
Не хочу заморачиваться с расбери или с ардуинкой, которая, конечно бы все это потянула, поскольку 1) хочу получить промышленное решение на базе продаваемого оборудования (чтобы в дальнейшем применять), ведь уникальность это всегда плохо. 2) проработать максимально дешевое решение, ведь просто купить теплосчетчик и воткнуть можно всегда. 3) за эту штуку денег не заплатят, я это делаю в рамках обслуживания. с них материалы, с меня реализация.
з.ы. ночью обычно горячей водой никто не пользуется. спят потому как. чистая рециркуляция полотенчиков если что. банальный коэффициент, который определяется за пару тройку ночей для расчетов...
я правильно понимаю, что мы получаем среднее теплопотребление исключительно полотенчиков, делим его на их количество, получаем условное потребление полотенчика при прокачке 1 куба воды, а далее умножаем пролитую исключительно на ГВС воду на условное теплопотребление полотенчика, а учитывая, что я сказал. что может идти пролив от 1 до 5 полотенчиков. берем среднее, допустим 3 теплообменника. тут вроде понятно, только вот что делать с учетом того. что через полотенчик идет одновременно 2 расхода - это пролив ГВС и ее циркуляция. это что, это тепло надо вычитать из накопленного рециркуляцией??? :confused: все.. я совсем завис....
Вообще-то, когда пользуются горячей водой, то пользуются горячей водой а не полотенчиками. Ведь ГВС вы тоже обязаны предоставлять или нет ?
суть такая. есть счетчик(и) расхода горячей воды, это ВОДА ГОРЯЧАЯ, понимаете ? за сутки ГВС потребили столько то кубов (слили в раковину), потрачено время Х на слив воды. 24часа - X = Y времени работало чисто на полотенчики.
Ну либо знаем кубы слитой воды отнимаем от общих кубов, прокачанных через систему, то же получаем кубы, потраченные на полотенчики. Вот полученное и раскидываем на все квартиры. а за горячую воду они платят по счетчикам, сумма которых должна соответствовать общему счетчику минус прокачка через систему при отсутствии разбора воды.
А то так, считая сколько потратили на нагрев ГВС (для расхода горячей воды) и тут же лепите этот же расход на полотенчики, вы людей дважды имеете, вот им и не нравится, что естесственно.
з.ы. промПК в качестве шлюза это промышленное решение, но правда будет стоить дороже. Хотя на борту будет все тот же Linux на котором развернут шлюз. только за другие деньги, нежели Raspberry. Если что, после появления слейва для Modbus неплохо прокатит даже 1-й вариант Raspberry. Что у вас в качестве связи с Облаком используется ? ПМ210 ?
Вообще-то, когда пользуются горячей водой, то пользуются горячей водой а не полотенчиками. Ведь ГВС вы тоже обязаны предоставлять или нет ?
суть такая. есть счетчик(и) расхода горячей воды, это ВОДА ГОРЯЧАЯ, понимаете ? за сутки ГВС потребили столько то кубов (слили в раковину), потрачено время Х на слив воды. 24часа - X = Y времени работало чисто на полотенчики.
Ну либо знаем кубы слитой воды отнимаем от общих кубов, прокачанных через систему, то же получаем кубы, потраченные на полотенчики. Вот полученное и раскидываем на все квартиры. а за горячую воду они платят по счетчикам, сумма которых должна соответствовать общему счетчику минус прокачка через систему при отсутствии разбора воды.
так я, чтобы одно из другого не вычитать, счетчик ГВС хочу поставить на ХВС перед точкой возврата циркуляции, тогда с него будем получать точное количество потраченной воды, за исключением тех редких случаев, когда по какой-то причине буду сливать стояк гвс, но это бывает так редко, и объем так мал, что этим можно пренебречь.
А то так, считая сколько потратили на нагрев ГВС (для расхода горячей воды) и тут же лепите этот же расход на полотенчики, вы людей дважды имеете, вот им и не нравится, что естественно. в целом логично. пока жильцы и управляшка в этом вообще разобраться до конца не могут, потому просто ждут каких-то объективных цифр. я пораскинул мозгами еще и понял, что тепло при проливе полотенчиков по сути уже учтено в той воде, которой попользовались, а выражается оно в том, что на первом этаже вода холоднее на полтора десятка градусов! потому, по сути за это тепло платит обделенный температурой пользователь.
з.ы. промПК в качестве шлюза это промышленное решение, но правда будет стоить дороже. Хотя на борту будет все тот же Linux на котором развернут шлюз. только за другие деньги, нежели Raspberry. Если что, после появления слейва для Modbus неплохо прокатит даже 1-й вариант Raspberry. Что у вас в качестве связи с Облаком используется ? ПМ210 ?
нет ПЕ210, но айпишкник со стороны провайдера чорный-при-чорный
в каком-то другом случае, может это и оправданно (применение самодельного шлюза), но тут даже квартирный_теплосчетчик_с_левым_протоколом+расбери +время_на_разработку > разницы в стоимости колхоза на ПРке и полноценным теплосчетчиком. потому и в данном случае бессмысленно.
при другом раскладе надо уже думать, размышлять, а иногда не глядя применять (я вот применил ардуинку для преобразования температуры с нестандартного NTC резисотра в RS485, поскольку такое решение на рынке промки полностью отсутствует, стоимость Прки для этих целей перебор (ценность именно этих показаний очень сомнительна) и скорость реализации сыграли свою роль.
Вообще-то, когда пользуются горячей водой, то пользуются горячей водой а не полотенчиками. Ведь ГВС вы тоже обязаны предоставлять или нет ?Это считается так.
1. Измеряется объем кубов ГВС водомером на линии подпитки. Потом пересчитывается в стоимость подогрева, устанавливается антимонополькой. Выставляется счет за физическую воду по цене холодной (водоканал), который прибавляется к ХВС. Разбивку по квартирным водомерам + общедомовые нужды сейчас не рассматриваем.
2. Берется потребленное тепло по домовому теплосчетчику (у меня теплосеть). Из нее вычитается затраты на подогрев ГВС, остаток делится пропорционально площади собственников.
3. Это все прописано в соответствующем ППРФ, и нечего изобретать велосипед.
в данном случае это тсж, я условно сказал, что "управляшка" потому они устанавливают общим собранием все что угодно, хоть вообще весь газ с котельной делить по ровну и класть хрен. это их право.
Сергей0308 я вот все равно думаю, что условно бесконечное накопление дифференциала температур это неправильно. все-таки мне кажется, что его усредненное значение надо сбрасывать каждый промежуток времени равный минимальной чувствительности счетчика. допустим какое-то время нет расхода (не привязываясь к нашей задаче, где такое условно быть не может), а количество усреднений уже достигло 1000-2000, и вот тут наконец приходит новый импульс и вся эта накопленная дичь вываливается нам в расчет.
Не совсем так, вернее, совсем не так.
В РФ преимущество публичного права (НПА) над договорами.
Сергей0308
12.05.2020, 21:08
в данном случае это тсж, я условно сказал, что "управляшка" потому они устанавливают общим собранием все что угодно, хоть вообще весь газ с котельной делить по ровну и класть хрен. это их право.
Сергей0308 я вот все равно думаю, что условно бесконечное накопление дифференциала температур это неправильно. все-таки мне кажется, что его усредненное значение надо сбрасывать каждый промежуток времени равный минимальной чувствительности счетчика. допустим какое-то время нет расхода (не привязываясь к нашей задаче, где такое условно быть не может), а количество усреднений уже достигло 1000-2000, и вот тут наконец приходит новый импульс и вся эта накопленная дичь вываливается нам в расчет.
Поэтому правильно иметь, для таких случаев, не счётчик с импульсным выходом, а расходомер и лучше электромагнитный или ультразвуковой, механический счётчик менее надёжен, у нас бывает такие встают, а электромагнитный работает уже как минимум лет 5, ни разу не сбоил, там считываются значения, например раз в секунду и вычисляется энергия, ни каких проблем, если расход ноль, то умножив на ноль получим ноль энергии за последнюю секунду! А среднюю температуру за период между импульсами можно высчитывать для повышения точности измерений при использовании счётчика с импульсным выходом, если Вам точность ни к чему или температура медленно меняется, то это и не нужно!
а у этого ПЕ210 только 485-й интерфейс для приборов ? тогда наверное да, колхоз с ПР может и оправдан. Но расходомеры и счетчики воды однако тоже денег стоят.
А так, имея прибор с экраном (теплосчетчик), всегда можно подвести любого и показать, сколько энергии прошло через счетчик. Хочь каждый месяц води...
А что вы покажете по счетчикам воды кроме кубов ? да ничего собственно кроме кубов. Тут с одной стороны дешево, но задницу не прикроете никак.
Я думаю, как только это дело начнет работать, то после пары-тройки месяцев статистики вся эта система будет не нужна. Будут сделаны все нужные выводы и принято решение да и задницу перекрывать ни чью не надо. Особо додельных в этом доме нет. Это скорее информация для себя и правления.
Да, к сожалению у всех выпускаемых на данный момент шлюзов только 485 интерфейс, что печалит. Надеюсь в ближайшее время появится шлюз с 485+ ethernet.
Друзья! после некоторого перерыва возвращаюсь к данной теме. поскольку времени у меня катастрофически не хватает, прошу не безвозмездной помощи в разработке данного алгоритма.
несмотря на ненадежность механических счетчиков, они все равно остаются самым дешевым и простым в обслуживании устройством, которое необременительно установить в рамках эксплуатации объекта.
всего нужно 2 отдельных блока (в виде макросов):
1-й макрос: простой накопительный счетчик потребленных кубометров, для которого задается начальное (или текущее, на случай перебоев в электроснабжении) значение механического счетчика, вес импульса.
нужно накапливать 2 значения:
1-е: просто непрерывный инкремент, который дублирует текущее показание механического счетчика. в случае корректировки показания с экрана - присваивать текущее значение для совпадения показаний.
2-е: за календарный месяц с последующим складированием этого в "архив" который будет представлен некоторой глубиной из нескольких (идеально 12) переменных со сдвигом и подтиранием самого "древнего". если в какой-то момент корректируется показание механического счетчика, то разницу между последним известным и новым нужно прибавлять к результату счета текущего месяца.
для месячных накоплений иметь вход полного сброса.
2 макрос: технический учет тепла, который, как обсуждалось в этой теме по простейшей формуле (расход*перепад температур) высчитывает количество тепла и результат представляет в Гкал. входные данные - вес импульса счетчика, минимальный расход счетчика по паспорту.
от макроса дополнительно нужно:
1. между счетными импульсами идет непрерывное накопительное усреднение перепада температур подачи и обратки, при этом выборка значений с входов должна стробироваться , я думаю 1 раз в 100 м/с
2. исходя из веса импульса и минимального расхода должно автоматически рассчитываться максимальное время между импульсами (я думаю достаточно точности кратной 1 секунде.
3. в случае, если между импульсами происходит превышение времени, соответствующего минимальному паспортному расходу, то усреднение температур прекращается и обнуляется до появления следующего счетного импульса (чтобы при временном отсутствии расхода не происходило очень длительного накопления усредненного значения)
4. количество потраченной энергии так же должно ежемесячно складываться в несколько переменных как и в предыдущем макросе.
5. иметь кнопку сброса всего накопленного счета.
обсуждение бюджета, если есть желающие помочь - в личку!
Powered by vBulletin® Version 4.2.3 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot