Riktigt bra jobbat! Låter som att du har kommit långt!C Cff skrev:
När det gäller temperatur i Zennio Quad så var det korrekt gjort. Det är två saker egentligen. Dels så har man ett gruppobjekt för det uppmätta temperatur-värdet. Med det får man in temperaturen på KNX-bussen och skulle kunna skicka vidare det till en termostat i en helt annan apparat, men i detta fallet använder du en termostat I samma Quad-puck och då behöver man knyta gruppadressen för uppmätt temperatur till termostat-funktionen och eftersom insamling sker på samma puck så måste man knyta samma gruppadress till både temperaturgivare och termostat.
En viktig inställning för temperaturgivaren är dock att ställa in att pucken ska skicka uppdatering av värdet vid en temperaturförändring. I default-läge så är det inställt på 0°C och då kommer den inte skicka sitt värde till termostaten med resultatet att värmeregleringen inte kommer funka.
Gällande problemet att ladda ner applikationsprogram så tycker jag att det låter som en dålig anslutning till programmeringsgränssnittet. Har du ett USB-gränssnitt eller använder du EIBport som IP-gränssnitt?
//Patrik
Stort tack!Patrik_Hed skrev:
Då behåller jag tempgivarna som de är. Lite synd dock för jag hoppades lite att det skulle visa sig vara anledningen till att det fortfarande inte går att göra temperaturen termostat-styrd. 😊
Jag har dock flera hypoteser och nästa steg är att jag skall titta på varför flera av XÄB verkar så underliga. Jag vet inte hur de bör se ut, men intuitivt tycker jag att XÄB inte borde avvika jättemycket från XÄ och XB - som det är nu så känns det som att det för flera givare har XÄB inte någon som helst relation med värdena för XÄ och XB - inte heller verkar värmen slå på när XÄB understiger XÄ (tror jag i alla fall, jag dubbelkollar detta genom att se om XS är på/1 när XÄB överstiger XÄ). Vet inte om detta antagande stämmer, det är inget som elfirman har lagt in. I deras app syns "Akutellt" (sic) [XÄ], Intällt värde [XB] och en inställningsknapp av typen "Temp Control" kopplad till XÄB.
Oavsett så slår ingen värme förutom om jag manuellt slår på (och då är det på max) (fram tills nu har gjort detta i elskåpet...) plus att elfirman för ett år sedan kom hit och satte på så att värmen i badrumsgolvet går i 15 min när närvaro-sensorn aktiveras i badrummet (detta var inget jag önskade, utan deras nödlösning när de på tre månader inte lyckades göra den "termostat-styrd"). Så jag klurar och testar vidare
Det ligger en temp.givare samt en dörr-brytare som inte är adress-satta på två av Zenniorna , så jag vill gärna kunna uppdatera dessa. Min acces när jag försöker ladda upp är via nätverket (kabel) till Eibport. Jag har dock inte ännu testat att koppla datorn med kabel direkt till eibport så det tänkte jag göra nu. Det vore ju otroligt skönt om det inte stämmer att det är för lite ström på 1.1. 😂.
Jag har lite svårt att hänga med i förkortningarna, men tittar man på Zennios termostat så är det egentligen endast 5 st gruppadresser som behövs för att få till en enkel reglering. Jag brukar kalla dessa för detta:C Cff skrev:
- Ärvärde 2 Byte (Uppmätt rumstemperatur)
- Börvärde 2 Byte (Önskad rumstemperatur)
- Börvärde Status 2 Byte (Status för visning av inställt börvärde i visualisering)
- Reglervariabel signal 1 Byte (Signal från termostat till värmeaktor)
- Värmeaktor kvittens (Status från värmeaktor som visar Status på ställdon)
Här finns ett bra applikationsexempel som går igenom golvvärmestyrning.
https://www.google.com/url?sa=t&sou...gQFnoECBQQAQ&usg=AOvVaw329KB1gDNJeHDxu6LeCmu2
Du kan ta en bild på elcentralen så kan vi se vad du har för strömförsörjning. Borde vara en 640mA.
Felmeddelandet att det saknas strömförsörjning är för att elfirman inte har lagt in någon strömförsörjning i projektfilen. Den behöver inte programmeras och brukar därför inte läggas in av vissa, men det är bra att lägga in så att man vet vad det är för storlek på den.
//Patrik
Jag hittar bara 4 st gruppadresser per värmeenhet.
XÄ tolkar jag som Ärvärdet och det är 2-byte float (2 objekt, båda har samma format grader C)
XB - Current Setpoint (tolkar jag som Börvärde) - 2 byte float
XÄB - Reference Setpoint (Claude säger att detta är Ärbörvärdet, förkortningen XÄB är elfirmans) - 2 byte float
XS - output - Switch, 1 bit
XÄ, XB och XÄB verkar vara kopplade till Quaden och XS till en aktor.
Jag bifogar skärmbilder på dessa samt en på Quaden (där är det IN:2 om är kopplad till samma som de andra skärmbilderna, värme vid terrassdörr. Jag blev lite förvånad när jag såg att IN:a står som binary eftersom även den är kopplad till en temperaturgivare)...
Jag bifogar bilderna på min eibport och vad jag antar är strömförsörjningen (dessa sitter i mitt mediaskåp som är alldeles för rörigt för att jag skall visa det här i sin helhet 😂) (säg gärna till om du ser någon id-info på någon av bilderna - i så fall skall jag sudda ut det)
Hmmm, det här med Zennio och temperaturgivare verkar lite komplicerat, minst sagt 😂
ytterligare en sak som jag är osäker på är att jag noterar i ETS (som är programmerat av elkonsulten) är ikryssat att det är Zennio probes - något jag känner mig osäker på. I elektrikerns dokumentation (som inte alltid överensstämmer med vad elkonsulten programmerat...) står det bara NTC 15kohm/25 gr.
Andra saker som gör mig konfunderad är att det i termostatinställningarna står "warm water" som kontroll-parameter, men den aktuella enheten är ju en T2 golvvärme. Claude (min AI) går varm och jag slår nu hela tiden i maxanvändandet och får glädjen att "vila mig" i 2 timmar tills jag får ställa fler frågor (han, dvs Claude, klara inte riktigt av detta - Bab-tec var enkelt för honom, men det här är lite överkurs 😊)
ytterligare en sak som jag är osäker på är att jag noterar i ETS (som är programmerat av elkonsulten) är ikryssat att det är Zennio probes - något jag känner mig osäker på. I elektrikerns dokumentation (som inte alltid överensstämmer med vad elkonsulten programmerat...) står det bara NTC 15kohm/25 gr.
Andra saker som gör mig konfunderad är att det i termostatinställningarna står "warm water" som kontroll-parameter, men den aktuella enheten är ju en T2 golvvärme. Claude (min AI) går varm och jag slår nu hela tiden i maxanvändandet och får glädjen att "vila mig" i 2 timmar tills jag får ställa fler frågor (han, dvs Claude, klara inte riktigt av detta - Bab-tec var enkelt för honom, men det här är lite överkurs 😊)
Zennio har egna NTC-givare och kör man med dessa så kan man välja "Zennio prob".
Har man en egen NTC-givare så kan man välja det andra alternativet och då få möjlighet att själv ställa in karakteristiken för den NTC-givaren.
Testa ställa in parametrar och gruppadresser efter hur jag har gjort. Då borde det börja funka om du har elektrisk golvvärme.
//Patrik
Har man en egen NTC-givare så kan man välja det andra alternativet och då få möjlighet att själv ställa in karakteristiken för den NTC-givaren.
Testa ställa in parametrar och gruppadresser efter hur jag har gjort. Då borde det börja funka om du har elektrisk golvvärme.
//Patrik
Det verkar onekligen som att du kanske borde testa "Custom NTC Probe" istället?
Elektrikern kan ju ha valt en "standarsprobe".
Jag har en gammal Zennio-enhet där det valet inte fanns utan man var hänvisad till Zennios egna prober. Jag vet att jag rotade lite i det där för att se om det gick att använda andra prober än Zennios. Jag vill minnas att det var svårt då Zennio hade valt någon annan metod än standard NTC.
Om du har fått koll på eibport'en så kan du skapa enkla visualiseringar där du även kan mata in värden via webgränssnitt. Då kan du dels de vilka värden en givare ger men även själv mata in t.ex. ärvärden för temperatur (istället för givarens värde) och på så sätt se att termostatfunktionen beter sig som den ska.
Du kan alltså testa bit för bit i kedjan istället för allt på en gång där det kan finnas flera samtidiga felaktigheter.
Elektrikern kan ju ha valt en "standarsprobe".
Jag har en gammal Zennio-enhet där det valet inte fanns utan man var hänvisad till Zennios egna prober. Jag vet att jag rotade lite i det där för att se om det gick att använda andra prober än Zennios. Jag vill minnas att det var svårt då Zennio hade valt någon annan metod än standard NTC.
Om du har fått koll på eibport'en så kan du skapa enkla visualiseringar där du även kan mata in värden via webgränssnitt. Då kan du dels de vilka värden en givare ger men även själv mata in t.ex. ärvärden för temperatur (istället för givarens värde) och på så sätt se att termostatfunktionen beter sig som den ska.
Du kan alltså testa bit för bit i kedjan istället för allt på en gång där det kan finnas flera samtidiga felaktigheter.
Nu verkar jag äntligen ha fått kontakt med eibporten via ETS. Det verkar som att jag enkelt kan skicka nya värden på alla 4 parametrarna (3 temperaturparametrar i quaden och 1 switchparameter i en aktor), de nya värdena syns i appen så gruppadresserna verka uppdateras, men jag hade ju hoppats att när jag ändrar endera värdet för nuvarande temp eller önskad temp så skulle det tredje värdet ändras automatiskt, men det sker inte (kanske sker det med fördröjning). Men, det är också oroande att även om jag ändrar Är/bör-värdet (det tredje som jag tror är någon form av funktion av de andra två) så slår ändå inte aktorn på/av.jbr skrev:
Jag har hittat att det är dessa temperaturprober som jag har: ZN1AC-NTC68F (för golvvärme, 5 st (ev ytterligare 1-2, förberedda för snösmältning på terrass) samt ZN1AC-NTC68S (2-3 stycken) - så de är alla Zennio trots allt. Skönt!
Så jag tänkte nu testa parametrarna och adresserna du föreslagit - skall bli superspännande 😊.
Verkligen supertack!
Är det här inställningarna du använder dig av?C Cff skrev:
Om så är fallet...
Termostatfunktionen kommer att skicka ett värde mellan 0 och 100%. Det kräver att (värme)aktorn som styr värmekällan (i ditt fall elektrisk golvvärmeslinga) kan ta emot detta 1-byte-värde och basera sina till- och frånslag på det, Continous (1 byte).
Om du enbart har en aktor för till- och frånslag, dvs. standardaktor för belysning etc, så måste termostatfunktionen skicka 1-bit-värde, alltså 1 eller 0. Det gör den om du istället väljer PWM (1 bit).
Termostatfunktionen fungerar alltså så här:
Under en given tidsperiod (cycle time) bestämmer termostatfunktionen hur länge värmen ska vara till, t.ex. 34%. Det värdet kan skickas till värmeaktorn som får göra något vettigt med det, Continous (1 byte). Alternativt så skickar termostatfunktionen 1 när tidsperioden startar och 0 när 34% av tidsperioden har uppnåtts, PWM (1 bit), vilket fungerar utmärkt för en standardaktor som används för belysning, eluttag etc.
Du kan också göra som @Patrik_Hed föreslår, välja termostatfunktionen 2-point Control. Då sänder termostatfunktionen antingen 0 eller 1, vilket måste matchas i aktorn som styr golvvärmeslingan.
Du behöver inte bekymra dig om att Warm Water (5K/150min) är vald som Control Parameter. Det styr endast hur snabbt/trögt beräkningscykeln i termostatfunktionen ska arbeta. Ofta vill man att det ska finnas en tröghet även i regleringen då förändringar tar en viss tid att få effekt. (Beroende på uppvärmningsmetod, material i golvet etc.)
Om man tar vattenburen golvvärme som exempel så måste man där ha en lite längre cycle time eftersom det kan ta en minut för ställdonet att öppna resp. stänga. Om cycle time är t.ex. 20 minuter och termostatfunktionen skickar ett värde på 15% så är slingan fullt öppen endast en minut, resten av tiden är den under reglering till öppet resp. stängd.
Redigerat:
När jag tittar på inställningarna som är nu (innan jag justerat) blir jag lite konfunderad över kontrollmetoden PI Control med Control typ Continuous (1 byte). Om det är korrekt så funkar det ju inte med den 4e gruppadressen som är en switch på 1 bit. Vad är det som är kopplat till själva av och på av värmeenheten (en t2 blue golvkabel från Raychem)?
Jag har börjat med golvvärmen vid terrassdörren eftersom denna verkar "minst problematisk" (andra delar av värmesystemet saknar för närvarande t.ex. Ärvärde (Current Temperature/Temperature sensor value) eller har riktigt skumma värden på Ärbörvärde (Basic setpoint/Reference Setpoint).
Hursomhelst, jag har ändrat till PWM, det verkar också stämma överens med den aktor som är kopplad till samma golvvärme (märks XS) (se bifogade skärmbilder på parametrarna för denna). Jag märker inte riktigt att golvet bli varmare eller kallare, men tänker att det kanske tar tid eftersom det är sten som skall värmas upp eller svalna så tänkte kolla igen imorgon bitti. En intressant observation är att när jag ändrat till PWM så verkar det fungera med den ursprunglig setupen i appen där "inställt värde" (XB)/current setpoint ändras med ett "Temp contol"-element kopplat till XÄB/Reference setpoint. Jag fattar inte riktigt hur logiken är, men nu är XB och XÄ samma och när jag ändrar XÄB i appen så ändras XB. Så här långt har jag dock inte sett att switchen (XS) slår om när jag ändrar XÄB.
En sak som fortfarande är ett mysterium är hur Zennio-termostaten styr aktuatorn - skickar den telegram för av- och på och var hittar jag i så fall informationen om hur detta styrs (var står det vart telegrammen skall skickas)?
Det jag inte riktigt fått grepp om ännu är vad som egentligen styr slingan. Jag vet inte om det är självklart hur det fungerar eller om jag skall leta efter informationen någonstans i ETS.
Jag har börjat med golvvärmen vid terrassdörren eftersom denna verkar "minst problematisk" (andra delar av värmesystemet saknar för närvarande t.ex. Ärvärde (Current Temperature/Temperature sensor value) eller har riktigt skumma värden på Ärbörvärde (Basic setpoint/Reference Setpoint).
Hursomhelst, jag har ändrat till PWM, det verkar också stämma överens med den aktor som är kopplad till samma golvvärme (märks XS) (se bifogade skärmbilder på parametrarna för denna). Jag märker inte riktigt att golvet bli varmare eller kallare, men tänker att det kanske tar tid eftersom det är sten som skall värmas upp eller svalna så tänkte kolla igen imorgon bitti. En intressant observation är att när jag ändrat till PWM så verkar det fungera med den ursprunglig setupen i appen där "inställt värde" (XB)/current setpoint ändras med ett "Temp contol"-element kopplat till XÄB/Reference setpoint. Jag fattar inte riktigt hur logiken är, men nu är XB och XÄ samma och när jag ändrar XÄB i appen så ändras XB. Så här långt har jag dock inte sett att switchen (XS) slår om när jag ändrar XÄB.
En sak som fortfarande är ett mysterium är hur Zennio-termostaten styr aktuatorn - skickar den telegram för av- och på och var hittar jag i så fall informationen om hur detta styrs (var står det vart telegrammen skall skickas)?
Nu har jag löst alla knutar. Det som tog längst tid, och var mest frustrerande, visade sig vara ett fånigt fel jag gjorde när jag uppdaterade (och som gjorde att mina uppdateringar inte gick helt igenom och jag trodde därför att jag inte hade hittat felet (felen)).
Följande fel har jag korrigerat (ok, några enheter kvar att fixa, men nu vet jag åtminstone vad som behöver göras) för värmeenheterna:
1. i Bab-tech-appen var +- knapparna ofta kopplade till fel enhet så att när ändrade temperaturen på en enhet så ändrades värdena för en annan
2. i ETS var parametern för termostaten (i Quaden) inställd på PI för alla enheter, men aktorn behöver PWM
3. Det saknades helt en koppling mellan quaden (termostaten) och aktorn som är kopplad till respektive värmekälla... - vilket gjorde allting så svårbegripligt för mig för jag kunde inte förstå hur termostaten styrde värmekällan. Jag har nu kopplat aktorns gruppadress till PI Control (PWM) i Quaden
4. Parametern Relative Setpoints var inställd, men Special mode och Special mode status saknades gruppadresser och därmed koppling så inga scenarios var förberedda (och därmed helt onödigt att massa parametrar för olika scenarios var programmerade). Här har jag börjat att lägga till gruppadresser för Special mode och SM status så att jag så småningom kan börja köra scenarios med dessa.
5. PWM cycle time i quadarna inställd på 15 min och i aktorerna på 10. Vet inte om det spelar någon roll att de skiljer sig åt, men har nu satt alla på 15 min för säkerhets skull
6. diverse (slarv?)fel för enstaka värmekällor:
- en värmekälla var börvärdet kopplad till T2 istället för T1 (dvs till en annan termostat än övriga delar av styrningen var kopplade till)
- en värmekälla var kopplad till Current basis Setpoint T1 istället för Current Setpoint T2
7. Av mina 9 värme-enheter som är kopplade till en KNX-termostat så har 3 en datatyp i aktorn som är 5 som är av datatypen switch och en som helt enkelt saknar datatyp. Kan det finnas någon rationell anledning till att man har valt olika (av de 5 är det 2 som är golvvärme så det är inte värmekällan som skiljer) eller ska jag byta så att alla är samma (de jag fixat hittills har alla haft datatypen switch)?
En av värmekällorna (en golvkonvektor) styrs av en aktor som är inställd som switchaktor och inte som Heating actor vilket övriga värmekällor är. Är detta ytterligare ett slarvfel eller tror ni att kan vara gjort så av någon specifik anledning (det är den enda golvkonvektor jag har så jag har inget att jämföra med)?
Utöver ovan är ett antal adresser kopplade till fel ingångar i quadarna (allt är korrekt i elektrikerns dokumentation, så detta är elkonsulterna som slarvat), andra har adressen kopplad till en ingång, men sedan är parametrarna satta för en annan (tom ingång)
Ytterligare ett antal devices som helt enkelt saknade adresser...
osv
osv
Plus en helt oanvändbar app (men som jag nu programmerat om så det blir nog bra).
Jag kanske borde gråta (elkonsultfirman har totalt fakturerar över 330.000 kr och jag tror att det nästan bara är timmar.... - det kändes helt orimligt, men jag kände hela tiden att jag var tvungen att fortsätta att betala för att de skulle "göra klart") - men väljer att bara vara lättad och lycklig över att jag nu äntligen har kontroll över detta och kommer att ha ett fungerande hem. 😊
Plus att jag tycker det är kul att lära mig nya saker och nu känner jag mig faktiskt ganska bekväm med hur ETS och Bab-tech fungerar. Mycket kvar att justerar och scenarios att bygga, men redan nu såååå mycket bättre.
Stort tack för hjälpen! 😊
Följande fel har jag korrigerat (ok, några enheter kvar att fixa, men nu vet jag åtminstone vad som behöver göras) för värmeenheterna:
1. i Bab-tech-appen var +- knapparna ofta kopplade till fel enhet så att när ändrade temperaturen på en enhet så ändrades värdena för en annan
2. i ETS var parametern för termostaten (i Quaden) inställd på PI för alla enheter, men aktorn behöver PWM
3. Det saknades helt en koppling mellan quaden (termostaten) och aktorn som är kopplad till respektive värmekälla... - vilket gjorde allting så svårbegripligt för mig för jag kunde inte förstå hur termostaten styrde värmekällan. Jag har nu kopplat aktorns gruppadress till PI Control (PWM) i Quaden
4. Parametern Relative Setpoints var inställd, men Special mode och Special mode status saknades gruppadresser och därmed koppling så inga scenarios var förberedda (och därmed helt onödigt att massa parametrar för olika scenarios var programmerade). Här har jag börjat att lägga till gruppadresser för Special mode och SM status så att jag så småningom kan börja köra scenarios med dessa.
5. PWM cycle time i quadarna inställd på 15 min och i aktorerna på 10. Vet inte om det spelar någon roll att de skiljer sig åt, men har nu satt alla på 15 min för säkerhets skull
6. diverse (slarv?)fel för enstaka värmekällor:
- en värmekälla var börvärdet kopplad till T2 istället för T1 (dvs till en annan termostat än övriga delar av styrningen var kopplade till)
- en värmekälla var kopplad till Current basis Setpoint T1 istället för Current Setpoint T2
7. Av mina 9 värme-enheter som är kopplade till en KNX-termostat så har 3 en datatyp i aktorn som är 5 som är av datatypen switch och en som helt enkelt saknar datatyp. Kan det finnas någon rationell anledning till att man har valt olika (av de 5 är det 2 som är golvvärme så det är inte värmekällan som skiljer) eller ska jag byta så att alla är samma (de jag fixat hittills har alla haft datatypen switch)?
En av värmekällorna (en golvkonvektor) styrs av en aktor som är inställd som switchaktor och inte som Heating actor vilket övriga värmekällor är. Är detta ytterligare ett slarvfel eller tror ni att kan vara gjort så av någon specifik anledning (det är den enda golvkonvektor jag har så jag har inget att jämföra med)?
Utöver ovan är ett antal adresser kopplade till fel ingångar i quadarna (allt är korrekt i elektrikerns dokumentation, så detta är elkonsulterna som slarvat), andra har adressen kopplad till en ingång, men sedan är parametrarna satta för en annan (tom ingång)
Ytterligare ett antal devices som helt enkelt saknade adresser...
osv
osv
Plus en helt oanvändbar app (men som jag nu programmerat om så det blir nog bra).
Jag kanske borde gråta (elkonsultfirman har totalt fakturerar över 330.000 kr och jag tror att det nästan bara är timmar.... - det kändes helt orimligt, men jag kände hela tiden att jag var tvungen att fortsätta att betala för att de skulle "göra klart") - men väljer att bara vara lättad och lycklig över att jag nu äntligen har kontroll över detta och kommer att ha ett fungerande hem. 😊
Plus att jag tycker det är kul att lära mig nya saker och nu känner jag mig faktiskt ganska bekväm med hur ETS och Bab-tech fungerar. Mycket kvar att justerar och scenarios att bygga, men redan nu såååå mycket bättre.
Stort tack för hjälpen! 😊
Glädjande att du börjar få ordning på det.
Jag kan varmt rekommendera att grotta ner sig i eibporten. Visualiseringarna är mycket bra och mycket användbara för att skapa websidor där man kan övervaka med hjälp av såväl indikeringar som grafer.
Vidare är modulen Cubevision mycket användbar om man t.ex. vill ska en appliknande gränssnitt för olika funktioner. Passar både för dator och mobil.
Logikeditorn är fantastisk, där kan man göra det mesta.
Bör inte spela någon större roll. I Quaden påverkar det hur beräkningen görs vilket avspglas i hur ett värde beräknas ch skickas ut på bussen. I aktorn påverkar värdet hur aktorn styr aktuell värmekälla.C Cff skrev:
Slarvfel tippar jag. Ser ingen anledning till att funktionen switchaktor där.C Cff skrev:
Jag kan varmt rekommendera att grotta ner sig i eibporten. Visualiseringarna är mycket bra och mycket användbara för att skapa websidor där man kan övervaka med hjälp av såväl indikeringar som grafer.
Vidare är modulen Cubevision mycket användbar om man t.ex. vill ska en appliknande gränssnitt för olika funktioner. Passar både för dator och mobil.
Logikeditorn är fantastisk, där kan man göra det mesta.
Stort tack!
Spännande, jag skall titta närmare på Logikeditorn och Cubevision. För närvarande är appen jag använder för att styra systemet gjord i Bab-tech eibPort editor (efter att jag nu har rättat upp och designat om det mesta av det som konsulten ”programmerar” så är den hyfsat användbar och även om det inte är lättöverskådligt har jag lyckats lägga till en del logik i den).
Spännande, jag skall titta närmare på Logikeditorn och Cubevision. För närvarande är appen jag använder för att styra systemet gjord i Bab-tech eibPort editor (efter att jag nu har rättat upp och designat om det mesta av det som konsulten ”programmerar” så är den hyfsat användbar och även om det inte är lättöverskådligt har jag lyckats lägga till en del logik i den).
Skönt att du börjat lösa sig för dig!
Ett tips om du inte redan använder det är att köra Gruppdiagnostik när du testar funktioner. Där kan du se alla busstelegram som skickas och t.ex. kunna se dimringskvitten från en dimmer när du skriver 60% till den.
Om du har Facebook så kan jag även tipsa om gruppen "KNX Sverige" för att få inspiration och hjälp. Finns både en grupp och en KNX-chatt på Messenger som är ganska aktiv.
//Patrik
Ett tips om du inte redan använder det är att köra Gruppdiagnostik när du testar funktioner. Där kan du se alla busstelegram som skickas och t.ex. kunna se dimringskvitten från en dimmer när du skriver 60% till den.
Om du har Facebook så kan jag även tipsa om gruppen "KNX Sverige" för att få inspiration och hjälp. Finns både en grupp och en KNX-chatt på Messenger som är ganska aktiv.
//Patrik