IHC, M-bus, Nilan og DanTherm ventilation.

[Lars1]

Jeg har gennem det sidste år fra flere kilder hørt rygter om at LK er på vej med en løsning, således at f.eks. Nilan og DanTherm's ventilations anlæg kan styres fra IHC controleren. Jeg har flere gange hørt at det skulle være lige på trapperne, men endnu er det ikke lykkes mig at få flere informationer om hvordan det vil komme til at virke, eller hvornår det bliver frigivet. En sælger hos DanTherm kom dog på et tidspunkt til at nævne at kommunikationen kommer til at ske via M-bus, og han lovede mig faktisk at jeg kunne få en early release af systemet, hvis jeg købte et DanTherm ventilation anlæg. Detsværre vil han ikke længere stå ved det han har lovet. Jeg står og skal anskaffe mig et ventilations anlæg i løbet af de næste 3-6 mdr. og jeg er vældig interesseret i at kunne styre det via min IHC installation. Jeg håber derfor at der er nogen her, som kan kaste lidt mere lys over denne tilsyneladen dybe hemmelighed hos LK.

[Lars Jacobsen]

Jeg her et Nilan 450 system og det normale interface tillader én Externt brugervalgt indstilling som aktiveres vha en kontakt eller relæ(IHC).Selve systemet styres dog vha modbus og skulle derfor kunne kontrolleres af andet end deres egen CTS600. Jeg har dokumentation på protokollen, men har endnu ikke haft mulighed for at teste det. Det kræver jo en pc/cpu der kan snakke modbus og har rs485 interface. Det sidste har IHC controlleren jo, så det burde jo "bare" være et spørgsmål om LK kan/vil implementere det.Andre anlæg kan styre ind/udblæsning uafhæng og direkte vha relæ indgange og her er der ingen problemer med at lade ihc'n styre det. Søg lidt i forummet og du vil se et par eksempler.

[Lars1]

Hvor gammelt er dit Nilan 450 system? Det er kun et par mdr. siden at jeg sidst fik at vide at der ikke er nogen mulighed for at fjernstyre en comfort 300 eller VPL15 udover via Nilans betjenings panel. De benytter begge CTS600, såvidt jeg er orienteret, men CTS600 modulet findes selvfølgelig også i flere varianter, selvom Nilan alle kalder dem CTS600 i deres reklame papir. Selvom der er en mulighed for at lave 1 bruger valgt indstilling er det ikke helt nok. Som udgangs punkt ønsker jeg at kunne sætte en ubeboet tilstand (jeg er ofte væk i flere dage af gangen), samt en brand tilstand. Det er lidt svært hvis man kun har mulighed for at sætte 1 bruger valgt indstilling.Jeg håber virkelig at LK snart kommer med en opdatering. De andre features jeg har hørt rygter om, som f.eks. sammenkobling af flere controler via ethernet vil også være ganske lækre, da den nuværende sammenkobling med ind og udgange noget forældet idag.

[Lars Jacobsen]

Ja jeg vil også gerne have mulighed for at have mere end én bruger indstilling. Nogle gange vil jeg have højere udsugning (fugt i badeværelse/røg i køkkenet) og andre gange vil jeg gerne have højere indblæsning (centralstøvsuger kører/optænding i brændeovnen).Mit er godt 2 år gammelt:Software 1: 1.31 (Anlæg)Software 2: 1.01 (CTS600 Betjeningspanel)Og det er helt rigtigt det ikke er muligt at fjernstyre via betjeningspanel. Men systemer er jo lavet så det er muligt at koble flere betjeningspaneler på, og her er det så man kan "hacke" lidt og lave et betjeningspanel vha en pc, arduino, IHC-controller eller anden CPU. Det kræver som sagt blot der er RS485 interface og så understyttelse af Modbus protokollen. Så kan du selv emulere betjeningspanel og styre stort set alt. Det kræver selvfølgelig kendskab til Nilans implementering af Modbus protokollen, og hvilke registre de anvender. Men det kan du se i disse 2 dokumenter :

dos.txt

Prot485.pdf

[Nikolaj_K]

Hej,

