Opentherm probléma

Elektronika, Elektromos eszközök

Sziasztok

Korábban már láttam hogy vannak itt többen akiknek van itt tapasztalata Opentherm-es  kazánvezérlés témában. A kiépítés a következő: adott egy Hajdu HGK 24-es kazán, és egy Wiser WT734R 2 zónás termosztát. A termosztát Opentherm-en kapcsolódik a kazánhoz, a kazánból kijövő meleg vizet pedig 1 - 1 vezérelhető szelepen keresztül a földszint (2-es zóna) és/vagy az emelet (1-es zóna) fűtőköre felé engedi. A szelepeket a termosztát vezérli egy-egy relés kimeneten keresztül.

A problémám a következő: amikor az egyes zónában fűtésigény jelentkezik, nyit a 1-es zóna szelep és a termosztát kapcsolja is a kazánt OT-n keresztül. Viszont ha csak a kettes zónában van fűtésigény, akkor ugyan kapcsolja a termosztát a 2-es zóna szelepét, viszont a kazán nem indul el. Mi lehet a probléma? Van valakinek tapasztalata hasonló kiépítéssel? Ugye jól gondolom hogy a termosztátnak mindenképpen indítania kellene a kazánt OT-n keresztül akár az 1. akár a 2. zónában jelentkezik fűtésigény, egymástól függetlenül? Rendeltem egy Schelte Bron féle OT gateway-t, azon keresztül meg akarom nézni hogy mit vagy mit nem kommunikál a termosztát és a kazán hogy legalább lássam hogy nem is megy ki parancs a 2-es zóna kapcsolásakor vagy esetleg csak a kazán "nem érti meg". Felvettem a termosztát gyártójával is a kapcsolatot de első körben csak a legalacsonyabb szintű support-tól kaptam még választ ami nem sokat ért.

Vázlat:

 Vázlat

  • 1150 megtekintés

( Vamp | 2021. 02. 03., sze – 15:03 )

Szerkesztve: 2021. 02. 03., sze – 15:26

Ezt nezted?

 

https://www.directheatingsupplies.co.uk/pdfs/Drayton%20Wiser%20Instruct…

 

Sztm a kazan fele mar csak a hoigeny megy, szamara irrelevans hogy a Wiser melyik relet nyitja. Szoval sztm wiser oldalon lesz a baj, vagy config vagy bekotes problema.

 

Magat a hoigenyt szeleptermosztatok vagy egy-egy wiser fali termosztat a ket szinten figyeli?

 

Ezt nezted?

 

https://i.ibb.co/7X4x8b4/image.png

Igen, már sokszor átnéztem, de nem lettem okosabb. A kábelezést is átnéztük már ketten is, nem látok benne hibát. Egyébként faék egyszerűségű az egész.
Közben jött egy ilyen válasz a support-tól: "The Wiser system currently supports OpenTherm only in conjunction with a combi boiler and a 1 channel Wiser HubR."

Mi értelme így árulni ha csak 1 csatornán megy az opentherm?

Nyilván átköthető az egész ki/be kapcsolós változatra, de pont ezt akarnám elkerülni.

Magat a hoigenyt szeleptermosztatok vagy egy-egy wiser fali termosztat a ket szinten figyeli?

Egy-egy rádiós termosztát figyel a szinteken.

Ha igaz amit a support ir, akkor ezt csak szoftveresen tudod megoldani. Mindket radios termosztatot ugyanahoz a csatornahoz kell rendelned, de kulonbozo szobakhoz. (ha lehet ilyet... Nem tudom, ki kell probalni). A radios termosztatoknak van heating request -je, ami szoftveresen latszik. Szerencsere a Wiser localisan is vezerelheto, eleg egyszeruen. Ehhez csak meg kell szerezni a kontroller api titkos kulcsat. Igy: https://it.knightnet.org.uk/kb/nr-qa/drayton-wiser-heating-control/#system-secret

 

