fim

опыт показывает если шо хочешь найти в нете по теплу и отоплению, то нужно идти к "законодателям" темы... немцам и вот недолгое хождение вывело на волшебный эликсир формул AT_gedämpft_neu = AT_gedämpft_alt * ((ZK - 1) / ZK)) + (AT_Ist / ZK) (взято с обсуждения "аматоров дешифровщиков" аналогичной темы висмана) в переводе на окснер это выглядит так Tavg(n) = Tavg(n-1) *((ZK - 1) / ZK)) + Toutside(n)/ZK где ZK - затухание амплитуды, формула корректна для интервала замеров (записи в бд) 10 мин формулы затухания и временного лага не привожу их значения, в принципе, можно посмотреть на u-wert для своего "пирога" ограждающих на графиках: 1) (с верху в низ) просто данные outside & average и расчетная средняя скользящая 2) добавляем avg_formule, расчитанное для затухания 60 (или примерно 400мм газоблока Д400) соответствующее сопротивлению R=3,7 И... каким-то чудом идет отличная корреляция с average гтн 3) с avg_formule, расчитанное для затухания 90 (или примерно 460мм газоблока Д400) соответствующее сопротивлению R=4 4) с avg_formule, расчитанное для затухания 14 (или примерно 300мм газоблока Д400) соответствующее сопротивлению R=2,6 зы имхо по умолчанию контроллер считает average примерно для R=3.7, а пересчитывает ли при дальнейшей эксплуатации... посмотрим

неа судя по данным базы average (02-020 Outdoor temperature average value) пересчитывается мин через 1 мин - макс 20 мин на графике в нижнем левом углу нужно поставить 1 - "без сглаживания данных" и можно отследить как часто контроллер пересчитывает average да это понятно может я не правильно сформулировал свою мысль... попробую еще контроллер окснера использует правильную/грамотную величину average (для погодозависимой кривой) название average (среднее) - это "упрощенное" название для пользователя/обывателя дабы не парить ему (обывателю) мозг деталями алгоритмов другие производители контроллеров (например будерус, етс) называют этот параметр (average) - демпфированной температурой, т.е. сглаженной уличной, где сглаживается амплитуда суточных колебаний. НО при этом для стартового расчета демпфированной температурой (а фактически коэффициента сглаживания амплитуды суточных колебаний) в контроллер вводится доп.уставка отражающая инертность конкретного дома, где установлен котел с контроллером. потом (в процессе эксплуатации), при наличии FB сглаживание можно (теоретически) пересчитывать по динамике Totside, Troom, 01-002 Setpoint heating circuit flow temperature, 00-002 Actual heating circuit flow temperature, т.е. по факту и для конкретных/фактических условий эксплуатации (местности, розы ветров, солнечной инсоляции, цвета дома, климата, амплитуды суточных колебаний уличной температуры, инертности ограждающих и ТП, тепловыделений обитателей и техники, етс...) собственно вопрос был о 1) "доп.уставке" для стартового расчета сглаживания, т.е. стартовый алгоритм расчета average (старт/рестарт ГТН/контроллера); 2) алгоритм пересчета average (эксплуатация ГТН/контроллера)

