[KNX] - Huis en Gebouwautomatisering / Domotica

[teaser]

bartvb schreef op maandag 16 januari 2017 @ 09:23:
Mijn plan is dan ook om alle logica/schakelwerk via de Loxone te laten lopen. De KNX componenten praten niet met elkaar maar puur en alleen met de miniserver. Op die manier kan je gewoon Ekinex schakelaars gebruiken en MDT relays (voor dezelfde prijzen) en heb je wel het makkelijk kunnen schakelen/combineren/visualiseren van de Loxone.

Overigens deel ik jullie zorgen wat betreft de richting die Loxone op lijkt te gaan. Aan de andere kant verwacht ik voor mijn gebruik geen grote problemen en stel dat Loxone echt rare dingen doet dan trek je die uit het systeem en vervang je de Loxone door een Loxone clone, PLC, KNX logic module of iets compleet nieuws dat tegen die tijd op de markt is.

Dat laatste is voor mij best een belangrijke factor. Het hele domotica-verhaal staat nog steeds erg in de kinderschoenen. Er zijn niet heel vele nieuwbouwwoningen waarbij dit wordt toegepast, er is op dit moment wel erg veel aandacht voor. Nu nog vooral retrofit (Zwave, de meeste Homekit oplossingen, Hue) maar dat gaat ongetwijfeld ook komen voor nieuwbouwsystemen. Handig dus als je over 10, 15 of 20 jaar de mogelijkheid heb om makkelijk je systeem om te bouwen naar iets moderners.

Ik vind dit een bedenkelijke opzet. Zo haal je een groot voordeel van een KNX installatie onderuit: namelijk de betrouwbaarheid.
De toegevoegde waarde van de miniserver is dat je er makkelijke logica mee kan implementeren en een visualisatie er bovenop kan zetten. Dit zijn voor mij "extra's". De basisinstallatie, het schakelen van verlichting e.d., moet altijd werken en dus betrouwbaar zijn. Hiervoor zet ik dus KNX in. Wat ik er later bovenop zet voor de logica in visualisatie bekijk ik nog wel. Er zijn mogelijkheden genoeg, dus als Loxone niet betrouwbaar zou zijn in combinatie met KNX dan sluit ik dat gewoon uit als optie en kies ik een alternatief. Ingrijpen in de basisinstallatie om de extra's te verwezenlijken is voor mij gewoon geen optie.

HyperBart schreef op maandag 16 januari 2017 @ 10:21:
Ik moet het LED verhaal nog even afwachten maar het komt hier ooit wel, ik ben nu al verslingerd aan deep dimming van de halogeens tijdens TV kijken, ik wil er niet op achteruit gaan maar dat verbruik wel terugdringen

Ik zit gewoon nog niet in die fase van afwerking/inrichting dat er overal al definitieve armaturen hangen. Daarom op veel plaatsen nog peertjes of halogeen GU10 spotjes die uit het plafond hangen.

Net gezien dat je van Antwerpen bent, Belg dus .

Yep, ook van in de buurt?

[tss68nl]

teaser schreef op maandag 16 januari 2017 @ 07:41:
Hoe doe je die sleepmode dan precies? Ik heb dat ook nog nodig.

Haha, dat heb ik hem ook al gevraagd, ben ook benieuwd hoe hij de statussen doorgeeft. Bart: tip van de dag: kijk eens in die Ekinexen van je, onder het kopje 'Logic functions'

That's right....8 logische modules met OR/AND/XOR, en 4 input kanalen per logisch blok Met dik 10+ van die dingen in huis, kan je aardig wat logica laten afhandelen

[bartvb]

teaser schreef op maandag 16 januari 2017 @ 11:02:
[...]

Ingrijpen in de basisinstallatie om de extra's te verwezenlijken is voor mij gewoon geen optie.

Zoveel mensen, zoveel wensen... Ik vind gemak en flexibiliteit van een centrale installatie belangrijker dan de extra betrouwbaarheid. Sowieso vind ik die betrouwbaarheid vrij relatief. Als je in een standaard KNX installatie een probleem krijgt met de bus (kortsluiting b.v.) dan ligt je hele systeem plat. Wat dat betreft is een Loxone/PLC achtige constructie weer betrouwbaarder.

Daarnaast lijkt het erop dat die Miniservers erg stabiel zijn. Ik zit er wel aan te denken om een soort 'nood' stand te maken voor in ieder geval de verlichting. Maar moet nog uitzoeken hoe en wat precies. Iig iets in combinatie met een UPS en de (DMX) LED drivers.

Ik snap heel goed waarom je voor de puur KNX oplossing zou gaan, ik heb echter het idee dat in mijn specifieke situatie, met mijn voorkeuren/prioriteiten een centraal systeem handiger werkt. Daarbij ga ik er tot nu toe wel vanuit dat de koppeling van Loxone met KNX als extra inputs/outputs gewoon goed werkt?

[bomberboy]

bartvb schreef op maandag 16 januari 2017 @ 12:13:
[...]
Ik snap heel goed waarom je voor de puur KNX oplossing zou gaan, ik heb echter het idee dat in mijn specifieke situatie, met mijn voorkeuren/prioriteiten een centraal systeem handiger werkt. Daarbij ga ik er tot nu toe wel vanuit dat de koppeling van Loxone met KNX als extra inputs/outputs gewoon goed werkt?

Ik heb even gezocht, maar kon het niet direct terug vinden.
Waarom dan wel een centrale loxone miniserver, maar niet iets als een gira homeserver of logic machine ofzo waarmee je ook gelijkaardige zaken kan doen? (Oprechte vraag, ik wil je niet overtuigen van iets anders )

[HyperBart]

tss68nl schreef op maandag 16 januari 2017 @ 11:24:
[...]


Haha, dat heb ik hem ook al gevraagd, ben ook benieuwd hoe hij de statussen doorgeeft. Bart: tip van de dag: kijk eens in die Ekinexen van je, onder het kopje 'Logic functions'

That's right....8 logische modules met OR/AND/XOR, en 4 input kanalen per logisch blok Met dik 10+ van die dingen in huis, kan je aardig wat logica laten afhandelen

Ik ben van plan iets in het volgende te doen:


Bv:

1/0/1 als input op een logische module OR
1/0/1 is "NACHTMODE INPUT"

1/1/1 als output op de logische module hierboven beschreven NACHTMODE OUTPUT


De PD11 bewegingsdetectie naar 1/0/2 BEWEGING

Op een andere logische module AND volgende inputs

1/0/2 BEWEGING
1/1/1 NACHTMODE OUTPUT

Als beide op 1 staan dan stuurt de logische module een scene value uit die lampen gedimd aan doet.

Misschien mis ik iets maar volgens mij moet dit prima mogelijk zijn .

[ Voor 4% gewijzigd door HyperBart op 16-01-2017 13:34 ]

[bartvb]

Gira homeserver is nog (voor zover ik weet) nog meer gesloten dan Loxone en wel heel erg aan de prijs.
Logicmachine is op zich een interessante optie. Is ook duurder dan een Miniserver (maar niet super veel), nog niet heel goed naar gekeken.

Maar terechte vraag. Het belangrijkste bij mijn toekomstige installatie is dat (vrijwel) alles via een ster wordt aangelegd. Daarna is hoe je alles aan elkaar plakt op zich secunair. Dat kan via een Loxone miniserver maar ook via KNX componenten, KNX met een logic module, PLC, RPi, etc. Ik ben een paar jaar terug (2012 oid) bij Loxone terecht gekomen. Inmiddels ziet de markt er weer anders uit (o.a. Loxone lijkt zich op een niet heel fijne manier te ontwikkelen). Ook heb ik nu wat meer zicht op de KNX wereld en heeft MDT ook een hoop gedaan om KNX echt wel een interessante optie te maken.

Groot voordeel van Loxone is dat het relatief open is. DMX, TCP en UCP inputs/outputs, KNX, 1-wire, etc. Daarnaast gebruik je behoorlijk 'domme' componenten wat de kosten laag houdt. Een deurcontact hoeft geen KNX te praten maar is gewoon een reed contact aangesloten op een digitale input. Een bewegingsdetector kost daardoor geen 150 euro maar 40 (inclusief input), temperatuursensors koppel je via 1-wire, etc.

Naast kosten is een ander voordeel van die 'domme' componenten dat ze erg makkelijk te integreren zijn in een nieuw systeem. Een bewegingsmelder die je aansluit op een potentiaalvrij contact kan je vrijwel altijd koppelen, een KNX sensor zal je via een bridge aan je nieuwe systeem moeten hangen of vervangen.

Ook zorgt de miniserver voor erg gemakkelijke configuratie en visualisatie. Dat kan voor een deel ook met b.v. een home-server, maar je houdt twee systemen. Je basis logica stop je in de componenten (schakelaar A bedient DMX actor B en C) met ETS en echte intelligentie stop je in je logic module. Dat lijkt allemaal een stuk complexer dan een simpel centraal systeem als de miniserver. Maar voor een deel is het bij mij dus ook een gebrek aan kennis/inzicht in de mogelijkheden van KNX om tot een echt slim systeem te komen.

Maar future-proofing (domme componenten) is voor mij best een belangrijk aspect. Grote kans dat de domiticamarkt (en mogelijkheden) er over 10 jaar echt heel anders uit ziet. Kijk alleen al naar de opkomst van de voice assistants van de afgelopen 2 jaar.

[ Voor 22% gewijzigd door bartvb op 16-01-2017 13:42 ]

[tss68nl]

bomberboy schreef op maandag 16 januari 2017 @ 12:46:
Ik heb even gezocht, maar kon het niet direct terug vinden.
Waarom dan wel een centrale loxone miniserver, maar niet iets als een gira homeserver of logic machine ofzo waarmee je ook gelijkaardige zaken kan doen? (Oprechte vraag, ik wil je niet overtuigen van iets anders )

Goede toevoeging! We zeggen het er niet altijd bij...maar dat sommige mensen (mezelf inclusief) klinken als een langspeelplaat met een kras op sommige onderwerpen wil niet zeggen dat we niet open staan voor andermans mening of dat niet kunnen begrijpen.

Ik vind het juist altijd leuk om te horen hoe andere mensen het aanpakken. Als ik anderen moet adviseren, dan ben ik heel stellig, en ik zou zelf de twee nooit mixen omdat er gewoon een aantal dingen mis gaan. Maar aan de andere kant vind ik het mooi dat je de twee combineert, en eigenlijk heel benieuwd naar het resultaat.

bartvb schreef op maandag 16 januari 2017 @ 12:13:
Zoveel mensen, zoveel wensen... Ik vind gemak en flexibiliteit van een centrale installatie belangrijker dan de extra betrouwbaarheid.

Spijker op z'n kop wat betreft de wensen. Als je gemak van programmeren belangrijker vind dan de betrouwbaarheid, dan ziet de wereld er ineens heel anders uit

Sowieso vind ik die betrouwbaarheid vrij relatief. Als je in een standaard KNX installatie een probleem krijgt met de bus (kortsluiting b.v.) dan ligt je hele systeem plat. Wat dat betreft is een Loxone/PLC achtige constructie weer betrouwbaarder.

Tjah, alles is relatief. Als er een bom valt op je huis werkt geen enkel systeem meer Maar krijg je kortsluiting in een Loxone bus dan werkt er ook niets meer, dus ik zie niet in hoe Loxone daarin betrouwbaarder is?
Krijg je echter een kabelbreuk in je bus.... dan werkt er bij Loxone ook niets meer, maar met KNX blijven afzonderlijke units gewoon met elkaar praten. Ik kan mijn halve 230V systeem spanningsloos maken, inclusief KNX/IP router, logische modules...qua aansturing werkt er dus niets meer, maar de busspanning zorgt dat alle knoppen en actoren nog steeds alles besturen. Valt de busspanning weg? Dan zit er een NC relais in de garage, waar een backup powersupply op aan zit gesloten....en die neemt de boel automatisch over.

Wat betreft logica programmeren....Gira heeft ook de L1 en X1.... din-rail variant van de G1 eigenlijk, en de X1 heeft ook een L1 ingebouwd. Programmeert ook best makkelijk complexe logica, met als voordeel dat je de basis gewoon in KNX kan laten. Ik vind het bijna zonde om allemaal kleine computertjes aan de muur te kopen, en ze dan alleen als domme 0/1 schakelaar te gebruiken.

Wel hebben de G1/L1/X1 allemaal een beperking op 160 GA's.... wat ik wat krap vind. Aan de andere kant...de basisfunctionaliteit hoeft er niet in, dus die GA's importeer je ook niet.

[tss68nl]

HyperBart schreef op maandag 16 januari 2017 @ 13:32:
[...]


Ik ben van plan iets in het volgende te doen:


Bv:

1/0/1 als input op een logische module OR
1/0/1 is "NACHTMODE INPUT"

1/1/1 als output op de logische module hierboven beschreven NACHTMODE OUTPUT


De PD11 bewegingsdetectie naar 1/0/2 BEWEGING

Op een andere logische module AND volgende inputs

1/0/2 BEWEGING
1/1/1 NACHTMODE OUTPUT

Als beide op 1 staan dan stuurt de logische module een scene value uit die lampen gedimd aan doet.

Misschien mis ik iets maar volgens mij moet dit prima mogelijk zijn .

Wat komt er op die eerste 1/0/1 binnen dan? Schakelaar aan/uit? Die schakelaar pak je dan negative, en als hij aangaat cancelt hij de nachtmode? Schakel je hem weer uit, dan gaat de nachtmode automatisch weer aan?

Ik denk dat je alleen vast komt te zitten met het verzenden van een scene? Meeste logic modules kunnen 0/1 uitgeven. Dan zal je dus verschillende kanalen gevoelig moeten maken voor scene 0 en 1? Of zie ik dat verkeerd?
Het klopt wel dat de MDT binary input scenes kan verzenden als logic output. Maar je kan maar twee externe logic waarden aannemen, hij is eigenlijk bedoeld als logic module over de binary inputs van het apparaat zelf

[bartvb]

tss68nl schreef op maandag 16 januari 2017 @ 13:44:
[...]

ik zou zelf de twee nooit mixen omdat er gewoon een aantal dingen mis gaan. Maar aan de andere kant vind ik het mooi dat je de twee combineert, en eigenlijk heel benieuwd naar het resultaat.

In een installatie waarin KNX leidend is snap ik dat helemaal. De miniserver heeft geen idee wat de status is van de individuele KNX componenten omdat deze elkaar aansturen. Het hele principe achter de miniserver (alle logica op een plaats) valt dan weg wat idd gegarandeerd problemen geeft.

Maar zijn er los daarvan nog andere problemen? Zoals ik het zie kan je prima een MDT AKS/AKI naast je miniserver hangen zolang je maar zorgt dat alleen de miniserver de MDT aanstuurt. Zelfde met een Ekinex taster, die praat puur en alleen met de miniserver, de miniserver zorgt vervolgens dat de juiste DMX instellingen worden gedaan of schakelt de MDT AKS.

Op die manier gebruik je een heel groot deel van de functionaliteit/voordelen van KNX niet (het decentraal werken) maar je zorgt wel dat je Loxone installatie mooie/functionele tasters heeft en betaalbare verbruiksmeters/outputs.

Tjah, alles is relatief. Als er een bom valt op je huis werkt geen enkel systeem meer Maar krijg je kortsluiting in een Loxone bus dan werkt er ook niets meer, dus ik zie niet in hoe Loxone daarin betrouwbaarder is?

Klopt, maar dan heb je het over Loxone Tree. Dat vind ik een prutsoplossing Als je een bus wil gebruiken gebruik dan KNX.

Ik heb het over een 'klassieke' Loxone installatie. Een deurcontact of bewegingsmelder gaat via een eigen kabel naar je schakelruimte. Een LED driver heeft een eigen kabel naar de LEDs. Als je dan kortsluiting of kabelbreuk hebt (maar geen idee hoe dat zou kunnen gebeuren als je niet aan het (ver)bouwen bent) dan is er maar 1 component dat uitvalt ipv alles dat aan de bus hangt.

In the end hebben beide systemen in mijn ogen een single point of failure. Bij Loxone is dat de miniserver (maar kleine kans dat die ontploft ofzo), bij KNX is dat de bus (maar kleine kans dat je daar kortsluiting krijgt).

Maar het is vooral zo dat ik best een beetje (gepercipieerde) betrouwbaarheid op wil geven voor meer flexibiliteit of lagere kosten. Als het om een ziekenhuis of kantoor zou gaan dan zou de afweging anders zijn. Hoewel je bij een kantoor ook gewoon een miniserver op voorraad kan houden

Ander ding waarom ik op dit moment de voorkeur heb voor Loxone is dat je daar niet afhankelijk bent van de functionaliteit die de componentenleverancier heeft ingebouwd. De logica zit in de miniserver en is behoorlijk uitgebreid. Als je wil kan je ook eigen functies bouwen in PicoC. Bij KNX heb je pech als een actor net niet doet wat jij zou willen. Of als twee componenten net anders denken over een functie. Dat vergt veel meer ervaring en planning (lijkt mij). Aan de andere kant; geen idee hoe reeel dat probleem is. Zal ook sterk afhangen van de gewenste functionaliteit.

[teaser]

bartvb schreef op maandag 16 januari 2017 @ 14:11:
Op die manier gebruik je een heel groot deel van de functionaliteit/voordelen van KNX niet (het decentraal werken) maar je zorgt wel dat je Loxone installatie mooie/functionele tasters heeft en betaalbare verbruiksmeters/outputs.

Grappig dat je hier een grote misvatting van KNX, dat het duur is, onderuithaalt terwijl er gisteren in ditzelfde topic diezelfde misvatting nog werd aangehaald

Zoveel mensen, zoveel wensen

Volledig mee eens uiteraard. Maar net zoals tss68nl adviseer ik anderen naar mijn eigen overtuiging, wat dan niet wil zeggen dat een ander niet zijn eigen ding mag doen. Het klinkt bijna religieus maar we staan hier uiteraard wel open voor andere meningen (waarom zou je anders erover gaan discussieren op een forum).

Ik heb het over een 'klassieke' Loxone installatie. Een deurcontact of bewegingsmelder gaat via een eigen kabel naar je schakelruimte. Een LED driver heeft een eigen kabel naar de LEDs. Als je dan kortsluiting of kabelbreuk hebt (maar geen idee hoe dat zou kunnen gebeuren als je niet aan het (ver)bouwen bent) dan is er maar 1 component dat uitvalt ipv alles dat aan de bus hangt.

Ik zie nu ook niet direct hoe je een kortsluiting van de bus kunt hebben zonder dat je aan het verbouwen bent. Ik heb het 1 keer voorgehad, toen ik een reservelijn aansloot op de bus die langs het andere uiteinde gewoon was afgeknipt. Door het afknippen raakten de 2 draden mekaar daar, dus kortsluiting.
Als je je verbindingen overal proper en 'volgens de regels van de kunst' maakt, kun je volgens mij niets voorhebben.

[HyperBart]

tss68nl schreef op maandag 16 januari 2017 @ 14:01:
[...]


Wat komt er op die eerste 1/0/1 binnen dan? Schakelaar aan/uit?

Inderdaad, schakelaar AAN/UIT, eventueel ook komende vanuit een scene die aangeroepen wordt: "SLAPEN".

Die schakelaar pak je dan negative, en als hij aangaat cancelt hij de nachtmode? Schakel je hem weer uit, dan gaat de nachtmode automatisch weer aan?

Omgekeerd: je drukt op een knop, en nacht mode wordt ge-enabled. Hoe ik slaap mode dan ga disablen ben ik ook nog niet uit, misschien als er beweging gedetecteerd wordt in de hal beneden

Ik denk dat je alleen vast komt te zitten met het verzenden van een scene? Meeste logic modules kunnen 0/1 uitgeven.

De MDT Binary input kan idd een scene uitsturen uit de logische output maar niks verhindert mij om alle voorgaande logicals te doen op een Ekinex ofzo en de laatste logical te maken met de MDT.

Dan zal je dus verschillende kanalen gevoelig moeten maken voor scene 0 en 1? Of zie ik dat verkeerd?
Het klopt wel dat de MDT binary input scenes kan verzenden als logic output. Maar je kan maar twee externe logic waarden aannemen, hij is eigenlijk bedoeld als logic module over de binary inputs van het apparaat zelf

[Rafael]

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Belgen hebben doorgaans monofase 40A dacht ik, en als je 3 x 20A hebt liggen ben je vandaag de dag al een flinke jongen of heb je wat interessantere plannen dan de doorsnee consument.

1x40A is de standaard in België (ben ook Belg ). Hoger wordt momenteel zelfs een beetje afgeraden door een eventuele extra belasting afhankelijk van je aansluitwaarde.

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Waarom niet? Ik heb hier na een dagje knutselen met een goede vriend van me het hele huis op HomeKit gehangen, rPI hangt niet op de bus maar praat via de IP interface die ik ook al had met de bus, werkt prima

Ik heb schrik dat ik daar te veel tijd in moet steken, plus ook een klein beetje twijfels bij de stabiliteit. Ik heb 0 ervaring met een rPI of Linux varianten. Hoewel ik met programmeren zelf wel redelijk overweg kan.

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Double tap kent een knop binnen KNX idd volgens mij niet, maar misschien weet tss68nl er wel eentje.

Loxone heeft verlichtingsblokken die je per ruimte gebruikt, waarbij een dubbelklik op éénder welke verlichtingsknop in die ruimte, alle lichtpunten in die ruimte uitschakelt. Leek me wel handig, daarom dat ik met die dubbelklik in m'n hoofd zit. Kan ook nog anders opgelost worden natuurlijk.

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Concreet: ik heb nu omwille van het tijdelijke karakter van mijn verlichting (halogeen peertjes) een AKK dimmer van MDT

Je hebt nu nog halogeen, maar in hoeverre kunnen de standaard dimmodules om met GU10 leds? Ik heb de discussie enkele pagina's terug doorgenomen (waarvan het besluit 'niet' was), maar Loxone bvb beweert dat hun dimmodule wel omkan met bepaalde GU10 led lampen (zie deze pagina). Onzin? Of een reden van hun iets duurdere dimmer? Of dezelfde resultaten ook wel te halen met een KNX dimmer, als je maar de juiste fabrikant vindt? Helemaal dimmen zoek ik niet, maar het lijkt mij in de toekomst wel leuk om een GU10 led tussen 50% en 100% te kunnen sturen?

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Bij de end-user, ook wel de decisionmaker genoemd hier in dit huis , merk ik dat de terugmelding van de LED's uitermate belangrijk is. Ik zie mijn echtgenote vaak naar de schakelaars kijken om deze te gebruiken als schematische voorstel van de lichtpunten op bv. de badkamer. Denk er nog eens goed over na voor je besluit om de LED's te laten vallen als je met Niko en flushmounted KNX binaire ingangen/inputmodules aan de slag gaat.

[...]

Als je al twee iPad's hebt rondslingeren is HomeKit echt wel een goed alternatief voor visualisatie. Zeker als je ze blijkbaar op overschot hebt. Voorzie ergens in je muur 230V op kijkhoogte, werk een adapter in de muur in, koop een beugel aan en je hebt een mooie visu tegen de muur. Oh ja, vergeet daar dan zeker ook geen UTP en KNX kabel naar datzelfde potje te leggen, dan kan je later alle richtingen uit daar

De iPads worden redelijk actief gebruikt, daarom de bedoeling om de visualisatie daarop te krijgen en niet ergens te monteren. Ook de reden dat de knoppen in living waarschijnlijk enkel kort gebruikt gaan worden bij het binnenkomen en verlaten, eens je in de zetel zit heb je wel een smartphone of tablet bij de hand.

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Voor het Ekinex verhaal verwijs ik je graag door naar Kinetic Automation:

[e-mail].

Laat je niet afschrikken door de under construction webpagina of het feit dat het in een woonhuis gevestigd is, het is een ZZP'er met een (on)gezonde passie voor KNX en elektronica

"We'll be back soon"... Maar opgeslagen om later te bekijken.

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Je bedoelt schakelpunten of echt dat je knoppen al opoffert daarvoor? Vergeet niet dat je short en long press hebt EN dat je misschien ook eens wat moet afstappen van het klassieke denken.

