--- title: "KNX'i telefondan kontrol etmek: uzaktan erişim, görselleştirme ve KNX Secure · Colga Bilişim" description: "KNX sistemine uzaktan nasıl bağlanılır? IP interface mi IP router mı, görselleştirmeyi ne üretir, KNX Data Secure ile IP Secure farkı ve şartname maddeleri." url: https://colgabilisim.com/rehber/knx-uzaktan-erisim-gorsellestirme-knx-secure/ source: Colga Bilişim language: tr-TR --- > Kaynak: Colga Bilişim — İzmir zayıf akım, CCTV, yangın algılama, yapısal kablolama, veri ağı, sistem odası ve KNX akıllı bina yüklenicisi. > Kanonik URL: https://colgabilisim.com/rehber/knx-uzaktan-erisim-gorsellestirme-knx-secure/ > HTML sürümü: https://colgabilisim.com/rehber/knx-uzaktan-erisim-gorsellestirme-knx-secure/ ## Kısa cevap "KNX'i uzaktan kontrol etmek" tek bir karar değildir. Birbirine karıştırılan **üç ayrı karar** vardır ve her biri farklı bir disipline aittir: Karar Soru Kim verir **1. IP'ye çıkış** Bus'ı IP'ye hangi cihaz bağlıyor — IP interface mi, IP router mı? KNX tasarımcısı (hat sayısına göre) **2. Görselleştirme** Ekranı/uygulamayı ne üretiyor — bus üstü panel mi, üretici bulutu mu, yerel sunucu mu? İşveren + KNX tasarımcısı (ömür ve sahiplik kararı) **3. Uzaktan erişim yolu** Dışarıdaki kullanıcı ağa nasıl giriyor — VPN mi, üretici bulutu mu, açık port mu? Ağ/BT tarafı Kısa cevaplar: çok hatlı bir tesiste **IP router**, tek hatlı küçük kurulumda **IP interface** yeter. Görselleştirmede kurumsal varsayılan **yerel** olandır; bulut, kabul edilen bir bağımlılıktır, varsayılan değil. Uzaktan erişimde kurumsal varsayılan **VPN**'dir. Ve tek cümlelik kural şudur: **KNXnet/IP portunu internete açmak bir yöntem değildir.** Klasik KNXnet/IP'de kimlik doğrulama yoktur; o porta ulaşabilen herkes grup adreslerine yazabilir — yani ışığı yakabilen, jaluziyi indirebilen, kombiyi kapatabilen herkes demektir. **KNX Secure** de tek bir şey değildir, iki ayrı katmandır: **KNX IP Secure** IP üzerindeki trafiği, **KNX Data Secure** bus telegramının kendisini korur. Biri diğerinin yerine geçmez. ## Önce bir rahatlatıcı gerçek: bant genişliği burada sorun değil Kamera tarafından gelen alışkanlıkla KNX'e bakıldığında ilk refleks kapasite hesabı olur. Gerek yoktur. KNX TP bus'ı **9 600 bit/s** hızında çalışır; bir buton basımı, bir sıcaklık okuması veya bir jaluzi komutu birkaç on bayttır. Yüz odalı bir otelin tüm KNX trafiği, tek bir kameranın alt akışının yanında ölçülemeyecek kadar küçüktür. Bunu baştan söylemekte fayda var, çünkü KNX'in uzaktan erişimindeki riskler kapasite değil **yetki ve süreklilik** başlıklarındadır. [Kamera sistemlerinde upload hattı gerçek bir sınırdır](https://colgabilisim.com/rehber/guvenlik-kamerasi-uzaktan-izleme-port-acma-p2p-vpn/); KNX'te değildir. Buna karşılık KNX'te kameralarda olmayan bir risk vardır: uzaktan erişim yalnızca *izlemeye* değil, **binayı çalıştırmaya** açılır. ## Karar 1 — Bus'ı IP'ye ne bağlar: interface mi, router mı? KNX'i IP ağına bağlayan iki cihaz sınıfı vardır ve isimleri benzediği için sıkça karıştırılır. Fark teknik bir ayrıntı değil, **topoloji kararıdır**. ### KNXnet/IP: tunnelling ve routing KNX'in IP üzerindeki protokolü **KNXnet/IP**'dir ve **UDP 3671** portunu kullanır. İki farklı çalışma biçimi vardır: - **Tunnelling (tünelleme):** Bir istemci — ETS, bir mobil uygulama, bir görselleştirme sunucusu — bus'a tek bir noktadan bağlanır. Noktadan noktaya bir oturumdur. - **Routing (yönlendirme):** Telegramlar IP ağı üzerinden **multicast** ile taşınır; varsayılan grup adresi **224.0.23.12**'dir. Burada IP ağı, hatlar arasındaki **omurga hattı** görevini görür. ### Hangisi hangi projede? **KNX IP interface** **KNX IP router** Ne yapar Yalnızca tunnelling Tunnelling **+** routing (hat bağlayıcı) Rolü Bus'a bir erişim kapısı IP omurgası üzerinden hat/alan bağlayıcı Filtre tablosu Yok Var (hat bağlayıcı gibi çalışır) Tipik yeri Tek hatlı villa, küçük ofis Çok katlı/çok hatlı bina, kampüs, otel Karar kuralı basittir: **kurulum tek hattaysa** (bir güç kaynağı, bir TP segment) bir IP interface yeterlidir. **Birden fazla hat varsa** ve bu hatlar birbirine TP omurga yerine bina ağı üzerinden bağlanacaksa, her hatta bir IP router konur ve omurga IP olur. [KNX bus kablolama rehberimizde](https://colgabilisim.com/rehber/knx-bus-kablolama-kablo-mesafe-guc-kaynagi/) anlattığımız hat ve alan sınırları burada doğrudan devreye girer: hat sayısını belirleyen şey cihaz sayısı ve mesafedir, IP omurga kararı da ondan sonra gelir. Mevcut binalarda bu seçim ayrıca bir kolaylıktır — kat başına TP omurga çekmek yerine [var olan ağ altyapısı omurga olarak kullanılabilir](https://colgabilisim.com/rehber/mevcut-binaya-knx-kurulabilir-mi-retrofit-knx-rf/). ### Eşzamanlı bağlantı sınırı: küçük ama can sıkıcı ayrıntı Bir interface/router'ın aynı anda kabul edebileceği **tünel bağlantısı sayısı sınırlıdır** ve ürüne göre değişir; kimi cihaz tek bağlantı verir, kimi birkaç eşzamanlı tünel destekler. Pratikte şu tabloyu yaratır: görselleştirme sunucusu bir tüneli tutar, mobil uygulama ikincisini ister, servis için gelen teknisyen ETS ile bağlanmak ister ve cihaz "meşgul" der. Şartnamede tek satırla çözülür: **kaç eşzamanlı tünel bağlantısı isteniyorsa yazılır** ve cihaz ona göre seçilir. Sonradan çözümü cihaz değiştirmektir. ## Karar 2 — Görselleştirmeyi ne üretir? Kullanıcının gördüğü ekran KNX'in kendisinden gelmez; onu üreten ayrı bir katman vardır. Üç seçenek vardır ve aralarındaki fark görsel kalite değil, **bağımlılık ve ömürdür**. ### (a) Bus üstü dokunmatik panel Duvara gömülü, bus'tan beslenen, ETS ile programlanan panel. İnternete ihtiyaç duymaz, üreticinin sunucusuna bağlı değildir, sistem kadar uzun yaşar. Buna karşılık ekranı sabittir, uzaktan erişim vermez ve arayüzü değiştirmek ETS'e dönmek demektir. **Nerede doğru:** her projede en az bir tane. Merkezî senaryo noktası olarak panel, internet olmasa da binanın çalışmasını sağlar. ### (b) Üreticinin gateway'i + mobil uygulaması (bulut) Üretici bir gateway cihazı verir, kullanıcı üreticinin uygulamasını indirir, bağlantı üreticinin sunucusu üzerinden eşleşir. Kurulumu en kolay, kullanıcı deneyimi en cilalı seçenektir. Bedeli şudur: **sistemin uzaktan erişimi artık bir şirketin hesabına ve hizmet ömrüne bağlıdır.** Hesap kimin adına açıldıysa erişim onundur — bu, projeyi teslim alan şirketin İK'sına bağlı bir güvenlik sorunu yaratır. Üretici hizmeti sonlandırırsa veya modeli destekten düşürürse, bus çalışmaya devam eder ama uygulama çalışmaz. **Nerede doğru:** konut ve küçük ofis; kurumsal yapıda ancak yetki devri yazılı olarak çözülmüşse. ### (c) Yerel görselleştirme sunucusu Tesis içinde çalışan bir sunucu/gömülü cihaz arayüzü üretir; kullanıcılar ona bağlanır, dışarıdan erişim VPN üzerinden verilir. Bulut bağımlılığı yoktur, yetkilendirme kurumun elindedir, log kurumda kalır. Karşılığında bakımı, yedeği ve güncellemesi kurumun işidir. **Nerede doğru:** ofis, otel, kampüs, kamu — kısacası erişimi bir kurumun yönetmesi gereken her yer. ### Kaçırılan asıl nokta: KNX'in en güçlü yanı buluta bağımlı olmamasıdır KNX'in kurumsal gerekçesi, merkezî bir beyne ve bir hizmet aboneliğine bağlı olmamasıdır: cihazlar mantığı kendi üzerlerinde taşır, bir cihaz düşse de kalanı çalışır, internet kesilse bina çalışır. [Tüketici ekosistemleriyle farkı da tam olarak buradadır.](https://colgabilisim.com/rehber/knx-mi-google-home-alexa-mi-akilli-bina-secimi/) Görselleştirmenin tamamı buluta verildiğinde bu avantaj kâğıt üzerinde durur ama pratikte iptal olur: kullanıcı binayı yalnızca uygulamadan yönetiyorsa, uygulamanın çalışmadığı gün bina "bozulmuş" sayılır. Bu yüzden doğru kurgu **katmanlıdır**: temel işlevler (aydınlatma, jaluzi, sıcaklık) her zaman fiziksel butonla ve bus üstü panelle çalışır; uygulama bunun *üstüne* gelen bir kolaylıktır, yerine geçen bir bağımlılık değil. ## Karar 3 — Uzaktan erişim yolu Bu, KNX'e özgü bir soru değildir; kamera tarafındaki tartışmanın aynısıdır ve cevabı da aynı yöndedir. Yöntem Ne yapar Nerede doğru **Port açma (UDP 3671)** KNXnet/IP'yi doğrudan internete koyar **Hiçbir yerde** **Üretici bulutu** Gateway dışarıya doğru bağlanır, üreticinin sunucusunda eşleşir Konut, küçük ofis; iki kademeli doğrulama zorunlu **VPN** Kullanıcıyı tesis ağının içine alır; KNX internete hiç çıkmaz Kurumsal varsayılan ### Port açmak neden bir seçenek bile değil? Klasik KNXnet/IP **kimlik doğrulamasız** tasarlanmıştır; güvenliği, "bu ağa zaten yalnızca yetkili kişiler girebilir" varsayımına dayanır. O portu internete açtığınız anda varsayım çöker: bağlanabilen herkes grup adreslerine yazabilir. Üstelik bu, okunamayan bir saldırı da değildir — bir telegram yakalayan, aynı grup adresine kendi komutunu yazabilir. İnternete açık kalmış bina otomasyonu geçitlerinin tarama motorlarında listelenebilmesi bilinen bir durumdur; bu yüzden "nasılsa kimse bilmez" yaklaşımı geçersizdir. Ayrıca Türkiye'de pratik bir engel daha vardır: **CGNAT** nedeniyle pek çok hatta port yönlendirme zaten çalışmaz. Statik IP bunu mümkün kılar, doğru kılmaz. ### VPN nasıl kurgulanır? 1. Uzak kullanıcı güvenlik duvarında **VPN ile sonlandırılır**; her kullanıcının kendi hesabı olur. 2. VPN kullanıcısı KNX'in bulunduğu ağa değil, **yalnızca görselleştirme sunucusuna / IP interface'e** erişecek şekilde kısıtlanır. 3. ETS ile programlama erişimi ayrı bir yetkidir — kullanıcıya verilmez, servis hesabına verilir. 4. Personel ayrıldığında kapatılan tek şey VPN hesabıdır; sistemin geri kalanına dokunulmaz. ## Ağ tarafı: KNX IP'yi ağa koymak bir network kararıdır IP router kullanıldığı anda KNX, bina ağının bir kiracısı olur ve ağ tarafında iki konu doğar. **Multicast.** KNX IP routing multicast (224.0.23.12) ile çalışır. Kurumsal anahtarlarda **IGMP snooping** düzgün yapılandırılmamışsa iki uçtan biri olur: ya multicast tüm portlara taşar ve gereksiz trafik yayılır, ya da snooping bir sorgulayıcı (querier) olmadan trafiği filtreler ve **hatlar birbirini hiç görmez** — sahada "KNX çalışmıyor" diye bildirilen arızaların bir bölümü budur. Aynı ağda birden çok bağımsız KNX kurulumu varsa her birine **farklı multicast adresi** verilir. **Segmentasyon.** KNX cihazları misafir ağıyla, kamera ağıyla ve kullanıcı ağıyla aynı yayın alanında durmamalıdır. Doğru kurgu, KNX IP trafiğini [ayrı bir VLAN'a almaktır](https://colgabilisim.com/rehber/vlan-nedir-nasil-yapilandirilir-ag-segmentasyonu/); o VLAN'a kimin gireceği güvenlik duvarında yazılır. Bu, kamera ağını ayırmakla aynı disiplindir ve aynı anda planlanmalıdır. Pratik sonuç: KNX'in IP omurgaya taşınması kararı **elektrik projesinde alınır ama ağ projesinde uygulanır.** İki taraf konuşmuyorsa, devreye alma günü multicast tartışmasıyla geçer. ## KNX Secure: iki ayrı katman, iki ayrı iş "KNX Secure" tek bir özellik değildir. İki bağımsız mekanizma vardır ve birbirinin yerine geçmezler. **KNX IP Secure** **KNX Data Secure** Neyi korur KNXnet/IP trafiği (tunnelling + routing) Grup telegramının kendisi, uçtan uca Hangi katman IP ağı Bus (TP, RF veya IP fark etmez) Neye karşı IP ağını dinleyen / oraya sızan Bus'a fiziksel erişen, telegram tekrarlayan Gerekli donanım Secure özellikli IP router/interface Secure özellikli **her** cihaz **IP Secure**, bina ağını dinleyebilen birinin KNX omurga trafiğini okumasını ve sahte telegram üretmesini engeller. **Data Secure** ise kapsamı cihaza kadar götürür: telegram, kaynağından hedefine kadar şifreli ve kimlikli taşınır — bus kablosuna dışarıdan erişilebilen yapılarda (ortak alan, dış cephe, otopark) asıl koruma budur. ### Uygulamada ne anlama gelir? - Secure cihazlar, kutusunun/etiketinin üzerinde yazan **FDSK** (fabrika anahtarı) ile ETS'e tanıtılır. Bu anahtar cihazla birlikte gelir ve **kaybedilirse cihaz fabrika ayarlarına döndürülmeden yeniden devreye alınamaz.** - ETS, Secure kullanılan projede bir **proje sertifikası** üretir. O sertifika ve parolası olmadan projeye başka kimse — sizin bir sonraki yükleniciniz dâhil — müdahale edemez. - Bu yüzden Secure bir *güvenlik kararı* olduğu kadar bir **teslim kararıdır**: [devreye alma ve teslim dosyası rehberimizde](https://colgabilisim.com/rehber/knx-devreye-alma-ets-programlama-sureci/) saydığımız `.knxproj` + parola + proje sertifikası üçlüsü, Secure kullanıldığında pazarlık konusu olmaktan çıkar. Secure zorunlu değildir. Ama **IP üzerinden uzaktan erişim veriliyorsa**, en azından IP Secure kullanılmaması bilinçli bir risk kabulüdür ve öyle yazılmalıdır. ## Merkezî izleme mi isteniyor, uzaktan kontrol mü? Bu iki talep sahada aynı cümleyle gelir ama farklı sistemleri işaret eder. "Telefondan ışığı açmak" uzaktan kontroldür; "kaç kW harcıyoruz, hangi cihaz arızalı, geçen ay hangi saatte ne çalıştı" sorusu **izleme ve raporlamadır** ve KNX'in görselleştirme katmanı bunu ancak sınırlı yapar. İşveren ikinci grubu istiyorsa, doğru tartışma uzaktan erişim tartışması değil [KNX–BMS sınırı tartışmasıdır](https://colgabilisim.com/rehber/knx-bms-bina-otomasyon-sistemi-farki/): alarm yönetimi, trend kaydı ve raporlama BMS'in işidir. Bunu baştan ayırmak, sonradan "uygulama neden rapor vermiyor" sorusunu ortadan kaldırır. ## Sık yapılan altı hata 1. **Uzaktan erişimi devreye alma gününde konuşmak.** IP router mı interface mi sorusu hat sayısına bağlıdır; hat sayısı ise kablolama aşamasında kesinleşir. Sonradan cihaz eklemek pano yeri ister. 2. **Port açmak.** En hızlı çözüm, en kalıcı açık. Üstelik CGNAT yüzünden çoğu hatta çalışmaz bile. 3. **Görselleştirmeyi tek bağımlılık hâline getirmek.** Fiziksel buton ve bus üstü panel her projede kalmalıdır; uygulama üstüne gelen katmandır. 4. **Bulut hesabını kurulumcunun e-postasıyla açmak.** Hesabın kurumda olmaması, teslim edilmemiş bir sistem demektir. Devri teslim tutanağına yazılır. 5. **Multicast'i ağ ekibine hiç söylememek.** IGMP snooping ve VLAN ayarları yapılmadan IP omurga çalışmaz ya da tüm ağı gereksiz yere meşgul eder. 6. **Secure'u açıp sertifikayı saklamamak.** Proje sertifikası kaybolursa yeni yüklenici projeye giremez; çözüm cihazları fabrika ayarına döndürüp baştan devreye almaktır. ## Teslim öncesi kontrol listesi - [ ] IP interface / IP router seçimi hat sayısına göre gerekçelendirildi mi? - [ ] Kaç eşzamanlı tünel bağlantısı gerektiği belirlendi ve cihaz ona göre seçildi mi? - [ ] KNX IP trafiği ayrı bir VLAN'da mı? Multicast adresi kayıt altına alındı mı? - [ ] IGMP snooping / querier yapılandırması ağ tarafında test edildi mi? - [ ] Uzaktan erişim VPN üzerinden mi veriliyor? Dışarıya açık port taramayla doğrulandı mı? - [ ] Her kullanıcının kendi hesabı var mı; ortak parola paylaşılmıyor mu? - [ ] ETS ile programlama yetkisi son kullanıcıdan ayrı tutuldu mu? - [ ] Bulut kullanılıyorsa hesap **kurum adına** mı açıldı; iki kademeli doğrulama açık mı? - [ ] İnternet kesildiğinde aydınlatma, jaluzi ve ısıtma yerelden çalışıyor mu? (Fiilen test edildi mi?) - [ ] `.knxproj` dosyası, parolası ve (Secure varsa) proje sertifikası + FDSK kayıtları teslim edildi mi? ## Şartnameye yazılacak maddeler - *"KNX hatlarının IP omurga üzerinden bağlanması hâlinde her hatta KNX IP router kullanılacak; filtre tabloları yüklenecek ve multicast adresi projede belirtilecektir."* - *"KNX IP cihazları ayrı bir VLAN'da konumlandırılacak; bu VLAN'a erişim güvenlik duvarında kaynak bazlı kısıtlanacaktır."* - *"Uzaktan erişim yalnızca VPN üzerinden sağlanacaktır. KNXnet/IP portu (UDP 3671) hiçbir koşulda internete yönlendirilmeyecektir; kabulde dışarıdan port taraması yapılarak tutanağa geçirilecektir."* - *"IP üzerinden erişim verilen kurulumlarda KNX IP Secure etkinleştirilecektir."* - *"Bulut tabanlı uygulama kullanılacaksa hesap idare adına açılacak, iki kademeli doğrulama etkin olacak ve hesap bilgileri teslim dosyasına eklenecektir."* - *"En az bir bus üstü dokunmatik panel ve tüm mahallerde fiziksel buton kontrolü bulunacak; internet veya bulut hizmeti kesildiğinde temel işlevlerin çalıştığı kabul testiyle gösterilecektir."* - *"ETS proje dosyası, parolası ve KNX Secure kullanılmışsa proje sertifikası ile FDSK kayıtları idareye teslim edilecektir."* ## Sık sorulan sorular **KNX'i telefondan kontrol etmek için internet şart mı?** Hayır. Aynı ağdayken (tesis içi WiFi) uygulama doğrudan yerel gateway'e bağlanır; internet yalnızca *tesis dışından* erişim için gerekir. Bu ayrımı yapmak önemlidir: çoğu kullanıcının asıl ihtiyacı bina içindeki kullanımdır ve o, dışarıya hiçbir kapı açmadan çözülür. **IP router ile IP interface arasındaki farkı basitçe nasıl anlarım?** Interface bir **kapıdır** — bus'a bağlanmanızı sağlar. Router bir **köprüdür** — iki KNX hattını IP üzerinden birbirine bağlar ve ayrıca kapı görevi de görür. Tek hat varsa köprüye gerek yoktur. **Üreticinin bulut uygulaması güvensiz mi?** Güvensiz değil, **bağımlı**. Ciddi üreticilerin altyapısı port açmaktan kat kat güvenlidir. Sorulacak soru şudur: hesap kimin adına, erişim personel ayrıldığında nasıl kapanıyor, üretici hizmeti sonlandırırsa bina nasıl çalışmaya devam ediyor? Bu üç sorunun yazılı cevabı varsa bulut makul bir seçimdir. **KNX Secure kullanmak maliyeti çok artırır mı?** Donanım tarafında Secure özellikli cihazlar bir miktar farklıdır; asıl fark **iş gücündedir** — anahtar yönetimi ve dokümantasyon devreye alma süresini uzatır. IP üzerinden dışarıya erişim veriliyorsa bu fark, alınan riskin karşısında küçük kalır. **Mevcut KNX kurulumumuza uzaktan erişim sonradan eklenebilir mi?** Genellikle evet. Panoda ray yeri ve bus hattına erişim varsa bir IP interface/router eklemek sınırlı bir iştir; asıl iş ağ tarafındadır (VLAN, güvenlik duvarı, VPN). Data Secure ise sonradan eklenemez — cihazların kendisi Secure destekliyor olmalıdır. **Sesli asistanla (Google/Alexa) kontrol KNX'e zarar verir mi?** Zarar vermez ama bir bulut bağımlılığı daha ekler ve çoğu kurulumda üreticinin gateway'i üzerinden geçer. Konutta makul, kurumsal yapıda gereksiz bir saldırı yüzeyidir. [KNX ile tüketici ekosistemlerinin karşılaştırmasını ayrı bir rehberde ele aldık.](https://colgabilisim.com/rehber/knx-mi-google-home-alexa-mi-akilli-bina-secimi/) ## Özet - "KNX'i telefondan kontrol etmek" üç ayrı karardır: **IP'ye çıkış cihazı**, **görselleştirme katmanı** ve **uzaktan erişim yolu**. Üçü ayrı ayrı verilmelidir. - **IP interface** bir erişim kapısıdır (tek hat); **IP router** hatları IP omurga üzerinden bağlar (çok hat). Seçim hat sayısından çıkar, tercihten değil. - KNXnet/IP **UDP 3671**'i kullanır, routing ise **multicast 224.0.23.12** ile çalışır — bu yüzden ağ tarafında **IGMP snooping ve VLAN** ayarları tasarımın parçasıdır. - **Port açmak bir yöntem değildir:** klasik KNXnet/IP kimlik doğrulamasızdır; CGNAT nedeniyle zaten çoğu hatta çalışmaz. Kurumsal varsayılan **VPN**'dir. - Görselleştirmede asıl soru görsel kalite değil **bağımlılık ve ömürdür**. Bulut kolaydır ama erişimi bir şirketin hesabına bağlar; temel işlevler her zaman **fiziksel buton + bus üstü panelle** çalışmalıdır. - **KNX IP Secure** IP trafiğini, **KNX Data Secure** telegramı uçtan uca korur; ikisi birbirinin yerine geçmez. Secure aynı zamanda bir teslim kararıdır — **proje sertifikası ve FDSK kayıtları** olmadan sisteme bir sonraki yüklenici giremez. - Bant genişliği KNX'te sorun değildir (bus 9 600 bit/s); risk **yetki ve süreklilik** başlıklarındadır. - Kabulün ölçülebilir maddesi ikilidir: **dışarıdan port taraması** ve **internet kesildiğinde binanın çalıştığının gösterilmesi**. İzmir ve Ege Bölgesi'nde KNX kurulumlarını yalnızca bus tarafıyla değil, bağlanacağı ağla birlikte tasarlıyoruz: IP omurga kararı, VLAN ayrımı, VPN sonlandırması ve KNX Secure ile teslim dosyası aynı projenin parçası olarak ele alınır. [İzmir KNX akıllı bina sistemleri hizmetimize](https://colgabilisim.com/izmir-knx-akilli-bina-sistemleri) göz atabilir, [iletişim sayfamızdan](https://colgabilisim.com/iletisim) bize ulaşabilirsiniz. ### Bu konuda yardım mı lazım? İzmir ve Ege Bölgesi'nde keşif, projelendirme ve kurulum için bize ulaşın. [Teklif al](https://colgabilisim.com/iletisim) İlgili rehberler 1. [KNX ile fancoil ve klima kontrolü: hangi aktüatör gerekir?](https://colgabilisim.com/rehber/knx-ile-fancoil-klima-kontrolu-aktuator-secimi/) 2. [Mevcut binaya KNX kurulabilir mi? Retrofit yöntemleri](https://colgabilisim.com/rehber/mevcut-binaya-knx-kurulabilir-mi-retrofit-knx-rf/) 3. [KNX bus kablolama: hangi kablo, kaç metre, kaç güç kaynağı?](https://colgabilisim.com/rehber/knx-bus-kablolama-kablo-mesafe-guc-kaynagi/)