Men systemer er jo lavet så det er muligt at koble flere betjeningspaneler på, og her er det så man kan "hacke" lidt og lave et betjeningspanel vha en pc, arduino, IHC-controller eller anden CPU. Det kræver som sagt blot der er RS485 interface og så understyttelse af Modbus protokollen. Så kan du selv emulere betjeningspanel og styre stort set alt

 

Jeg ved det er et gammelt emne, men jeg ville lige høre om der var andre der havde givet sig i kast med det. Så vidt jeg ved kører betjeningen (CTS600) og styreenheden (placeret i selve anlæget) i ModBus Master/slave, hvor det er CTS600 der er master og styreenheden der er slave. Idet der på serial Modbus kun kan være _en_ master, kan jeg ikke umiddelbart se hvordan man kan sætte flere betjeningspaneler på uden samtidig at udvikle en enhed der sidder mellem styreenheden og betjeningsenhederne som proxy med det formål at opsamle requests og sætte disse i kø så der ikke kommer buskollisioner. Rent programmeringsteknisk kunne man nok komme omkring det med kollisionerne da der er automatisk retransmission indbygget i protokollen, men jeg tænker at der vil være problemer rent elektrisk med 2 mastere der tilgår bussen samtidig hvis der ikke er en proxyenhed imellem?

 

/Nikolaj

[Lars1]

Hej,

 

Jeg ved det er et gammelt emne, men jeg ville lige høre om der var andre der havde givet sig i kast med det. Så vidt jeg ved kører betjeningen (CTS600) og styreenheden (placeret i selve anlæget) i ModBus Master/slave, hvor det er CTS600 der er master og styreenheden der er slave. Idet der på serial Modbus kun kan være _en_ master, kan jeg ikke umiddelbart se hvordan man kan sætte flere betjeningspaneler på uden samtidig at udvikle en enhed der sidder mellem styreenheden og betjeningsenhederne som proxy med det formål at opsamle requests og sætte disse i kø så der ikke kommer buskollisioner. Rent programmeringsteknisk kunne man nok komme omkring det med kollisionerne da der er automatisk retransmission indbygget i protokollen, men jeg tænker at der vil være problemer rent elektrisk med 2 mastere der tilgår bussen samtidig hvis der ikke er en proxyenhed imellem?

 

/Nikolaj

Den forklaring jeg fik fra LK, da jeg kiggede på deres løsning var at det var deres PLC, som er master, mens CTS6000 er slave. Det er også grunden til at DanTherm ikke er med på vognen. De vil ikke aksepter at LK's PLC er master.

 

Jeg synes LK's løsning er penge ud af vinduet, men jeg har endnu ikke haft tid til selv at gå i gang med at lave noget bedre.

[Lars Jacobsen]

Har købt mig en usb-rs485 dims, men syntes ikke rigtig jeg kan "sniffe" noget fornuftigt iht protokollen.

Derfor har jeg sat projektet lidt på standby, men behovet er der stadig.

Som jeg forstår protokollen så er master-slave forholdet ment at der kun kan initieres fra en master, ikke en slave.

Derfor er betjeningspanelet master og cts600 styringen i anlæget slave. Normal id på disse to er 1 for panel og 3 for styring.

Id nr 2 er reserveret til en PC. Denne kan godt være master og dermed kommunikere med styringen (id3) ellers var der vel ingen grund til at have den. Alt efter hvilken software man så installerer på PC noden (som kan vælre en PLC, arduino eller lig.) ja så kan man få enheden til at være master eller slave efter behov. Det giver nok mest mening som master.

[Nikolaj_K]

Jeg troede egentlig at CTS600 var navnet på selve betjeningspanelet, men som jeg kan forstå så er det betegnelsen for styringen i selve anlæget?

 

Vi er i hvert fald enige om at betjeningspanelet er master og anlæget er slave. Jeg har dumpet trafikken mellem betjeningspanelet og anlæget, og det viser at betjeningspanelet poller anlæget  periodisk (hvert sekund), og sender tastetryk on-demand. Anlæget returnerer med bl.a. komplette genererede skærmbilleder til displayet. Så vidt jeg kan se er der er dog ikke 100% overensstemmelse med den udleverede protokol-spec fra Nilan - bl.a. passer antallet af bytes i typeWI_RO_REGS ikke helt.

 

