A régi, 7/2006 TNM szerinti tanúsításokat fogadó helyre nem tölthető fel a 9/2023 ÉKM szerinti XML. Erre a Lechnernek egy új feltöltő felülete van.

Ha nem teljes épületről van szó, hanem önálló rendeltetési egységről, akkor kötelező megadni a közterület nevét és típusát (pl Kossuth utca), a házszámot, emeletet és ajtót.

Ha nincs emelet és ajtó, akkor is valamit be kell írni, mondjuk egy-egy - (mínusz) jelet.

A Lechner rendszerén belüli hiba, egyelőre nem tudják pontosabban meghatározni. Feléjük kell jelezni.

Itt lehet megadni az épület szimbólumát. Erre egyébként a WinWatt is figyelmeztet.

Három kategóriához kötelező képet megadni. Ezek a következők

• Első lapra kerülő, egyben homlokzati kép
• Jellemző hőleadót, annak szabályozását ábrázoló kép
• Jellemző nyílászáró képe

A képeket az épületnél, a fotók lapon lehet megadni. Ügyeljünk a megfelelő kategória kiválasztásra is a képeknél.

Először azt kell megvizsgálnunk, hogy a program fizikailag érzékel-e kulcsot. Ezt abból tudjuk eldönteni, hogy a jelszó megadásra szolgáló ablakban mit ír ki a program kulcsazonosítóként, az ábrán pirossal jelölve.

Ha a Nem található kulcs jelenik meg itt, akkor nagy valószínűséggel a kulcsdriver program nem lett telepítve, vagy a működése nem megfelelő. Célszerű ilyenkor a kulcsdrivert újratelepíteni.

Ha továbbra sem látja a program a kulcsot, akkor a program indító ikonján az egér jobb gombjával kattintva a menüben válasszuk a tulajdonságok pontot. A kompatibilitás fülön a kompatibilis üzemmód részben kapcsoljuk be a futtatás a következő kompatibilitási üzemmódban kapcsolót, és alatta válasszuk ki a Windows 8-at.

Ha talált kulcsot, célszerű ellenőrizni, hogy az a jelszó adatokban megadottal megegyezik-e. Az ábrán pirossal jelöltük.

Ha eltérő, lehet, hogy több kulcsunk is van, és nem a megfelelő van a gépbe dugva. (Több kulcs esetén az elsőre megtalált kulcsot írja ki a program.) Ha egyeznek az adatok, vizsgáljuk meg a további adatok helyességét. A név, a cím és a jelszó adatok esetében is ellenőrző értékek segítenek ebben, ezeket a képeken zölddel jelöltük meg. Ha valamelyiknél eltérést tapasztalunk, akkor valamit rosszul adtunk meg. Ügyeljünk az ékezetekre, írásjelekre, szóközökre, kis és nagybetűkre. Gyakran a kis l és az egyes karakter, illetve a kis o és a nulla karakter keveredik. A jelszó adatokban csak kisbetűk és számok szerepelnek. Az is fontos, hogy a jelszó adat ehhez a programhoz tartozzon. Ezt az információt kékkel jelöltük az ábrán. A WinWatt esetében külön jelszó tartozik az EPBD modulhoz, ezért itt még a következőkre kell ügyelni.

Az alap jelszó felvételekor a jelszó típusánál a program legyen kiválasztva. A listában az ilyen jelszó előtt a modulnév üres. Az EPBD modulhoz tartozó jelszó felvételekor az EPBD modul legyen kiválasztva. A listában ebben az esetben a modulnév az EPBD modul lesz, az ábrán kékkel jelöltük.

Az Avast naplófájljában a Sentinel Protection Server esetén azt találjuk, hogy arra az alapértelmezett szabály vonatkozik.

Ha erre az alapértelmezett szabályra kattintunk, az avast alkalmazásszabályaihoz jutunk. Az Avast már a hálózati szabályoknál blokkolja a folyamatot, a megjelölt sornál. (Ilyenkor a felette lévő sor még nem létezik, a kép azután készült, hogy már létrehoztuk az új szabályt.)

A megjelölt sor elé létrehozunk egy új szabályt, a példában Sentinel Prot. Serv. Saját szabálynak neveztük, és a következő beállításokat adtuk hozzá.