не ошибается тот, кто ничего не делает одна голова хорошо, а две лучше оказалось не просто мастер ГТН отправляет слейву FB запрос, на который FB дает ответ содержащий температуру, относительную влажность и некоторые вероятно статусы другими словами инициатором запроса есть ГТН, а не FB и "эмулятор" FB, т.е. ebusd (в моем случае) должен а) знать команду; б) на момент отправки запроса иметь актуальные данные с датчиков и... неизвестные пока статусы; в) уметь ответить задал автору ebusd(а) вопрос про возможность "ответить" и получил ответ вроде "в принципе возможно, но на данный момент - нет" короче, не получится "эмулятор" из-за б) неизвестные статусы и в) невозможность ответить, следовательно будет FB вот уже как несколько недель "подсел" я на влияние инертности ограждающих конструкций (и дома в целом) и ТП на остывание дома и что самое главное на погодозависимую кривую так вот по идее у окснера погодозависимая считается по average (02-020 Outdoor temperature average value -> 01-002 Setpoint heating circuit flow temperature), т.е. по средней но... т.к. пишется база, то проверил и получилось, что average - это не средняя (среднесуточная скользящая от даты определения до дата опр. - 1 день), а демпфировання температура улицы такие фокусы используют и другие производители контроллеров для корректировки погодозависимой на инертность, НО пока не понятен принцип определения этой самой average, т.к. для этого необходимо знать или damping (ratio) или thermal lag (time lag thermal mass) или определить их из других параметров для конкретного дома и ТП для своего дома я считал time lag для ТП и ограждающих, при использования "комфортного"/круглосуточного режима отопления, можно снизить амплитуду суточных колебаний (затухание) до средней, а не просто до демпфированной температуры при использовании ночного тарифа как приоритетного нужна немного другая логика, другая кривая смещение демпфированной температуры к средней для низкотемпературных генераторов дает прирост кпд так вот хотелось бы знать логику расчета average, в мануалах ничего не нашел (вопрос ко всем) есть какие мысли? неужели average контроллер определяет по 03-021 Heating limit outdoor temperature, 03-051 Room temp day heating operation и 03-053 Room temp night Heating operation?

справедливости ради... "продвинутые" контроллеры считающие подачу или среднее в СО по адаптивной погодозависимой кривой используют не просто уличную температуру, а демпфированную температуру, учитывающую инертность дома основными параметрами позволяющими определить демпфированную температуру являются thermal lag & damping (ratio), т.е. "опаздывание" от простой Тулица и затухание амплитуды суточных колебаний так вот, при определенных стечениях обстоятельств, ну если угадать глубину заложения, то - да, должен признать, что действительно такой датчик (заложенный не на стену а в глубь стены) будет показывать демпфированную температуру... снимаю шляпу, НО глубину нужно угадать или точно посчитать

извините был напуган(с) конечно же Вт = Дж / с = кг·м²/с³ перевожу из Си (кДж) в Вт*ч, т.к. sqpr(Вт*кДж)=ХЗ, а sqpr(Вт*Вт*ч)=Вт*ч^(1/2) имхо не суть важно, например, считал дачича один европейский стандарт, так там абсолютные величины температуры в разных местах были в С и К, я долго не мог понять суть получаемых "космических" цифр, пока не обнаружил сей казус сравниваю для того, чтобы понять "догонять" или "отставать" алгоритму управления автоматики (оптимальная коррекция/адаптация погодозависимой кривой) короче ищу простые формализации основных процессов кста, blacktigra, проверьте плиз мои расчеты энтальпии бэз Нд диаграмм ставлю ща фанкойл мидея 400 (3-х рядный 30Па) от геоконтура (пассивное охлаждение) и хотелось бы адекватной автоматизации и тут энтальпия1.xls

стр.4 и Вт/(кг*С) = кДж/кг*К/3,6 тут да по плотности промах, но для сравнения нет значения так для дельты без разницы, а абсолютное значение - разница (С&K) 273,15 имхо по размерности I≡(k*ρ*c)^(1/2) - эт не инертность, а коэффициент инертности, вот по аналогии коэф.теплопроводности -> теплопотери, посчитал инертность огражающих и ТП ну это,... я прошелся тока по первому методу, а завтра с напором посамтрю

еще ж нужно учитывать и теплопроводность, и плотность тепловая инертность: I≡(k*ρ*c)^(1/2) W*m^(−2)*K^(−1)*s^(-1/2) ≡ tiu я тут как мог посчитал для дома из газоблока и получилось, что тепловая инертность дома (ограждающих конструкций) гораздо ниже тепловой инертности ТП - караул может где и ошибся...

круто! мне понравилась еще реализация гвс (размещение пто) а с контроллером мне проще могу (теоретически, т.к. пока не делал) реализовать такую/нужную логику + при необходимости связь с гтн (по ебус) зы