Innentol tetszoleges rendszerbe integralhato. Van kesz integracio is, pl Home Assistant-hoz: https://github.com/asantaga/wiserHomeAssistantPlatform A ket szelepet vezerelheted valami okosrelevel, pl  2 Shelly 1, vagy 1 SONOFF 4CH PRO R3.

 

Egyre kell vigyazni. Mivel ebben az esetben az okosrelek nyitnak/zarnak, ha barmi gebasz van a vezerlessel, akkor nem fog kinyitni egyik sem, de a futes elindul... Ezt a kazan szivattyuja nem fogja kultivalni... A megoldas ha meg a ket szelepvezerlo kozott, a "kozos szakaszon" beepitetek egy Tularam szelepet, ahol at tud fordulni a viz. https://www.viz-gaz-futes.hu/tularam-szelep-a-kazan-vedelmeben/

 

Illetve a HA integracio github oldalan rakerdeztem azert a problemadra, hatha valaki hasonlo cipoben jart es sikerult megoldania: https://github.com/asantaga/wiserHomeAssistantPlatform/issues/141

 

Viszont igy nincs sok ertelme a 3 csatornanak... kb eleg lenne a sima is....

ha barmi gebasz van a vezerlessel, akkor nem fog kinyitni egyik sem, de a futes elindul... Ezt a kazan szivattyuja nem fogja kultivalni... A megoldas ha meg a ket szelepvezerlo kozott, a "kozos szakaszon" beepitetek egy Tularam szelepet, ahol at tud fordulni a viz.

Vagy fix nyomás módba állítani a szivattyút és így szépen visszaveszi a teljesítményt, ha mindkét szelep zárva van.
A radiátorkört mi így állítottuk be. Elég XIX. századi megoldás már a bypass.

Köszi hogy foglalkoztál a problémámmal. Most sem időm sem kedvem nem lesz hogy ilyen szintű hackelésbe belefogjak. Out of the box szerettem volna használni ezt az összeállítást. Még megnézem majd a gateway-el hogy mi látszik OT-n. De valószínűleg akkor egyelőre átkötöm ON/OFF-ra, az OT-t pedig szétkapcsolom. Ha bármelyik zóna reléje kapcsol akkor 1-1 +relén keresztül kapcsolom a kazánt és a megfelelő szelepet.

( Vamp | 2021. 02. 03., sze – 16:23 )

A zonaszelepek pontosan milyenek. Drayton-ok azok is? Z5 vagy Z6?

Szep talalat! Hiaba, nagyon sok mindenre jo az OTGW (nekem is van) Ez amugy viszonylag jo hir, mert konnyen orvosolhato is lehet akar... Ez egesz egyszeruen azt jelenti, hogy a termosztat egy masodik futesi kornek kezeli ezt az erteket, amit a kazanod vagy, 1. Nem tamogat, 2. nincs rajta engedelyezve. A masodik pont egyszeru, az elso mar cinkesebb.... A problema:

ugye a kepen latszik, hogy a setpointot a "Control Setpont" al allitod, (MsgID=1) Viszont, neked a masodik kor a "Control setpoint 2" (MsgID=8) ra megy, amit nem tud ertelmezni a kazan. Azt sztm meg tudnad oldani, hogy a masodik kor setpointjat az elso korre tedd (gondolom NodeMCU van az OTGW-n) viszont ez azt eredmenyezi, hogy az elso korrol jovo termosztat erteket mar nem fogadja el a kazanod. Ennek az az oka, hogy ha az OTGW-n folulirod a setpoint erteket, az abban a pillanatban manualis lesz (amit csak a CS=0 parancsal tudsz visszaadni a termosztatnak). Magyarul ha az elso futesi korrol jon egy 65 fokos igeny, a masodikrol pedig egy 40-es es te ezt rakuldod OTGW-vel az elso korre, akkor mindaddig 40 fokot kuld a kazan, amig nem jon egy mas ertek a masodik kortol amit szinen rakuldesz, vagy nem adod vissza a CS=0 val a vezerlest a termosztatnak.