Grunden til at jeg ville lave en proxy og bruge multiple mastere er at jeg ønsker at bibeholde betjeningspanelet, samtidig med at jeg kan styre indblæsning/udsugning via et embedded board som jo også ville være en master.

 

/Nikolaj 

[Lars1]

Har købt mig en usb-rs485 dims, men syntes ikke rigtig jeg kan "sniffe" noget fornuftigt iht protokollen. Derfor har jeg sat projektet lidt på standby, men behovet er der stadig. Som jeg forstår protokollen så er master-slave forholdet ment at der kun kan initieres fra en master, ikke en slave. Derfor er betjeningspanelet master og cts600 styringen i anlæget slave. Normal id på disse to er 1 for panel og 3 for styring. Id nr 2 er reserveret til en PC. Denne kan godt være master og dermed kommunikere med styringen (id3) ellers var der vel ingen grund til at have den. Alt efter hvilken software man så installerer på PC noden (som kan vælre en PLC, arduino eller lig.) ja så kan man få enheden til at være master eller slave efter behov. Det giver nok mest mening som master.

Hmm. en bus med max 3 medlemmer er ikke meget bus i min verden.

[Lars1]

Jeg troede egentlig at CTS600 var navnet på selve betjeningspanelet, men som jeg kan forstå så er det betegnelsen for styringen i selve anlæget?

 

Vi er i hvert fald enige om at betjeningspanelet er master og anlæget er slave. Jeg har dumpet trafikken mellem betjeningspanelet og anlæget, og det viser at betjeningspanelet poller anlæget  periodisk (hvert sekund), og sender tastetryk on-demand. Anlæget returnerer med bl.a. komplette genererede skærmbilleder til displayet. Så vidt jeg kan se er der er dog ikke 100% overensstemmelse med den udleverede protokol-spec fra Nilan - bl.a. passer antallet af bytes i typeWI_RO_REGS ikke helt.

 

Grunden til at jeg ville lave en proxy og bruge multiple mastere er at jeg ønsker at bibeholde betjeningspanelet, samtidig med at jeg kan styre indblæsning/udsugning via et embedded board som jo også ville være en master.

 

/Nikolaj 

Vedr. CTS6000, så er Nilan er også på dette dette punkt gode til at misinformer. CTS6000 er navnet på den samlede pakke af styringes enhed (slave) som sidder i anlægget og betjenings panelet (master)

Såidt jeg husker, kan du med LK's metode, fortsat bruge Nilan's betjenings panel parallet med LK's PLC, men jeg har ikke kigget på det siden i sommers, så jeg kan huske forkert.

[Lars Jacobsen]

Enig med dig Lars1, at CTS6000 er hele systemet og ikke kun een af delkomponenterne.

Men der kan sættes ligeså mange enheder på busen som protokollen tillader. (255 stk), og det er kun de første 3-4 stykker som er reserverede. Men nok om topologi diskutionen, og lad os høre lidt mere om løsninger/erfaringerne fra Nikolai.

Har du prøvet at sende komandoer direkte fra PC'n til styringen i anlæget ? Det burde i min optik være muligt at gøre direkte, uden at skulle omkring en proxy eller lign.

Når det er på plads vil jeg foreslå en roadmap i tråd med det jeg tidligere har skrevet. Nemlig en Arduino, Rpi eller lign. som billig blackboks mellem IHC og Nilan. Istedet for Schneider PLC'n. En sådan løsning vil kunne tilgåes og styres både via net/lan via software eller via i/o interfaces fra anden hardware.

[Nikolaj_K]

Enig med dig Lars1, at CTS6000 er hele systemet og ikke kun een af delkomponenterne. Men der kan sættes ligeså mange enheder på busen som protokollen tillader. (255 stk), og det er kun de første 3-4 stykker som er reserverede. Men nok om topologi diskutionen,

 

Jeps, bortset fra navneforvirringen i starten er vi er helt enige om master/slave forhold og om at systemet generelt følger ModBus RTU.

 

og lad os høre lidt mere om løsninger/erfaringerne fra Nikolai. Har du prøvet at sende komandoer direkte fra PC'n til styringen i anlæget ?

 