если Вы не против, то я мог бы взять ноут с демоном, адаптер usb-ebus, и отсканировать команды "разговора" внешнего блока (FB) и контроллера там вопрос характера "разговора", или FB отправляет периодически данные (темперратуру и влажность) контроллеру - тогда все просто и хорошо, или контролер посылает запрос, а FB отвечает, тогда немного сложнее мне с "эмуляцией", а так же будет понятно мастер и слейв адреса FB так же по характеру имхо можно будет сделать косвенные выводы об алгоритме "адаптации" (если таковая имеется) погодозависимой кривой, или он (контроллер) на основании разницы температур комнаты во времени и разницы температур подачи во времени, а так же dTout & dTroom определяет инертность ТП и ограждающих конструкций, что было бы здорово; или учитывает общую инертность; или использует Troom как простую целевую точку для сравнения или/или возможно для сканирования придется немного "простимулировать" FB для отправки данных контроллеру, путем изменения в непосредственной близости Т и RH

про записанную недельную базу

а какой контроллер? есть ли какой протокол обмена данными с внешним миром? с этого места можно поподробнее? правило "большого пальца" (оптимальные соотношения ключевых параметров)? и остальные пароли, явки...

поделитесь пожалуйста опытом (фото) укладки датчика температуры в пол

думаю это, исхожу из стр 6 (количество входов/выходов, ebus) т.к. один производитель ТЕМ, совместимость шины и т.д.

мне конечно лестно такое слышать, тем более от Вас но я не придумал никаких новых инструментов, просто использую готовые "кирпичики" для своей задачи я не говорю, что алгоритм у Окснера не такой... имхо объективно - один из лучих я говорю, что в своих мануалах они дают сильно упрощенную информации и фсё Нибе мне не нравится тем, что нет шины, усложнена возможность собрать систему под себя, т.к. идет все готовым блоком с гвс (я противник блоков) а в целом Нибе - отличная фирма, у меня стоит их камин (нордпейс 25) - я доволен Ochsner пользую только один сезон, полностью оправдал мои ожидания, даже больше: мне фанату камина (живого огня) запрещают его использовать - жарко а Вы схему можете нарисовать? "автоматизируем сброс тепла от солнца на первичный контур ТН в диапазоне температур от +3С" - это с промежуточным теплообменником или на прямую? есть ли контроллеры у которых уже есть такой алгоритм и возможность переключать дополнительный трехходовой на "сброс"? в параллельной ветке бросали ссылку на китайцев с такой реализацией для воздушников у меня такой есть, но Вы же видите, что он немного "укороченный" по отношению к ТЕМ мануалу зы InSAn, почему-то автоматом ссылку подгружает к слову "камин"

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

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

мануал конвертнул в html и перевел при помощи translate.google можно почитать здесь de версия здесь, можно так же перевести онлайн гоголем коряво, но смысл при желании имхо уловить можно

вопрос про алгоритмы дело в том, что окснер имхо не удачно написали мануалы т.к. австрийцы используют швейцарский контроллер ТЕМ SE6001WPC то приходится обращаться к первоисточнику, но судя по всему для окснера делают спецзаказ и некоторые позиции отличаются так вот есть ли в природе нормальный мануал окснера? вот имхо нормальное описание швейцарцев про "03-021 Предел нагревания" компенсатор инерции а вот про кривую нагрева

кстати о комарах... маскитные сетки vs фильтры рекуператора стали появляться комары, которые раздражают стандартная борьба - маскитные сетки вот подумал, что если сравнить обслуживание фильтров рекуператора и маскитных сеток... имхо равнозначно или даже проще с рекуператором "вот вам и вторая выгода!"(с) и не надо забывать про искажение прекрасного вида из окон маскитными сетками