Azt latom megoldasnak, hogy a termosztat felol jovo 2 kerest parse-olod az ESPeasy-n (Gondolom az van a NodeMCU-n) es mindig a nagyobbat kuldod tovabb a kazannak (ha a ket ertek egyenlo, akkor nyilvan mind1 melyiket) nyilvan az elso futesi korre, hiszen csak azt tudja ertelmezni. Igy megoldod azt, hogy mindket helyrol johet adat. Nyilvan azert kell a magasabbat a kazannak elkuldeni, mert mindig a nagyobb hoigeny az "erosebb". 

nyilvan a control setpointod igy is manual lesz folyamatosan, de ez egy "dinamikus" manual lesz, amit a termosztatod ket setpointjanak a nagyobbika fog minden egyes triggerevel felulirni.

Ha ugy erzed, ez tul osszetett , vagy nem akarsz belemenni ennyire, lehet erdemes jelezni ezt a dolgot ezen a forumon: https://www.domoticaforum.eu/viewforum.php?f=75

A fejleszto, hvxl lehet OTGW oldalon tudja ezt neked fixalni, mondjuk valami olyan parameter hozzaadasaval, ami engedelyezesevel mar elore osszevonja a ket setpoint erteket.

Amire viszont vigyazni kell, meg eszben tartani, hogy egy OT termosztat nem csak setpointot allithat... meg kell nezni, hogy a masodik futesi korhoz milyen ID-k tartozhatnak (asszem amugy a C2/H2  command van csak, pont az uj 5.0 firmware-ben kerultek bele)

Erdemes par napig lementeni a logot OTmonitorral es nezni, mi jon a termsoztattol (T-vel kezdodo sorok)

Azt latom megoldasnak, hogy a termosztat felol jovo 2 kerest parse-olod az ESPeasy-n (Gondolom az van a NodeMCU-n) es mindig a nagyobbat kuldod tovabb a kazannak

Igen, NodeMCU van az OTGW-n és és azon pedig EspEasy. Viszont tudnál iránymutatást adni hogy hol tudom ezt megvalósítani amit írsz? Az EspEasy forrásában?

Read flow 2 temperature, Read DHW2 temperature ilyeneket látok még amikre nem jön válasz, szerintem ezek nem fontosak.

Hát én ez alapján nem igazán látom át hogy hogyan tudom ezt megcsinálni. Példákat sem igazán találok. Talán csinálnom kéne egy taszkot ami olvas/ír publikus változókba/ból a ser2net adatok alapján, a rule-ban pedig a saját logikám szerint módosítom a változókat?

C# -ban simán megcsinálnám az egészet, de hogy még egy eszközt vagy a homservert bevegyem a vezérlésbe emiatt, erős túlzásnak érzem.

Esetleg innen lehetne inspiraciot merinteni. Ez az FW pontosan azt csinalja ami neked kell. mar ESP oldalon feldolgozza az adatokat.

 

https://github.com/rvdbreemen/OTGW-firmware

 

Itt erdemes szetnezni. Az FW ezen resze C és C# lehet ezzel akkor jobban boldogulsz. nalad ket ertek jatszik, a TsetCH2 es a Tset. ennel a ket erteknel kell elerni, hogy a nagyobbat kuldje tovabb a kazannak.

 

https://github.com/rvdbreemen/OTGW-firmware/blob/main/OTGW-Core.ino

 

https://github.com/rvdbreemen/OTGW-firmware/blob/main/OTGW-Core.h

 

 

A firmware-hez van rest API is. /api/v1/otgw/command/{any command}