Ezt követően már a kulcs felismerést nem zavarja az Avast.

A rovatba írt értéknek a helyiségek határoló szerkezeteinél van szerepe. Akár az új határoló szerkezetek felvételekor, akár egy már felvett határoló szerkezet adatainak módosításakor a párbeszédpanel tartalmaz egy tájolás rovatot. Ennek gyorsabb és kényelmesebb kitöltésére a program a legördülő listában felsorolja a négy fő (É, K, D, NY) és a négy mellék tájolást (ÉK, DK, DNY, ÉNY). Mindegyik szöveg előtt szerepel egy szögérték is. A program a számításokhoz csak a szögértéket vizsgálja, a mögötte lévő szöveget nem értelmezi, az csak a felhasználó számára könnyíti meg a tájékozódást. A legördülő listában a nyolc szöveghez tartozó szögértéket tudjuk az épület adatok tájolás értékével befolyásolni. Az itt megadott -23° és +23° közti értéket rendeli az északi irányhoz. Ha a megadott érték kivül esik ezen a tartományon, akkor a program automatikusan 45°-os forgatásokkal megkeresi a tényleges északi falnak az északi irányhoz viszonyított szögét.
Ezek után tehát úgy kezeljük ezt a rovatot, hogy először megnézzük, hogy az épületünknek az északi irányba eső falának normálisa mekkora szöget zár be a tényleges északi iránnyal, és ezt a szögértéket írjuk az épület tájolás rovatba, pozitív az érték, ha kissé keleti, negatív, ha kissé nyugati irányba néz. Ezzel könnyebbé tesszük a tájolás értékek kiválasztását az egyes határoló szerkezetek felvételénél. Fontos, hogy csak a felkínált értékek módosulnak a rovat módosításával, a korábbi határoló szerkezeteket nem "forgatja"!

Sajnos nagyon sok anyagnál hiányzik a szorpciós izoterma, illetve a megengedett nedvességtartalom a programmal szállított adatbázisban is. Ennek oka, hogy a jellemzők meghatározását célzó vizsgálatokat viszonylag kevés gyártó végeztette eddig el, mivel ezekre korábban a számításokhoz nem volt szükség, illetve nem is olcsóak. Reméljük, hogy egyre több gyártó szembesül ezzel a problémával, és kap indíttatást a vizsgálatok elvégzésére, és az eredmények közzétételére. Addig is milyen lehetőségünk vannak a probléma kezelésére?

• Ha egy rétegnél nincs szorpciós izoterma vagy megengedett nedvességtartalom megadva, akkor a program annál a rétegnél, más információ híján, 75 %-nál magasabb relatív páratartalom esetén már figyelmeztetést ad. Ha tudjuk, hogy ez arra a rétegre túl szigorú megkötés, mert akár 100 %-os relatív páratartalom is megengedhető lenne, akkor vegyünk fel a szorpciós izotermára egy biztonságosan alacsony értéket, például adjunk meg a 100 %-os relatív páratartalomhoz 0.1 %-ot, és ugyanezt adjuk meg a megengedett nedvességtartalom rovatban is.
• Az adott szerkezetnél bekapcsolhatjuk az egyszerűsített módon kapcsolót. Ebben az esetben a program nem foglalkozik a szorpciós izotermákkal, nem számol feltöltési időt, hanem csak a páralecsapódásra ellenőriz.
• A program beállítások viselkedés lapján bekapcsolhatjuk az egyszerűsített páradiffúziós számítás, csak a páralecsapódásra ellenőriz kapcsolót. Ebben az esetben minden szerkezetre az előbb leírt módon viselkedik a program.