Nej, ikke endnu. Intil videre parser jeg bare beskederne efter bedste evne... jeg synes der mangler lidt i den sparsomme info fra Nilan til at få et helt klart billede. Dog modtager jeg fint de informationer som sendes til skærmen på betjeningspanelet, og også de tastetryk der sendes til anlæget.

 

Det burde i min optik være muligt at gøre direkte, uden at skulle omkring en proxy eller lign.

 

Ja, hvis betjeningspanelet ikke er koblet på er der ingen problemer i at sende kommadoer... og hvis man venter til slave responset er modtaget af betjeningspanelet så har man ca 900 ms inden betjeningspanelet sender en ny request. Jeg ved dog ikke om betjeningspanelet aktivt styrer bussen i pausen , således at denne og master nr 2 sætter output mod output, men det må jeg jo prøve af (og det var derfor jeg ville sætte en embedded enhed ind som proxy)

 

Når det er på plads vil jeg foreslå en roadmap i tråd med det jeg tidligere har skrevet. Nemlig en Arduino, Rpi eller lign. som billig blackboks mellem IHC og Nilan. Istedet for Schneider PLC'n. En sådan løsning vil kunne tilgåes og styres både via net/lan via software eller via i/o interfaces fra anden hardware.

Jeg har lavet min RPI om til en SousVide controller, så jeg havde planlagt at bruge min BeagleBone. Den styrer i forvejen min alarm, og kører openHab som igen taler med IHC. På den måde er det også let at lave et webinterface til at styre Nilan'en.

 

Det jeg gerne vil opnå er at styre ind/udblæsning, samt at få info fra følerne i anlæget. Jeg synes ikke det fremgår i hvilke registre de ligger i Nilans dokumentation. Jeg overvejer at lave en scanningsroutine der prøver alle registre af - det kan være man kan være heldig at se et mønster i registermap'et.

 

/Nikolaj

[Lars Jacobsen]

OK BeagleBone kendte jeg så ikke lige, men det gør jeg så nu.

Mener ellers nok registre på følerene kan findes i dokumentationen jeg har uploadet, men eller kan de vel hurtigt identificeres ved en snifning.

Glæder mig til at høre om den videre udviklig.

[Nikolaj_K]

OK BeagleBone kendte jeg så ikke lige, men det gør jeg så nu. Mener ellers nok registre på følerene kan findes i dokumentationen jeg har uploadet, men eller kan de vel hurtigt identificeres ved en snifning. Glæder mig til at høre om den videre udviklig.

 

Det er desværre ikke lige til synes jeg. TXX-følerne står som input registre, og ikke output... det er det jeg studser over, men jeg har heller ikke sat mig ned for at læse modbus spec'en som Nilans implementation bygger over, så det kan være at jeg misforstår input/output begrebet.

 

Nå, men jeg må igang med at hacke skidtet. Jeg skal nok melde tilbage hvis der sker nogen form for gennembrud :-)

 

/Nikolaj

[Lars Jacobsen]

En temperatur føler der giver information til (ind i) systemet benævnes vel meget logisk som et input register og så er det vel bare at skrive læs komandoen til det pågældende register for at udlæse den aktuelle værdi.

Hvis man vil aktivere en udgang som bypass, eller en motor skriver man vel bare til det pågældende register/bit. Dette gælder f.eks. også hvis man vil sætte en temperatur.

Syntaxen/logikken er helt i samme tråd som IHC.

Men det er muligt der er bliver brugt flere/andre adresser end de der er i det gamle dokument jeg har vedhæftet. Der er jo kommet et par releases siden da, med bla. muligheden for fugt og co2 og flere bruger presets.

[Nikolaj_K]

En temperatur føler der giver information til (ind i) systemet benævnes vel meget logisk som et input register og så er det vel bare at skrive læs komandoen til det pågældende register for at udlæse den aktuelle værdi. Hvis man vil aktivere en udgang som bypass, eller en motor skriver man vel bare til det pågældende register/bit. Dette gælder f.eks. også hvis man vil sætte en temperatur. Syntaxen/logikken er helt i samme tråd som IHC.