En Valahogy ugy csinalnam, hogy a Tset es TsetCH2 erteketet eltarolnam egy-egy valtozoban, majd megvizsgalnam a ket valtozot hogy melyik a nagyobb es az API-n keresztul elkuldenem. (CS=XX command-al) azt kell mindenkepp figyelni, hogy a bejovo adatok a termosztattol jojjenek! Mivel ha beallitasz manual setpointot, akkor az jonni fog a gatewaytol is! (valahogy igy: https://i.imgur.com/AlxTGPH.png)

Nos belehackeltem a logikát a processOTGW függvénybe. Lefordul de most nem állok már neki tesztelni.

void processOTGW(const char * buf, int len)
{
  static float TrSetCurr = 0.0;
  static float TrSetCH2Curr = 0.0;

  bool SPChanged = false;

  // ...

        case TrSet:
        {
          OTdataObject.TrSet = print_f88();
          
          if(buf[0] == 'T')
          {
            SPChanged = true;
            TrSetCurr = OTdataObject.TrSet;
          }
          
          break;
        }
        case TrSetCH2:                      
        {
          OTdataObject.TrSetCH2 = print_f88();

          if(buf[0] == 'T')
          {
            SPChanged = true;
            TrSetCH2Curr = OTdataObject.TrSetCH2;
          }
          
          break;
        }

  // ...

  if(SPChanged)
  {
    float SetPoint = TrSetCurr;

    if(TrSetCH2Curr > TrSetCurr)
    {
      SetPoint = TrSetCH2Curr;   
    }

    char CommandBuff[32];
    snprintf(CommandBuff, 32, "CS=%.1f", SetPoint);

    sendOTGW(CommandBuff, strlen(CommandBuff));
  }
}

Nekem CH parancsot nem kell manuálisan küldenem?

Barmelyik parancs, ami elter a CS=0-tol, az A CH-t "1" re billenti.

http://otgw.tclcode.com/firmware.html#configuration

 

CH=state
Central Heating - When using external control of the control setpoint (via a CS command with a value other than 0), the gateway sends a CH enable bit in MsgID 0 that is controlled using the CH command. Initially this bit is set to 1. When external control of the control setpoint is disabled (CS=0), the CH enable bit is controlled by the thermostat.
Example: CH=0, CH=1

Esetleg azt kell megoldani meg nalad, hogyha a termosztat keri a CH-t (0 vagy 1) akkor azt igy lehet nalad nem fogja figyelembe venni a kazan, mert manual modban vagy. Vagyis ezt kb forwardolni kell a kazan fele.

 

Szerk: igen igen... kozben irtam, csak mar nem engedte szerkeszteni... Ha a termosztat keri a CH 0-at akkor azt kuldeni kell.

 

Egy kerdes. firmware keszitoje kerdezteti, hogy hol van ez a valtozas :) Mert ot is erdekli :D (Egyutt csinaljuk vele a firmwaret, bar o a programozo en csak a segito/tesztelo..:D )

Most így nem látom hirtelen, de a termosztát melyik üzenettel állíthat CH-t? :D Hát ez elég hack még így, ezt nyilván átgondoltabban kéne majd belevarrni, illetve ki/bekapcsolhatóvá tenni. 

Más: vajon ha megszakad a kapcsolat a termosztát és a kazán között, akkor a kazán leáll vagy fűt tovább a világba az utoljára beállított manuális setpoint alapján?

Nem úgy van hogy a CH/CH2 csak egy státusz bit a kazántól hogy a beállított setpoint alapján éppen van-e fűtés vagy nincs? A gateway CH parancsa pedig csak ugyanúgy a setpointot veszi le minimumra illetve állítja vissza az utolsó értékre.

Szerintem beleteszek egy plusz védelmet akkor, ha mondjuk 2 másodpercig nincs semmilyen üzenet a termosztáttól akkor kapcsoljon le a kazán. 

ha a CH enabled, de a CS-nek van manualis erteke (pl 10) akkor a kazan folyamatosan keringetni fogja a vizet (viszont nem gyujt a lang) addig, amigy nem kap kikapcs parancsot. (vagy nem adod vissza a CS=0 val  vezerlest a termosztatnak es nem kuld o kikapcsot) Nekem ez a tapasztalatom.