Negatív feltöltési idő valóban nem létezik, a szabványban megadott és a programban alkalmazott közelítő módszer elhanyagolásaiból adódik ez a furcsa jelenség. A feltöltési idő számításánál sok elhanyagolást alkalmazunk, a bonyolult probléma kezelhetővé tétele céljából. Durván megfogalmazva az alkalmazott algoritmus azt vizsgálja, hogy az egyensúlyi állapotban a szerkezetben lévő nedvesség mennyiségéből kivonva a szerkezetben kiinduláskor meglévő nedvességtartalmat kapunk egy vízmennyiséget, amit a falba beáramló gőzáram fog a feltöltési idő alatt a szerkezetbe bevinni. Ezért a feltöltési idő számítása úgy történik, hogy a vízmennyiséget elosztjuk a gőzáram értékével. Ez akkor adódik negatív értékre, ha a szerkezetben eleve nagyobb volt a vízmennyiség, mint amennyi az egyensúlyi állapothoz tartozik. (A kezdeti nedvességtartalomra a szabvány azt mondja, hogy az minden rétegnél legyen a 60%-os relatív páratartalomhoz tartozó nedvességtartalommal egyenlő.) A valóságban persze ahhoz is bizonyos időre van szükség, hogy a nedvességtartalom az egyensúlyi állapothoz tartozó lefutás szerintire rendeződjön át, de ezt az algoritmus nem kezeli. Írhatna a program ilyen esetben mondjuk nullát is az időre, hogy kevésbé legyen a jelenség zavaró, de úgy gondoltuk, hogy az érték nagysága esetleg hordoz információt, ezért maradtunk a negatív érték kijelzése mellett.

Ebben az esetben is van lehetőségünk áttérni egyszerűsített páradiffúziós számításra.

A Windows vezérlőpultjában a Területi és nyelvi beállítások Speciális lapján az Unicode-ot nem használó programok nyelvénél válasszuk ki a magyart. A megoldást szemléltető videóhoz kattintson ide.

A Windows VirtualStore technológiája okozhat ilyen problémát. Először is szokjunk le arról, hogy projekteket a Program Files könyvtárban tárolunk. Javasoljuk a Dokumentumok könyvtárt erre a célra. A másik jótanács, időnként archíváljuk a projektjeinket. Visszatérve a problémához, a VirtualStore lényegében egy olyan könyvtár, ahova a felhasználó által a Program Files könyvtárba létrehozott fájlok ténylegesen kerülnek, a Windows pedig úgy mutatja, mintha ezek a fájlok a Program Files könyvtárban lennének. Ez időnként viszont nem működik helyesen, az okát nem tudjuk, a lényeg, hogy a fájljainkat nem találjuk.

Hogy lehet ehhez a VirtulStore könyvtárhoz hozzáférni? Először is a fájlkezelőnket rá kell bírni arra, hogy a rejtett fájlokat is mutassa. Újabban ezt a Vezérlőpultban, a Mappa beállításai részbe belépve tudjuk megtenni. A Nézet fülön a Rejtett fájlok és mappák részben váltsunk át a Rejtett mappák, fájlok és meghajtók megjelenítésére.

Hol található ez a VirtualStore könyvtár? c:\users\username\Appdata\local\Virtual Store\. A users helyett lehet hogy Felhasználók szerepel. A username helyére a saját profilunk nevét kell választani.

Ha sikerült eljutnunk ebbe a könyvtárba, azon belül megtaláljuk a Program Files, vagy Program Files (x86) könyvtárat és azon belül a progrmunk könyvtárát. Ha szerencsénk van, itt megtaláljuk az elveszettnek hitt projekteket. Célszerű ezeket átmásolni a Dokumentumok könyvtárba és a továbbiakban onnan használni.

A program a felhasználó AppData könyvtárában keresi az adatbázisokat, ide is lesz telepítve. Ha nem a saját profilunkból történt a telepítés, akkor az adatbázisok ebben a másik profilban találhatóak, csak a program nem ott keresi.

Hogy javítható ez a hiba? Több megoldás is létezik.

• Először is a fájlkezelőnket rá kell bírni arra, hogy a rejtett fájlokat is mutassa. Újabban ezt a Vezérlőpultban, a Mappa beállításai részbe belépve tudjuk megtenni. A Nézet fülön a Rejtett fájlok és mappák részben váltsunk át a Rejtett mappák, fájlok és meghajtók megjelenítésére.
  Hol találhatóak az adatbázis fájlok, melyik könyvtárban? c:\users\username\Appdata\Roaming\Bausoft\WinWatt gólya. A users helyett lehet hogy Felhasználók szerepel. A username helyére a saját profilunk nevét kell választani, illetve a WinWatt gólya helyett a megfelelő WinWatt változat nevét.
  A fájlokat annak a felhasználónak a profilja szerint találjuk meg, akinek a nevében történt a telepítés, ez lehet, hogy a rendszergazda. Ezt a teljes könyvtárat kell átmásolnunk a saját profilunkba a fentebb leírt útvonal alá.