Som jeg læser modbus standarden (og nu har jeg aldrig leget med PLC'ere så jeg har ingen domæneviden her), er input registre read-only, og Output registre (holding registre) er read/write, og det var mere dét der forvirrede mig.  Jeg forventede at et inputregister var noget som masteren skrev til, og et output register var noget masteren læste fra, men jeg kan godt se at det ikke hænger sådan sammen. Så blev jeg så meget klogere :-)

 

Nå, men lad os komme til sagen. Nedenfor er et udsnit af et dump af trafikken mellem betjeningspanelet og anlæget. Venste kolonne er antallet af microsekunder siden sidste transmission. Det ses således at der normalt er 20ms - 40ms mellem en request fra masteren til svaret er modtaget. Derefter går der ca 960-980 ms inden næste periodiske request bliver sendt fra masteren.  

 

 

 

974883:         03 42 01 00 00 01 00 02 00 00 67 F5

30736:          03 42 02 00 00 05 00 0A 56 41 52 4D 45 20 20 20 00 00 1C FE

976920:         03 42 00 2A 00 01 00 02 00 E8 27 BF

27811:          03 42 02 0A 00 05 00 0A 3E 31 3C 20 32 30 DF 43 00 00 A1 A3

 

 

Dekodes pakkerne fås:

03 42 01 00 00 01 00 02 00 00 67 F5

03         Destination (3=anlæg) 

42         CMD = _FC_WI_RO_REGS

01 00    Adresse = 0x0100 

00 01    Antal registre

00 02    Antal bytes

00 00    Data  (tastetryk )

67 F5    CRC

 

Svar

03       Destination (3=anlæg) 

42        CMD = _FC_WI_RO_REGS

02 00 (adresse = display data)

00 05  Antal registre

00 0A  Antal bytes

56 41 52 4D 45 20 20 20 00 00 (Ascii = Varme<spc><spc><spc>)

1C FE CRC

 

 

 

03       Destination (3=anlæg) 

42        CMD = _FC_WI_RO_REGS

00 2A (adresse = A/D count)

00 01 Antal registre

00 02 Antal bytes

00 E8 A/D count  (fra temp føler i betjening)

27 BF CRC

 

 

03         Destination (3=anlæg) 

42        CMD = _FC_WI_RO_REGS 

02 0A   (adresse = LCD linie 2)

00 05   Antal registre

00 0A   Antal bytes

3E 31 3C 20 32 30 DF 43 00 00  (Ascii = "<1> 20*C")

A1 A3

 

 

Det ses at betjeningspanelet blot fungerer som en framebuffer. Betjeningspanelet har ingen tilstandsmaskine, og den modtager ikke konkrete dataværdier såsom temperatur og hastighed, men derimod komplette skærmbilleder fra anlæget. Når man så trykker på en knap sendes dette til anlæget og et nyt skærmbillede genereres og sendes til betjeningspanelet udfra viden om nuværende tilstand og det indkomne tastetryk. 

 

Næste post kommer jeg med registerdump.

 

/Nikolaj

[Nikolaj_K]

Hej igen,

Hermed registerdump. Jeg har dumpet registrene i pakker á 32 bytes (16 registre á 2 bytes). De pakker der udelukkende indeholdt 32 bytes med 0x00 har jeg udeladt. Payload er markeret med bold

 

 

Reading Output Regs:

Dump reg  00 to  0F: 03 03 20 00 10 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6F C8 

Markeret med rødt = indblæsning/udblæsning. Skifter jeg mellem de 4 hastigheder ser jeg en ændring her. Om det dirkete en en værdi til PWM ved jeg ikke. 

 

Dump reg 100 to 10F: 03 03 20 00 00 00 00 00 01 00 00 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 32 

Markeret med rødt = Display codepage

Markeret med grønt = SW version

 

Dump reg 200 to 20F: 03 03 20 00 56 00 41 00 52 00 4D 00 45 00 20 00 20 00 20 00 00 00 00 00 3E 00 34 00 3C 00 20 00 32 00 30 76 64 

Markeret med rødt = Ascii encoding af display: "varme   \n<4> 20"

 

Dump reg 210 to 21F: 03 03 20 00 DF 00 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6A F8 

Markeret med rødt = Ascii encoding af display: "*c"

 

Reading Input regs:

Dump reg  00 to  0F: 03 04 20 00 00 00 00 00 1D 00 C2 00 00 00 00 00 34 00 F5 00 00 00 60 00 00 00 00 00 00 00 00 00 1C 00 00 F5 32 

Markeret med rødt = temperaturværdier. Umiddelbart ser jeg ingen direkte sammenhæng mellem de målte værdier og temperaturen. Måske det bare er en A/D måling direkte fra NTC'erne? Sidste værdi (0x001C) repræsenterer måleværdien fra betjeningens temeraturføler.

 

Dump reg  20 to  2F: 03 04 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 00 00 00 00 00 00 00 00 00 00 BA CB 

Markeret med rødt = A/D count fra betjening (temperatur). Bruges i beregningen af ovennævnte værdi fra betjening.

 

Dump reg 100 to 10F: 03 04 20 00 00 00 00 00 02 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 63 

Markeret med rødt = Reset årdag og status

 

Dump reg 110 to 11F:  03 04 20 00 39 00 07 00 16 00 04 00 20 00 12 00 12 00 20 00 39 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2E C4 

Markeret med rødt = Tidspunktet (16:07: 39 - 20/12/12 - 4=4.dag=torsdag)

 

 

Som sagt ville jeg gerne styre ind/udblæsning samt læse temperatur. Jeg kunne forsøge at sætte hastigheden direkte (hvis det altså er PWM værdier), men jeg ved ikke om der er andet man skal tage højde for så man ikke roder i styringens tilstandsmaskine. 

 

Alternativet er at man laver ændringerne ved at navigere rundt i menusystemet ved at sende tastaturkommandoer til styringen og parser det returnerede skærmdump(har prøvet og det virker ok)... det er en lidt øv løsning, men det er måske den mindst invasive?

 

/Nikolaj

[Thomas Nissen]

Kan det hjælpe noget at Visility har en IHC Funktionsblok til Nilan CTS602??

http://www.visility.com/media/3154/visility_funktionsblokke_26-01-2013.zip

[Jesper B]

Hej Nikolaj_K

 

Yderst interessant emne dette med at styre Nilan. Jeg går selv og skal nok til at investere i noget ventilation og vil selvfølgelig  have det til at virke med IHC. Så jeg er begyndt at tænke i samme baner som dig. A la en Beaglebone black og noget openHAB. Dette ser også ud til at være nogenlunde til ift. IHC da der der er en binding i OpenHAB til IHC. Men hvordan havde du tænkt dig over mod Nilan. bruger du der en USB til RS485?

Havde du tænkt dig at lave en ny binding til OpenHAB der kunne styre Nilan? Hvis det var sådan kunne jeg godt tænke mig at være med i det.

Men mit første fokus er nok at få Beaglebone til at køre med IHC dernæst Nilan :-).