A CH nem status bit, az a MsgID 0 (egy adott bitje), amit a CH parancs vezerel. Ez lesz azonnal 1, ha barmilyen CS parancsot kuldesz ami elter a CS=0-tol.

a 2 mp nem biztos, hogy eleg, mert nem kuld ilyen gyakran sztm a termosztat setpointot (nalam legalabbis)

Oké, azt hiszem kezdek megvilágosodni. Szóval akkor beletettem még azt is, hogy figyelem hogy a masternél a CH vagy CH2 változik-e, és küldöm a CH || CH2 értéket a gateway felé a CH=x paranccsal. Illetve ha a termosztát kapcsolata megszakad (ezt a régi vegyes tüzelésű kazán termosztátja meg tudja szakítani ha véletlen begyújtanánk), akkor garantáltan 0-át küld. Majd megnézem hogy mennyire gyakran kommunikál a termosztát, úgy emlékszem hogy elég sűrűn.

Feltöltöttem NodeMCU-ra, látszólag oké. Majd kéne egy kis idő hogy odatelepedjek a kazán mellé.

( agostonl | 2021. 02. 06., szo – 12:01 )

Bocsi, OFF leszek.

[OFF]Mondom OpenTherm. Valamilyen terminál progi? Kattintok... nem az.

Valamikor a '90-es években, mikor még a BMV-n volt az IFABO, apám, a teherautós vállalkozó megjelent a bejáratnál, hogy IFA-hoz keres váltót.

Na... nem az volt. :) [/OFF]

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( Des | 2021. 02. 09., k – 11:25 )

Nos működik minden, viszont van néhány "DE", ami miatt egyelőre nem bízom rá a vezérlést:

 - a termosztát HUB-on lévő két relés kimenet a zónákhoz nem alkalmas arra hogy vezéreljem vele OT üzemben a két vízkört. Az arra jó hogy ON/OFF módba kapcsolgasson, viszont így hogy én OT-n átveszem a vezérlést, nekem kellene a NodeMCU-ról vezérelni a szelepeket is, mert például utókeringetésnél hiába nincs fűtésigény a kazán még keringetné a vizet, a szelep viszont akkor már zárva van. Ugyanez probléma akkor is amikor CH=0 -át küldök. A lángot elveszi a kazán a keringetést viszont majd csak később valamikor. Zárt szelepeknél a kazán ugyan visszaveszi/kikapcsolja a szivattyút, de ennek nyilván nem ez a módja.

 - nem érzem elég stabilnak a NodeMCU-s vezérlést. Opentherm monitorban néha másodpercekre megakad az egész adatfolyam, nem tudom hogy miért. Ilyenkor amikor magához tér, észreveszi hogy több mint két másodperce nem jött a termosztáttól üzenet és már küldi is a CH=0 -át, viszont mivel utána nem sokkal később megint jönnek az adatok megy megint a CH=1. Mivel nem sok idő telik el ilyenkor, nem kapcsolódik le a kazán egy pillanatra sem. De egy alkalommal volt olyan hogy megállt az adatfolyam és nem is indult újra. Ilyenkor megállt a kazán is.

Az elso pont amit irtal amugy fura... mert siman ON/OFF nal is van utokeringetes (nalam pl alapbol 5 perc) Most akkor kapcsolos modban is, abban a pillanatban zarja a szelepeket a Wiser, amint jon egy lang OFF? Amikor a termosztat kuld egy CH=0-at akkor kene parhuzamosan zarni a szelepeket... Az nem epp logikus h a lang elvetelekor zarja.... Biztos vagy benne, hogy igy mukodik?

Jelenleg az Opentherm egyáltalán nincs bekötve. Csak a termosztát két reléje kapcsolja a két szelepet. A szelepek végálláskapcsolója pedig ki/be kapcsolgatja a kazánt.

De Opentherm módban is biztos hogy azonnal kapcsoltak a relék, ahogy az adott zóna elérte a beállított hőfokot. Hallottam is ahogy a szivattyú először leszabályoz aztán leáll. Tehát azt gondolom hogy azokat nem Opentherm-el együtt történő üzemre szánta a Wiser. Openterm módban talán a kazánnak (vagy jelen esetben a gateway-nek) kellene kapcsolnia az adott kört.