• A program telepítésekor megválaszthatjuk, hogy a telepítő az adatbázisokat hova tegye. Itt választható a minden felhasználó számára elérhető mód, ilyenkor mindegyik felhasználó ugyan azt az adatbázist használja.

Amennyiben a hibaüzenetben az SSL Library-ra vonatkozó jelzés szerepel, szükséges egy további modul telepítése. Az SSL Library telepítőprogramja innen tölthető le.

(Az SSL Library a https:// kezdetű kapcsolatokhoz szükséges eszköz.)

A program beállításokban a betűtípusoknál a korábbi MS Sans Serif típust cseréljük le Microsoft Sans Serif típusra. A korábban használt betűtípus nem tartalmazta a görög betűket, az új sokkal bővebb, még a cirill betűket is tartalmazza.

Az épületre beállított jelleg (könnyű, vagy nehéz) ellentmond a számított fajlagos hőtároló tömeg értéknek.
A program a rendelet előírása szerint, a 6-os melléklet alapján végzi a fajlagos hőveszteség követelményértékének számítását. Itt szerepel a következő kitétel.
Abban az esetben, ha az épület a fajlagos hőtároló tömege szerint nehéznek minősül, elegendő az 5. melléklet II. részében szereplő követelmény teljesítése ahhoz, hogy az épület közel nulla energiaigényűnek minősüljön.
Ezért fontos, hogy az épületre beállított jelleg összhangban legyen a számított fajlagos hőtároló tömeg értékkel.

A számított fajlagos primer energiaigény értéke két kategória határán van, és a WinWatt program nem ugyan olyan módon kerekít mint a központi rendszer.

• A tanúsítás adataiban kisebb módosítással elmozdíthatjuk a kategória határtól az eredményt, és így a kerekítési hiba kiküszöbölhető.
• Az XML feltöltés helyett a kézi adatmegadás is választható a tanúsítás feltöltésekor.

A BB besorolás feltételei a rendelet szerint a következők:

• A számított fajlagos primer energia igény <= 100 %
• A fajlagos hőveszteség tényező számított értéke a 6. melléklet szerinti követelménynek feleljem meg.
• Az épület megújuló részaránya legalább 25 % legyen.

Épületrész esetén a fenti feltételekből az utolsó kettőnek az egész épületre teljesülnie kell.
A WinWatt az épületrészre számolt adatok alapján juthat arra a következtetésre, hogy teljesülnek a BB kategória feltételei, a feltöltéskor azonban az épületre vonatkozó, legalább BB-s tanúsítással kellene rendelkeznünk. Ha ilyen tanúsításunk nincs, maximum CC kategóriát kaphat az épületrész.
Ahhoz, hogy a WinWatt is ezt adja, a megújuló részarány számítási módját állítsuk "megadja az épületre" módra, és adjunk meg kevesebb mint 25 %-ot.

3. melléklet a 176/2008. (VI. 30.) Korm. rendelethez:
"3. „AA” vagy annál jobb besorolás csak a Rend. szerinti részletes módszerrel vagy dinamikus szimulációval alátámasztott módon adható. A dinamikus szimulációs esetén is a Rend.-ben meghatározott mértezési alapadatokkal egyenértékű adatokkal kell végezni a méretezést.
4. „AA” vagy annál jobb besorolás csak olyan esetben adható
4.1. ahol a hőtermelő időjárásfüggő szabályozása megoldott,
4.2. ahol a hűtési és fűtési rendszer helyiségenkénti szabályozhatósága megoldott,
4.3. ahol az önálló tulajdonú vagy külön bérbe adható épületrészek energiafogyasztásának mérése külön legalább költségosztók felszerelésével vagy egyedi mérőkkel megoldott."

A Budapesti és Pest Megyei Mérnöki Kamara közleménye szerint a részletes módszer a következőket jelenti: (ezek WinWatt vonatkozásait mellé írtuk)