[Nikolaj_K]

Yderst interessant emne dette med at styre Nilan. Jeg går selv og skal nok til at investere i noget ventilation og vil selvfølgelig  have det til at virke med IHC. Så jeg er begyndt at tænke i samme baner som dig. A la en Beaglebone black og noget openHAB. Dette ser også ud til at være nogenlunde til ift. IHC da der der er en binding i OpenHAB til IHC. Men hvordan havde du tænkt dig over mod Nilan. bruger du der en USB til RS485?

Havde du tænkt dig at lave en ny binding til OpenHAB der kunne styre Nilan? Hvis det var sådan kunne jeg godt tænke mig at være med i det.

Men mit første fokus er nok at få Beaglebone til at køre med IHC dernæst Nilan :-).

 

Siden jeg skrev ovenstående indlæg har jeg implementeret en anden løsning, da der var flere ting der irriterede mig.

 

1) Idet protokollen mellem Nilan anlæget og vægbetjeningen er Modbus RTU som pr. definition er et master-slave forhold med max 1 master, er det ikke lige til at sætte en Beaglebone (eller andet embedded udstyr) ind som en ekstra master. Det kan dog lade sig gøre hvis man sørger for at Beaglebone ikke bruger bussen når vægbetjeningen taler med anlæget (hvilket den gør et par gange i sekundet). Alternativt kan man sætte Beaglebone ind mellem vægbetjeningen og anlæget og lade Beaglebone fungere som en proxy der sørger for at der ikke kommer kollisioner.  

 