Most olvasom pontosan amit irsz. Ha jol ertem, szelepvezerlessel sorba kototted a ket termosztat kabelet es ha elzar a szelep, az kapcsolja a WT734R-t es az pedig a kazant?

Igen, igy valoban az van amit mondasz... Viszont ha ez a Wiser koncepcioja, az eleg gaz... Ezt a reszt viszont akkor nem ertem:

 

https://i.imgur.com/eh5jICv.png

 

Esetleg arra nincs mod, hogy a kazan vezerelje a szelepeket? Az megoldana a gondot. Nekem egy  Westen Boyler Condens+ om van, ahhoz lehet kapni egy rele kartyat (dupa reles) ami parameterezheto. Alapbeallitasban azt csinalja, hogy ha a CH=1 akkor ON, ha CH=0 akkor OFF. Teljesen fuggetlen attul, mit kuld a termosztat, csak azt figyeli, mit csinal a kazan. Havernal (Ugyanilyen kazanja van mint nekem) kotottunk ra egy padlofutes szivattyut es teljesen szinkronban mukodik a kazan belso szivattyujaval.

Igy nez ki:

https://i.imgur.com/qPboZph.png

https://i.imgur.com/vIndOEr.png

Nincs sorba kötés, vagy csak elbeszélünk egymás mellett. Szóval HUB CH1, CH3 megy a szelepek L (barna) kábeleire. A két szelep fehér kábele összekötve, a két narancs szintén és azok pedig mennek a kazán ki/be bemenetére. Így bármelyik szelep nyit a kazán kap indítójelet.

A doksi szerint a kazán tud két fűtökört kezelni, de két külön termosztáttal és ebből csak az egyik lehet Opentherm-es. Van kimenete egy háromjáratú szelephez és az tereli vagy az egyik kör vagy a másik kör felé a vizet. De ez nekem így nem jó. Én azt akarom hogy a két kör tudjon egyszerre fűteni.

Nézegettem még a kazán doksiját és megtaláltam hogy a szervizmenüben lehet állítani az utókeringetés idejét percekben (alapból 1 perc), volt kéznél két időrelé most azokat beraktam a hub és a szelepek közé olyan módban hogy ha a HUB zárná az adott szelepet utána az időrelé még kicsivel több mint egy percig nyitva tartja. Így most legalább nem záródik rá a kazánra vízkör amikor az még utókeringetni akarna.

Majd szerintem még futok egy kört az Opentherm részével valamikor. De most örülök hogy ez így működik.

Ertelek mar.

Ha az OTGW firmware picit univerzalisabb lenne (mint pl a tasmota vagy az ESPeasy) akkor lehetne egy relay Shieldet ultetni az ESP-re (van szabad GPIO-ja boven) es direktben vezerelni a kazantol jovo "cental heating disable" ID-vel a leallast. Akkor nem szamitana az utokeringetes, mert akkor zarna el a ket szelep, amikor teljesen leall a kazan. A nyitast (1-es vagy 2-es) meg hozzarendelheted a termosztattol jovo CH es H1 parancsokhoz (amit most parse-olsz)

- tehat egyesiteteni az egyes es a kettes kor infojat az egyesbe (ez mar megvan)

- ezzel parhuzamosan (meg az egyesites elott) ha jon az adott kor felol a termosztattol az "enable heating, illetve setpoint" keres azzal az adott relet zarni (a szelepet nyitni)

-  ha a kazan felol jon a CH=0 (tehat mar tuti nem megy a szivattyu sem) akkor mindket relenek kuldeni egy nyitast (szelepek zarnak)

 

Mondjuk ahogy nezem, annyira nem lenne nehez integralni OTGW firmware-be sem. Van sok tutorial, pl: https://randomnerdtutorials.com/esp8266-relay-module-ac-web-server/