Je hebt zeker gelijk dat we van dat klassieke denken af moeten, maar dat is nog niet zo simpel, zeker omdat de woning nog gebouwd moet worden en we ook nog totaal geen idee hebben hoe er in geleefd gaat worden. Per zonwering (screen of rolluik nog te bekijken) ben ik waarschijnlijk al 2 knoppen kwijt, dus dat telt snel op. Langs de andere kant komt er ook een lichtsensor en temperatuursensor en zullen de rolluiken grotendeels automatisch worden. (Scheelt EPB punten, nog zo'n lollig ding)

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Ik had eerst ook een mechanisme uitgedacht om iedere knop een afzonderlijke lamp te laten schakelen. 2 maanden verder en de benedenverdieping is al bijna functioneel ingericht: de schakelaar waar ik het meeste endpoints mee moest bedienen heb ik ondertussen volledig functioneel ingericht met scenes:
Gezellig 1
Gezellig 2
Werken
Uit

Ik denk dat wij iets meer sferen zouden nodig hebben, maar ik vat de logica erachter. Als de aparte bediening ook mogelijk blijft met de visualisatie, hoeft niet elke lamp een aparte knop te hebben. Lampen instellen met de tablet, opslaan als sfeer die via de knop werkt en klaar, juist?

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Ben je in dat soort ruimtes niet beter af met presence detection met eventueel een manual override op een centralere plek? Trek gerust de kabels he, maar voorzie in de kelder zeker kabel aan het plafond voor melders.

[...]

Dan zet je daar toch één schakelaar of bedien je die ruimte met een bewegingsensor? Of je laat het esthetische in een "facility room" daar gewoon varen en zet er een mooie Niko in het zwart met een inputmodule onder?

In een kelder zou ik liever geen geld verspillen aan detectie. Dat is een (kille) opslagruimte waar je hooguit 10 minuten op een dag bent. Als ik dan toch al een binaire input module nodig heb voor de contacten in de ramen, kan ik er nog wel 1 bijkopen of eentje kopen met meer ingangen, en de standaard Niko Hydro drukknoppen er op plaatsen met SSV?

Idem voor het toilet, het is toch goedkoper om SSV te leggen en bij op de binaire ingang te plaatsen, dan zo'n kleine koppelaar achter de drukknop zelf weg te duwen? Of mis ik nog een nadeel? Het is nu niet dat ik op het toilet ooit die knop zou willen vervangen door een display of dergelijk, want dat is het enige nadeel dat ik zou zien?

Je begint dan wel wat kabels te mixen en misschien is het verstandig om gewoon beide te trekken naar die punten, maar functionele nadelen zie ik niet?

HyperBart schreef op zondag 15 januari 2017 @ 23:21:
Stel je voor dat je voor Loxone kiest en dat aan de hand hebt , dan heb je wel heel weinig keuze plots he? Alle gekheid op een stokje; dan is het op dat moment even kiezen. Wees blij dat je dan voor KNX gekozen hebt, kan je desnoods op een slaapkamer een schakelaar weghalen en op die plek zetten. Voor dat probleem heb ik één Ekinex op de plank liggen hier...

Als de Loxone miniserver sneuvelt en Loxone failliet is, kan ik door de sterbekabeling nog een andere fabrikant kiezen, maar mijn knopjes houden wel hetzelfde uiterlijk Het gaat alleen harder (financieel) 'pijn' doen, want alle extensies zijn dan ook ineens onbruikbaar.

[bomberboy]

bartvb schreef op maandag 16 januari 2017 @ 13:36:
Gira homeserver is nog (voor zover ik weet) nog meer gesloten dan Loxone en wel heel erg aan de prijs.
Logicmachine is op zich een interessante optie. Is ook duurder dan een Miniserver (maar niet super veel), nog niet heel goed naar gekeken.

Er zijn ook nog andere visualisaties beschikbaar die goedkoper zijn (startend vanaf 600EUR). Maar ik moet toegeven dat ik met geen enkele daarvan enige ervaring heb. De feedback over het programmeren van Loxone die ik tot nu al gehoord heb is inderdaad steeds positief.

Maar terechte vraag. Het belangrijkste bij mijn toekomstige installatie is dat (vrijwel) alles via een ster wordt aangelegd.
...

Je kan KNX ook perfect in een ster topologie steken hoor

Groot voordeel van Loxone is dat het relatief open is. DMX, TCP en UCP inputs/outputs, KNX, 1-wire, etc. Daarnaast gebruik je behoorlijk 'domme' componenten wat de kosten laag houdt. Een deurcontact hoeft geen KNX te praten maar is gewoon een reed contact aangesloten op een digitale input. Een bewegingsdetector kost daardoor geen 150 euro maar 40 (inclusief input), temperatuursensors koppel je via 1-wire, etc.

Reken in dat verhaal ook zeker de kost van zo'n input van je Loxone module mee. Want dan loopt het ook best op. Voor KNX zijn er bovendien ook wel universele input modules die je kan gebruiken, maar ik denk dat deze twee punten al een paar keer gemeld zijn

Ook zorgt de miniserver voor erg gemakkelijke configuratie en visualisatie. Dat kan voor een deel ook met b.v. een home-server, maar je houdt twee systemen. Je basis logica stop je in de componenten (schakelaar A bedient DMX actor B en C) met ETS en echte intelligentie stop je in je logic module. Dat lijkt allemaal een stuk complexer dan een simpel centraal systeem als de miniserver. Maar voor een deel is het bij mij dus ook een gebrek aan kennis/inzicht in de mogelijkheden van KNX om tot een echt slim systeem te komen.

Er zijn vast wel installaties te vinden waar alle logica in een homeserver zit en nauwelijks iets in de rest van de componenten. Maar dat is natuurlijk niet helemaal de bedoeling

Maar future-proofing (domme componenten) is voor mij best een belangrijk aspect. Grote kans dat de domiticamarkt (en mogelijkheden) er over 10 jaar echt heel anders uit ziet. Kijk alleen al naar de opkomst van de voice assistants van de afgelopen 2 jaar.

Ik denk eigenlijk dat KNX (EIB) de enige "standaard" is die al meer dan 10 jaar bestaat
(en met standaard bedoel ik dat er meer dan 1 fabrikant achter zit)

Een collega heeft net ook een bouw met Loxone installatie afgewerkt en is er op dit moment erg positief over. Inderdaad ook het programmeren ervan leek erg goed. Enige opmerking van hem was de toch hoger dan verwachte kost van de extra componenten en de inputs/outputs.

[HyperBart]

Rafael schreef op maandag 16 januari 2017 @ 16:58:
[...]


1x40A is de standaard in België (ben ook Belg ). Hoger wordt momenteel zelfs een beetje afgeraden door een eventuele extra belasting afhankelijk van je aansluitwaarde.


[...]


Ik heb schrik dat ik daar te veel tijd in moet steken, plus ook een klein beetje twijfels bij de stabiliteit. Ik heb 0 ervaring met een rPI of Linux varianten. Hoewel ik met programmeren zelf wel redelijk overweg kan.

Ik ben ook geen held in Linux, maar kan een beetje mijn weg vinden en knutselen en anders heb je GoT nog

Je hebt nu nog halogeen, maar in hoeverre kunnen de standaard dimmodules om met GU10 leds? Ik heb de discussie enkele pagina's terug doorgenomen (waarvan het besluit 'niet' was), maar Loxone bvb beweert dat hun dimmodule wel omkan met bepaalde GU10 led lampen (zie deze pagina). Onzin? Of een reden van hun iets duurdere dimmer? Of dezelfde resultaten ook wel te halen met een KNX dimmer, als je maar de juiste fabrikant vindt? Helemaal dimmen zoek ik niet, maar het lijkt mij in de toekomst wel leuk om een GU10 led tussen 50% en 100% te kunnen sturen?

Als Loxone het kan dan kan KNX het zeker . Of je dat wil is iets anders, daar ging die discussie over. Wij hebben nu de luxe om het van begin goed te doen. Al die GU10 spullen die je ziet zijn doorgaans voor mensen die al 15 jaar hun huis hebben staan en nu naar LED's "moeten" van de EU en die ook dimbaar willen hebben, maar die prestaties zijn ondermaats tov een 12/24V en drivers en voeding.

[...]


De iPads worden redelijk actief gebruikt, daarom de bedoeling om de visualisatie daarop te krijgen en niet ergens te monteren. Ook de reden dat de knoppen in living waarschijnlijk enkel kort gebruikt gaan worden bij het binnenkomen en verlaten, eens je in de zetel zit heb je wel een smartphone of tablet bij de hand.

Mja, hier hetzelfde, iPad ligt op de zetel.

[...]


"We'll be back soon"... Maar opgeslagen om later te bekijken.

Sowieso doen . Ook voor het LED verhaal.

[...]


Je hebt zeker gelijk dat we van dat klassieke denken af moeten, maar dat is nog niet zo simpel, zeker omdat de woning nog gebouwd moet worden en we ook nog totaal geen idee hebben hoe er in geleefd gaat worden. Per zonwering (screen of rolluik nog te bekijken) ben ik waarschijnlijk al 2 knoppen kwijt, dus dat telt snel op. Langs de andere kant komt er ook een lichtsensor en temperatuursensor en zullen de rolluiken grotendeels automatisch worden. (Scheelt EPB punten, nog zo'n lollig ding)

Euh? Geldt dat ook voor zonwering die EPB punten als ze automatisch gaan?

[...]


Ik denk dat wij iets meer sferen zouden nodig hebben, maar ik vat de logica erachter. Als de aparte bediening ook mogelijk blijft met de visualisatie, hoeft niet elke lamp een aparte knop te hebben. Lampen instellen met de tablet, opslaan als sfeer die via de knop werkt en klaar, juist?

Eerst wandelen dan lopen. Zorg eerst maar dat je lichten aan en uit gaan, en daarna functioneel gaan denken. Ik heb hier waarschijnlijk ook wat meer scenes/sferen nodig maar ik wil het goed doen, maar je gaat wel verschieten dat je daarna de manuele bediening niet meer gebruikt.

[...]


In een kelder zou ik liever geen geld verspillen aan detectie. Dat is een (kille) opslagruimte waar je hooguit 10 minuten op een dag bent. Als ik dan toch al een binaire input module nodig heb voor de contacten in de ramen, kan ik er nog wel 1 bijkopen of eentje kopen met meer ingangen, en de standaard Niko Hydro drukknoppen er op plaatsen met SSV?

Ga je dan kabels mengen? dus SVV in de kelder en op je bovenverdiepingen bus-kabel? Ik zou gewoon overal buskabel in ieder potje leggen. Ok, je zet je "vast" dat het altijd een bus systeem zal moeten zijn maar dat is geen ramp.

Idem voor het toilet, het is toch goedkoper om SSV te leggen en bij op de binaire ingang te plaatsen, dan zo'n kleine koppelaar achter de drukknop zelf weg te duwen? Of mis ik nog een nadeel? Het is nu niet dat ik op het toilet ooit die knop zou willen vervangen door een display of dergelijk, want dat is het enige nadeel dat ik zou zien?

Je begint dan wel wat kabels te mixen en misschien is het verstandig om gewoon beide te trekken naar die punten, maar functionele nadelen zie ik niet?

Beide trekken is natuurlijk helemaal luxe qua toekomst, of je de goesting daarvoor hebt...

[...]


Als de Loxone miniserver sneuvelt en Loxone failliet is, kan ik door de sterbekabeling nog een andere fabrikant kiezen, maar mijn knopjes houden wel hetzelfde uiterlijk Het gaat alleen harder (financieel) 'pijn' doen, want alle extensies zijn dan ook ineens onbruikbaar.

Dat wel, maar door niet native KNX knoppen te kiezen verlies je wel wat terugmeldingen, en dat vind ik best wel wat waard hier... En dan doe je je geliefde Niko's ook niet meer weg "want het werkt toch"...

[HyperBart]

bomberboy schreef op maandag 16 januari 2017 @ 17:15:
Een collega heeft net ook een bouw met Loxone installatie afgewerkt en is er op dit moment erg positief over. Inderdaad ook het programmeren ervan leek erg goed. Enige opmerking van hem was de toch hoger dan verwachte kost van de extra componenten en de inputs/outputs.

Efkes op zijn Belgisch Nederlands:

Das toch ongelooflijk eh die mannen. "Loxone si en la, das goedkoper en meer functies" en dan komt er ene langs "oeh ja, toch een beetje verschoten van de prijs, oeh tis toch wa duurder uitgevallen" . Ik zie ze graag komen. Een collega heeft het ook zo hoog op over Loxone: "Ja, gij met uwe KNX en uw sensorkes, hoeveel zijt ge wel nie kwijt voor ne schakelaar, ik met 1 wire en al nie zenne!".


Zullen we de twee bedragen in the end nog eens langs mekaar leggen? En dan ook nog eens functies op EUR gemapt? Ik denk dat het Loxone-verhaal dan snel over en uit is.

[Rafael]

HyperBart schreef op maandag 16 januari 2017 @ 17:22:
Als Loxone het kan dan kan KNX het zeker . Of je dat wil is iets anders, daar ging die discussie over. Wij hebben nu de luxe om het van begin goed te doen. Al die GU10 spullen die je ziet zijn doorgaans voor mensen die al 15 jaar hun huis hebben staan en nu naar LED's "moeten" van de EU en die ook dimbaar willen hebben, maar die prestaties zijn ondermaats tov een 12/24V en drivers en voeding.

[...]

Sowieso doen . Ook voor het LED verhaal.

Ben vooral benieuwd hoe het 'goede' LED verhaalt zich vertaalt in prijs. Moet me er toch nog eens goed in verdiepen, maar er kruipt al veel meer tijd in bouwen dan ik ooit had gedacht.

HyperBart schreef op maandag 16 januari 2017 @ 17:22:
Euh? Geldt dat ook voor zonwering die EPB punten als ze automatisch gaan?

Dat heeft mijn EPB verslaggever mij toch wijsgemaakt, dat automatische zonwering beter is dan handmatige met het voorbeeld dat als je op je werk bent en de zon staat vol op je huis, niemand de zonwering kan bedienen en ze die dag gewoon nutteloos was. Klopt blijkbaar ook nog volgens deze website: Rolluiken zijn goed voor het E-peil: Een manuele bediening zal minder punten opleveren dan een (vol-)automatische bedienen die reageert op de effectieve zonnestraling.

HyperBart schreef op maandag 16 januari 2017 @ 17:22:
Ga je dan kabels mengen? dus SVV in de kelder en op je bovenverdiepingen bus-kabel? Ik zou gewoon overal buskabel in ieder potje leggen. Ok, je zet je "vast" dat het altijd een bus systeem zal moeten zijn maar dat is geen ramp.

[...]

Beide trekken is natuurlijk helemaal luxe qua toekomst, of je de goesting daarvoor hebt...

Het is niet dat kabel op zich zoveel kost en als de slijpschijf dan toch al draait Het uit te sparen bedrag in als voorbeeld mijn kelder is volgens mij al meer dan de meerkost aan kabel...

[tss68nl]

Rafael schreef op maandag 16 januari 2017 @ 16:58:
Ik heb schrik dat ik daar te veel tijd in moet steken, plus ook een klein beetje twijfels bij de stabiliteit. Ik heb 0 ervaring met een rPI of Linux varianten. Hoewel ik met programmeren zelf wel redelijk overweg kan.

Ik kan ook niet met linux overweg, maar van een niet nader te noemen tweaker kreeg ik een werkende VMWare opgestuurd Kan nu de services herstarten, en de config aanpassen....dat werkt

Je hebt nu nog halogeen, maar in hoeverre kunnen de standaard dimmodules om met GU10 leds? Ik heb de discussie enkele pagina's terug doorgenomen (waarvan het besluit 'niet' was), maar Loxone bvb beweert dat hun dimmodule wel omkan met bepaalde GU10 led lampen (zie deze pagina). Onzin? Of een reden van hun iets duurdere dimmer? Of dezelfde resultaten ook wel te halen met een KNX dimmer, als je maar de juiste fabrikant vindt? Helemaal dimmen zoek ik niet, maar het lijkt mij in de toekomst wel leuk om een GU10 led tussen 50% en 100% te kunnen sturen?

Dit is precies het probleem. Hoeveel led-vervangers zijn er op de markt? Honderden? Duizenden? Loxone heeft zelfs een formuliertje gemaakt waar je je ervaringen makkelijk kan melden, en het resultaat is een lijst van 10 compatibel lampen met hun dimmer? Dat is niet veel.
En wat is compatibel? Dimt het flikkerloos, dimt het onder de 50%? En hoe lang kan dat dimniveau behouden worden? Veel van die lampjes dimmen in een test prima voor 30 seconden. Maar na een uur gaan ze ineens continue knipperen of andere rare dingen doen.

En het grootste probleem: van die paar ledjes die ze compatibel achten, is er geen enkele die een goede kleurkwaliteit heeft. 90% wat op de markt komt is qua kleurkwaliteit (niet temperatuur, maar CRI) gewoon ronduit slecht. Olino.org heeft er zo'n 2000 getest, en er zijn er maar twee met een redelijke kleurweergave. Maar die dimmen weer slecht met een Loxone dimmer

Ik zou er iig hoofdpijn van krijgen: wil je goed licht, dan zijn ze niet dimbaar, wil je ze dimbaar, dan zijn ze niet goed van kleur. Vandaar dat veel mensen gewoon goede losse spots nemen, en goede losse dimmers/drivers in de meterkast. Dat is echter wel een kostenpost, nog naast je KNX automatisering. LED is nog niet erg goedkoop.
De markt laat het ook toe. Niemand wil een TL balk in zijn woonkamer vanwege 'ongezellig licht': de consument is door schade en schande wijs geworden. LED heeft exact hetzelfde probleem, maar dat besef is er nog niet bij de consument. Dus we installeren vrolijk allemaal Philips Hue of slechter, en over een jaar of 5 weten we niet beter meer dan dat alle huiskamers er groen/paars/blauw uit zien. Of we maskeren het met veel RGB, dat kan natuurlijk ook

Je hebt zeker gelijk dat we van dat klassieke denken af moeten, maar dat is nog niet zo simpel, zeker omdat de woning nog gebouwd moet worden en we ook nog totaal geen idee hebben hoe er in geleefd gaat worden. Per zonwering (screen of rolluik nog te bekijken) ben ik waarschijnlijk al 2 knoppen kwijt, dus dat telt snel op. Langs de andere kant komt er ook een lichtsensor en temperatuursensor en zullen de rolluiken grotendeels automatisch worden. (Scheelt EPB punten, nog zo'n lollig ding)

Die is leuk Waarom heb je per zonwering 2 knoppen nodig? Wat dacht je van een scene: zonbescherming voor het hele huis? Een KNX systeem of vergelijkbaar kan prima op basis van lichtintensiteit, zonnestand, windsnelheid, jaargetijde, temperatuur en gebruik van de ruimte bepalen wat de ideale stand is van de rolluiken, screens etc. Om die standen in te leren...gebruik je geen knop in die kamer, maar je ipad met je visualisatie, of je ETS tool natuurlijk

Ik denk dat wij iets meer sferen zouden nodig hebben, maar ik vat de logica erachter. Als de aparte bediening ook mogelijk blijft met de visualisatie, hoeft niet elke lamp een aparte knop te hebben. Lampen instellen met de tablet, opslaan als sfeer die via de knop werkt en klaar, juist?

Juist Je hebt knoppen aan de muur voor de scene van die ruimte en/of huis. Je kan de belangrijkste lampen (ik heb linksboven altijd de hoofdverlichting, zodat bezoekers het begrijpen) wel een aparte knop geven. Dat zorgt er voor dat je wel wat zaken kan aanpassen incidenteel.

In een kelder zou ik liever geen geld verspillen aan detectie. Dat is een (kille) opslagruimte waar je hooguit 10 minuten op een dag bent. Als ik dan toch al een binaire input module nodig heb voor de contacten in de ramen, kan ik er nog wel 1 bijkopen of eentje kopen met meer ingangen, en de standaard Niko Hydro drukknoppen er op plaatsen met SSV?

Reed-contact in de deurpost. Aansluiten op je centrale binaire input.

• Deur open = licht aan, deur dicht is licht uit.
• Als je deur dicht moet kunnen als je binnen bent iets lastiger: bij iedere beroering van de deur zet je het licht aan, met een time-out van 15 min bijvoorbeeld.
• Of, bij ieder openen van de deur wissel je lamp aan/uit. Dan trek je een keer de deur dicht. Ga je er weer uit, dan gaat het licht uit. Combineren met langere time-out voor veiligheid.

Idem voor het toilet, het is toch goedkoper om SSV te leggen en bij op de binaire ingang te plaatsen, dan zo'n kleine koppelaar achter de drukknop zelf weg te duwen? Of mis ik nog een nadeel? Het is nu niet dat ik op het toilet ooit die knop zou willen vervangen door een display of dergelijk, want dat is het enige nadeel dat ik zou zien?

Je begint dan wel wat kabels te mixen en misschien is het verstandig om gewoon beide te trekken naar die punten, maar functionele nadelen zie ik niet?

Wie wil er nu nog een knop in het toilet? Reed-contact voor basis functionaliteit, IR sensor voor betere detectie. Stilzitten is geen ramp...zet gewoon een timeout op 15 min. Als iemand niet beweegt in 15 min, dan kan het licht ook wel weer uit

Als de Loxone miniserver sneuvelt en Loxone failliet is, kan ik door de sterbekabeling nog een andere fabrikant kiezen, maar mijn knopjes houden wel hetzelfde uiterlijk Het gaat alleen harder (financieel) 'pijn' doen, want alle extensies zijn dan ook ineens onbruikbaar.

Ja Loxone is tegenwoordig wat aan de prijzige kant. Voor hetzelfde geld heb je vol KNX... wat iets minder risico is. Bestaat als standaard nu al 25 jaar, waarmee stabiliteit wel is bewezen, en gaat er een fabrikant failliet? Zijn er nog 500 andere met vergelijkbaar materiaal

[Rafael]

tss68nl schreef op maandag 16 januari 2017 @ 17:53:
Ik kan ook niet met linux overweg, maar van een niet nader te noemen tweaker kreeg ik een werkende VMWare opgestuurd Kan nu de services herstarten, en de config aanpassen....dat werkt

Interessant, als die niet nader genoemde Tweaker dit leest, de interesse is er wel...

tss68nl schreef op maandag 16 januari 2017 @ 17:53:
Dat is echter wel een kostenpost, nog naast je KNX automatisering. LED is nog niet erg goedkoop.

Heb je hier een concreet prijsvoorbeeld van? Ik kom spullen tegen richting € 500 voor 1 lichtpunt... Wat is de mening voor niet gedimde punten? GU10 wel aanvaardbaar of ook betere oplossingen?

tss68nl schreef op maandag 16 januari 2017 @ 17:53:
Die is leuk Waarom heb je per zonwering 2 knoppen nodig? Wat dacht je van een scene: zonbescherming voor het hele huis? Een KNX systeem of vergelijkbaar kan prima op basis van lichtintensiteit, zonnestand, windsnelheid, jaargetijde, temperatuur en gebruik van de ruimte bepalen wat de ideale stand is van de rolluiken, screens etc. Om die standen in te leren...gebruik je geen knop in die kamer, maar je ipad met je visualisatie, of je ETS tool natuurlijk

Klassieke denkwijze Omhoog/omlaag commando. Scene is mogelijk, hoewel ik 1 zonwering toch apart bedienbaar zal "moeten" houden denk ik: die voor het keukenraam (die als deur gebruikt zal worden in de zomer), dan kan die nog snel open 's avonds als je de tuin in wil. Die moet ik dan ook nog op 1 of andere manier koppelen aan de contacten in de deur, niet dat we in de zomer op het terras zitten en de besturing de zon te fel vindt en de deur blokkeert met de zonwering..

tss68nl schreef op maandag 16 januari 2017 @ 17:53:
Reed-contact in de deurpost. Aansluiten op je centrale binaire input.

In de kelder komen met 99% zekerheid geen deuren. Beter voor de verluchting er door (ben ik wijsgemaakt) en beter voor mijn portemonnee (heb ik mezelf wijsgemaakt). Goedkoopste oplossing die minder mooi is vind ik zelf, is gewoon alle ruimtes koppelen en bedienen met de schakelaar bovenaan de trap.

tss68nl schreef op maandag 16 januari 2017 @ 17:53:
Wie wil er nu nog een knop in het toilet? Reed-contact voor basis functionaliteit, IR sensor voor betere detectie. Stilzitten is geen ramp...zet gewoon een timeout op 15 min. Als iemand niet beweegt in 15 min, dan kan het licht ook wel weer uit

Een sensor is nog niet volledig afgeschreven... Hoewel je dan bij een kleine boodschap elke keer 13 minuten elektriciteit aan het verspillen bent.

[Femme]

teaser schreef op maandag 16 januari 2017 @ 14:29:
[...]

Grappig dat je hier een grote misvatting van KNX, dat het duur is, onderuithaalt terwijl er gisteren in ditzelfde topic diezelfde misvatting nog werd aangehaald

Het is maar waar je mee vergelijkt.

Knx-tasters zijn aanzienlijk duurder dan simpele pulsdrukkers aan een 24V input. Zelfde voor digitale outputs. Een nette Merten Artec Edelstahl dubbele pulsdrukker in aluminium kost zo'n 31 euro per stuk, een input is 7,50 euro in het geval van Wago en 50 euro als je een Loxone Extension alleen voor de inputs zou kopen. Een Ekinex taster zit volgens mij snel op 175 euro.

Een 1-wire temperatuursensor kost bijna niets, in de installatie zit wel veel werk en dat is ook wel een groot verschil tussen tasters op een bussysteem en simpele potentiaalvrije pulsdrukkers.

Voor outputs hetzelfde verhaal:
Wago 750 digitale output + 16A relais: ca. € 7,50 per input en € 7,50 per relais, maakt € 15 euro totaal (heb je wel een plc en programmeersoftware van 600 euro nodig om mee te beginnen, ook is er een extra rijgklemmetje nodig per output)
Railduino: ca. €14 per 5A relais en dan krijg je er onder andere 24 inputs gratis bij. Dit is wel een beetje een knutseloplossing maar wel een interessante voor tweakers die low-cost aan de slag willen gaan met bedrade domotica.

Het grote voordeel van een centraal aangestuurd systeem is dat systeem overzicht heeft van de totale staat van het systeem en eventuele externe diensten en hier op kan acteren. Dat geeft je meer mogelijkheden qua logica. De logica in een hardwaremodule stoppen vind ik persoonlijk niet echt een logische oplossing aangezien de logica iets zachts is dat je aan de omstandigheden wilt kunnen aanpassen en hardware inherent onveranderlijk is (op de mogelijkheid van een firmware-update na).

Een succesvolle automatisering valt of staat met de kracht en het gemak waarmee je de logica in elkaar kunt zetten. In mijn eigen huis loop ik vrij vaak tegen het probleem aan dat iets recht toe rechtaan automatiseren niet het gewenste resultaat geeft omdat er in de praktijk vrij regelmatig bijzondere cases optreden (van té stil zitten waardoor het licht ongewenst uitgaat tot aan huisdieren, stofzuigrobots en een laagstaande zon die aanwezigheidssensoren triggeren). Er is een groot verschil tussen een huis waarin bepaalde processen geautomatiseert zijn en een slim huis, waarvoor een bepaald bewustzijn nodig is van wat de bewoners willen.

Ik heb daar nu geen kant-en-klare oplossing voor maar ik ben wel benieuwd of mensen in ETS met de mogelijkheden van de hardwaremodules echt voor elkaar krijgen wat nodig is om een huis slim te maken.

[tss68nl]

Femme schreef op maandag 16 januari 2017 @ 19:09:
Het is maar waar je mee vergelijkt.

Dat klopt, het vergelijk ging in dit geval over KNX vs Loxone. Daarbij is Loxone doorgaans een stuk duurder.

Wat je aangeeft met PLC automatisering: dat klopt, daar kan je zaken een stuk goedkoper maken dan KNX en Loxone. Je hebt dan ook meer controle over de uiteindelijke logica, alleen je moet wel alle logica willen programmeren. Je hebt ook veel meer controle over 'slimme' integratie in meubels/deuren/speakers etc, alleen moet je wel van knutselen houden

Knx-tasters zijn aanzienlijk duurder dan simpele pulsdrukkers aan een 24V input. Zelfde voor digitale outputs. Een nette Merten Artec Edelstahl dubbele pulsdrukker in aluminium kost zo'n 31 euro per stuk, een input is 7,50 euro in het geval van Wago en 50 euro als je een Loxone Extension alleen voor de inputs zou kopen. Een Ekinex taster zit volgens mij snel op 175 euro.

Yup, als je geen statusterugmelding nodig hebt, en maar 1 a 2 functies op een locatie, dan kan het redelijk goedkoop.
Voor KNX koppeling zou je dan bijvoorbeeld een GIRA 018200 voor €60 kunnen nemen (is taster en businterface ineen) en zit je niet met allemaal SVV kabel.
Heb je veel tasters door het huis dan gebruik je twee kanalen van een MDT BE-16000.01 met 16 inputs. Dan kom je uit op €30 per 2 kanalen, achter de door jouw genoemde Merten dubbele pulsdrukker voor wederom €60 + SVV kabel.

Een 1-wire temperatuursensor kost bijna niets, in de installatie zit wel veel werk en dat is ook wel een groot verschil tussen tasters op een bussysteem en simpele potentiaalvrije pulsdrukkers.

Ja dat was wel een dingetje wat mij tegen hield: 3 wires voor m'n 1-wire als extra busnetwerk door het hele huis voorzien is op zich niet mis. En veel custom werk om de sensors netjes weg te bouwen dat ze ook echt de ruimtetemp weergeven, en niet van de inbouwdoos Wat is jouw ervaring daar mee? Achter een schakelwip of wcd frontplaat is voldoende thermish contact?

Een succesvolle automatisering valt of staat met de kracht en het gemak waarmee je de logica in elkaar kunt zetten.

Ik zou die iets willen uitbreiden:

• Gemak van logica programmeren
• Installatiegemak
• Eenvoud van de uiteindelijke oplossing
• Betrouwbaarheid

Als je makkelijker kan installeren, kan je ook makkelijker en sneller uitbreiden/verbeteren. Eenvoud zorgt voor betere acceptatie van de niet-tweakers in huis. Die laatste groep is doorgaans zwaar in ondertal En betrouwbaarheid is wat mij betreft de belangrijkste...als het systeem heel slim is, maar niet altijd, dan heb ik er nog weinig aan.

Ik heb daar nu geen kant-en-klare oplossing voor maar ik ben wel benieuwd of mensen in ETS met de mogelijkheden van de hardwaremodules echt voor elkaar krijgen wat nodig is om een huis slim te maken.

Ik denk dat je er met standaard modules niet van uit moet gaan dat je echt hele slimme dingen in elkaar kan zetten, en daarom is een logicmodule geen overbodige luxe.

[tss68nl]

Rafael schreef op maandag 16 januari 2017 @ 18:37:
Heb je hier een concreet prijsvoorbeeld van? Ik kom spullen tegen richting € 500 voor 1 lichtpunt... Wat is de mening voor niet gedimde punten? GU10 wel aanvaardbaar of ook betere oplossingen?

€500 per lichtpunt is wat overdreven. Fatsoenlijke lichtkwaliteit koop je in een spot van €60 tot €100, echt goede spots koop je tussen de €100 en €200 doorgaans. Dat ligt een beetje aan het formaat, lichtopbrengst, en of het een richtbaar armatuur is. (en of je het armatuur mee weg wil stucen in het plafond)
Voor gedimd of niet gedimd zou ik die zelfde armaturen aan houden, een GU10 gaat veel sneller kapot en heeft doorgaans echt een slechtere lichtkwaliteit.

Qua drivers kan je natuurlijk wel veel goedkoper als je niet gedimd wil hebben. Je kan zoals bij halogeen kleine gecombineerde voedingen/drivers gebruiken. Beetje afhankelijk van je soort spots zijn er al prima drivers voor €30 a €50 waar dan 2 tot 5 spots per driver op gaan. Als je wat ruimte in je plafond hebt (met IBtronic inbouwdozen bijvoorbeeld) dan kan je zelfs 230V naar de groep spots leggen en de driver naast de eerste spot leggen in het plafond.

Voor gedimde spots is het ook sterk afhankelijk van de gekozen led-spot karakteristieken (nominale stroom en spanning) hoe veel je er op welke manier kan aansluiten op een driver. Doorgaans moet je denken aan €20 tot €30 per dimbare spot. In uitzonderlijke gevallen kan het zijn dat de karakteristieken van je led-chip zo gunstig zijn, dat je op €12 per spot gemiddeld uit komt. Dan kan je ze dus beter allemaal dimbaar maken voor die prijs

Klassieke denkwijze Omhoog/omlaag commando. Scene is mogelijk, hoewel ik 1 zonwering toch apart bedienbaar zal "moeten" houden denk ik: die voor het keukenraam (die als deur gebruikt zal worden in de zomer), dan kan die nog snel open 's avonds als je de tuin in wil. Die moet ik dan ook nog op 1 of andere manier koppelen aan de contacten in de deur, niet dat we in de zomer op het terras zitten en de besturing de zon te fel vindt en de deur blokkeert met de zonwering..

Nachtshootcontact Daarmee bepaal je of de deur op slot zit. En alleen dan mag het systeem het screen naar beneden doen. Heeft nog een voordeel: wil je naar buiten en doe je de deur van het slot af? Het specifieke screen gaat vanzelf omhoog Denk je in het langslopen "waarom is het screen niet naar beneden?"...yup, omdat de deur niet op slot zit

Het enige wat je nodig hebt: het signaal vanuit de scene dat het screen dicht moet zijn, het signaal van het nachtschootcontact of het screen dicht mag, en een AND-logicgate uit een Ekinex unit die het uiteindelijke commando verstuurt zodra de situatie wijzigt door een van de inputs

In de kelder komen met 99% zekerheid geen deuren. Beter voor de verluchting er door (ben ik wijsgemaakt) en beter voor mijn portemonnee (heb ik mezelf wijsgemaakt). Goedkoopste oplossing die minder mooi is vind ik zelf, is gewoon alle ruimtes koppelen en bedienen met de schakelaar bovenaan de trap.

En dan met je telefoon als je de verkeerde ruimte aan hebt geschakeld? Of je hangt de schakelaar beneden, en gebruikt de ledjes als orientatieverlichting Hier is het huis 's nachts verlicht door de Ekinex ledjes allemaal aan te zetten (behalve de slaapvertrekken).

Een sensor is nog niet volledig afgeschreven... Hoewel je dan bij een kleine boodschap elke keer 13 minuten elektriciteit aan het verspillen bent.

VOC sensor erbij, en je kan detecteren of het om een kleine boodschap ging

Andere optie: plaats in de deur een reed-contact. Hanteer een 15 min timeout zolang de deur niet open gaat. Zodra de deur weer open gaat, zet je de timeout op 30 seconden.

[teaser]

Femme schreef op maandag 16 januari 2017 @ 19:09:
Er is een groot verschil tussen een huis waarin bepaalde processen geautomatiseert zijn en een slim huis, waarvoor een bepaald bewustzijn nodig is van wat de bewoners willen.

Ik heb daar nu geen kant-en-klare oplossing voor maar ik ben wel benieuwd of mensen in ETS met de mogelijkheden van de hardwaremodules echt voor elkaar krijgen wat nodig is om een huis slim te maken.

Er bestaan momenteel gewoon geen systemen die je huis slim maken. Je kan wel hopen logica en uitzonderinkjes programmeren in je Loxone, OpenHAB of whatever, maar daarmee heb je nog steeds gewoon een huis met bepaalde geautomatiseerde processen.
Een echt slim huis leert de gewoontes en routines van zijn bewoners en past zich automatisch daarop aan, en kan daarnaast ook overweg met uitzonderingen zoals een dagje verlof, een lamp die defect is of een heel koude nacht.
Er bestaan wel al lerende sensoren zoals Nest, maar dat is nog mijlenver verwijderd van de echte smart home.

[Rafael]

tss68nl schreef op maandag 16 januari 2017 @ 20:33:
En dan met je telefoon als je de verkeerde ruimte aan hebt geschakeld? Of je hangt de schakelaar beneden, en gebruikt de ledjes als orientatieverlichting Hier is het huis 's nachts verlicht door de Ekinex ledjes allemaal aan te zetten (behalve de slaapvertrekken).

Nee, ik doelde op de 5 ruimtes samenplaatsen als 1 lichtpunt. Maar dat is ook maar een klus-oplossing.

tss68nl schreef op maandag 16 januari 2017 @ 20:00:
Dat klopt, het vergelijk ging in dit geval over KNX vs Loxone. Daarbij is Loxone doorgaans een stuk duurder.

Dat dacht ik eerst ook, maar ik ben nog eens aan het tellen geweest en ik kom nu op het volgende uit. Mijn berekening gaat er voorlopig nog van uit dat elk lichtpunt ook effectief een schakelaar krijgt. Ik heb de volgende projectgegevens genomen: 27 geschakelde lichtpunten, 12 gedimde lichtpunten, 11 zonweringen, 7 raamcontacten. Dat geeft dan 57 digitale ingangen, 12 dimmers en 49 digitale uitgangen (een zonwering telt dubbel hier).

Loxone
Ik heb dan nodig: 1 miniserver, 2 extensies, 2 relais extensies, 3 dimmer extensies, 1 voeding. Dit geeft 56 digitale ingangen (dus 1 lichtpunt moet achter lange puls of dergelijk), 52 digitale uitgangen en 12 dimmers. Dat komt uit op € 3.654. De schakelpunten (Niko) 7x 6 voudig, 10x 2 voudig, 6x enkelvoudig. Dat komt uit op € 728. Totaal Loxone € 4.382. Bekabeling tel ik bewust niet, buskabel of SSV vind ik verwaarloosbaar van prijs.

KNX
- MDT JAL-0410.02 en MDT JAL-0810.02: 12 zonweringen voor € 376.
Door de rolluikmodules te gebruiken, kan ik 22 digitale uitgangen schrappen van de vorige lijst en heb ik er nog maar 27 nodig.
- MDT AKS-1216.02: 3x 12 uitgangen = 36 uitgangen voor € 750 of MDT AKS-2016.02 = 2x 20 uitgangen = 40 uitgangen voor € 700.
De laatste is het meest gunstige van prijs en geeft nog wat overschot.
- MDT AKD-0401.01: 3x 4 dimmers = 12 dimmers voor € 783.
- MDT STV-0320.01 320mA voeding voor € 117.
- ETS5 Lite software: komt nog op +- € 100 na de korting.
- MDT BE-16000.01: 1x 16 digitale ingangen: € 222. Al zeker 7 nodig voor de raamcontacten.
- De 7 6-voudige drukknoppen gebruikt in mijn Loxone berekening zouden vervangen mogen door een Ekinex taster met 4 vakken, 8 drukpunten: nog geen prijzen van gevonden, ik ga schatten naar € 200 per stuk, totaal € 1.400.
- Dan nog een oplossing zoeken voor de overige 10x 2 voudige, 6x enkelvoudige...
- LogicMachine, prijslijst past ontvangen: LML5Lp € 740 excl. btw = € 895 inclusief btw. LogicMachine met 1-wire zit op € 850 excl. btw = € 1.028 inclusief btw.
- MDT SCN-IP100.01 interface met UTP voor € 267.
Totaal met LogicMachine lite, zonder interface: € 4.593 met nog steeds enkele missende schakelpunten/inputs.
Totaal zonder LogicMachine, maar wel de interface dan: € 3.965 met ook nog steeds enkele missende schakelpunten/inputs.

Ik kom in deze berekening uit op € 4.382 incl. alle bedienpunten voor Loxone en € 4.593 voor KNX, maar met nog missende inputs/tasters... Waar loop ik mis? Wat kan goedkoper/beter?

[Femme]

tss68nl schreef op maandag 16 januari 2017 @ 20:00:
[...]

Ja dat was wel een dingetje wat mij tegen hield: 3 wires voor m'n 1-wire als extra busnetwerk door het hele huis voorzien is op zich niet mis. En veel custom werk om de sensors netjes weg te bouwen dat ze ook echt de ruimtetemp weergeven, en niet van de inbouwdoos Wat is jouw ervaring daar mee? Achter een schakelwip of wcd frontplaat is voldoende thermish contact?

Ik heb overal dubbele pulsdrukkers met een redelijke spleet tussen de wippen. De meting via de 1-wire sensor hierachter reageert goed op temperatuurschommelingen in de ruimte. Ik heb de buis wel dichtgedrukt met foam.

Op een paar plekken heb ik inbouwdozen tegenover elkaar zitten in de wand (bijvoorbeeld tussen wand tussen overloop en slaapkamer) waarbij de sensoren via een enkele kabel zijn aangesloten. Hier is scheiding tussen beide dozen niet helemaal optimaal.

De meting is nauwkeurig en je kunt de verwarming er prima op laten reageren. Op een paar plekken heb ik z-wave multi-sensoren met een lagere nauwkeurigheid en minder goede reactietijd. Daar zijn de over- en ondershoots naar mijn idee groter.

Inbouwen kost wel echt veel werk en is gepruts. Ik heb overal kale DS18B20-sensoren ingebouwd (anders lukt het niet qua ruimtegebruik) en gesoldeerd. De bekabeling is in lijnvorm aangelegd (data-ader heen en terug naar de verdeelkast).

Rafael schreef op woensdag 18 januari 2017 @ 19:04:
[...]

Dat dacht ik eerst ook, maar ik ben nog eens aan het tellen geweest en ik kom nu op het volgende uit. Mijn berekening gaat er voorlopig nog van uit dat elk lichtpunt ook effectief een schakelaar krijgt.

Waarom zou je elk lampje los willen schakelen met een knop?

Ik heb een dubbele pulsdrukker per ruimte om al het licht in de ruimte aan of uit te zetten, van scène te wisselen en te dimmen. In combinatie met korte, lang en dubbeldrukken hou ik dan nog mogelijkheden over voor extra functies zoals home cinema aanzetten.

[tss68nl]

Rafael schreef op woensdag 18 januari 2017 @ 19:04:

Dat dacht ik eerst ook, maar ik ben nog eens aan het tellen geweest en ik kom nu op het volgende uit. Mijn berekening gaat er voorlopig nog van uit dat elk lichtpunt ook effectief een schakelaar krijgt. Ik heb de volgende projectgegevens genomen: 27 geschakelde lichtpunten, 12 gedimde lichtpunten, 11 zonweringen, 7 raamcontacten. Dat geeft dan 57 digitale ingangen, 12 dimmers en 49 digitale uitgangen (een zonwering telt dubbel hier).

Ik kom in deze berekening uit op € 4.382 incl. alle bedienpunten voor Loxone en € 4.593 voor KNX, maar met nog missende inputs/tasters... Waar loop ik mis? Wat kan goedkoper/beter?

Qua prijs:

• Wat je in ieder geval bent vergeten bij Loxone, is het toevoegen van temperatuursensoren, lichtsensoren, én de benodigde ingangen daarvoor. Ook de extra buis, potjes en muurvervuiling (IR, temp kan je wegwerken via 1-wire achter knoppen)
• In je Loxone setup heb je geen status-leds voor alle knoppen. Reken met name de uitgangen die je daar voor nodig hebt.
• Bekabeling kan wel degelijk significant zijn, als je ieder schakelpunt vanwege de hoeveelheid aders direct naar de meterkast moet brengen. Twee 6-voudige doorlussen op dezelfde SVV kabel is wellicht te doen, maar 3 haal je niet, en als er statusleds in het spel zijn dan ben je sowieso het dubbele aantal aders kwijt.
• Die 230V dimmers hakken er flink in. Ik zou beginnen met 1 dimmer, en je zal zien dat je die uiteindelijk ook niet meer gebruikt omdat je alles vervangt door led.
• Als je ipv 230V led-dimmers gaat gebruiken, dan heb je bij Loxone nog een DMX of Dali extensie nodig. Met KNX heb je die al in de LogicMachine zitten.

Nu kan het zijn dat je status leds echt niet denkt te gaan gebruiken (wat de installatie wel een pak minder intuitief maakt), maar dan gaat wel het vergelijk scheef. 1-wire is met Loxone de goedkoopste oplossing voor de sensors, maar je moet er dan wel een aparte bus voor aanleggen en de afzonderlijke sensors meerekenen. Temp is niet heel duur, licht al iets meer denk ik. Dat buizennetwerk komt vanwege het slijpwerk ook niet voor niets.

Zo zie je maar, Loxone wordt vaak als goedkoop afgedaan, en KNX als duur... maar uiteindelijk denk ik dat het eigenlijk om het even is?

Femme schreef op woensdag 18 januari 2017 @ 19:30:
Waarom zou je elk lampje los willen schakelen met een knop?

Spijker op z'n kop. Dat duurt soms even voordat je van je oude denken af bent dat je overal knoppen voor moet hebben.

Al zit het niet in de weg om Loxone en KNX qua prijs te vergelijken. Als je namelijk minder knoppen rekent, maar hetzelfde aantal relais, dan valt Loxone in verhouding duurder uit.

[ Voor 9% gewijzigd door tss68nl op 18-01-2017 19:55 ]

[Dennis]

Vraagje nog hier. Voor bewegingsmelders, is het dan handiger om gewoon binaire aansluitingen te gebruiken in combinatie met een KNX binaire ingang-apparaat of gebruiken mensen bewegingsmelders waar een directe KNX-aansluiting op zit?

En hoe zit dat met rookmelders?

En als je een alarmsysteem hebt, dan kan ik beter die als bron gebruiken denk ik en dat met bijvoorbeeld een KNX-module of integratiesysteem (OpenHAB) doorlussen naar de KNX-bus en actoren denk ik. Toch?

[Rafael]

Femme schreef op woensdag 18 januari 2017 @ 19:30:
Waarom zou je elk lampje los willen schakelen met een knop?

Om nu gemakkelijk te kunnen tellen in de prijsvergelijking Het zal toch een KNX oplossing worden, maar vergelijken vind ik wel interessant, zeker omdat er nu weer naar boven kwam dat KNX echt een stuk goedkoper kan dan Loxone maar het mij niet lukt.

Graag ook wat advies hoe jullie de knoppen zouden voorzien, 2 ruimtes met redelijk wat lichtpunten:
- Ruimte 1: woonkamer, living en bureau gedeelte is 1 ruimte, lopen allemaal in elkaar over (je kan het je voorstellen als een grote L vorm). 2 deuren, 1 aan het keuken stuk, 1 aan het bureaustuk. De keuken heeft plafondverlichting, verlichting boven het keukeneiland en sfeerverlichting in het keukeneiland. De eetkamer heeft plafondverlichting en verlichting boven de tafel. De woonkamer heeft plafondverlichting. Het bureau heeft plafondverlichting. Daarbij nog 3 geschakelde stopcontacten, voorzien voor sfeerverlichting: 1 aan de TV, 1 aan de zetel, 1 aan de kast in de eetkamer. (10 punten totaal)
- Ruimte 2: badkamer met centrale plafondverlichting, verlichting boven het bad, verlichting boven de douche, en verlichting aan de wasbakken. (4 punten totaal)

tss68nl schreef op woensdag 18 januari 2017 @ 19:45:
Bekabeling kan wel degelijk significant zijn, als je ieder schakelpunt vanwege de hoeveelheid aders direct naar de meterkast moet brengen. Twee 6-voudige doorlussen op dezelfde SVV kabel is wellicht te doen, maar 3 haal je niet, en als er statusleds in het spel zijn dan ben je sowieso het dubbele aantal aders kwijt.

Als de buskabel van Voltus van € 0,33 per meter kwalitatief OK is, dan kan dat inderdaad wel een goed stuk schelen. SSV 16x0,8 is 4x zo duur.

tss68nl schreef op woensdag 18 januari 2017 @ 19:45:
Die 230V dimmers hakken er flink in. Ik zou beginnen met 1 dimmer, en je zal zien dat je die uiteindelijk ook niet meer gebruikt omdat je alles vervangt door led.
Als je ipv 230V led-dimmers gaat gebruiken, dan heb je bij Loxone nog een DMX of Dali extensie nodig. Met KNX heb je die al in de LogicMachine zitten.

En dan zijn ze nog goedkoper dan de Loxone variant, vond die nog meevallen qua prijs

tss68nl schreef op woensdag 18 januari 2017 @ 19:45:
Nu kan het zijn dat je status leds echt niet denkt te gaan gebruiken (wat de installatie wel een pak minder intuitief maakt), maar dan gaat wel het vergelijk scheef.

Heb je een concreet voorbeeld van het intuïtieve daaraan? Leds die tonen welke verlichting ingeschakeld is zodat je niet moet gokken welke knop het is om uit te schakelen? Vanaf je sferen gaat creëren en nog amper knopjes hebt, wat is dan de echte meerwaarde van de leds dan nog? Het is niet dat ik het voordeel van de leds niet wil zien, maar ik kan het me nog niet goed voorstellen.

tss68nl schreef op woensdag 18 januari 2017 @ 19:45:
Zo zie je maar, Loxone wordt vaak als goedkoop afgedaan, en KNX als duur... maar uiteindelijk denk ik dat het eigenlijk om het even is?

Al zit het niet in de weg om Loxone en KNX qua prijs te vergelijken. Als je namelijk minder knoppen rekent, maar hetzelfde aantal relais, dan valt Loxone in verhouding duurder uit.

Ik denk net het omgekeerde, tenzij je echt over-the-top gaat met het aantal relais... In mijn voorbeeld met Loxone zitten 68 drukknoppen verrekend op 23 locaties... In de KNX setup zitten slechts 7 tasters... Wel 8 voudige, maar ook maar op 7 locaties te plaatsen.

[ Voor 7% gewijzigd door Rafael op 19-01-2017 17:46 ]

[Femme]

Rafael schreef op donderdag 19 januari 2017 @ 16:50:
[...]

Als de buskabel van Voltus van € 0,33 per meter kwalitatief OK is, dan kan dat inderdaad wel een goed stuk schelen. SSV 16x0,8 is 4x zo duur.

Je kunt ook twee keer utp-kabel door een buis trekken. Voor het aansluiten van 24V pulsdrukkers maakt het niet uit wat voor een kabel je gebruikt zolang het elektronen geleidt. Voor de toekomstbestendigheid kan het wel verstandig zijn om kwalitatief hoogwaardige kabel te trekken. Svv lijkt me dan als toekomstige communicatiekabel niet zo geschikt omdat niet getwist is.

Heb je een concreet voorbeeld van het intuïtieve daaraan? Leds die tonen welke verlichting ingeschakeld is zodat je niet moet gokken welke knop het is om uit te schakelen? Vanaf je sferen gaat creëren en nog amper knopjes hebt, wat is dan de echte meerwaarde van de leds dan nog? Het is niet dat ik het voordeel van de leds niet wil zien, maar ik kan het me nog niet goed voorstellen.

Wat ik met de gasten in ons gastenverblijf merk is dat ze niet gewend zijn aan het gebruik van pulsdrukkers en licht dat middels een fade-in van een paar seconden aan gaat (dat vind ik nu eenmaal veel mooier dan aan/uit). Af en toe hebben we mensen die meteen al bij binnenkomst op alle knopjes drukken en het licht uitzetten met dezelfde knop waarmee ze het een seconde eerder hebben aangezet. Ik moet nog bedenken om de UX te verbeteren. Dat heb je wellicht minder als er terugkoppeling op de toets zit.

Een terugkoppeling is met Loxone niet echt goedkoop te realiseren. Het is nogal jammer om en relais te krijgen om een 24V ledje te laten branden. Voor dit doeleinde zou je een Wago buskoppelaar op de kop kunnen tikken met wat 24V outputmodules om via modbus/tcp de terugkoppeling te doen, dan doe je het voor zo'n € 7,50 euro per output of nog veel minder als je de modules gebruikt van eBay.de haalt.

[tss68nl]

Rafael schreef op donderdag 19 januari 2017 @ 16:50:
Om nu gemakkelijk te kunnen tellen in de prijsvergelijking Het zal toch een KNX oplossing worden, maar vergelijken vind ik wel interessant, zeker omdat er nu weer naar boven kwam dat KNX echt een stuk goedkoper kan dan Loxone maar het mij niet lukt.

Ik denk dat KNX nooit veel goedkoper gaat worden dan Loxone, maar het is wel maar net hoe je het vergelijkt:

• Neem je standaard KNX (dus zonder logic module omdat het eigenlijk allemaal klein computertjes zijn), dan ben je met een leuk aantal relais al snel wél goedkoper uit met KNX. Loxone heeft meer logica mogelijkheden, KNX meer statusleds/stabiliteit door de gedecentraliseerde logica
• Neem je in KNX een logische module op, dan ben je aardig wat geld kwijt, en denk ik dat je uiteindelijk voor een normaal systeem ongeveer gelijk uit komt qua prijs.
• Heb je een heel klein systeem, met amper relais en wil je voornamelijk veel logica puzzelen...dan is Loxone goedkoper doorgaans.

Het blijft appels met peren vergelijken, omdat beide systemen hun voor en nadelen hebben. Komt de prijs echter gelijk uit tussen de twee systemen? Dan zou ik me nooit vast willen pinnen op de nadelen van Loxone als ik een open alternatief heb.

Als de buskabel van Voltus van € 0,33 per meter kwalitatief OK is, dan kan dat inderdaad wel een goed stuk schelen. SSV 16x0,8 is 4x zo duur.

Ik doelde meer op de kosten voor buis/inslijpen etc dan van de kabel zelf. Al gaat in Belgie de boel doorgaans gewoon recht de muur en de vloer in toch? Dan is dat verschil ineens een stuk minder groot

Heb je een concreet voorbeeld van het intuïtieve daaraan? Leds die tonen welke verlichting ingeschakeld is zodat je niet moet gokken welke knop het is om uit te schakelen? Vanaf je sferen gaat creëren en nog amper knopjes hebt, wat is dan de echte meerwaarde van de leds dan nog? Het is niet dat ik het voordeel van de leds niet wil zien, maar ik kan het me nog niet goed voorstellen.

Ook met scenes is het handig om te weten of de scene aan staat. Maar, de led's zijn onafhankelijk van de knoppen. Je kan dus bijvoorbeeld overal het ledje rechtsonder gebruiken om te signaleren dat er nog een deur van het slot is, of, dat er verlichting op de bovenverdieping aan is. Ook kan je de led gebruiken om aan te geven dat de lamp uit gaat schakelen, daar waar lampen een tijdvertraging hebben. Wat vaak wordt gedaan is de leds omdraaien: zet alle leds aan wara uberhaupt een functie onder zit, en maak ze een andere kleur of zet ze uit zodra de lamp aan is.

Heb je meteen orientatievrelichting door je hele huis Niet aan te raden op de slaapkamer overigens!

Ik denk net het omgekeerde, tenzij je echt over-the-top gaat met het aantal relais... In mijn voorbeeld met Loxone zitten 68 drukknoppen verrekend op 23 locaties... In de KNX setup zitten slechts 7 tasters... Wel 8 voudige, maar ook maar op 7 locaties te plaatsen.

Yep, de truc is om voor de minder blangrijke ruimtes aflternatieve oplossingen met deursensors, ir sensors of bundeling naar één unit toe te passen. En als het echt blijft steken op een simpele schakelaar dan is die Gira die ik eerder noemde wel een oplossing. €60, en je prikt hem zo op de bus in. Blijft €60, maar een SVV variant inclusief I/O unit in de meterkast is niet goedkoper

[tss68nl]

Femme schreef op donderdag 19 januari 2017 @ 18:47:
Je kunt ook twee keer utp-kabel door een buis trekken. Voor het aansluiten van 24V pulsdrukkers maakt het niet uit wat voor een kabel je gebruikt zolang het elektronen geleidt. Voor de toekomstbestendigheid kan het wel verstandig zijn om kwalitatief hoogwaardige kabel te trekken. Svv lijkt me dan als toekomstige communicatiekabel niet zo geschikt omdat niet getwist is.

Klopt, het heeft weinig stroom te verwerken, maar wil je er later een PoE apparaat op zetten ben je blij dat je toch AWG22/23 hebt gelegd

Wat ik met de gasten in ons gastenverblijf merk is dat ze niet gewend zijn aan het gebruik van pulsdrukkers en licht dat middels een fade-in van een paar seconden aan gaat (dat vind ik nu eenmaal veel mooier dan aan/uit). Af en toe hebben we mensen die meteen al bij binnenkomst op alle knopjes drukken en het licht uitzetten met dezelfde knop waarmee ze het een seconde eerder hebben aangezet. Ik moet nog bedenken om de UX te verbeteren. Dat heb je wellicht minder als er terugkoppeling op de toets zit.

Ik denk dat veel mensen als ze op de knoppen staan te tikken ondertussen rondkijken wat ze zien gebeuren aan licht, dus dat statusleds in dat geval niet altijd zullen helpen.

Wat je wel kan doen:

• Inputs voorzien van een debunk-time zodat ze gewoon niet zo snel reageren achter elkaar.
• Detecteren dat het fout gaat, en direct gesproken instructies door het huis laten galmen..

[teaser]

Dennis schreef op donderdag 19 januari 2017 @ 14:41:
Vraagje nog hier. Voor bewegingsmelders, is het dan handiger om gewoon binaire aansluitingen te gebruiken in combinatie met een KNX binaire ingang-apparaat of gebruiken mensen bewegingsmelders waar een directe KNX-aansluiting op zit?

Een bewegingsmelder die rechtstreeks op de bus zit heeft veel meer mogelijkheden dan een standaard melder die rechtstreeks het licht schakelt. Vaak hebben KNX aanwezigheidsmelders ook lichtmeting, wat ineens nog een hele hoop extra mogelijkheden geeft.
Nadeel is dat een standaard PIR sensor een pak goedkoper is dan eentje voor KNX.

En hoe zit dat met rookmelders?

Ik heb Gira Dual Q rookmelders gekocht met buskoppelaar. De buskoppelaar is een aparte module, je kunt er ook een relaiscontact of draadloze module insteken. Nog niet geinstalleerd overigens.
Het is sowieso al moeilijk om een deftig uitziende rookmelder te vinden met relaiscontacten. De meesten zijn wel draadloos onderling koppelbaar, maar niet met een domoticasysteem. Met die van Gira kun je dus alle kanten uit.

En als je een alarmsysteem hebt, dan kan ik beter die als bron gebruiken denk ik en dat met bijvoorbeeld een KNX-module of integratiesysteem (OpenHAB) doorlussen naar de KNX-bus en actoren denk ik. Toch?

Dat kan, als het alarmsysteem dat toelaat. De bewegingsdetectoren moeten dan wel rechtstreeks met het alarmsysteem gekoppeld worden, en dan zijn de mogelijkheden naar KNX toe weer beperkt. Of je werkt met aparte melders voor alarm en KNX. Deur- en raamcontacten uitlezen via het alarmsysteem geeft geen nadelen omdat die sowieso op een gewone input zouden hangen van het KNX systeem.

[Rob Z]

...Nadeel is dat een standaard PIR sensor een pak goedkoper is dan eentje voor KNX.

Ja dat verschil is aanzienlijk. Weet iemand een betaalbare en betrouwbare oplossing daarvoor?
Een goedkopere PIR met een binaire buskoppelaar?
Of is het beter niet te gaan klooien en wat meer uit te geven?

[tss68nl]

Rob Z schreef op vrijdag 20 januari 2017 @ 10:04:
[...]

Ja dat verschil is aanzienlijk. Weet iemand een betaalbare en betrouwbare oplossing daarvoor?
Een goedkopere PIR met een binaire buskoppelaar?
Of is het beter niet te gaan klooien en wat meer uit te geven?

Je probleem is dat een 'domme' PIR altijd een voedingsspanning nodig heeft om te kunnen werken volgens mij. Dus hoe ga je die spanning voorzien?

Een simpele pir kost al snel een €30, aangevuld met een buskoppelaar van zeker €30....ben je per PIR minimaal €60 kwijt.
Voor €100 heb je een PIR op de bus, die meerdere schakelkanalen heeft, timers, time-outs, kan tellen hoeveel bewegingen in een bepaalde tijd nodig zijn om alarm af te laten gaan, een lichtmeting heeft...soms zelfs led voor nachtverlichting.....

[teaser]

Stom eigenlijk dat er geen tussenoplossingen bestaan, ik heb ze althans nog niet gevonden. Een relatief simpele PIR die wel aan de bus hangt, met een enkel schakelkanaal, geen lichtmeting, geen alarmmodus... voor bv €60. Ik heb al minstens 4 plaatsen waar een PIR hangt maar ik niet meer functionaliteit nodig heb dan dat.

[tss68nl]

teaser schreef op vrijdag 20 januari 2017 @ 10:53:
Stom eigenlijk dat er geen tussenoplossingen bestaan, ik heb ze althans nog niet gevonden. Een relatief simpele PIR die wel aan de bus hangt, met een enkel schakelkanaal, geen lichtmeting, geen alarmmodus... voor bv €60. Ik heb al minstens 4 plaatsen waar een PIR hangt maar ik niet meer functionaliteit nodig heb dan dat.

Het alternatief is: leg je alarmsysteem aan met PIRs, voorzie het alarmsysteem van een relaismodule waarmee je individuele pirs kan doorkoppelen als PV contact, koppel met een MDT binaire ingang de PIRs op KNX.

Binaire ingangen kosten wel €30 per stuk ongeveer zo uit mn hoofd, en een alarmsysteem met relaismodule...ligt aan de fabrikant. Al mag je die kosten niet helemaal mee rekenen als je toch al een alarmsysteem wilde

[Dennis]

teaser schreef op vrijdag 20 januari 2017 @ 07:32:
Ik heb Gira Dual Q rookmelders gekocht met buskoppelaar. De buskoppelaar is een aparte module, je kunt er ook een relaiscontact of draadloze module insteken. Nog niet geinstalleerd overigens.
Het is sowieso al moeilijk om een deftig uitziende rookmelder te vinden met relaiscontacten. De meesten zijn wel draadloos onderling koppelbaar, maar niet met een domoticasysteem. Met die van Gira kun je dus alle kanten uit.

Ja dat zijn mooie rookmelders, maar ik vind die KNX module ontzettend duur in vergelijking met de rookmelder zelf. Ik zou denk ik toch gaan voor het koppelen aan alarmsysteem middels relaismodule en voeding middels 230V. Het lijkt erop dat de KNX module niet voor een voeding zorgt, klopt dat?

Dat kan, als het alarmsysteem dat toelaat. De bewegingsdetectoren moeten dan wel rechtstreeks met het alarmsysteem gekoppeld worden, en dan zijn de mogelijkheden naar KNX toe weer beperkt. Of je werkt met aparte melders voor alarm en KNX. Deur- en raamcontacten uitlezen via het alarmsysteem geeft geen nadelen omdat die sowieso op een gewone input zouden hangen van het KNX systeem.

tss68nl schreef op vrijdag 20 januari 2017 @ 11:06:
Het alternatief is: leg je alarmsysteem aan met PIRs, voorzie het alarmsysteem van een relaismodule waarmee je individuele pirs kan doorkoppelen als PV contact, koppel met een MDT binaire ingang de PIRs op KNX.

Ja, de deur- en raamcontacten zijn het probleem niet, die gaan sowieso op het alarmsysteem. Maar je hebt ook bewegingsdetectoren nodig voor je alarmsysteem en dan is het wel zo mooi als je die ook meteen kunt gebruiken voor je domotica. Overigens wil ik een Satel Integra en daarvoor is een KNX-module verkrijgbaar. Je kunt alles gewoon prima doorkoppelen: daar heb je die relaismodule en MDT binaire ingangen niet voor nodig.

[teaser]

Dennis schreef op vrijdag 20 januari 2017 @ 11:25:
[...]

Ja dat zijn mooie rookmelders, maar ik vind die KNX module ontzettend duur in vergelijking met de rookmelder zelf. Ik zou denk ik toch gaan voor het koppelen aan alarmsysteem middels relaismodule en voeding middels 230V. Het lijkt erop dat de KNX module niet voor een voeding zorgt, klopt dat?

Je hebt, voor zover ik begrepen heb (want ik heb ze dus nog niet aangesloten) maar 1 KNX module nodig. De andere melders zou je zo aan mekaar kunnen koppelen. Je weet dan in KNX wel niet waar een alarm getriggerd is.
Voeding wordt door die KNX module inderdaad niet voorzien. Maar je wilt ook beschermd zijn als de bus er zou uitvallen, dus een batterij heb je toch nodig. En die gaat jaren mee.

[Rafael]

Femme schreef op donderdag 19 januari 2017 @ 18:47:
Je kunt ook twee keer utp-kabel door een buis trekken. Voor het aansluiten van 24V pulsdrukkers maakt het niet uit wat voor een kabel je gebruikt zolang het elektronen geleidt. Voor de toekomstbestendigheid kan het wel verstandig zijn om kwalitatief hoogwaardige kabel te trekken. Svv lijkt me dan als toekomstige communicatiekabel niet zo geschikt omdat niet getwist is.

Dat mag dus ook in plaats van de groene buskabel? De buskabel die ik zag was 2x2x0,8mm, maar ik heb nog een rol F/UTP cat 6 AWG 23 liggen, maar AWG23 is maar 0,57mm (als ik goed gezocht heb). Daarom de "2 keer" trekken en die dubbel nemen? Of hoe moet ik dat zien?

tss68nl schreef op donderdag 19 januari 2017 @ 20:04:
Ik doelde meer op de kosten voor buis/inslijpen etc dan van de kabel zelf. Al gaat in Belgie de boel doorgaans gewoon recht de muur en de vloer in toch? Dan is dat verschil ineens een stuk minder groot

Kosten voor inslijpen e.d. zijn te verwaarlozen: doe-het-zelf Kabels los de muur in mag onder bepaalde voorwaarden, maar ik ga ze toch allemaal in flexbuis stoppen.

tss68nl schreef op donderdag 19 januari 2017 @ 20:04:
Ook met scenes is het handig om te weten of de scene aan staat. Maar, de led's zijn onafhankelijk van de knoppen. Je kan dus bijvoorbeeld overal het ledje rechtsonder gebruiken om te signaleren dat er nog een deur van het slot is, of, dat er verlichting op de bovenverdieping aan is. Ook kan je de led gebruiken om aan te geven dat de lamp uit gaat schakelen, daar waar lampen een tijdvertraging hebben. Wat vaak wordt gedaan is de leds omdraaien: zet alle leds aan wara uberhaupt een functie onder zit, en maak ze een andere kleur of zet ze uit zodra de lamp aan is.

Heb je meteen orientatievrelichting door je hele huis Niet aan te raden op de slaapkamer overigens!

Das wel handig, hoewel een lamp die gaat uitschakelen misschien beter zelf even kort knippert? Zal harder opvallen dan een led in de schakelaar. Maar verder zijn dat wel goede ideeën om met de leds te doen, had ik nooit zelf aan gedacht.

tss68nl schreef op donderdag 19 januari 2017 @ 20:04:
Yep, de truc is om voor de minder blangrijke ruimtes aflternatieve oplossingen met deursensors, ir sensors of bundeling naar één unit toe te passen. En als het echt blijft steken op een simpele schakelaar dan is die Gira die ik eerder noemde wel een oplossing. €60, en je prikt hem zo op de bus in. Blijft €60, maar een SVV variant inclusief I/O unit in de meterkast is niet goedkoper

MDT heeft een 2 voudige input die bij in het inbouwpotje kan voor € 32. Niko opbouwdrukknopjes voor de kelder komen op € 12. Dan ben ik voorzien voor € 44 en heb ik nog de kans om daar later in te pluggen wat ik wil. Ik begin de voordelen meer en meer te zien.

Iemand trouwens ervaring met een Vaillant gasketel op KNX met bvb de Gira G1?

[tss68nl]

Rafael schreef op vrijdag 20 januari 2017 @ 16:20:
Dat mag dus ook in plaats van de groene buskabel? De buskabel die ik zag was 2x2x0,8mm, maar ik heb nog een rol F/UTP cat 6 AWG 23 liggen, maar AWG23 is maar 0,57mm (als ik goed gezocht heb). Daarom de "2 keer" trekken en die dubbel nemen? Of hoe moet ik dat zien?

Hooo wacht, Femme had het over UTP voor potentiaalvrije contacten zoals Niko. Voor de bus moet je zeker gewoon buskabel gebruiken omdat

• Er veel meer stroom overheen gaat -> de units gebruiken vermogen wat PV contacten niet doen
• De bus moet gegarandeerd afgescheiden zijn van 230V, wat een sterke en dikke (losse) mantel vereist
• De windingen in een buskabel zijn aangepast op de frequentie van KNX. UTP heeft een veel te hoge frequentie van windingen.

Kosten voor inslijpen e.d. zijn te verwaarlozen: doe-het-zelf Kabels los de muur in mag onder bepaalde voorwaarden, maar ik ga ze toch allemaal in flexbuis stoppen.

Maar dan loopt die flex door de vloer tot aan de verdeelkast? In NL zijn we gewend rigide buis te leggen van potje tot verdeel/meterkast, zodat je later er nog andere kabel in kan leggen. Als je ook 'wachtbuizen' wilt voorzien...ik raad je echt aan om rigide buis te nemen. Flexbuis is zeer lastig om achteraf nog draad door te trekken.

Das wel handig, hoewel een lamp die gaat uitschakelen misschien beter zelf even kort knippert? Zal harder opvallen dan een led in de schakelaar. Maar verder zijn dat wel goede ideeën om met de leds te doen, had ik nooit zelf aan gedacht.

Dat kan inderdaad.... maar zelf vind ik het mooier als alle lampen aan/uit "vloeien"...dus geen knipperen. Dan ga ik wel naar de disco

MDT heeft een 2 voudige input die bij in het inbouwpotje kan voor € 32. Niko opbouwdrukknopjes voor de kelder komen op € 12. Dan ben ik voorzien voor € 44 en heb ik nog de kans om daar later in te pluggen wat ik wil. Ik begin de voordelen meer en meer te zien.

Iemand trouwens ervaring met een Vaillant gasketel op KNX met bvb de Gira G1?

Dat is heel goedkoop die €12 opbouw schakelaars Ik denk niet dat er veel mensen reeds ervaring hebben met de G1. Is ook gewoon een doorgeefluik met wat leuke visualisaties voor instellen temp, lampen etc. Of het uit een G1 of een andere unit komt, maakt bij KNX weinig uit.

[Rafael]

tss68nl schreef op vrijdag 20 januari 2017 @ 17:09:
Hooo wacht, Femme had het over UTP voor potentiaalvrije contacten zoals Niko. Voor de bus moet je zeker gewoon buskabel gebruiken omdat

• Er veel meer stroom overheen gaat -> de units gebruiken vermogen wat PV contacten niet doen
• De bus moet gegarandeerd afgescheiden zijn van 230V, wat een sterke en dikke (losse) mantel vereist
• De windingen in een buskabel zijn aangepast op de frequentie van KNX. UTP heeft een veel te hoge frequentie van windingen.

Oeps Verkeerd begrepen dan, ik had de indruk dat het dan in de toekomst ook nog mogelijk was om je installatie om te vormen naar een KNX installatie en die UTP dus geschikt ging zijn.

tss68nl schreef op vrijdag 20 januari 2017 @ 17:09:Maar dan loopt die flex door de vloer tot aan de verdeelkast? In NL zijn we gewend rigide buis te leggen van potje tot verdeel/meterkast, zodat je later er nog andere kabel in kan leggen. Als je ook 'wachtbuizen' wilt voorzien...ik raad je echt aan om rigide buis te nemen. Flexbuis is zeer lastig om achteraf nog draad door te trekken.

Flex van potje tot verdeelkast, dus door de wand en door de vloer (chape op z'n Belgisch). Het nadeel van andere draad trekken neem ik er bij, hoe vaak komt het voor dat er draden gewisseld worden of nog bijgetrokken moeten worden... Ik hou er wel rekening mee tijdens het leggen van de flex, overal ruime bochten. Met een goede trekveer is het dan nog wel doenbaar, maar inderdaad veel moeilijker..

tss68nl schreef op vrijdag 20 januari 2017 @ 17:09:
Dat kan inderdaad.... maar zelf vind ik het mooier als alle lampen aan/uit "vloeien"...dus geen knipperen. Dan ga ik wel naar de disco

Maar voor dat vloeien heb je een dimmer nodig, een gewone MDT actor zou dat al niet kunnen... Toch?

tss68nl schreef op vrijdag 20 januari 2017 @ 17:09:
Ik denk niet dat er veel mensen reeds ervaring hebben met de G1. Is ook gewoon een doorgeefluik met wat leuke visualisaties voor instellen temp, lampen etc. Of het uit een G1 of een andere unit komt, maakt bij KNX weinig uit.

Vaillant / KNX combinatie algemeen dan.. Heb de vraag ook voorgelegd aan Vaillant zelf, ben benieuwd. Als we dan toch zouden investeren in een G1, kan die misschien ineens dienst doen als thermostaat en hoeven we niet zo'n lelijke, dikke Vaillant thermostaat te hangen... Al heb ik mijn twijfels of dat gaat lukken

[HyperBart]

Rafael schreef op maandag 16 januari 2017 @ 18:37:
[...]
Interessant, als die niet nader genoemde Tweaker dit leest, de interesse is er wel...

Ik ben op dit moment bezig met een upgrade naar de nieuwe versie. De oude doet nog meer als prima zijn werk, maar ik wil mee met de laatste versies om te voorkomen dat ik binnen X aantal maanden of jaar een serieuze inhaalactie moet doen.

Ik heb dus al een tijdje mijn volledige woning in HomeKit zitten en ben nu bezig om ook de ventilatie KNX en HomeKit toegankelijk te maken (https://github.com/snowdd1/homebridge-knx/issues/77).

Ik zal eens kijken of ik mijn huidige image (die nog bijzonder leeg is, kan anonimiseren want het laatste wat ik wel wil is dat er iets van mijn thuis op straat ligt .

[Rafael]

HyperBart schreef op maandag 23 januari 2017 @ 16:04:


Ik ben op dit moment bezig met een upgrade naar de nieuwe versie. De oude doet nog meer als prima zijn werk, maar ik wil mee met de laatste versies om te voorkomen dat ik binnen X aantal maanden of jaar een serieuze inhaalactie moet doen.

Ook direct een van de nadelen dan? Hoewel, een LogicMachine of zelfs een Loxone hebben ook regelmatig updates, dus dat is geen nadeel. Misschien zelfs een voordeel. Als je wat klaar krijgt, ik heb altijd interesse

Nog een bijkomende vraag: voor de zonwering dacht ik aan de buitentemperatuur en lichtmeting, waarna ik dan uitkom bij iets als deze Theben Luna. Is dat wat? Mij lijkt het handig dat deze rechtstreeks op de bus kan (en de prijs van € 245 valt best mee vond ik), maar ik las ook al dat het onverstandig is om je bus naar buiten te brengen? Kijk ik dan beter uit naar aparte 1-wire sensoren of is het toch niet zo'n ramp?

[bomberboy]

Rafael schreef op maandag 23 januari 2017 @ 16:44:
[...]
maar ik las ook al dat het onverstandig is om je bus naar buiten te brengen? Kijk ik dan beter uit naar aparte 1-wire sensoren of is het toch niet zo'n ramp?

Ik breng mijn bus ook naar buiten, maar ga er wel een aparte lijn van maken. Dit betekent dat standaard communicatie (je schakelt het licht op de slaapkamer aan) niet leesbaar is op die buitenlijn.

Je kan dan eigenlijk definiiëren welk type telegrams wel of niet over de verschillende lijnen heen mogen gaan en het voorkomt dat een inbreker zijn computer op de bus aansluit en het signaal geeft om alle deuren te openen.

Je moet er dan wel rekening mee houden in de topologie van je kabels dat "binnen" en "buiten" gescheiden zijn van elkaar.


edit ivm de zonwering: het kan ook relevant zijn om de windsnelheid te meten. Niet alle screens vinden windstoten van 60km/u leuk en dat kan ook een reden zijn om ze toch omhoog te doen ipv neer te laten.
En bij het programmeren wordt aangeraden om omgekeerd te redeneren.
Dit wil zeggen: je beslist niet op basis van een te hogen windsnelheid dat ze moeten binnengetrokken worden, maar je beslist dat als de windsnelheid lager is dan de drempel ze wel naar beneden mogen. Dat voorkomt ook problemen dat indien je windsensor het begeeft ze toch naar beneden gaan en de failsafe is dat ze altijd veilig opgerold zijn.

[ Voor 27% gewijzigd door bomberboy op 23-01-2017 17:28 ]

[tss68nl]

Rafael schreef op maandag 23 januari 2017 @ 16:44:
Ook direct een van de nadelen dan? Hoewel, een LogicMachine of zelfs een Loxone hebben ook regelmatig updates, dus dat is geen nadeel. Misschien zelfs een voordeel. Als je wat klaar krijgt, ik heb altijd interesse

Het verschil tussen Loxone/LogicMachine, en open-source software is, dat de software van die eerste groep niet wordt gemaakt door een eenling van 16 jaar oud, welke veilig weggestopt op de zolderkamer van moeders zijn hele interface in integratiemogelijkheden ongeveer 4x per jaar omgooit omdat hij in de volgende fase van zijn leerproces is aangekomen en nu beginnersfout #25 moet herstellen.

Beetje gechargeerd, maar zelfs grote projecten als PrestaShop hebben er last van: groot team, maar toch bij een minor versie upgrade *alles* op de schop van templatesysteem, moduleframework tot front-end scripting aan toe....alles van voorgaande versies compleet onbruikbaar.

Dus die software updates van Loxone durf ik wel aan, maar wordt altijd heel verdrietig van nieuwe versies van doe-het-zelf-software

Nog een bijkomende vraag: voor de zonwering dacht ik aan de buitentemperatuur en lichtmeting, waarna ik dan uitkom bij iets als deze Theben Luna. Is dat wat? Mij lijkt het handig dat deze rechtstreeks op de bus kan (en de prijs van € 245 valt best mee vond ik), maar ik las ook al dat het onverstandig is om je bus naar buiten te brengen? Kijk ik dan beter uit naar aparte 1-wire sensoren of is het toch niet zo'n ramp?

Je kan de bus naar buiten brengen, als je:

• De twee netwerken galvanisch gescheiden houdt. Dus twee aparte voedingen, en een galvanisch gescheiden lijnkoppelaar. (Let op dat ze niet allemaal galvanisch gescheiden zijn!)
• Je de lijnkoppelaar (of KNX Router) dusdanig configureert dat je groepadressen van buiten gecommuniceerd worden, en binnen volledig afgeschermd wordt.

[HyperBart]

Rafael schreef op maandag 23 januari 2017 @ 16:44:
[...]


Ook direct een van de nadelen dan? Hoewel, een LogicMachine of zelfs een Loxone hebben ook regelmatig updates, dus dat is geen nadeel. Misschien zelfs een voordeel. Als je wat klaar krijgt, ik heb altijd interesse

Goh, ik noem vooruitgang en ontwikkeling geen nadeel, en HomeKit is volop in ontwikkeling dus tja een hobby mag tijd kosten zeker ?

Zonet alles al klaar kunnen zetten voor ventilatie . Magnifiek blijf ik dat HomeKit vinden. Moet er dringend eens een blogpost over schrijven.

[HyperBart]

tss68nl schreef op maandag 23 januari 2017 @ 18:43:
[...]


Het verschil tussen Loxone/LogicMachine, en open-source software is, dat de software van die eerste groep niet wordt gemaakt door een eenling van 16 jaar oud, welke veilig weggestopt op de zolderkamer van moeders zijn hele interface in integratiemogelijkheden ongeveer 4x per jaar omgooit omdat hij in de volgende fase van zijn leerproces is aangekomen en nu beginnersfout #25 moet herstellen.

Nou nou nou . Overdrijf je niet een beetje? . Zo erg is het nu toch ook niet, plus als ik het mij goed herinner heeft de devver zich moeten aanpassen aan Homekit en niet uit zichzelf, omdat Homekit nu zowat alle devices en bijhorende classes ondersteunt. Maw je kan prima een garagepoort aanmaken die bij wijze van spreken een temperatuur aanneemt in Homekit. Beetje raar voorbeeld maar je snapt me wel, en volgens mij is dat iets wat pas recent in HK zit...

[stekkel]

Ik haak wat laat in maar ik lees hier het e.e.a. over Dali vs DMX. Het probleem met DMX is dat er geen enkele logica in een dmx device zit en alle intelligentie van de dmx controller moet komen die ook nog eens continue met max 240kbps te dmx bus moet aansturen zonder dat er iets veranders is.

Met Dali gebeurt dat allemaal decentraal in de driver. Scenes, groepen, fade time, fade rate (fade stappen bij een up en een down), minimum dim waarde, maximum dimwaarde, power on dimwaarde, laatst gebruikte dimwaarde, dim curve. Allemaal decentraal in firmware opgeslagen. Daarnaast heeft dali een device discovery mechanisme zodat je geen id's per driver hoeft in te stellen. Via dali bus commando's is alles in te stellen.

Ik heb hier gelezen dat het standby verbruik van dali devices hoog zou zijn. De standaard schrijft voor dat de interface maximaal 2ma mag verbruiken. In de ontwerpen van daliinterfaces die op het internet te vinden zijn is de grootste stroomverbruiker de led van de optocoupler tussen de bus en de mcu. Door deze default uit te zetten en pas aan te zetten bij een logische 1 op de bus gaat de idle stroom richting de 0,25ma (heb de interface net ontworpen die tevens ook als ebus of opentherm interface kan dienen).

Ik weet het e.e.a. van dali omdat ik als hobbyprojectje toevallig heb ik de nieuwe Dali2 standaard geïmplementeerd in c++ met als oorspronkelijke bedoeling om uiteindelijk met een arduino nano 4 meanwell ldd drivers aan te sturen. Ik was begonnen met de AMD reference implementatie die 8KB aan gecompileerde C code was. Gelukkig kreeg ik de beschikking over de nieuwe dali 2 101, 102, 103 standaard en heb ik besloten om die reference implementatie terzijde te leggen want wat structuur en implementatie betreft vond ik het helemaal niks en heb alles from scratch herschreven en tevens alle nieuwe Dali 2 functionaliteit toegevoegd als multi master ondersteuning. Wat wel positief is dat die referentieimplementatie alle benodigde registers direct schreef dus dat heb ik maar overgenomen zodat ik een 100% interrupt gestuurde implementatie over hield zonder gebruik te maken van arduino libraries.

Resultaat, 5KB gecompileerde c++ code en volledige protocol ondersteuning en < 200bytes geheugen gebruik (kan nog kleiner).

Zonder de uren te rekenen heb je dan voor 30 euro een 4 kanaals driver excl. een externe 48V voeding. Als je de externe voeding dan ook nog kan controleren en afsluiten als er geen lamp aan is, dan is je idle gebruik alleen je busvoedinggebruik en dat is dan 5mW voor 4 devices.

Vervolgens ook in de dali 2 103 standaard voor sensoren gedoken, Deze moet ik nog implementeren maar als je de dali 2, 102 standaard geïmplemeteerd hebt dan ben je al voor 90% klaar. Die sensor standaard is wel interessant. Je kan dan drukknoppen, pirsensoren, etc etc op basis van de dali standaard implementeren. Daar is wel een applicatiecontroller voor nodig maar dat kan die zelfde arduino zijn. De applicatiecontroller stuurt op basis van de sensor informatie de commando's voor de dali gear devices op de bus. Maar het gaat verder, je kan ook je eigen sensoren als temperatuur, co2 e.d. allemaal aan de dalibus hangen. Het is aan de applicatiecontroller om daar wat nuttigs mee te doen. Omdat in principe iedere dali device een applicatiecontroller kan zijn is het wel handig dat je de rules op de applicatiecontroller opslaat (dus in de driver, de schakelaar, whatever). Als je domoticasysteem er dan uitvliegt en de bus blijft draaien dan zit de configuratie decentraal.

Het nieuwe plan is een stap verder. Er is namelijk meer dan licht alleen en had ook al EBUS nodig voor het aansturen van een ventilatiesysteem en er moeten ook kleppen (0-10v), rolluiken, gordijnen, noem maar op aangestuurd kunnen worden. In principe kan het meeste via de dalibus maar eigenlijk wil ik daar protocol onafhankelijk zijn. Verder is de dalistandaard niet zaligmakend voor aan/uit devices.

Zo als het er nu naar uitziet kies ik voor de arm cortex m0+ en knal ik er gelijk een ruleengine op waardoor je in principe een complete domotica oplossing hebt. Ik zal dan ook andere interface als modbus, KNX, ethernet, ebus, opentherm, dmx512, 1-wire en mogelijk ook de wireless protocollen als zwave, zigbee en klikaanklikuit ondersteunen. DMX512 is de makkelijkste. Met die M0+ kan ik met 240Kbps in standby modus draaien en toch 240kbps op de dmx bus gooien (door de I2S interface te misbruiken).

Met de ruleengine moet het dan mogelijk zijn om wat je maar wilt in te regelen o.a. gateway/bridge functionaliteit en device specifieke commando's aan protocollen toe te voegen. Als de ruleengine dan ook nog in templatevorm te vullen is dan kan er een mooi ecosysteem ontstaan. Het moets dan ook mogelijk zijn om 64 devices vanaf 1 unit aan te sturen (is gelijk je hele dalibus vol maar pluggable interfaces van 5 euro per stuk lost dat probleem op).

De kunst is de configuratie compact op te slaan maar aan de andere kant, met 256KB flash waar een dynamische gedeelte als eeprom te gebruiken is moet dat niet zo'n probleem zijn. De device info is i.i.g niet het probleem als je bedenkt dat een dali device minimaal 14 bytes eepromruimte vraagt, oftewel > 400x minder dan dit bericht.

Het meeste werk is eigenlijk de userinterface. Ik was al begonnen met nodejs/angular2 met als bedoeling om via de raspberrypi de dalibus aan te sturen maar nieuwe plan is dus eerst die ruleengine met een blockly interface en eens kijken of dat ook rechtstreeks op een cortex m0 te draaien is via websockets of udp. CPU load zal niet intens zijn omdat de userinterface een kwestie van een keer de javascript binnen halen (kan van usb interface op de m0+ afgetrokken worden) en de rest is alleen maar low traffic want updates via websockets of udp zijn slechts enkele bytes per keer.

In the end hoop ik alle overprices gateways de markt uit te kunnen prijzen want stuk voor stuk kosten die dingen aan materiaalkosten hooguit 25-50 euro en voor een KNX device 8 euro meer vanwege de dure chip. De rest is software.

[Rafael]

bomberboy schreef op maandag 23 januari 2017 @ 17:23:
edit ivm de zonwering: het kan ook relevant zijn om de windsnelheid te meten. Niet alle screens vinden windstoten van 60km/u leuk en dat kan ook een reden zijn om ze toch omhoog te doen ipv neer te laten.
En bij het programmeren wordt aangeraden om omgekeerd te redeneren.
Dit wil zeggen: je beslist niet op basis van een te hogen windsnelheid dat ze moeten binnengetrokken worden, maar je beslist dat als de windsnelheid lager is dan de drempel ze wel naar beneden mogen. Dat voorkomt ook problemen dat indien je windsensor het begeeft ze toch naar beneden gaan en de failsafe is dat ze altijd veilig opgerold zijn.

Dan ben ik beter af met het weerstation van MDT. Kost quasi evenveel en zou meer functies hebben. Ziet er alleen wat fragiel uit.

tss68nl schreef op maandag 23 januari 2017 @ 18:43:
Je kan de bus naar buiten brengen, als je:

• De twee netwerken galvanisch gescheiden houdt. Dus twee aparte voedingen, en een galvanisch gescheiden lijnkoppelaar. (Let op dat ze niet allemaal galvanisch gescheiden zijn!)
• Je de lijnkoppelaar (of KNX Router) dusdanig configureert dat je groepadressen van buiten gecommuniceerd worden, en binnen volledig afgeschermd wordt.

Best een dure oplossing, ruw geteld een kleine € 300... Nog eens narekenen, maar dan lijkt een 1-wire oplossing alweer goedkoper. Al die keuzes

[tss68nl]

HyperBart schreef op maandag 23 januari 2017 @ 22:54:
Nou nou nou . Overdrijf je niet een beetje? . Zo erg is het nu toch ook niet, plus als ik het mij goed herinner heeft de devver zich moeten aanpassen aan Homekit en niet uit zichzelf, omdat Homekit nu zowat alle devices en bijhorende classes ondersteunt. Maw je kan prima een garagepoort aanmaken die bij wijze van spreken een temperatuur aanneemt in Homekit. Beetje raar voorbeeld maar je snapt me wel, en volgens mij is dat iets wat pas recent in HK zit...

Ik zeg toch, ik chargeer Maar het raakt wel een essentieel probleem met open source software. Je komt om in de packages, frameworks, versies, afhankelijkheden etc. Iedereen bouwt maar wat, en kennis van zaken is niet vereist.

Dat wil zich nog wel eens vertalen in zeer onstabiele projecten, die je beter als 'goed voorbeeld om iets te doen' kan gebruiken, dan dat je daadwerkelijk afhankelijk blijft van de developer.

Natuurlijk is HomeKit voorzien van nieuwe features, maar dat betekent niet dat je de config van Homebridge helemaal moet verbouwen. Wat reeds kon, had hetzelfde kunnen blijven werken, en de extra classes en mogelijkheden hadden bijgevoegd kunnen worden.
In het uiterste geval was het zelfs beter geweest om 'versie 2' classes naast de oude te zetten, en de oude als het ware door te koppelen op de nieuwe. Deprecated notice erbij in de docs, en pas support droppen over een paar jaar. Oh right.....documentatie

Met open source draait het eigenlijk altijd uit op één van de twee volgende dingen:

• Je neemt een oude versie van de software in eigen beheer en past deze aan alleen op die punten, die strikt noodzakelijk zijn voor je eigen integratie.
• Je upgrade voor de nieuwe standaard mogelijkheden, en pakt het rework wat daar regelmatig bij hoort voor lief.

Begrijp me niet verkeerd...ik maak er graag gebruik van, maar weeg het altijd wel af tegen betaalde varianten die gewoon nette backwards compatible releases maken. Voor storage en videoopslag/cameras kan je ook zelf van alles aan elkaar bouwen, alleen als ik dan de €600 voor een Synology er tegen af zet....doe mij maar de Synology De hardware is inderdaad overpriced....maar tegen de features kan ik niet op programmeren

Ik vind Homebridge leuk hoor... werkt prima (al is hij regelmatig onbereikbaar). Maak me alleen zorgen of ik het wel steeds weer wil upgraden om in de lucht te houden Ga waarschijnlijk nog één keer upgraden...een paar dingen erbij bouwen die ik zelf nodig heb, en dan bevriezen. Kijken wanneer ik daar een keer tijd voor heb

[bartvb]

stekkel schreef op dinsdag 24 januari 2017 @ 03:52:
Ik weet het e.e.a. van dali omdat ik als hobbyprojectje toevallig heb ik de nieuwe Dali2 standaard geïmplementeerd in c++ met als oorspronkelijke bedoeling om uiteindelijk met een arduino nano 4 meanwell ldd drivers aan te sturen

[...]

De rest is software.

Wow, klinkt super tof!

DALI vind ik (technisch gezien) zeker de betere optie t.o.v. DMX. Maar zoals tss68nl ook aangeeft heeft Dali ook best een aantal nadelen zoals het standby gebruik van veel Dali devices en de verschillen tussen Dali versies.

Als je echter de mogelijkheid hebt om een eigen Dali LED driver te maken/gebruiken die vrijwel geen standby gebruik heeft dan ben je in een klap van die nadelen af. Aan wat voor een driver zit je te denken? Wat zou je in totaal nodig hebben bij jouw oplossing? En komt je code ergens beschikbaar? Klinkt bijzonder goed!

Wat betreft het automatiseren van meer dingen via de Dali-bus; ik zou zelf gaan voor een ander systeem. Er hebben mensen al honderden uren gestopt in het aan de praat krijgen van andere domoticasystemen, dit allemaal vanaf scratch bouwen lijkt mij een bijzonder grote opgave. Zeker als je dit later constant up to date wil houden. Die energie zou ik dan eerder in een bestaand project stoppen zodat dit project samen met anderen verder komt.

Maar wat de Dali LED drivers betreft; ik ben bijzonder geïnteresseerd!

[stekkel]

bartvb schreef op woensdag 25 januari 2017 @ 08:57:
[...]


Wow, klinkt super tof!

DALI vind ik (technisch gezien) zeker de betere optie t.o.v. DMX. Maar zoals tss68nl ook aangeeft heeft Dali ook best een aantal nadelen zoals het standby gebruik van veel Dali devices en de verschillen tussen Dali versies.

Als je echter de mogelijkheid hebt om een eigen Dali LED driver te maken/gebruiken die vrijwel geen standby gebruik heeft dan ben je in een klap van die nadelen af. Aan wat voor een driver zit je te denken? Wat zou je in totaal nodig hebben bij jouw oplossing? En komt je code ergens beschikbaar? Klinkt bijzonder goed!

Wat betreft het automatiseren van meer dingen via de Dali-bus; ik zou zelf gaan voor een ander systeem. Er hebben mensen al honderden uren gestopt in het aan de praat krijgen van andere domoticasystemen, dit allemaal vanaf scratch bouwen lijkt mij een bijzonder grote opgave. Zeker als je dit later constant up to date wil houden. Die energie zou ik dan eerder in een bestaand project stoppen zodat dit project samen met anderen verder komt.

Maar wat de Dali LED drivers betreft; ik ben bijzonder geïnteresseerd!

Thnx

Dali voor lichtbesturing in huis is naar mijn mening inderdaad superieur t.o.v. andere oplossingen.

Technisch gezien was ik begonnen met de atmel reference implementatie die je op de atmel side kan downloaden. Die is voor 8 bit, 8 Mhz, 512 byte rom avr cpu's. Dat was de inspiratie en die code heb ik compleet herschreven. Standaard kan je op die 8 bitters makkelijk 4 PWM kanalen aansturen met 4096 resolutie (Dali heeft een resolutie van 254 bit, een hogere resolutie is voor smooth fading). Probleem dat ik moest oplossen is dat er maar voor 2 PWM kanalen een 16 bit clock beschikbaar was (om PWM in te stellen) maar met een 8 bit clock en meerdere loops kan je ook een hogere resolutie krijgen. Nog simpeler is er een pwm driver chip aan te hangen met 16 pwm kanalen.

Als je dat voor elkaar hebt dan hoeft je alleen nog maar met het pwm signaal een driver aan te sturen. De meanwell ldd reeks ondersteunt dat. Dat zijn blokjes van 2 bij 3 cm met een pwm in en een DC in tot 65V en verkrijgbaar in 300ma, 500, 600, 700 ..... ma. Die hebben een DC-DC efficiency van rond de 95%, afhankelijk van spanning in/spanning uit verhouding. Deze drivers kosten rond de 5 - 7,5 euro. Als je dan ook nog een mosfet tussen Vin en de drivers zet dan gaat het standby gebruik van 1ma naar 0 ma. Een atmel avr cpu gebruikt enkele ua in powerdown mode en wordt snel genoeg wakker via een interrupt van een dali signaal op de interface. Ik denk dat het mogelijk is om 64 dali kanalen met 1 mcu aan te sturen mocht je dat willen maar dat is redelijk pointless want je wilt de drivers decentraal en via de bus aansturen anders blijf je kabels trekken.

Als mijn project af is en ik besluit er commercieel niks mee te doen dan gooi ik het op github.

Wat de rest betreft, daar twijfel ik ook af en toe. Punt is dat ik sowieso meerdere protocollen wil ondersteunen en in de basis alle protocollen overeenkomsten hebben. Met een goed opgezette basis kan je met weinig effort meer ondersteunen. Bijvoorbeeld ebus, dali en opemtherm kan ik op bit niveau met dezelfde code ondersteunen. Alleen de frame opbouw verschilt. Alle protocollen hebben iets van een adres en een commando in zich waarbij de commando's ook nog eens overlap hebben. Ik ben nu zo veel mogelijk protocollen aan het absorberen zodat op architectuurniveau je met dezelfde basis alles kan ondersteunen. Specifiek zijn acties als priority mechanismen en foutafhandeling maar ook daar zitten weer grote overeenkomsten. Er blijft dan alleen nog mapping over van protocol 1 naar protocol 2 en dat is binnen de mogelijkheden van een protocol ook niet zo heel ingewikkeld.

Maar de sleutel tot dit alles is een ruleengine en een iets zwaarder arm m0+ mcu met voldoende eeprom opslag. Als je flexibel wilt zijn dan moet je iets van een ruleengine hebben zodat je dynamisch de condities en acties kan definiëren. Als je dat hebt dan kan je in principe alles ondersteunen zonder extra effort behalve het invoeren van de rules. Die ruleengine wil ik toch al maken om bijvoorbeeld een menustructuur op een oled scherm op te kunnen bouwen. Je hebt de ruleengine ook nodig om te anticiperen op sensor data binnen het protocol. Als je dan de variablen voor een rule-engine juist definieert en verschillende types en lists aan kan en deze compact kan opslaan, de rules ook nog eens buffert zoals reet rule-engines, dan kan je op een embedded device bijna alles. Alleen de basis zaken en de wat ingewikkelde actions maak je macro's voor of programmeer je in c++. Dingen als dauwpunt berekeningen, sunset, drukverliesberekingen voor ventilatiesystemen, warmteverlies berekeningen op basis van sensor inputs en ruimte properties e.d. ondersteun je dan als basis.
Je kan default op low level de nodige protocol levels en implementeren en op een hoger level de boel aan elkaar knopen met rules.

Het up2date houden is dan gereduceerd tot aanpassen van rules. De user interface, die is het meest ingewikkeld want ik moest mij dingen als asynchone requests met observer patterns e.d. aanleren op angular 2. CSS was ook niet mijn ding. Daar zit ook het onderhoud op en dat gedeelde zou ik het liefst geschikt willen maken voor andere systemen zodat ik niet zelf iedere keer apps e.d. moet genereren. Aan de andere kant, ik ben al iets aan het bouwen met widgets, dynamische forms en een event system waardoor die kant ook dynamisch is en ook met een rule-engine ingeregeld kan worden. Je user interface is dan ook ineens dynamisch en relatief onderhoudsarm. Het enige wat dan nog resteert is externe devices. Maar als het protocol reeds ondersteund wordt is de ondersteuning van een device niet meer dan de ondersteunde properties kennen en die kunnen instellen.

Maar nu nog afmaken

[bartvb]

Haha, en ik denk dat je met die laatste zin de crux van je verhaal te pakken hebt

In concept is het allemaal inderdaad niet ingewikkeld maar the devil is in the details. Bij dit soort systemen is het relatief 'eenvoudig' om een basis werkend te krijgen in relatief weinig tijd. Het overgrote deel van de tijd, energie en frustratie zin in het afmaken. Alle edge cases, compatibiliteit met externe zaken, updates van externe systemen/frameworks, etc, etc.

Als ik jou zo hoor zou ik je echt heel (heel) erg aanraden om eerst te focussen op een ding. B.v. eerst zorgen dat het aansturen van drivers via Dali feilloos werkt. Daarbij natuurlijk prima om rekening te houden met andere protocollen, maar first things first.

Het grote bezwaar van je systeem, zoals ik het zie, is dat je opzet niet heel modulair is. Vrijwel alles zit in geoptimaliseerde C++ code waar verder niet heel veel mensen mee uit de voeten kunnen. Ook los je een hoop problemen op die al lang zijn opgelost door b.v. Symcom, Loxone, KNX, openHAB, HomeAssistant, etc, etc, etc. En die systemen integreren met meer zaken dan jij in je leven voor elkaar kan krijgen. Al is het maar omdat je geen toegang hebt tot alle compatible apparatuur.

Maar bovenstaande hangt allemaal ook heel erg af van je doel. Wat wil je bereiken? Een stabiel platform om beter en goedkoper je LED verlichting aan te sturen? Een compleet custom domoticaplatform voor je eigen huis? Een project om regenachtige zondagen te vullen? Een domoticaplatform dat je kan verkopen? Al die dingen zorgen voor nogal andere prioriteiten en tijdpaden.

[ Voor 13% gewijzigd door bartvb op 25-01-2017 11:42 ]

[teaser]

Bij mijn zoektocht naar een goeie visualisatie en centrale logicasturing zit ik ook een beetje met het dilemma of ik nu voor een dure kant-en-klare oplossing moet gaan, of een DIY oplossing waar de grootste investering tijd is.

OpenHAB heb ik al aan de praat gekregen (zeer basic, 2 lampen aansturen). Maar na mijn dagelijkse activiteiten als programmeur ontbreekt het me wat aan goesting om 's avond weer mentale arbeid te verrichten achter de computer, dus het is er nog niet van gekomen hier meer mee te doen.

Voor de kant-en-klare oplossingen heb ik ondertussen wat zoekwerk verricht en 4 systemen bekeken: xxter, ayControl, iRidium en LogicMachine.
De voordeligste zijn ayControl en iRidium, maar hier betaal je ook enkel voor een software license. Voor de hardware (bv een RPI) moet je zelf zorgen. En 'voordelig' is ook nog relatief, want je betaalt nog steeds 600-800 euro.
Zowel xxter als LogicMachine zijn effectief een hardwaremodule die je in de verdeelkast inbouwt. Ze zijn gelijkaardig geprijsd, al heb je bij LM ook goedkopere/duurdere versies met minder/meer mogelijkheden, terwijl xxter gewoon 1 standaardmodule heeft.

stekkel schreef op woensdag 25 januari 2017 @ 10:25:
Als mijn project af is en ik besluit er commercieel niks mee te doen dan gooi ik het op github.

Jij zit ook op bouwinfo he?

[stekkel]

bartvb schreef op woensdag 25 januari 2017 @ 11:41:
Het grote bezwaar van je systeem, zoals ik het zie, is dat je opzet niet heel modulair is. Vrijwel alles zit in geoptimaliseerde C++ code waar verder niet heel veel mensen mee uit de voeten kunnen. Ook los je een hoop problemen op die al lang zijn opgelost door b.v. Symcom, Loxone, KNX, openHAB, HomeAssistant, etc, etc, etc. En die systemen integreren met meer zaken dan jij in je leven voor elkaar kan krijgen. Al is het maar omdat je geen toegang hebt tot alle compatible apparatuur.

Maar bovenstaande hangt allemaal ook heel erg af van je doel. Wat wil je bereiken? Een stabiel platform om beter en goedkoper je LED verlichting aan te sturen? Een compleet custom domoticaplatform voor je eigen huis? Een project om regenachtige zondagen te vullen? Een domoticaplatform dat je kan verkopen? Al die dingen zorgen voor nogal andere prioriteiten en tijdpaden.

Ik heb niet de illusie om out of the box alles te ondersteunen. Key is protocol vanuit de specificaties. Als bepaalde apparatuur daar niet mee over weg kan dan is dat een edge case die ik niet wil oplossen. Deze bottem up benadering leidt mijn inziens tot minder problemen dan dat je vanuit de device begint te denken en werkend gaat maken. Dat blijf je bezig met aanpassingen omdat de volgende device net weer andere dingen van onderliggende protocollen gebruikt. Heb in het verleden te veel ellende gezien waarbij niet vanuit de protocol specs geprogrammeerd werd. Chaos krijg je daarvan.

Voor mijzelf wil ik niet meer dan pwm sturing van leds, pir sensoren, lumen sensoren, hall sensoren temp/vocht/co2 sensoren, rolluikbediening, 0-10v sturing, ebus sturing, klep sturing en wat complexer, een systeem om drukverlies in ventilatiekanalen te berekenen en op basis daarvan klepstanden in te stellen op basis van klepcurves en drukverlies input. Verder wat andere bouwfysica zaken als warmteverlies berekeningen e.d. om slimme dingen te doen met je temperatuur inputs.

Wat betreft de geoptimaliseerde c++ code. Ja, maar daar ziet een enduser niks van. Het enige wat de end-user ziet is een list van devices met protocol en een blockly interface voor de spannende dingen. Als een device extended commands heeft dan moet client side op basis van een device id de extended commands ondersteunen. Zolang het binnen het protocol past zou de embedded device er mee over weg moeten kunnen. Ik leg alleen de basis archituur neer waarmee toekomstige devices eenvoudig ondersteund kunnen worden.

Dat is de softwarekant.

Aan de hardware kant heb ik de standaard interfaces en extenties al uitgedacht waarbij op basis van automatische detectie de mcu precies weet welke uitbreiding het is. Kwestie van 256 id's reserveren en bij het opstarten de id's uitlezen uit sequentiëel gekoppelde shiftregisters. Zo weet ik welk type hardware interface er aan hangt, of het een I/O kaart is, een 0-10V kaart, noem maar op. Externe hardware zijn busdevices die je niet anders dan regulier gewoon via buscommando's kan aansturen. Uitbreidingskaarten kan ik zelfs via I2C extenders op afstand zetten en onbeperkt koppelen. Als geen hoge snelheid gewenst, en dat is zelden nodig voor simpele aan/uit acties, dan kan je op deze wijze in theorie eenvoudig duizenden poorten aansturen. Voor inputs kan je irq's delen en de data inlezen. binnen een ms kan je heel wat poorten inlezen en actie ondernemen. Dus trigger, ruleset ophalen en actie.

De modulariteit zit dus aan de hardwarekant en aan de softwarekant door een ruleengine die in principe alles zou moeten ondersteunen. De enige beperking is opslag maar het enige wat ruimte kost zijn strings. Een rule is in principe niet meer dan een byte voor de conditie, een adres voor var 1 en var 2. En een ruleset is niet meer dan een trigger, een list van rules en een list met actions. Dat kan dus allemaal heel compact.

[tss68nl]

Een domotica systeem bouwen via Dali? Ja, dat kan, en dat kan ook via 100 andere protocollen. Sterker nog, het is al 300+ keer gedaan. Iedere fabrikant heeft tegenwoordig zijn eigen bussysteem. Het grootste nadeel is doorgaans dat het goed werkt rond hun eigen core business, maar elders tekort schiet. Kijk eens bij Somfy bijvoorbeeld (ja, van de zonwering)... die willen ook al je lampen aansturen over hun zonweringsbus

Als Tweaker snap ik de uitdaging, en het is leuk om zoiets te bouwen om zelf kennis op te doen! Als je het puur voor jezelf bouwt, dan wordt dat wel je project waar al je tijd in gaat zitten. Het programmeren van een dergelijk systeem is zeer tijdrovend. De vraag is dan: kan je wel vergelijken op prijs? Je rekent al je eigen uren niet mee, maar in die tijd had je ook bijvoorbeeld kunnen werken (zeker als je voor jezelf werkt, is die vergelijking zeer valide).

Dus ik vind de vergelijking wel scheef:

• Ja ik kan voor €40 een Dali gateway bouwen. Maar hoeveel dagen werk gaan daar in zitten?
• Ik kan er ook één kopen voor €300. Dat is hooguit een dag werken, in loondienst 3 omdat het van netto af moet.
• Wil je meer controle en alle features zelf bepalen? Dan is er een LogicMachine voor €1000 waar je nog veel meer mee kan, maar, ook met een aantal standaard libs binnen notime je DMX of Dali in de lucht hebt. Voor 3 dagen werk...ga ik m'n vingers dan nog steeds niet branden aan zelfbouw.

Ik ben meer van het gebruiken van reeds bestaande producten, en kijken hoe die makkelijk aan elkaar passen. Zo kan ik op meer gebieden een verschil maken, dan dat ik alles een eigen project moet maken. Slapen is ook belangrijk soms!
Ik heb wel een eigen data-analyse/logging systeem gebouwd omdat ik niet kon vinden wat ik zocht. Maar zelfs daar steek ik meer tijd in het zoeken naar een betaald alternatief, dan het doorontwikkelen van m'n eigen product. Er gaat gewoon teveel tijd in zitten, en anderen er blij mee maken...dan moet je ook weer ondersteuning gaan bieden, en allerlei features inbouwen die ik zelf niet zou gebruiken.

Wat betreft Dali vs DMX:
Ik dacht ook ooit dat Dali veel geschikter is voor besturing van lampen in huis omdat het speciaal ontwikkeld is voor die toepassing. Maar in de praktijk is Dali gewoon nog niet volwassen genoeg. Dat klinkt vreemd voor zo'n oud protocol...maar ze hebben het alle kanten op laten groeien. Het is *echt* een puinhoop met verschillende versies, geen backwards compatibility etc:

• Dali devices moeten altijd aan staan vanwege dat de Dali driver zelf alles uitvoert, als de driver een busbericht mist....dan is het game over. Het sluipverbruik is bij veel drivers gewoon niet goed omdat de idle stand pas veel te laat aan gaat, of niet. Ipv een paar mA verbruikt een dergelijke driver rustig 100mA.
• Protocol verschillen: niet alle Dali apparaten werken met elkaar door alle verschillende versies én dialecten. Dat gaat beter worden, maar is nog niet zo. Je kan natuurlijk een combinatie vinden die nu werkt, maar wees a.u.b. niet verbaasd als je over 2 jaar een nieuw Dali product wil installeren/vervangen, dat je hele systeem vervangen moet worden.
• Dali heeft een max van 64 kanalen per universe/gateway/buslijn. Dat lijkt veel, totdat je RGBW accent verlichting gaat gebruiken, of duotone witlicht. Dali rekent echt per kanaal.
• Logica in de driver lijkt een voordeel, maar als je nieuwere features wil gaan gebruiken is het een groot nadeel. Bij centrale logica in de gateway upgrade je de gateway en doen alle drivers vrolijk mee. Bij Dali begint het werk dan pas, want alle drivers moeten worden vervangen om een nieuw trucje te kunnen.

Het blijft wel zo dat er iets meer goedkope Dali drivers te vinden zijn. Wel is het zo, dat die vaak maar één Dali kanaal hebben, op 2 LED outputs wat het aantal kanalen van een driver reduceert maar dat hoeft geen probleem te zijn.

Ik blijf Dali best interessant vinden, maar ik denk dat ik pas Dali wil adviseren als het protocol ook echt stabiel is, en we er van uit kunnen gaan dat de Dali producten over 5 of 10 jaar nog steeds zullen werken met Dali. Klinkt vreemd die laatste zin, maar toch is het zo

[stekkel]

teaser schreef op woensdag 25 januari 2017 @ 13:29:
Bij mijn zoektocht naar een goeie visualisatie en centrale logicasturing zit ik ook een beetje met het dilemma of ik nu voor een dure kant-en-klare oplossing moet gaan, of een DIY oplossing waar de grootste investering tijd is.

OpenHAB heb ik al aan de praat gekregen (zeer basic, 2 lampen aansturen). Maar na mijn dagelijkse activiteiten als programmeur ontbreekt het me wat aan goesting om 's avond weer mentale arbeid te verrichten achter de computer, dus het is er nog niet van gekomen hier meer mee te doen.

Voor de kant-en-klare oplossingen heb ik ondertussen wat zoekwerk verricht en 4 systemen bekeken: xxter, ayControl, iRidium en LogicMachine.
De voordeligste zijn ayControl en iRidium, maar hier betaal je ook enkel voor een software license. Voor de hardware (bv een RPI) moet je zelf zorgen. En 'voordelig' is ook nog relatief, want je betaalt nog steeds 600-800 euro.
Zowel xxter als LogicMachine zijn effectief een hardwaremodule die je in de verdeelkast inbouwt. Ze zijn gelijkaardig geprijsd, al heb je bij LM ook goedkopere/duurdere versies met minder/meer mogelijkheden, terwijl xxter gewoon 1 standaardmodule heeft.


[...]

Jij zit ook op bouwinfo he?

Yes

Scheelt verder dat ik geen programmeur ben en het niet meer dan hobby is en met een sabatical bezig ben. Ik heb er lol in om nieuwe dingen aan te leren. Afgelopen jaar c++, typescript, javascript eigen gemaakt en alles van internals van MCU's voor lekker low level geneuzel. En ondertussen ook nog op het bouwfysica vlak eigen gemaakt. Je moet wat als je dingen voor elkaar wilt krijgen. Scheelt natuurlijk wel dat ik in het verleden wel meer geprogrammeerd heb en iets met elektrotechniek als opleiding heb.

Als ik niet de tijd zou hebben dan zou ik ook voor LogicMachine of OpenHab oplossingen gaan. OpenHab heeft wel een aardige architectuur en dat Eclipse SmartHome ziet er als standaard goed uit. Heb alleen geen zin om Java aan te leren en zelf bindings te gaan schrijven. Domoticz vind ik niks. Heb de code eens doorgebladerd en word niet echt vrolijk hoe ze per device ondersteuning bieden.

[stekkel]

tss68nl schreef op woensdag 25 januari 2017 @ 14:26:
Een domotica systeem bouwen via Dali? Ja, dat kan, en dat kan ook via 100 andere protocollen. Sterker nog, het is al 300+ keer gedaan. Iedere fabrikant heeft tegenwoordig zijn eigen bussysteem. Het grootste nadeel is doorgaans dat het goed werkt rond hun eigen core business, maar elders tekort schiet. Kijk eens bij Somfy bijvoorbeeld (ja, van de zonwering)... die willen ook al je lampen aansturen over hun zonweringsbus

Als Tweaker snap ik de uitdaging, en het is leuk om zoiets te bouwen om zelf kennis op te doen! Als je het puur voor jezelf bouwt, dan wordt dat wel je project waar al je tijd in gaat zitten. Het programmeren van een dergelijk systeem is zeer tijdrovend. De vraag is dan: kan je wel vergelijken op prijs? Je rekent al je eigen uren niet mee, maar in die tijd had je ook bijvoorbeeld kunnen werken (zeker als je voor jezelf werkt, is die vergelijking zeer valide).

Dus ik vind de vergelijking wel scheef:

• Ja ik kan voor €40 een Dali gateway bouwen. Maar hoeveel dagen werk gaan daar in zitten?
• Ik kan er ook één kopen voor €300. Dat is hooguit een dag werken, in loondienst 3 omdat het van netto af moet.
• Wil je meer controle en alle features zelf bepalen? Dan is er een LogicMachine voor €1000 waar je nog veel meer mee kan, maar, ook met een aantal standaard libs binnen notime je DMX of Dali in de lucht hebt. Voor 3 dagen werk...ga ik m'n vingers dan nog steeds niet branden aan zelfbouw.

Tja, hobby en een sabatical, heb lang genoeg voor mezelf gewerkt Maar je punten zijn valide.

Wat betreft Dali vs DMX:
[list]
• Ik dacht ook ooit dat Dali veel geschikter is voor besturing van lampen in huis omdat het speciaal ontwikkeld is voor die toepassing. Maar in de praktijk is Dali gewoon nog niet volwassen genoeg. Dat klinkt vreemd voor zo'n oud protocol...maar ze hebben het alle kanten op laten groeien. Het is *echt* een puinhoop met verschillende versies, geen backwards compatibility etc:

Ik ken alleen de dali 1 en dali 2 standaard. Dali 2 is volledig backwards compattible en bevat een hele lijst met testprocedures voor certificering. Gecertificeerde producten zouden moeten werken. Met Dali 2 denk ik dat het wel een stuk volwassener wordt omdat ze vanuit de standaard drukknoppen e.d. gaan ondersteunen die je op een uniforme wijze kan programmeren.

• Dali devices moeten altijd aan staan vanwege dat de Dali driver zelf alles uitvoert, als de driver een busbericht mist....dan is het game over. Het sluipverbruik is bij veel drivers gewoon niet goed omdat de idle stand pas veel te laat aan gaat, of niet. Ipv een paar mA verbruikt een dergelijke driver rustig 100mA.

Dat is dan een slechte driver. Een driver is niet meer dan een spanningsvoorziening, een businterface en een mcu. Met de MCU kan je de spanningsvoorziening standby of uit zetten. De MCU kan zelfs in power down mode staan en snel genoeg wakker worden door een interupt van de interface bij een 0 op de bus. De interface mag niet meer dan 2ma gebruiken volgens de standaard. Mijn interface gebruikt minder dan 0,25ma en de MCU kan buspowered zijn en gebruikt in standby enkele microampères. De MCU verbruikt hooguit 5ma wanneer die aan staat en een busframe moet afhandelen. Dat verdisconteerd zich met een switched regulator in een paar ma.
Wanneer een driver aanstaat dus een PWM signaal ontvangt, kan de MCU in standby draaien. Het PWM signaal loopt gewoon door. Alleen tijdens fades staan ze wat langer aan. Het is mogelijk om alles binnen de <2 ma eis te krijgen al is meer stroomverbruik mogelijk als het op de driver is aangegeven.

Dus ik herken mij niet in hoog sluipverbruik van dali drivers.

• Protocol verschillen: niet alle Dali apparaten werken met elkaar door alle verschillende versies én dialecten. Dat gaat beter worden, maar is nog niet zo. Je kan natuurlijk een combinatie vinden die nu werkt, maar wees a.u.b. niet verbaasd als je over 2 jaar een nieuw Dali product wil installeren/vervangen, dat je hele systeem vervangen moet worden.

Hehe, gelukkig maak ik mijn eigen drivers dus dat probleem heb ik niet.

• Dali heeft een max van 64 kanalen per universe/gateway/buslijn. Dat lijkt veel, totdat je RGBW accent verlichting gaat gebruiken, of duotone witlicht. Dali rekent echt per kanaal.

Dali ondersteund ook 6 kanaals RGBWXX devices met één ID. Part 209: Particular requirements for control gear – Colour control (device type

• Logica in de driver lijkt een voordeel, maar als je nieuwere features wil gaan gebruiken is het een groot nadeel. Bij centrale logica in de gateway upgrade je de gateway en doen alle drivers vrolijk mee. Bij Dali begint het werk dan pas, want alle drivers moeten worden vervangen om een nieuw trucje te kunnen.
[/list]

De Dali device blijft een dom ding. Het ondersteunt slechts een paar dingen als fade, groups en scenes. De slimme logica zit toch al op de gateway / dali master. Zonder dali master kan je namelijk de sensor inputs van drukknoppen, pir sensoren e.d. niet afhandelen. Daar zit dan ook de intelligentie. Je kan daar ook eenvoudig virtuele groepen e.d. maken al kost dat meer bustijd. Daar waar je op device niveau groepen kan gebruiken is dat altijd beter want dan hoeft je maar 1 commando op de bus te gooien.

Op Dali device niveau kan je wel meer intelligentie stoppen door extra commando's te ondersteunen of het ding in een compleet andere mode te zetten (wordt vanuit protocol ondersteund), Verder kan je met eigen framesizes werken. Die moeten genegeerd worden door andere dali devices die dat niet ondersteunen. Ik vermoed dat aan die kant veel mis gaat doordat dali devices het protocol niet goed implementeren en aan de gang gaan met de eerste 16 bits van proprietary custom frames.

Het blijft wel zo dat er iets meer goedkope Dali drivers te vinden zijn. Wel is het zo, dat die vaak maar één Dali kanaal hebben, op 2 LED outputs wat het aantal kanalen van een driver reduceert maar dat hoeft geen probleem te zijn.

Ik blijf Dali best interessant vinden, maar ik denk dat ik pas Dali wil adviseren als het protocol ook echt stabiel is, en we er van uit kunnen gaan dat de Dali producten over 5 of 10 jaar nog steeds zullen werken met Dali. Klinkt vreemd die laatste zin, maar toch is het zo

De omarming van Dali 2 met sensors is key. Met de steeds goedkopere mcu's hoeft de hardware geen drol meer te kosten. Het dali gedeelte met interface is te maken voor minder dan 2 euro aan componenten. De rest is niet anders dan niet dali drivers. Wanneer dit zich vertaald in goedkopere dali producten dan zou het ook interessant zijn voor de woningmarkt. Een standaard bus voor verlichting heeft toch wel iets. Maar de tijd zal het leren.

[HyperBart]

Grrrrrrrrrrr, zonet de MDT AIO in gebruik genomen (nog niet aangesloten op de ventilatie unit). Merk ik op dat via Homekit het percentage op de bus wordt gezet als een 2 byte float (DPT 9) ipv een 1 byte percentage (5.001). Ik zie door de conversie van ETS netjes wel "het getal" wat ik ingesteld heb op Homekit voorbij vliegen, maar het de input van MDT kan daar niet veel mee natuurlijk.

Terwijl ik deze post schreef eens wat anders geprobeerd en als DPT op de input nu 9.007 gekozen wat overeenkomt met Humidity% en dat werkt wel, als in 'ik kan sliden en ik krijg het respectievelijke voltage' Ik hoop dat dit geen problemen gaat geven als ik met een schakelaar of scene de ventilatie ga willen bedienen, maar via HomeKit kan ik nu toch al wel een 0-10V signaal uitsturen .

To be continued...

[ Voor 5% gewijzigd door HyperBart op 26-01-2017 00:09 ]

[Anoniem: 174333]

Hallo,

Ik lees al een tijdje mee met grote interesse. Inmiddels heb ik een boek gekocht (Heimautomation mit KNX, DALI, 1-Wire und Co.) wat samen met dit topic een schat/overvloed aan informatie is.

Nu kom ik echter op het moment dat ik zelf eens wat gaan proberen ofwel een aantal basis bouwblokjes kopen (IP-router, voeding, schakelmateriaal ed.)

Nu was ik aan het loeren op de eerdergenoemde duitse aanbieder site welke vele spullen aanbied. Echter zie ik ook dat waarschijnlijk veel fabrikanten elkaars modellen delen ? dus dat maakt de keuze wat eenvoudiger. Ik ben echter een leek op dit gebied en vroeg mij dus af of er ook enkele ervaringen zijn op dat gebied ?

Zijn alle IP routers goed van de bekende merken zoals Gira, Abb, Jung, Merten, Enertek, etc of moet ik enkele links laten liggen ?

Zijn alle voedigen met trafo ? aangezien ze zo groot zijn, ik heb ook een Apricum voeding gezien welke een stuk kleiner is bij zelfde vermogen, denk switched psu en hiervan is ook de efficiëntie terug te vinden (82%) ? Ofwel wat is een zuinige, betrouwbare voeding aangezien er ook vele merken zijn.

En weet iemand een goede keuze voor een relais welke een inductieve (spoel) van ongeveer 230V/2500W zou kunnen schakelen ?

Bedankt.

[Rob Z]

De gerenommeerde merken verkopen doorgaans geen rommel.
Voedingen met trafo zijn voor normale toepassingen (buiten audio etc.) geheel verleden tijd. Kies je er een van bijvoorbeeld het merk Meanwell dan zit je goed.

[teaser]

Als voeding moet je zeker een KNX voeding gebruiken met smoorspoel. Niet zomaar eender welke voeding is hiervoor geschikt.

Een IP router heb je meestal niet nodig, met een IP interface heb je doorgaans genoeg. Wil je ooit een visualisatie aan je KNX installatie hangen kan het wel handig zijn een interface te nemen die meerdere tunnels tegelijk kan openen. Bv de MDT SCN-IP000.01 supporteert er 4, de ABB IPS/S 2.1 slechts 1.

[Anoniem: 174333]

Rob Z schreef op vrijdag 27 januari 2017 @ 10:53:
De gerenommeerde merken verkopen doorgaans geen rommel.
Voedingen met trafo zijn voor normale toepassingen (buiten audio etc.) geheel verleden tijd. Kies je er een van bijvoorbeeld het merk Meanwell dan zit je goed.

Sorry ik heb het een beetje krom omschreven maar ik bedoelde dat een KNX busvoeding intern een opbouw heeft met een transformator blok (50Hz) of een geschakelde voeding (zoals computervoeding met hogere efficiëntie dan de eerst genoemde).

Een IP router heb je meestal niet nodig, met een IP interface heb je doorgaans genoeg. Wil je ooit een visualisatie aan je KNX installatie hangen kan het wel handig zijn een interface te nemen die meerdere tunnels tegelijk kan openen. Bv de MDT SCN-IP000.01 supporteert er 4, de ABB IPS/S 2.1 slechts 1.

Dit is inderdaad handige informatie, ik was van mening dat een IP interface slechts één tunnel kon openen en vandaar de router omdat deze meerdere kan. Nu zie ik inderdaad dat de genoemde er geen probleem mee heeft meerdere te openen.

[teaser]

Ik denk dat er sowieso geen rommel op de markt te vinden is qua knx producten, aangezien elk toestel met knx logo door een certificatieprocedure moet gaan. Zie https://www.knx.org/no/kn...y/certification/index.php

Ip routers zijn vooral nuttig om meerdere knx lijnen of area's met mekaar te verbinden. In een doorsnee huis is zoiets nogal overbodig

[Rafael]

Misschien een stomme vraag, maar toch voor de zekerheid (heb nog geen testmateriaal). De short en long press, zal de short press altijd eerst getriggered worden aangezien dit aparte objecten zijn? Dus bvb short press triggert object 1, houdt je hem langer in, triggert object 2 mee?

Voor bijvoorbeeld een "alles uit" na een long press. Stel dat ik een short press op "toggle" voor licht zet, en long press een "off" verstuurd, zal eerst de lamp zelf schakelen en daarna alles uitschakelen? Of wordt object 1 niet geschakeld zolang de bediening aanhoudt? (Zo is het bij Loxone geloof ik)

[tss68nl]

Rafael schreef op zaterdag 28 januari 2017 @ 13:19:
Misschien een stomme vraag, maar toch voor de zekerheid (heb nog geen testmateriaal). De short en long press, zal de short press altijd eerst getriggered worden aangezien dit aparte objecten zijn? Dus bvb short press triggert object 1, houdt je hem langer in, triggert object 2 mee?

Voor bijvoorbeeld een "alles uit" na een long press. Stel dat ik een short press op "toggle" voor licht zet, en long press een "off" verstuurd, zal eerst de lamp zelf schakelen en daarna alles uitschakelen? Of wordt object 1 niet geschakeld zolang de bediening aanhoudt? (Zo is het bij Loxone geloof ik)

Alleen stomme antwoorden bestaan

Nee hij triggert altijd alleen maar één van de twee. Omdat er op een knop een long-press is gedefinieerd, wacht hij totdat je de knop loslaat.
Als je alleen maar een normale functie hebt geprogrammeerd, dan reageert hij direct, ondanks dat je hem langer vast houdt. Programmeer de daar één of meerdere long-presses bij, dan zal hij altijd wachten tot je hem loslaat om te bepalen welke functie je wilde hebben.

Bij mij werkt normaal, 0.5 sec en 3 sec prima op één knop. Ik heb eigenlijk nooit de verkeerde functie te pakken

[Rafael]

tss68nl schreef op zaterdag 28 januari 2017 @ 13:48:
Bij mij werkt normaal, 0.5 sec en 3 sec prima op één knop. Ik heb eigenlijk nooit de verkeerde functie te pakken

En als je hem dan bvb 5 sec inhoudt, krijg je toch nog gewoon de actie van 3 sec na het loslaten? Ideaal dan. Tussendoor, niet om je op te jagen, al eens tijd gehad om naar m'n mailtje te kijken?

[tss68nl]

Rafael schreef op zaterdag 28 januari 2017 @ 15:03:
[...]


En als je hem dan bvb 5 sec inhoudt, krijg je toch nog gewoon de actie van 3 sec na het loslaten? Ideaal dan. Tussendoor, niet om je op te jagen, al eens tijd gehad om naar m'n mailtje te kijken?

Je krijgt dan na 3 seconden al de actie van 3 seconden. De twee seconden erna maken geen verschil meer. Hij voert het direct uit zodra hij kan bepalen welke actie het gaat worden.

Heb em wel gezien, maar nog niet geantwoord. Tikkie druk, komt goed!

[ Voor 6% gewijzigd door tss68nl op 28-01-2017 15:19 ]

[HyperBart]

Creatief vraagje van de dag:

Kan je met één 5G1.5 kabel 2 zonwering gerelateerde apparaten bedienen? Zijnde in casu screens aan de buitenzijde en gordijnen of van die doeken aan de binnenzijde?

Volgens mij moet dat te doen zijn met DC motoren, maar blijkbaar is dat niet zo courant aan de buitenzijde, binnenzijde op 24V DC wel.

Ik zie er namelijk nogal tegenop om op termijn een sleuf rondom mijn huis te moeten graven en een nieuwe kabel in te voegen in het metselwerk. (dat kan, aangezien onze woning nog niet ingevoegd is).

[teaser]

Ja met DC heb je maar 2 draden nodig per motor.
Met AC heb je voor 2 motoren toch minstens 5 draden nodig als je de neuter voor beiden hetzelfde kunt nemen. Dus dat gaat niet lukken.

[HyperBart]

Ja ik vreesde er al voor. Ken jij toevallig DC buitenmotoren?

[teaser]

Ik denk niet dat het een probleem is dat te vinden. Laat je je screens plaatsen? Gewoon vragen voor tweedraadsaansturing. Zou me straf lijken dat dat niet mogelijk is, 24V motoren bestaan gewoon, of dat nu voor binnen of buiten is maakt niets uit.

[tss68nl]

Ik ben vandaag naar de ISE 2017 beurs geweest, maar dat was niet helemaal wat ik er van had verwacht. Aanwezigheid van KNX is dit jaar nog veel verder uitgedund dan vorig jaar: de KNX hal was zelfs voorzien van veel fabrikanten die helemaal niets met KNX doen.

De rest van de beurs bestaat voornamelijk uit audio & video producten. LED-array schermen, en 85 verschillende HDMI over IP protocollen. De meeste protocollen worden aangemerkt als home-automation, omdat ze ook via IP een bedieningsknop hebben voor de functies van de audio/video centrale versterker. Stuk voor stuk denken ze allemaal dat zij de home-automation standaard worden, en dat bussystemen volledig zullen verdwijnen.

Voor diegenen die nog overwegen om te gaan: ik vond het persoonlijk wat zonde van mijn tijd. Tenzij je echt gaat voor audio/video, daar is wel wat van te vinden. Al is het meeste wel op reclame/winkelinrichting gericht, er is ook in de blauwe hal een hoek met consumer audio/video te vinden.

Volgend jaar is de Light+Building beurs in Frankfurt weer (om de twee jaar), en daar is wel zeer veel KNX te vinden. Voornamelijk Building

[HyperBart]

Heeft iemand het volgende wel eens aan de hand gehad?




Ik snap bv. niet hoe je op ieder device wat de IP interface aanspreekt kan zorgen dat hij telkens de juiste connectie gebruikt. Blijkbaar zou de MDT IP IF die ik heb meerdere connecties moeten ondersteunen, maar moet ik daar wel mee aan de slag? Is die limiet er echt of is dat omdat ik onbedoeld een bepaalde manier van connecteren gebruik terwijl ik eigenlijk een andere manier zou moeten gebruiken die geen connecties opsoupeert of connecties deelt?

Ik heb bv. een rPi voor Homekit, een tweede test-rPi voor Homekit en tot slot een VM met Grafana die connecteren met de IP IF. Dan zou ik in theorie nog eentje moeten overhebben voor mijn ETS?

EDIT: Nevermind, er stond nog een ETS op een VM open in Diagnostics

[ Voor 40% gewijzigd door HyperBart op 08-02-2017 13:33 ]

[bartvb]

Dank, tss68nl!
Ik had ISE op de agenda staan maar is helaas niet haalbaar ivm de rest van de planning hier.
Overigens nog wel op zoek naar een plek om eens wat schakelmateriaal te bekijken. Plaatjes op de websites van de fabrikanten zijn leuk, maar onvoldoende om een indruk te krijgen van de kwaliteit.

Maar goed om te horen dat ik weinig aan ISE heb gemist dus

[Dennis]

Ik ben ook blij met je review van ISE, ik had hem voor vrijdag gepland staan. Zal nog even overleggen met degene met wie ik zou gaan.

Jammer dat KNX zo beperkt aanwezig is inderdaad.

[teaser]

Ik had ISE vandaag op de planning staan maar door plotse ziekte niet kunnen gaan. Nu vind ik het toch al wat minder erg, want ik ging (uiteraard) vooral voor de KNX hal.

[teaser]

KNX Inside is gelanceerd

KNX Inside is een soort beperkte ETS (max 1 project, max 1 line) die op een mini pc draait, verbonden met je installatie. Via een web interface kun je dan parameters en groepsadressen wijzigen zoals met ETS. Een installateur kan dus zijn klanten toegang geven tot de installatie en zelf parameters laten wijzigen.
Prijs voor 1 licentie: 160 EUR.

Op zich een goeie vernieuwing, want een KNX installatie was voor de eindgebruiker echt een gesloten systeem. Daar komt nu eindelijk verandering in. Al heb ik er een dubbel gevoel bij: het lijkt weer iets extra waar geld uit kan geslagen worden, 160 EUR (excl BTW uiteraard) is toch ook niet weinig.

Ook de beperking van 1 lijn steekt me wat tegen. Een tweede (buiten)lijn is nu ook weer niet zo abnormaal voor residentiële toepassingen.

[tss68nl]

teaser schreef op donderdag 16 februari 2017 @ 07:32:
KNX Inside is gelanceerd

KNX Inside is een soort beperkte ETS (max 1 project, max 1 line) die op een mini pc draait, verbonden met je installatie. Via een web interface kun je dan parameters en groepsadressen wijzigen zoals met ETS. Een installateur kan dus zijn klanten toegang geven tot de installatie en zelf parameters laten wijzigen.
Prijs voor 1 licentie: 160 EUR.

Op zich een goeie vernieuwing, want een KNX installatie was voor de eindgebruiker echt een gesloten systeem. Daar komt nu eindelijk verandering in. Al heb ik er een dubbel gevoel bij: het lijkt weer iets extra waar geld uit kan geslagen worden, 160 EUR (excl BTW uiteraard) is toch ook niet weinig.

Ook de beperking van 1 lijn steekt me wat tegen. Een tweede (buiten)lijn is nu ook weer niet zo abnormaal voor residentiële toepassingen.

Ze hebben alleen wel één hele grote ontwerpfout gemaakt: Windows 10. Naast het feit dat een minipc met Windows 10 licentie even goed nog aardig aan de prijs is (die leveren ze zelf niet), is Windows 10 niet te installeren zonder de automatische update + herstart. Dit zorgt er voor dat je KNX Inside logica iedere twee weken even een tijdje offline gaat.

De oplossing is waarschijnlijk om een apart vlan te maken, waar geen toegang is tot internet (dus geen windows updates) na de initiële installatie.

Wat wel mooi is....je mag 255 devices gebruiken met ETS Inside, op een licentie van €160. Het is wel beperkt tot devices die een standaard ETS config hebben. Plugins worden niet toegestaan. Niet dat je die 255 devices fysiek op één lijn kan aansluiten, maar toch een leuk gebaar.

Ik ga het wel eens testen hier. Heb een ESXi server ingericht, en daar kan ik prima een Windows10 machine mee in de lucht brengen. Voor je het weet kan je je vriendin de ETS programmering laten doen...

[Anoniem: 157611]

De hell van het buizen leggen en kabels trekken is achter de rug en is goed gelukt, de dekvloer is inmiddels droog en alles heeft het overleefd Warmtepomp en zonnepanelen draaien goed, vloerafwerking is nu bezig, dan spuiten van de woning, keuken enz, gaat de goede kant op.


dekvloer eroverheen, ondertussen is die al droog, dit was net na het zetten

Feit is nu wel dat ik een hoop knx spul ga bestellen de komende weken, en ik nu ben beland bij de vvw actor en de aansturing van de zones.

Even een snelle vraag tussendoor voordat ik weer volledig de tijd heb om in dit knx topic te duiken, ik heb veel moeten schuren en stucen waardoor ik totaal niet aan knx-en ben toegekomen, tot nu dan zo'n beetje. KNX speelt overigens tijdens de afbouw voortdurend door je hoofd, om gek van te worden

Ik wil natuurlijk de vloerverwarming zones gaan sturen (16 in totaal) dmv de bekende thermomotortjes. Ik heb gelezen dat het niet goed te doen is, of in elk geval veel gedoe kan gaan geven, wordt afgeraden enz.

Dat de warmtepomp warmte moet leveren op het moment dat je de verdeler aanstuurt kan ik als leek inkomen en dat dat warmte geven afhangt van de thermistors die zijn ingesteld op de warmtepomp ook. En dus als de ruimte waar de thermistor hangt of waar ze hangen warm genoeg is/zijn, dat de ruimte zonder thermistor op de verdeler kan opendraaien wat ie wil maar dat de warmte pomp op dat moment geen warmte levert, dus de ruimte met vraag niet warmer kan worden op dat moment. Begrijpelijk, ik zal me hier op moeten gaan inlezen.

Lijkt mij dat de warmtepomp op een of andere manier in de winter moet kijken naar de koudste kamer met vraag en op basis daarvan bepalen of er warmte geleverd wordt, zodat alle ruimtes kunnen sturen op die warmte. Omgekeerd in de zomer met koelen kijken naar de warmste kamer en op basis daarvan koelte leveren. Dus thermistoren in elke ruimte hebben die verbonden zijn met de warmtepomp. puntje om uit te zoeken.

Dat er dan ook nog allerlei andere factoren gaan meespelen als hoeveel ramen, welke verdieping, schijnt de zon, isolatie enz daargelaten. gestoord veel nadenk werk, komt later wel.

Maarrrr, alleen komt bij mij nu de vraag op hoe dat straks dan gaat met koelen in de zomer. Ik heb een Zubadan warmtepomp buitenunit geinstalleerd, met ecodan binnenunit die in de zomer over de verdelers koel water kan gaan geven. Ik kan alleen niks vinden over hoe je de thermomotortjes open kunt zetten op basis van temperatuur verlaging in de zomer. Als je in de winter de temperatuur in een zone wilt verhogen draait die zone verder open, als je in de zomer de temp wilt verlagen zou die ook open moeten draaien.

Kun je dit aangeven bij het programmeren van de tastsensor / thermostaat ?

Het lijkt me nu dat het bij de thermostaat moet worden ingegeven, tenminste bij sommige actoren kan ik wel zien dat ze bijv koelingplafonds kunnen aansturen, maar de meeste hebben een zomer programma waarbij de zones op de verdeler dichtstaan en een paar minuten per dag worden gezet ter voorkoming dat ze vast gaan zitten.

Voordat ik nog 3 dagen verspil, weet iemand of dit uberhaupt kan met de huidige verwarmings actoren / tastsensor - thermostaten, of waar ik op moet zoeken ? Of wordt het een kwestie van omwegen zoeken en het foppen van het systeem om dit voor elkaar te krijgen ? (kan ik me overigens niet voorstellen anno 2017)

En dan te bedenken dat dit nog maar 1 aspect is van het moeras waar in dreig te verdwijnen, ahhhhhhhhhhhrgrg

[ Voor 8% gewijzigd door Anoniem: 157611 op 19-02-2017 10:36 ]

[HyperBart]

Klinkt bekend

[Femme]

Anoniem: 157611 schreef op zondag 19 februari 2017 @ 10:20:

Ik wil natuurlijk de vloerverwarming zones gaan sturen (16 in totaal) dmv de bekende thermomotortjes. Ik heb gelezen dat het niet goed te doen is, of in elk geval veel gedoe kan gaan geven, wordt afgeraden enz.

Ik heb zelf zo'n systeem gebouwd (niet op basis van knx) en bij mij werkt het best goed. Ik gebruik 1-wire temperatuursensoren met een nauwkeurigheid van zo'n 0,05℃. Dit maakt het mogelijk heel nauwkeurig de ventielen te regelen als de vloer warm is of er niet zoveel warmte in een vloer opgeslagen kan worden (bijv. droogbouw). Een betonnen vloer die helemaal afgekoeld is heeft uren nodig om op te warmen. Dit laat zich niet zo makkelijk regelen.

Dat de warmtepomp warmte moet leveren op het moment dat je de verdeler aanstuurt kan ik als leek inkomen en dat dat warmte geven afhangt van de thermistors die zijn ingesteld op de warmtepomp ook. En dus als de ruimte waar de thermistor hangt of waar ze hangen warm genoeg is/zijn, dat de ruimte zonder thermistor op de verdeler kan opendraaien wat ie wil maar dat de warmte pomp op dat moment geen warmte levert, dus de ruimte met vraag niet warmer kan worden op dat moment. Begrijpelijk, ik zal me hier op moeten gaan inlezen.

Een warmtepomp wordt meestal gecombineerd met een buffervat. Dat maakt de naregeling wat makkelijker omdat er nog wel een tijdje warmte in het buffervat zit op het moment dat de compressor uitslaat. Idealiter wil je een koppeling tussen de zoneregeling en de warmtepomp. Ik denk niet dat je dit makkelijker voor elkaar gaat krijgen in knx.

Lijkt mij dat de warmtepomp op een of andere manier in de winter moet kijken naar de koudste kamer met vraag en op basis daarvan bepalen of er warmte geleverd wordt, zodat alle ruimtes kunnen sturen op die warmte. Omgekeerd in de zomer met koelen kijken naar de warmste kamer en op basis daarvan koelte leveren. Dus thermistoren in elke ruimte hebben die verbonden zijn met de warmtepomp. puntje om uit te zoeken.

Ik heb een seriële interface aan mijn warmtepomp (Nibe F1145) hangen waarmee ik de warmtepomp in beperkte mate kan sturen (stooklijn verschuiven en doeltemperatuur regelen). Door het verschil tussen de actuele temperatuur en de doeltemperatuur te regelen in de ruimte waar de warmtepomp de temperatuur meet (dat doet hij bij mij ook maar op één plek terwijl ik ook zestien zones wil regelen) kan ik de warmtevraag wat bijsturen. Dit werkt niet perfect maar wel vrij goed. Tevens heb ik alle meetgegevens van de warmtepomp beschikbaar en kan ik de verwarming blokkeren.

Dat er dan ook nog allerlei andere factoren gaan meespelen als hoeveel ramen, welke verdieping, schijnt de zon, isolatie enz daargelaten. gestoord veel nadenk werk, komt later wel.

Een goede zoneregeling zorgt ervoor is dat je ondanks al deze externe factoren toch een vrij stabiele temperatuur hebt. Ik heb hier ook een huis waarin de verschillende per ruimte in het effect van bijvoorbeeld zoninstraling erg groot zijn.

Maarrrr, alleen komt bij mij nu de vraag op hoe dat straks dan gaat met koelen in de zomer. Ik heb een Zubadan warmtepomp buitenunit geinstalleerd, met ecodan binnenunit die in de zomer over de verdelers koel water kan gaan geven. Ik kan alleen niks vinden over hoe je de thermomotortjes open kunt zetten op basis van temperatuur verlaging in de zomer. Als je in de winter de temperatuur in een zone wilt verhogen draait die zone verder open, als je in de zomer de temp wilt verlagen zou die ook open moeten draaien.

Mijn warmtepomp heeft een potentiaalvrije uitgang waarmee je de koelstatus kunt uitlezen. Wellicht heeft jouw warmtepomp dat ook en kun je daar iets mee in jouw knx verhaal. Als koeling = aan en ruimtetemperatuur hoger dan gewenst, dan klep openzetten.

[Skyaero]

Ik heb weinig ervaring op gebied van KNX, maar de wens die je beschrijft @Anoniem: 157611 is regeltechnisch best ingewikkeld. Je spreekt over 16 groepen die je individueel wilt regelen. Je zit regeltechnisch dan op een niveau van een gemiddeld kantoorgebouw. En daar worden kostbare gebouwbeheersystemen gebruikt (bijv PRIVA) om het geheel een beetje te laten werken.

Als je het alleen hebt over verwarming:
- je kunt een thermostaat koppelen aan een groep. Temperatuur te laag -> flowregelaar verder open. Temperatuur te hoog -> flowregelaar dichter zetten. Ga je wel een PID achtige regeling voor nodig hebben, omdat vloerverwarming traag is.
- Zaken als zon zou ik geen expliciet rekening mee houden, dat is een enorm lastige regelfactor. Een goede PID regeling pakt zoninvloeden reeds (deels) op.
- Je warmtepomp wil je niet regelen via de thermostaten, maar puur op retourtemperatuur. Je warmtepomp wordt dan gedreven door warmtevraag en niet door een delta-T van de thermostaat.
- Bij bovenstaande is het handig een drukgeregelde pomp te hebben: als alle flowregelaars (bijna) dicht staan, draait de pomp minder hard dan als alle flowregelaars open staan.

Wil je ook koeling toepassen:
- Dan wordt ergens centraal een switch gemaakt van winter naar zomermode. Dit kan op basis van buitentemperatuur (vereist wel een hystereselus om dag/nacht omschakelingen te voorkomen) of op basis van een tijdsschema (welke maanden zomer en welke maanden winter).
- Bij het omschakelen, gaat de warmtepomp in de aircomodus en regelen de thermostaten op basis van koelvraag. Dit betekent ook dat als er een ruimte wel warmtevraag heeft, er een blokkering moet plaatsvinden (dwz koelvraag = 0 -> flowregelaar = dicht).

Ik twijfel of dit allemaal met KNX kan.

Bij grotere kantoren zie je bijvoorbeeld dat koel- en verwarmingscircuits gescheiden zijn, zodat een deel van het kantoor nog altijd verwarmd kan worden, terwijl een ander deel gekoeld wordt.

[Dennis]

Ik begrijp niet alles wat je vraagt @Anoniem: 157611, maar er zijn warmtepompen die met opentherm werken. Kun je die dan niet koppelen aan de Theben KNX OT-S?

Airco ben ik niet zo in thuis, maar ik weet wel dat losse airco-units aan KNX te koppelen zijn. Geïntegreerd in je bestaande systeem is natuurlijk mooier, maar of dat kan?

[tss68nl]

Anoniem: 157611 schreef op zondag 19 februari 2017 @ 10:20:
De hell van het buizen leggen en kabels trekken is achter de rug en is goed gelukt, de dekvloer is inmiddels droog en alles heeft het overleefd Warmtepomp en zonnepanelen draaien goed, vloerafwerking is nu bezig, dan spuiten van de woning, keuken enz, gaat de goede kant op.

Foppen van systemen is juist met systemen als PRIVA aan de orde van de dag, omdat ze niet met alternatieve vormen van energie om kunnen gaan.

Wat betreft de integratie van alle techniek in KNX:

• Bedenk hoe je het zelf handmatig zou regelen. En zoek de componenten die die specifieke functie voor je automatiseren. Dat maakt het veel minder complex.
• Zijn er niet-KNX componenten die jou het handmatig regelen ook al makkelijker zouden maken? Ja? Mooi, want dat scheelt weer logica/complexiteit.
• Begin simpel met een stabiele basis. Finetunen kan altijd nog.
• Stop met zoeken naar één magic-box die alles voor jouw specifieke situatie oplost. Die zijn er helaas nog niet.

Hoe je het volgens mij heel simpel kan oplossen:

• Je hebt per kamer een zone-sturing nodig als je ze echt allemaal individueel wilt regelen. Bekijk of je bepaalde ruimten kan groeperen. Bijvoorbeeld, alle slaapkamers? Gang erbij (die doorgaans toch al opwarmt/koelt door de aan/afvoer van de kamers), alle zones woonkamer + open keuken? De vloer verspreid de warmte, maar de lucht ook, zeker als je een temperatuurverschil in een open ruimte probeert te creëren.
• Bepaal per groep van zones, welke temperatuurmetingen je wilt doen. Veel controllers nemen meerdere temperaturen aan en nemen het gemiddelde.
• Neem per groep van zones een PI-controller. Dat kan in de vorm van een centrale unit (ABB en Theben hebben die), maar ook in de vorm van een roomcontroller zoals Ekinex die heeft. Deze schermpjes geven de huidige en doeltemperatuur/modus weer van de zone, én bevatten de logica om de klep(pen) aan te sturen, óók met vertragingstijd.
• Meten van de temperaturen door alle ruimten kan tegenwoordig met al het goede schakelmateriaal wat je aan de muur hangt. Die temperaturen link je dan gewoon op de gekozen PI-controller(zij het een schermpje, of een vaste unit)
• Dan blijft er over dat de ketel moet weten wanneer en van welke temperatuur er water geleverd moet worden. De simpelste variant is een standaard temperatuur, en een drukgestuurde pomp zoals eerder al werd genoemd. Draai je dan toevallig bijna alle ventielen dicht, dan zal de pomp veel minder hard gaan lopen. Andere opties zijn de Theben OT box waarmee je stooklijnen kan aanpassen en eigenlijk heel veel kan instellen aan je levering.
• Aansturen van ventielen gaat gewoon met 230V of 24V Triac actuators, vaak heating actuators genoemd. Die bestaan er zeer veel voor KNX, waaronder die van ABB, Theben en Ekinex. Kijk goed naar de combinatie ventiel/actuator. Je kan uitrekenen hoeveel fysieke ventielen je op één kanaal kan aansluiten, waardoor je veel makkelijker je 19 zones naar veel minder groepen kan brengen.

Wil je later uitbreiden op de basis functionaliteit met zoninval, weersvoorspelling etc etc, dan zal je echt een logicmodule er naast moeten zetten, die de bestaande componenten bijstuurt door bijvoorbeeld stooklijnen, ventielen etc actief aan te passen.

[carlw]

Mij hebben ze aangeraden om niet te veel met domotica te proberen ingrijpen op de stookcurves van de warmtepompen.

Doordat onze nieuwbouw zo zwaar geisoleerd is en massas beton bevat, varieert de temperatuur slechts zeer traag.

We zullen het hele huis op constante temperatuur houden. Enkel de slaapkamers en badkamers heb ik voorzien om motortjes op de vloerverwarmings kringen te plaatsen om daar toch beperkte variaties uit te voeren.

Ik kan echter pas volgend jaar vertellen of dit goed werkt of niet omdat binnen 2 weken pas de ruwbouw af zal zijn :-).

[HyperBart]

Even voor de geïnteresseerden, het staat nog in de kinderschoenen, maar een goede vriend van mij: (@FireDrunk) was zo vriendelijk om met met InfluxDB en Grafana aan de slag te willen gaan om wat data van KNX inzichtelijk te maken.

Het project staat al bijna sinds dag 1 op GitHub en is te vinden op https://github.com/FireDrunk/node-kninflux

Ik heb het zelf hier al een tijdje draaien, er zitten misschien nog wat schoonheidsfoutjes in maar het doet al wat het moet, namelijk data visualiseren. Zo heb ik nu bv. mijn temperatuur (dat is voorlopig het enige) gevisualiseerd op Grafana en dat is best eens interessant om te zien. Op termijn wil ik er verschillende dingen in zetten zoals Lux en kan je er volgens mij ook je schakelstatus van je lampen in laten zien.

We kunnen wel wat testers gebruiken, dus by all means: probeer het even uit .

[ Voor 10% gewijzigd door HyperBart op 19-02-2017 21:56 ]

[Anoniem: 157611]

Super alle reacties, ik ga er zeker mee aan de slag en laat weten hoe het verloopt. Ik bemerkte al dat inderdaad door de goede isolatie in nieuwbouw dat het erg snel aangenaam is en makkelijk in de niet aangenaam warm sferen komt.

Ik zal alle tips ter harte nemen, echt heel veel dingen waar je gewoon niet aan denkt omdat je het wiel nog niet gezien hebt.

Ik heb nu uiteindelijk ook een samenstelling gemaakt wat er in mijn kast komt, de heating actors stop ik bij de verdelers, verder komt alles in de meterkast erbij.

Ben uiteindelijk toch van THEBEN afgestapt nadat ik eens goed bij MDT op de website had gekeken en prijs vergelijking deed kwam ik tot de conclusie dat MDT veel beter in mijn budget past en ik moet zeggen, de uitleg op de website bij MDT is klare taal



Dit is wat ik dreig te gaan bestellen, ik weet dat het over the top is, zeker mbt het aantal te schakelen wcd's, maar ik had onder tijdsdruk te weinig tijd om te snappen hoe ik goede loops kon leggen in de leidingen, dus uiteindelijk heb ik besloten om alle wcd's afzonderlijk te trekken naar de meterkast. Een hoop buis in de vloer tot gevolg. haha maar daar zie je nu niets meer van tot je de meterkast opendoet.

Alles hangt er nu ongeordend bij, ik heb gelukkig een goede "electricien" als vriend die me gaat helpen bij het afmonteren van de meterkast dus ik heb er nog steeds alle vertrouwen in dat het technisch haalbaar is en dat ik het netjes afgemonteerd en werkend ga krijgen.

Nachten van wakker gelegen dat wel !

Er komt nog een 52 ports Linksys PoE switch en 2x 24 ports systimax cat 6 patch paneel bij te hangen, dus als het straks netjes hangt dan ga ik de eerste nacht voor de meterkast liggen genieten !

[tss68nl]

Anoniem: 157611 schreef op zaterdag 25 februari 2017 @ 21:06:
Super alle reacties, ik ga er zeker mee aan de slag en laat weten hoe het verloopt. Ik bemerkte al dat inderdaad door de goede isolatie in nieuwbouw dat het erg snel aangenaam is en makkelijk in de niet aangenaam warm sferen komt.

Ik zal alle tips ter harte nemen, echt heel veel dingen waar je gewoon niet aan denkt omdat je het wiel nog niet gezien hebt.

Ik heb nu uiteindelijk ook een samenstelling gemaakt wat er in mijn kast komt, de heating actors stop ik bij de verdelers, verder komt alles in de meterkast erbij.

Ben uiteindelijk toch van THEBEN afgestapt nadat ik eens goed bij MDT op de website had gekeken en prijs vergelijking deed kwam ik tot de conclusie dat MDT veel beter in mijn budget past en ik moet zeggen, de uitleg op de website bij MDT is klare taal

Goede keuze denk ik, Theben is doorgaans duurder en heeft minder goede/flexibele software in hun units zitten. MDT is heer en meester in functionaliteit in die apparaten stoppen.

Dit is wat ik dreig te gaan bestellen, ik weet dat het over the top is, zeker mbt het aantal te schakelen wcd's, maar ik had onder tijdsdruk te weinig tijd om te snappen hoe ik goede loops kon leggen in de leidingen, dus uiteindelijk heb ik besloten om alle wcd's afzonderlijk te trekken naar de meterkast. Een hoop buis in de vloer tot gevolg. haha maar daar zie je nu niets meer van tot je de meterkast opendoet.

Zo.... dat is een sloot hardware Ik schrik hier en daar wel, dus wil wel even een paar dingen met je checken:

WCD's en schakelen
Er is niets op tegen om alle WCD's afzonderlijk naar de meterkast te trekken. Kost buis en draad, maar je hebt je wel een hoop flexibiliteit en tijd gekocht daarmee. Het wil echter niet zeggen dat je ze ook echt allemaal apart op een MDT moet afmonteren....

• Ik wil je zeer sterk aanraden om klemmenstroken te gebruiken om al je draad op af te monteren onder of bovenin de meterkast (waar je buis vandaan komt). Met bijvoorbeeld etageklemmen van Wago of Phoenix kan je dan alle nul en aarde reeds in die klemmenstrook verdelen, en hoeft er alleen maar fase door de kast heen (bruin voor vast, zwart geschakeld....óók in je kast). Anders wordt het een puinhoop.
• Op dergelijke klemmenstroken, kan je met (in)steekbruggen, ook de fase bundelen. Dus als je met een MDT een fase schakelt, dan kan je daar een arbitrair aantal stopcontacten met een simpele brug mee koppelen. Ik denk dat je vervolgens niet zó veel AKS units nodig hebt.
• Bedenk je ook, dat het heel makkelijk is om een specifiek stopcontact later nog geschakeld te maken omdat je nou eenmaal alles op een klemmenstrook hebt afgemonteerd in een centrale kast. Je kan dus het gros gewoon op vaste spanning aansluiten (verdelen middels bruggen op klemmenstrook wederom), en je geschakelde kanalen spaarzaam gebruiken.
• Je hebt een AMI voorzien: die kunnen 20A aan en hebben zwaardere relais voor hoge inschakelstromen (van motoren etc). Een AMS heeft dezelfde functionaliteit, maar heeft door zijn lichtere relais een minder harde *klik*. Als het een bewuste keuze is, prima natuurlijk, maar veel mensen zien dit verschil over het hoofd.
• Ik zou een AKS vervangen door een AMS (met stroommeting) zodat je stopcontacten met een pc erop, tv, versterker, wasmachine, oven, etc etc etc kan meten. Het zijn bijna gratis stroommeters, als je toch al een AKS zou voorzien.

LED drivers?
Dit is denk ik de belangrijkste van allemaal: je noemt de AKD 0401 units LED drivers....omdat je er volgens MDT led mee kan sturen. Ik houd niet zo van schreeuwen en grote letters, maar

!! dat zijn geen led drivers !!.

Het zijn universele dimmers voor 230V gloeilampen (en dus ook 230V retrofit led die een gloeilamp nabootsen). Het kan natuurlijk zijn dat je per abuis een dimmer een led-driver noemt omdat je er retrofit led lampen aan wil hangen, maar kan maar beter het zekere voor het onzekere nemen niet?

MDT heeft wel led drivers (die ze led controllers noemen) voor led-strip, maar voor spots heb je bij MDT geen goede opties. Goede nieuws is wel, dat je voor de prijs van zo'n AKD, óók een echte 4 kanaals led driver met ingebouwde voeding hebt liggen van andere merken. Ik hoor graag van je wat je aan/in je plafond wil voorzien aan led verlichting, dan helpen we je met een concrete oplossing wat je nodig hebt aan materiaal

Alles hangt er nu ongeordend bij, ik heb gelukkig een goede "electricien" als vriend die me gaat helpen bij het afmonteren van de meterkast dus ik heb er nog steeds alle vertrouwen in dat het technisch haalbaar is en dat ik het netjes afgemonteerd en werkend ga krijgen.

Nachten van wakker gelegen dat wel !

Er komt nog een 52 ports Linksys PoE switch en 2x 24 ports systimax cat 6 patch paneel bij te hangen, dus als het straks netjes hangt dan ga ik de eerste nacht voor de meterkast liggen genieten !

Haha, ja dat is toch ook wel iets hè? Dat is één van de dingen die ik in mijn eigen huis niet heb voorzien, en waar ik nog steeds van baal. Ik heb het nu bij anderen wel voorzien, en het is echt een genot om al die netjes genummerde kabels in een geordend patroontje afgemonteerd, ingeplugd te zien....en als ze dan ook nog lekker rustgevend knipperen dan is het feest compleet. Zal wel een OCD dingetje zijn ofzo?

[ Voor 5% gewijzigd door tss68nl op 26-02-2017 02:58 ]

[GerjanT]

Anoniem: 157611 schreef op zaterdag 25 februari 2017 @ 21:06:

Dit is wat ik dreig te gaan bestellen, ik weet dat het over the top is, zeker mbt het aantal te schakelen wcd's, maar ik had onder tijdsdruk te weinig tijd om te snappen hoe ik goede loops kon leggen in de leidingen, dus uiteindelijk heb ik besloten om alle wcd's afzonderlijk te trekken naar de meterkast. Een hoop buis in de vloer tot gevolg. haha maar daar zie je nu niets meer van tot je de meterkast opendoet.

Dat zijn heel wat WCD's die je wilt schakelen. Wat @tss68nl al zegt prima qua flexibiliteit. De opmerking over de klemmenstroken is ook belangrijk, daarmee hou je het voor jezelf overzichtelijk maar ook vooral veilig. Ik zit zelf in de "denk"-fase en kom in ons huis rond de 35 geschakelde WCD's/verlichtingspunten. Uitgangspunt is dat ik overal 19mm (flex)buis heentrek met daarin 5/2.5mm2 (fase/nul/aarde/zwart/grijs). Ik ga er vanuit dat ik bij iedere set van WCD's er minimaal 1 wil schakelen, heb ik er twee dan gebruik ik de grijze schakeldraad.

Nogmaals, als je iedere WCD wilt schakelen, goed streven en vooral doen. Ik geef je alleen mijn beoogde set-up mee, misschien is dat voor jou al voldoende.

[teaser]

132 relaisuitgangen, dat is inderdaad gi-gan-tisch veel! Ik heb geen klein huis, en ik kom hier max aan 70 relaisuitgangen, en dat is inclusief lichtkringen.
Bereken even het hoognodige dat nu geschakeld moet worden en begin daarmee. Waarschijnlijk kom je dan aan 1/3de ofzo van wat je nu voorzien hebt

[tss68nl]

teaser schreef op zondag 26 februari 2017 @ 09:54:
132 relaisuitgangen, dat is inderdaad gi-gan-tisch veel! Ik heb geen klein huis, en ik kom hier max aan 70 relaisuitgangen, en dat is inclusief lichtkringen.
Bereken even het hoognodige dat nu geschakeld moet worden en begin daarmee. Waarschijnlijk kom je dan aan 1/3de ofzo van wat je nu voorzien hebt

Ja precies, ik draai zelf 225m2 huis op 48 relais. Nu is het wel zo dat de verlichting hoofdzakelijk LED is, waardoor die via DMX worden geschakeld: per 4 led-groepen gebruik ik maar 1 relais voor de voeding.

Maar goed, ik gebruik bijna ieder relais ook met een specifiek doel. Als ik een andere WCD geschakeld nodig heb, dan plug ik hem op de klemmenstrook om, óf ik sluit hem aan op een geschakelde fase die achter iedere groep wcd's langs komt.

Ik heb bijvoorbeeld 3x2WCD's of 4x2WCD's in één keten zitten. Daar heb ik de normale fase/nul/aarde achterdoor lopen, en twee geschakelde fasen. Ik kan dus gemakkelijk 2 of meer WCD's op één geschakelde draad zetten. Als je geen zin hebt om het ooit nog open te moeten halen, en je wil overal alles voorzien hebben, dan kom je op meer relais uit, maar dit werkt voor mij prima

[ Voor 33% gewijzigd door tss68nl op 26-02-2017 13:27 ]

[bartvb]

@Anoniem: 157611 Dat wordt een indrukwekkende kast zo Alles komt ook naar 1 kast toe dus? Niet gewerkt met meerdere verdeelkasten, bijvoorbeeld per verdieping?

Wat het plannen betreft; hebben jullie nog hints en tips wat tekenwerk betreft?
Wij zijn op dit moment vooral nog bezig met het bouwkundige deel van de woning. Dus waar willen we een WCD, waar een schakelaar/taster/controller, waar komt welke soort verlichting, etc.

Hebben jullie hints en tips om het teken- en ontwerp-werk een beetje overzichtelijk te houden? Een standaard E-plan tekening met de schakelaars/lichtpunten is goed te doen, maar het is ook handig om aan te geven wat bij elkaar in een leiding zit en een logisch nummerschema is ook prettig voor de afmontage in de kast. Voor zover relevant; ik gebruik Revit voor het meeste tekenwerk.

[Anoniem: 157611]

tss68nl schreef op zondag 26 februari 2017 @ 02:49:

Zo.... dat is een sloot hardware Ik schrik hier en daar wel, dus wil wel even een paar dingen met je checken:

WCD's en schakelen
Er is niets op tegen om alle WCD's afzonderlijk naar de meterkast te trekken. Kost buis en draad, maar je hebt je wel een hoop flexibiliteit en tijd gekocht daarmee. Het wil echter niet zeggen dat je ze ook echt allemaal apart op een MDT moet afmonteren....

Klopt 100%, mijn reden is min of meer het vooruitzicht van luiheid/te weinig tijd hebben, het idee dat ik straks alles vanaf de keukentafel in software kan bepalen en het feit dat ik geen electricien ben. Ik monteer de kast samen af met een vriend die er wel specialist in is, dus ik zal ongetwijfeld zeer snel de vinger er achter hebben, maar ik heb eigenlijk vanaf het begin het idee om die kast straks dicht te doen en vanaf ETS de zaak te groeperen.

Ik zie het voor me dat ik groepen maak per ruimte en die dan later steeds verder opdeel als ik eenmaal weet waar welk apparaat komt.

Mijn les uit mijn vorige woning is dat ik bijv het netwerk half had afgewerkt, alles werkte goed hoor, begrijp me niet verkeerd , maar ik heb daar eigenlijk constant spijt van gehad, en vaak op me knieen gezeten om nog het een en ander te realiseren of om te leggen enz. Een hoop dingen kon ik ook niet weten van te voren. Maar utp in elke kamer aan beide kanten spookte meteen door mijn hoofd en was toch wel fantastisch geweest als ik dat toen wel meteen had doorgezet.

Ik denk dat ik dat daarom ook met wcd's heb

Ben bang dat het een "never ending story" wordt. En feit dat ik nu voorbereid ben (door de hoeveelheid buis) op wat er kan gaan komen is ook wel prettig.

[list]
• Ik wil je zeer sterk aanraden om klemmenstroken te gebruiken om al je draad op af te monteren onder of bovenin de meterkast (waar je buis vandaan komt). Met bijvoorbeeld etageklemmen van Wago of Phoenix kan je dan alle nul en aarde reeds in die klemmenstrook verdelen, en hoeft er alleen maar fase door de kast heen (bruin voor vast, zwart geschakeld....óók in je kast). Anders wordt het een puinhoop.

Dat gaat zeker gebeuren, de tip om de nieuwe wago lasklemmen te nemen ipv doppen was heerlijk om mee te werken, fantastisch merk wago !

• Op dergelijke klemmenstroken, kan je met (in)steekbruggen, ook de fase bundelen. Dus als je met een MDT een fase schakelt, dan kan je daar een arbitrair aantal stopcontacten met een simpele brug mee koppelen. Ik denk dat je vervolgens niet zó veel AKS units nodig hebt.
• Bedenk je ook, dat het heel makkelijk is om een specifiek stopcontact later nog geschakeld te maken omdat je nou eenmaal alles op een klemmenstrook hebt afgemonteerd in een centrale kast. Je kan dus het gros gewoon op vaste spanning aansluiten (verdelen middels bruggen op klemmenstrook wederom), en je geschakelde kanalen spaarzaam gebruiken.

Dit gaat zeker weer door mijn hoofd malen, maar ik denk dat ik vasthoud aan quote 1.

• Je hebt een AMI voorzien: die kunnen 20A aan en hebben zwaardere relais voor hoge inschakelstromen (van motoren etc). Een AMS heeft dezelfde functionaliteit, maar heeft door zijn lichtere relais een minder harde *klik*. Als het een bewuste keuze is, prima natuurlijk, maar veel mensen zien dit verschil over het hoofd.

Ik zag dat over het hoofd, en ga voor de lichtere klik icm de quote hieronder.

• Ik zou een AKS vervangen door een AMS (met stroommeting) zodat je stopcontacten met een pc erop, tv, versterker, wasmachine, oven, etc etc etc kan meten. Het zijn bijna gratis stroommeters, als je toch al een AKS zou voorzien.
[/list]

Ook gezien, ik laat 1x AMI vervallen en pak 2x12 AMS erbij, ik hoop dat er ook functionaliteit is die op basis van, onder een bepaalde stroomvraag afschakelen enz kan

LED drivers?
Dit is denk ik de belangrijkste van allemaal: je noemt de AKD 0401 units LED drivers....omdat je er volgens MDT led mee kan sturen. Ik houd niet zo van schreeuwen en grote letters, maar

!! dat zijn geen led drivers !!.

Het zijn universele dimmers voor 230V gloeilampen (en dus ook 230V retrofit led die een gloeilamp nabootsen). Het kan natuurlijk zijn dat je per abuis een dimmer een led-driver noemt omdat je er retrofit led lampen aan wil hangen, maar kan maar beter het zekere voor het onzekere nemen niet?

MDT heeft wel led drivers (die ze led controllers noemen) voor led-strip, maar voor spots heb je bij MDT geen goede opties. Goede nieuws is wel, dat je voor de prijs van zo'n AKD, óók een echte 4 kanaals led driver met ingebouwde voeding hebt liggen van andere merken. Ik hoor graag van je wat je aan/in je plafond wil voorzien aan led verlichting, dan helpen we je met een concrete oplossing wat je nodig hebt aan materiaal

Oeps ....... ik bedoelde inderdaad dimmer. Ik heb dit huis overgenomen van een SPOT-ofiel die een weekend met gatenboor in de weer is gegaan en heb 72 spots te vullen. In mijn zoektocht was ik meteen opzoek naar een goede kwaliteit spot met het juiste dimbaar vermogen en vooral ook de juiste kleur licht. Ik ben toen min of meer uitgekomen op het merk OPPLE wat meer in kantoorgebouwen gebruikt wordt.

Ik heb de dimbare 9.5W variant door de hele woning geplanned met als uitzondering de douches en buiten spots op de terrassen. Daar heb ik een Philips met hogere IP waarde dimbaar met GU fitting maar daar ben ik overigens niet tevreden over. Echt een flut armatuur en het licht zelf is donkerder dan verwacht, het geeft een soort schaduwrijk licht. Erg irritant.



De OPPLE's daar ben ik echt van gecharmeerd, de lichtkleur is perfect, het aantal lumen is wel groter dan de Philips. Ik moet ze nog gedimd zien maar daar heb ik alle vertrouwen in.

Haha, ja dat is toch ook wel iets hè? Dat is één van de dingen die ik in mijn eigen huis niet heb voorzien, en waar ik nog steeds van baal. Ik heb het nu bij anderen wel voorzien, en het is echt een genot om al die netjes genummerde kabels in een geordend patroontje afgemonteerd, ingeplugd te zien....en als ze dan ook nog lekker rustgevend knipperen dan is het feest compleet. Zal wel een OCD dingetje zijn ofzo?

Precies mijn ervaring bij mijn vorige woning, vandaar dat ik overal nu aan 2 zijden 2x cat 6 heb voorzien. Ik wil het in de meterkast afgemonteerd hebben en heerlijk niks meer aan doen, alleen kijken

We zitten nu ook (in tijdelijke flat) met onder de tafel switches weggeschroefd, te korte kabeltjes etc.

Meterkast heaven is waiting hahaha (maar automatiserings hell ook ben ik bang !)

[tss68nl]

72 spots....je kan ook gewoon wat gipskarton in de gaten verwerken en de boel dicht pleisteren misschien?

Anoniem: 157611 schreef op dinsdag 28 februari 2017 @ 20:05:
Ook gezien, ik laat 1x AMI vervallen en pak 2x12 AMS erbij, ik hoop dat er ook functionaliteit is die op basis van, onder een bepaalde stroomvraag afschakelen enz kan

Ja hoor, die MDT units kan je zeer veel mee. Alleen je moet je wel afvragen in hoeverre zoiets werkbaar blijft in gebruik: als het stopcontact onder een bepaalde stroomgrens afschakelt....hoe schakelt hij dan aan en wanneer? Het is wel zo, dat hij alleen afschakelt als hij de grens passert. Dus, als er 0 verbruik is als je hem aan zet, dan moet hij eerst óver de grens heen, zakt hij daarna er onder, dan geeft hij een signaal of schakelt af, net wat je wil.
Als je wil dat hij sowieso afschakelt kan je een timer instellen. Dan checkt hij periodiek de status en zend het commando aan/uit op basis van de door jou ingestelde ondergrens.

Je kan ETS al eens downloaden, en ook de software van de MDT units. Zonder een fysiek netwerk kan je reeds de software bekijken, en met wat instellingen spelen. Je kan natuurlijk nog niet precies zien wat het doet, maar wel een gevoel krijgen van de features, zonder dat je de handleiding door hoeft te lezen.

Sowieso, als je alle stopcontacten geschakeld maakt, dan heb je dus zeker de helft van de relais altijd open staan voor vaste spanning op stopcontacten?

[teaser]

Sinds vandaag is ETS Inside verkrijgbaar in de KNX shop!

[Anoniem: 157611]

tss68nl schreef op woensdag 1 maart 2017 @ 09:44:
72 spots....je kan ook gewoon wat gipskarton in de gaten verwerken en de boel dicht pleisteren misschien?

hahaha zeker wel door mijn hoofd gegaan, maar toen toch besloten om nog wat extra spots in de keuken bij te maken

Ja hoor, die MDT units kan je zeer veel mee. Alleen je moet je wel afvragen in hoeverre zoiets werkbaar blijft in gebruik: als het stopcontact onder een bepaalde stroomgrens afschakelt....hoe schakelt hij dan aan en wanneer? Het is wel zo, dat hij alleen afschakelt als hij de grens passert. Dus, als er 0 verbruik is als je hem aan zet, dan moet hij eerst óver de grens heen, zakt hij daarna er onder, dan geeft hij een signaal of schakelt af, net wat je wil.
Als je wil dat hij sowieso afschakelt kan je een timer instellen. Dan checkt hij periodiek de status en zend het commando aan/uit op basis van de door jou ingestelde ondergrens.

Ahh super, ik dacht eraan om bepaalde apparaten (bijv een wasdroger) af te schakelen als de stroomvraag standby wordt. Dat de spanning erop komt kan ik dat geval dan waarschijnlijk wel regelen met een bewegingsmelder, dat zodra de deur opengaat dat het apparat weer van stroom wordt voorzien.

Wow super dat dat soort dingen dan straks programmeerbaar worden ! Ik kan nu alleen aan de wasdroger denken of wasmachine denken die in standby sluipverbruik heeft (wordt overigens vervangen door een nieuwe), maar dat zal waarschijnlijk met veel apparaten besparing kunnen opleveren of zeer handig om verbruik van apparaten te kunnen zien. Ik heb een wasmachine op warmwater draaien straks en de vaatwasser ook, dus interesting om te kunnen zien hoeveel het scheelt ;-) Heb ik weer wat te verkondigen op een verjaardag moehahah

Je kan ETS al eens downloaden, en ook de software van de MDT units. Zonder een fysiek netwerk kan je reeds de software bekijken, en met wat instellingen spelen. Je kan natuurlijk nog niet precies zien wat het doet, maar wel een gevoel krijgen van de features, zonder dat je de handleiding door hoeft te lezen.

Ja inderdaad, ik had dat voor de aankoop een keer gedaan, toen heb ik ook die online mini vragen quiz doorlopen, maar nog geen units gedownload en erin gesleept, ga ik zeker doen.

Sowieso, als je alle stopcontacten geschakeld maakt, dan heb je dus zeker de helft van de relais altijd open staan voor vaste spanning op stopcontacten?

Overdag en bij aanwezigheid zeker wel, doel is wel om 's nachts zoveel mogelijk uit te gaan doen, ik verwacht wel een grote wirwar van valkuilen waar ik eerst in val. Ik zit hier met 4 kids, playstations, TV's lichten die aan blijven staan enz, dus niet luisteren ? afschakelen die handel hehehe

[klaasopurk]

Ik ben bezig om een nieuw huis te gaan bouwen. In dat huis moet alles op domotica aangesloten worden. Ik heb nu ervaring met Zipato icm aantal Zwave dimmers / relais en deursensoren / temperatuur sensoren. KNX is echter voor mij nieuw. Het is lastig om alles op een rijtje krijgen hoe KNX werkt en wat ik dan nodig ben. Tips en tricks hiervoor zijn altijd welkom. Ik ga nog wel een online cursus hiervoor volgen.
Ik zat te denken aan het volgende wat ik wil / nodig heb: (niet alle scenes die ik wil staan hieronder. Dan wordt de lijst heel lang)

• alle WCD / lampen (niet dimbare) / magnetron / oven / vijver / vaatwasser / etc (behalve kookplaat ivm dubbele groep) op een relais (MDT 2016). Dat worden er heel wat zo'n 130 of nog wel meer. (ja ik heb bovenstaande doorgelezen over dat het handiger is op etageklemmen te zetten. Maar het lijkt mij zoveel makkelijker om alles naar de relais te lussen. Ik zou de etageklemmen alleen gebruiken voor om stugge draad 2.5mm af te monteren en via flexibel 2.5mm naar de relais te gaat. Anders krijg je het niet netjes weggewerkt.)
• dimbare lampen / schemer lampen via een etageklem naar een dimmer. dit ivm dimmer is duur en minimale dimlast. Ik kom nu uit op 6 verschillende ketens.
• deursensoren voor alle buitendeuren. Deze kan ik echter niet vinden. Kan iemand mij daarin helpen?
• bewegingsmelders voor op toiletten en hal voor en achter + buiten voor en achter
• speciale stekkerdoos voor TV en computer met daarin 5 stopcontacten / relais module via draadloos KNX. Ik verbouw de kamer zo vaak en computer en TV verhuizen dan, dat het niet te doen is om in allen hoeken standaard stopcontacten voor TV/ versterker / Wii etc te maken. Dan zou ik op teveel plekken standaard 4-6 stopcontacten moeten maken.
  Stopcontact waarin dan dit stekkerblok komt moet ik misschien wel of niet via een relaismodule laten lopen?
• zowel beneden als tussenverdieping in de toekomst een touchscreen voor bediening. Dit als blijkt dat bepaalde zaken niet te automatiseren zijn.
• overal standaard een 6 op 8 knops bedieningspaneel. Wel zo weinig mogelijk bedieningspanelen over de verdieping heen. Deze bedieningspanelen moeten kunnen onder andere:
  • rolluiken omhoog/omlaag/stoppen
  • licht kunnen geven in het donker. Dit alleen op overloop en hal en in woonkamer + keuken
  • lampen aan/uit / harder / zachter
• Rolluik aansturing vanuit de meterkast
• Alarminstallatie maken. Dit heb ik nu ook via Zipato. Deur open doen indien armed = alarm.

Vragen die ik heb:

1. Waar zijn de deursensoren voor detectie deur open/dicht?
2. Ik wil zoveel mogelijk bedraad KNX aanleggen. Alleen de stekkerdozen voor TV / Computer zijn draadloos. Geeft dit problemen met bereik? Denk aan een huis van 6,5x11 meter en 3 verdiepingen nieuwbouw. op de zolder moet ook nog bereik zijn.
3. Zijn en rekenmodules te vinden om makkelijk te vinden hoeveel mAh voeding je nodig hebt?
4. Kan elk knoppen paneel een dimmer aansturen? (ik kom er via handleidingen niet helemaal uit)
5. Kan 1 knop op een knoppen paneel zowel de lamper harder als zachter zetten of zijn hier echt 2 knoppen voor nodig?
6. Is het verstandiger om bijvoorbeeld een meterkast beneden en boven en zolder en schuur te maken? dit omdat alle buizen naar beneden in de meterkast krijgen een drama kan worden.
7. Bestaan er ook KNX glasbreukmelders?
8. Is een KNX-systeem te koppen aan bijv. Zipatobox zonder dat Zipato "de baas" wordt? Dus Zipato krijg van alles wel een signaal maar KNX systeem regelt zich zelf zoals een standalone KNX systeem standaard doet.
9. Is er een goede KNX app? Zodat bedienen vanaf telefoon makkelijk gaat?

Ik hoop dat ik niet al te veel noob overkom. Bedankt idg. Ik heb nog een zomer om alles op een rijtje te zetten qua apparaten / scenes / schakelingen / meterkast ontwerp etc

[tss68nl]

klaasopurk schreef op maandag 6 maart 2017 @ 20:44:
Ik hoop dat ik niet al te veel noob overkom. Bedankt idg. Ik heb nog een zomer om alles op een rijtje te zetten qua apparaten / scenes / schakelingen / meterkast ontwerp etc

Nou, ik heb nog nooit zoveel noob-vragen in één post bij elkaar gezien Geintje...je hebt al redelijk goed bedacht wat je allemaal wil,en volgens mij is iedereen op startpunt 0 begonnen met KNX leren. Je zit op de goede weg

Vragen die ik heb:

1. Waar zijn de deursensoren voor detectie deur open/dicht?
2. Ik wil zoveel mogelijk bedraad KNX aanleggen. Alleen de stekkerdozen voor TV / Computer zijn draadloos. Geeft dit problemen met bereik? Denk aan een huis van 6,5x11 meter en 3 verdiepingen nieuwbouw. op de zolder moet ook nog bereik zijn.
3. Zijn en rekenmodules te vinden om makkelijk te vinden hoeveel mAh voeding je nodig hebt?
4. Kan elk knoppen paneel een dimmer aansturen? (ik kom er via handleidingen niet helemaal uit)
5. Kan 1 knop op een knoppen paneel zowel de lamper harder als zachter zetten of zijn hier echt 2 knoppen voor nodig?
6. Is het verstandiger om bijvoorbeeld een meterkast beneden en boven en zolder en schuur te maken? dit omdat alle buizen naar beneden in de meterkast krijgen een drama kan worden.
7. Bestaan er ook KNX glasbreukmelders?
8. Is een KNX-systeem te koppen aan bijv. Zipatobox zonder dat Zipato "de baas" wordt? Dus Zipato krijg van alles wel een signaal maar KNX systeem regelt zich zelf zoals een standalone KNX systeem standaard doet.
9. Is er een goede KNX app? Zodat bedienen vanaf telefoon makkelijk gaat?

Deursensoren kan je bijvoorbeeld simpele reedcontacten voor gebruiken. Heb je houten kozijnen/enkele deuren, dan kan je ook heel makkelijk een nachtschootcontact plaatsen. Die sluit je aan op een binaire KNX input (MDT heeft ze ook).

Als je een stekkerdoos naar je TV/versterker legt, kan je toch ook een 230V+KNX kabel aan elkaar vast maken? (KNX kabel 2x2x0.8 is ook in wit of zwart te krijgen, en anders zijn er nog kabelhoezen). Neem een kleine verdeelbox voor buiten, en monteer een compacte relaisunit in de verdeelbox, en breng geschakelde 5G2.5 naar de contactdoos(dozen). Je hoeft alleen maar te zorgen dat je op een hoop punten met KNX kabel achter een blindplaat kan komen. (extra lege buis naar het linker stopcontact, terwijl je 230 altijd naar de rechter legt bijvoorbeeld). Draadloos, en zeker achter een wirwar aan draden/tv/versterker is niet aan te raden. Daarnaast zijn 10 lege buizen en wat draad nog stukken goedkoper dan een KNX-RF setup.

De meeste units gebruiken niet meer dan 10 mA (behalve schermen, maar die gebruiken meestal PoE/UTP). Koop gewoon een 640 mA voeding, en dan kan je er alle units op hangen die je nodig hebt. Heb je er echt 64 nodig dan gaat er iets niet goed

Het is op zich niet slecht om meerdere kasten te hebben. Vaak wordt 230V en verdeelkast KNX al gesplitst. De afstand voor een buis van verdieping naar verdieping is echter niet zo heel groot, maar wat je wel kan doen, is bijvoorbeeld één kast beneden, en één op zolder. Verbonden met voldoende buis zodat groepen, UTP, KNX, DMX etc allemaal apart getrokken kunnen worden. Zo kan je dan plafond 1ste en zolder op de kast boven doen, en beneden en vloer 1ste naar beneden. Schuur (als het losstaand is, en niet permanent verwarmd) zou ik sowieso een klein IP65 kastje binnen plaatsen en een vochtvreter/silicagel in plaatsen om te zorgen dat er door temperatuurswisselingen geen condensvorming kan ontstaan.

Er zijn tegenwoordig voor alarmsystemen IR sensoren die middels de frequenties van brekend glas ook op afstand breuk detecteren. Sowieso: overweeg eens een normaal alarmsysteem aan te leggen met een relaisstation. Dat relaisstation stelt je vaak in staat om in ieder geval de sensoren van het alarm te gebruiken voor KNX, en sommige systemen hebben zelfs een input zodat je met KNX alarm op/af kan schakelen en KNX sensoren te gebruiken. Dat is makkelijker dan je eigen systeem te bouwen. De extra features bouw je er dan makkelijk zelf gewoon bij. Bijvoorbeeld: plaats een reedcontact in iedere binnendeur. Gaat er een deur beneden open terwijl het alarm er op staat? -> Foute boel.

KNX app is er niet echt rechtstreeks, maar kijk hier eens naar:

• Gira heeft de X1 -> Een webinterface die ook werkt op je telefoon. De Gira G1 heeft dezelfde interface, maar dan als apparaat aan de muur.
• Ook kan je aan de slag met homebridge-knx als je een iPhone hebt. HomeKit wordt dan gekoppeld met de app, maar ook met stembediening/siri.

Knoppen: je geeft aan dat je wil dat je knoppen licht geven in het donker. Kijk eens naar de Ekinex FF 'NF. NF staat voor no-frame, waardoor deze met alle leds 's nachts als nachtverlichting kunnen dienen. Qua functionaliteit hangt het zeer sterk af van de software die bij de knoppen komt. In geval van Ekinex heb je een 4x2 configuratie: 4 vlakken, met ieder twee contactpunten (boven/beneden of links/rechts in de langwerpige variant). Normaal is om dan 1 vlak te nemen en daar met boven/onder de dimming op te doen, of de rolluiken.
Echter, die units hebben ook de mogelijkheid tot dimmen en rolluiken besturen met 1 contactpunt. Lang indrukken -> omhoog tot je loslaat, weer lang indrukken -> omlaag tot je loslaat. Dan kan je dus 8 groepen verlichting of rolluiken kwijt op één unit, én, je kan met een korte druk bijvoorbeeld gewoon aan/uit of omhoog/omlaag programmeren.

Wat betreft die etageklemmen/rijgklemmen: het hele doel van die dingen is om daar inderdaad alle stugge draad op een vaste positie op af te monteren, en daarna met flexibele draad door te lussen naar je actoren. Daarnaast bundel je daarmee direct de nul en aarde, zodat je veel minder dradenbende in kast krijgt. Overigens kan je ook gewoon rijgklemmen (enkellaags) gebruiken als je wil. Zolang je direct bij binnenkomst maar een rail hebt voor nul en fase. Let er op dat je verschillende groepen in je kast wil hebben en dat je die dus wil scheiden. Een makkelijke manier is: gebruik één fase per kolom in je kast. Kan je ook niets verwarren.

Ik zou je zeer sterk willen afraden om de stugge draad direct naar de actor te leggen, zoveel draad is onhandelbaar in stug. (Het heet niet voor niets stug ).

[Dest_]

Ik heb gisteren mijn 1e KNX speelgoed ontvangen
Spijtig genoeg was de MDT AKK-1616.02 defect bij aankomst (barst in behuizing, printplaat komt uit behuizing + er rammelt iets intern). Ik heb deze niet aangesloten en maar DOA teruggestuurd.

Ondertussen ben ik wel met de rest van mijn speelgoed aan het spelen geweest. Echter loop ik nog tegen problemen (hoort er bij). Door mijn gebrek aan KNX ervaring (is mijn 1e project) zit ik wat vast. Hopelijk kunnen jullie mij even verder helpen.

Momenteel heb ik een opstelling met 2 toestellen gemaakt, een voeding (MDT STR-0640.01) en een ip interface (MDT SCN-IP000.02). Ik heb in ETS een testproject gemaakt met deze 2 toestellen. Deze ziet er als volgt uit:

De IP interface heeft 2 bus adressen nodig, 1 voor de ip interface zelf en een 2e voor de resterende functies (time server, mail server).
Ik heb op beide toestellen een reset uitgevoerd voordat ik deze programmeer met ETS.

Als ik in ETS naar het tabblad bus gaat vind deze daar automatisch de ip interface terug.

Standaard staat van elke interface (usb, ip, serieel) het adres op 15.15.255. De webinterface van de ip interface geeft volgende aan:


Nu pas ik via ETS in het tabblad bus het individueel adres aan naar 1.1.2. Daar dit het adres is die voorzien heb voor de ip interface in mijn testproject. Als ik daarna de webinterface bekijk van de ip interface krijg ik volgende gegevens te zien:

Bij het individueel adres is de 1.1.2 er bij gekomen, maar de 15.15.255 blijft staan. Dat de 15.15.255 blijft staan vind ik bizar, daar ik ervan uitgaat dat de ip interface maar 1 adres op de bus heeft. Wss loopt het hier al mis.

De individuele adressen downloaden lukt voor de voeding en voor de time en mail server gedeelte van de ip interface. Maar dit lukt niet voor de ip interface zelf. Daar krijg ik deze mooi melding te zien:

Druk ik op "Local Interface Settings" krijg ik het bus adres van de ip interface te zien.

Deze staat correct (lijkt mij toch).
Kies ik voor "Local Download" krijg ik deze melding te zien:

Hier vind ik niet hoe ik deze moet oplossen.

Daarnaast heb ik nog een probleem als ik de toestellen van de applicatie wens te voorzien. Door bovenstaande handelingen beschikt elk toestel over zijn bus adres. Wanneer ik bijvoorbeeld de applicatie doorstuur naar de voeding dan werkt dit probleemloos.


Als ik echter de applicatie wenst door de sturen naar de time en mailserver gedeelte van de ip interface dan gaat de "Bus Error" led branden op de voeding, 2 seconden daarna gaat de led branden met "Trafic >60%". Deze beide leds blijven dan branden gedurende de tijd dat ETS de applicatie doorstuur. Echter geeft ETS wel aan de applicatie correct ingeladen is.

De instellingen die ik via ETS heb doorgestuurd zijn wel aangepast in de webinterface van de module. Nu vraag ik mij af waarom de 2 error led's dan branden op de voeding.
bij het doorsturen van de applicatie instellingen naar de ip interface (1.1.2) krijg ik ook dezelfde melding als bij het doorsturen van het adres.


Ik heb even alles gereset en mijn toestellen in ETS op de kring 1.0 geplaatst in plaats van de kring 1.1. Het adres van de ip interface is dan 1.0.2. Het wegschrijven van het adres (1.0.1) naar de voeding lukt, maar bij het wegschrijven van het adres (1.0.3) naar de time en mail server onderdeel van de ip interface krijg ik in ETS volgende foutmelding:

De webinterface geeft wel aan dat het bus adres aangepast is.


Ook op de 1.0 kring blijft het downloaden van de applicatie van de voeding werken. De rest van de problemen zoals op de 1.1 kring blijven ook op de 1.0 kring (bus errors + niet kunnen updaten van ip interface).

Ik ga vanavond nog enkele extra toestellen toevoegen aan mijn testopstelling om te zien of het enkel maar fout gaat bij het downloaden naar de ip interface.

Is er iemand die mij tips kan geven? Of mss iemand die hetzelfde heeft voorgehad in het verleden?

[tss68nl]

Dest_ schreef op dinsdag 14 maart 2017 @ 10:57:

[afbeelding]
Bij het individueel adres is de 1.1.2 er bij gekomen, maar de 15.15.255 blijft staan. Dat de 15.15.255 blijft staan vind ik bizar, daar ik ervan uitgaat dat de ip interface maar 1 adres op de bus heeft. Wss loopt het hier al mis.

Onhandige interface, maar 1.1.2 is een vervangen tunnel adres (geen individueel) voor zover ik kan zien. Ik denk dus dat hij het verkeerde soort adres heeft aangepast.

Je probeert dus ook via 15.15.255 IP interface, adressen op 1.0.x en 1.1.x uit te geven.... dat zal waarschijnlijk het issue zijn. Zorg dat de IP interface op 1.1.255 terecht komt, en deel de andere adressen via de webinterface in, óf, neem gewoon 15.15.255 en deel je apparaten allemaal een 15.15.x adres uit?

Dat lijkt mij de makkelijkste optie eigenlijk Ik draai ook op 15.15.x met mijn belangrijkste lijn.

[ Voor 26% gewijzigd door tss68nl op 14-03-2017 11:30 ]