2) Så vidt jeg kunne analysere mig frem ved at dumpe registrene, virkede det som om man er begrænset til at sætte en PWM værdi til at styre motorerne direkte, hvilket jeg ikke bryder mig om da jeg ikke ved om man så bypasser noget funktionalitet inde i anlæget. Jeg ville foretrække om man istedet kunne sætte motorhastigherne som 1-4 ligesom via vægbetjeningen. 

 

Istedet fandt jeg ud af at jeg egentlig kun har brug for at køre anlæget på 2 hastigheder: 2 (=normal hastighed), og 4(= højeste hastighed). Derfor har jeg lavet et lille print med en MCU, et relæ og en sensor til at måle luftfugtigheden i badeværelset. Hvis den bliver for høj, trækker MCU'en relæet og Nilan sætter hastigheden op indtil luftfugtigheden er normaliseret. Desuden kan jeg via et serielt interface mellem MCU'en og min Linux box, dels holde øje med luftfugtigheden, forcere en tilstand, indstille tærskelværdier, og programmere en ugeplan.

 

Jeg har endnu ikke interfacet det via openhab (mangler timer i døgnet) men det kommer nok en dag hvor jeg får tid... som det er lige nu kører det fint af sig selv :-)

 

God fornøjelse med projektet.

 

/Nikolaj 

[Jesper B]

Hej igen Nikolaj

Hvordan sætter du de to hastigheder alm og høj. Er det en fysisk kontakt/input på selve Nilan ventilationsenheden?

[Nikolaj_K]

Hej Jesper,

Der skal skabes en forbindelse mellem 2 inputs på Nilans styreprint. Du kan se hvilke på det medfølgende diagram fra Nilan. Når forbindelsen skabes bliver funktionen "Brugervalg" aktiveret. Hvad selve brugervalg funktionen skal udføre sættes op i forvejen via betjeningspanelet.

 

/Nikolaj

[Jesper B]

Tusind tak for svaret.

Jeg vil lige overveje hvilken løsning jeg vil arbejde på. Men det lyder ikke dumt det du der har gjort. Så kan man senere vurdere om man har brug for noget mere avanceret.

VH Jesper

[Lars Jacobsen]

Ja hvis man kan nøjes med Nilans implementeringer er der ingne grund til at lave det mere avanceret.

 

Default findes der jo ihverttilfælde 1 brugervalg som kan aktiveres af eksternt tryk, fugtsensor, timer, IHC eller ....

Hvad der skal ske programmere man så i betjeningeenheden.

 

Men hvis man er uheldig som mig der gerne vil køre med 2 balanceret standardhastigheder i løbet af dagen (lav = 1 og høj = 3) og samtidig har et ønske om forceret udsugning ved fugt/fest/røg eller lign. og et andet ønske om forceret indblæsning når emhætten køre, centralstøvsugeren kører eller der fyres op i pejsen. Ja så er det svært med kun 1 brugervalg. Nu har Nilan så lavet en ny udgave af styreprintet hvor der er 2 brugervalg, men en nyt print koster ca. 5K kr.  Så indtil nu nøjes jeg med det ene brugervalg.

Men det ville da være rart at kunne se/udlæse/logge data fra anlæget og benytte det i andre henseende. Derfor ønsket om en "blackbox" som interfacer. 

[Jesper B]

Ja et brugervalg er selvfølgelig ikke særligt meget og 5K kr. for et brugervalg mere vil jeg også kalde i overkanten   .

Jeg har har nu bestil en Beaglebone Black som jeg vil til at lege lidt med.

Første punkt bliver at få den til at virke med IHC og måske Sonos. Derefter vil jeg se hvor let det er at få den til at snakke Nilansk. Jeg har jo ikke en Nilan endnu.

Men jeg gad godt vide hvordan LK gør i den der halvdyre og dårlige PLC løsning mht. master og slave og det samme for Visility hvor de jo på en eller anden måde kan få noget til at virke.

Er der nogen der ved/har en idé om hvordan det virker?