спасибо! абсолютно согласен с тем, что контроллер справится с задачей переключения "охлаждение <-> обогрев" лучше пользователя у меня пока базовый (минимальный/экономный) комплект без импульсных расходомеров со стороны геополя - реле протока со стороны отопления - балансиром отрегулирована дельта 5С для подачи 35 думаю, что вероятность резкого изменения протоков с обеих сторон минимальна, а по каждой отдельной стороне о протоках можно судить по дельте, т.е. резкое аномальное повышение дельты (при прочих равных) - изменился проток но в целом с Вами не поспоришь, т.к. с расходомером и выработка тепла более точно считается и диагностика "прямая" а не косвенная через дельты и насколько я понимаю, с паролями можно смотреть/читать и давления в любом случае, при желании, после введения пароля можно просканировать коды протоков, давлений, внести небольшие изменения в конфигурационные файлы программы и эти значения будут отображаться кстати, у vaillant и давление, и протоки видно пользователю без спец пропусков поролей зы картинка (схема) - это хорошо, но просмотр всех или выборочных в группы значений, записанных в базу имхо масленнее графики буду смотреть примерно так GeoTeplo, geoterm, у меня вопрос я собрался считать автоматически сор и scop и для отопления, и для ГВС (протокол ээ счетчика ГТН расшифрован и есть возможность писать в базу и делать аналитику) с привязкой к циклам ГТН, т.е. для n-го цикла такой-то сор, есть нюанс... существует ли вероятность того, что в одном цикле будет и отопление и ГВС? или при переходе с отопления на ГВС стартует новый цикл? просто если в одном цикле возможно ГВС и отопление нужно еще привязываться к статусу трехходового

такое... в процессе реализации адаптера были использованы сразу три платы и... везде с КТ829А (брались в одном месте в разное время) - не работали сначала на одной поставил "Б" - эта заработала, потом на второй Б, третьей АТ - все работают работа (частичная) веб-лица в реальности на малинке

ссылкой можете поделиться? у меня на рисуноке пока не присутствуют некоторые данные, которые можно прочитать по ebus, сами коды ebus расшифрованы примерно на 90% полезной информации в схему со временем добавяться данные с контроллера коллектора (смотрю пока в сторону того же ТЕМ как и у Окснера), а так же: отвод от геоконтура на преднагрев рекуператора (при минусовой уличной температуре), круг2 для постнагрева рекуператора и возможно "поддержание" отопления в межсезонье от коллекторов определять (читать) или устранять? ошибки или аварии? читать: 1) при чтении (по ebus) статуса гтн видно в т.ч. и аварийные ситуации (расшифровка номера статуса пока только de): 0=Abgeschaltet;1=Heizbetrieb;2=Vorlaufzeit Heizbetrieb;3=Extern gesperrt;4=Kühlbetrieb;5=Vorlaufzeit Kühlbetrieb;6=Vorlaufzeit Abtaubetrieb;7=Abtaubetrieb;8=Störung;9=Abtropfen;10=DT Ueberwachung;11=Abtau Vorheizung;12=Abtauen 1;13=Abtauen 2;14=Abtauen 3;15=Alarm;16=Störung;17=Blockiert;21=TWVmax Abschaltung;22=TWVsoll Abschaltung;23=TQEmax Abschaltung;24=TQAmin Abschaltung;25=TKAmin Abschaltung;26=Bivalenzabschaltung;27=Warmwasser Ladesperre;28=Minimale Auszeit;29=Minimale Einzeit 2) чтение лога (по ebus) ошибок ("Error data") и анализ этих данных в динамике устранять. в 90% случае имхо нужно личное присутствие или я не правильно понял вопрос?

если вы об этой демке, то если вы о другом, то сорри

при таких параметрах вполне возможно но это днем, а ночью? мои скромные ночные сор=5, превратятся в эквивалент дневных сор=10 так шо имхо не совсем "замена грунтовому контуру" я понял вы тролите

не может работать по ночному тарифу на аккумуляцию не представляю как комфортно обогреть, например мои два этажа дмумя воздушниками (неканальными)... повторюсь: общий scop за сезон считали? если не считали, то сколько заплатила за сезон грн или КВт (отопление) ночь/день? как-то громко сказано "газообмен" - имеется ввиду воздухообмен? какой объем воздухообмена? про влажность. т.е. зимой увлажняет? не уверен и что у Daykin нет ежегодного сервисного обслуживания? переведите плиз, ничё не понял раскройте мысль, так сказать