433MHz-communicatie met microcontrollers

quote:

Fuzzillogic schreef op dinsdag 19 februari 2008 @ 13:17:
Waarschijnlijk heeft jouw ontvanger geen RSSI-out. Je kunt de digitale uitgang dan ook direct aan pin 2 hangen, en op regel 94 FALLING wijzigen in RISING (de schakeling met de tor maakt er juist een negatieve flank van)

Ik heb geprobeerd de code van Fuzzillogic werkend te krijgen. Mijn ontvanger heeft echter ook geen RSSI pin. De wijzigingen die je hier aangeeft werken niet. Ik moet nog even wat verder in je code duiken om een oplossing te zoeken.

De code van P. Tonkes werkt wel maar vind ik niet universeel genoeg. Shorty's code kreeg ik ook nog niet direct aan de praat.

quote:

j-a-s-p-e-r schreef op zaterdag 26 juli 2008 @ 12:35:
Ah, ik geloof dat ik de communicatie tussen de RFXCOM hardware en de diverse plugins nu wel aardig ontcijferd heb.

Hoe heb je dit gedaan? Heb je zelf een RFXCOM receiver aangeschaft? Kun je wat details laten zien?

quote:

j-a-s-p-e-r schreef op zaterdag 26 juli 2008 @ 12:35:
Ah, ik geloof dat ik de communicatie tussen de RFXCOM hardware en de diverse plugins nu wel aardig ontcijferd heb. Voor wie wil kan ik het hier wel posten (dan moet het namelijk even leesbaar worden gemaakt).
Mijn doel is nu om de RFXCOM 'na te apen' met de arduino zodat vrijwel alle homeautomation software (homeseer, powerhouse, mrhouse, indigo, xpl, etc) waar al 'plugins' voor bestaan direct bruikbaar zijn. Nu ik de protocol kant aardig ver heb is het nog een kwestie van een paar test applicatities maken voor de arduino en de code proberen te schrijven.
En nogmaals; xPL is echt een zeer prachtig multiplaform 'framework'. Voor wie het nog niet kent, ga zeker even de faq bekijken: http://wiki.xplproject.or...hat_is_the_xPL_Project.3F

Ik heb sinds kort een RFXCOM om mee te spelen bij koud en regenachtig weer - dat kan dus nog wel even duren.
Ik heb 'm op mijn apple via het screen commando al even een tijdje laten monitoren op wat KAKU spulltejes en oude temp sensoren en ik kan er nog niet veel van maken. Voor mij is het uitpuzzelen hiervan de hobby (en ik kan niet solderen en ook niet programeren dus zo'n arduno is (nog) niet aan mij besteed).
Maar ik heb dus zeker interese voor informatie over de rfxcom communicatie!

Ah leuk dat er nog meer mee bezig zijn!

Ik heb zelf geen RFXcom maar met véél zoeken op internet, nog meer lezen en veel puzzelen ben ik al een heel einde gekomen. De details van het protocol ga ik nu niet typen want ik moet van mezelf zo eens gaan slapen, maar wel even een sheetje. De KaKu decodering komt van Paul Tonkes, dus aan hem alle credits. De notering erachter is van mij.

edit:
voor het geval zich iemand het afvraagt: ik heb de rfxcom 'geanalyseerd' door middel van een test zend&ontvang tool. Te vinden op: http://www.rfxcom.com/downloads.htm Programma RFreceiver en RFtransmitter.

De RFXCOM geeft bijna alle signalen (iig die van kaku en nog een heel stel) door aan de computer als x10 signalen (x10.basic voor de googelaars). Van een heel stel kaku codes heb ik deze x10 codes uitgezocht (zie sheet).
Het x10 protcol is een beetje anders dan dat van KaKu, de RFXCOM werkt bij KaKu in 48bit mode (= variable bitmode). Zoals je kan zien begint elk signaal met 20 (hexadecimaal overigens). Dat is 'rommel' in 32 bit mode zit dat er niet voor maar 32 bit mode kan geen kaku ontvangen. Na de 0x20 komen 4 bytes. De eerste en de derde hiervan bevatten resp. de huis en kanaal+commando. De tweede en vierde byte is de inverse van de andere (dus 0xFF minus waarde of 255- decimale waarde)
Voorbeeld:
code:

20 60 9F 00 FF   = A1ON
xx                20 is opvulling
xx 60             60 is huiscode A
xx xx 9F          FF-60 = 9F checksum van huiscode
xx xx xx 00 xx    00 is kanaal 1 plus 'AAN'
xx xx xx xx FF    FF-0 = FF. duh.

Een 'aan' of 'uit' zit hem in het verhogen van de kanaalcode (3e bit). Bij UIT met 0x20, bij AAN blijft het gelijk. De checksum gaat dus 0x20 (of 0) omlaag (4e bit). De huiscode is hetzelfde voor kanaal 1 tm 8 (let goed, kanaal niet huis), bij kanaal 9 tm 16 gaat de huiscode 0x04 omhoog.
code:

20 64 9B 30 CF  = A 10 OFF
xx                20 is opvulling
xx 64             64 = 60 + 4 is huiscode A 
xx xx 9B          FF-64 = 9B checksum van huiscode
xx xx xx 30 xx    30 is kanaal 10 plus 'uit'
xx xx xx xx CF    FF-30 = CF

Mijn 'wijsheid' is gelukkig niet alleen in een excel sheet te vinden. Nadat ik nagenoeg de boel had uitgepluisd vond ik dit:
code:

'Unit High or Low used?
'Uncomment the line you like to use.
'-------------------------------------------
'In this example UNIT 3 OR 11 is selected
'and to select UNIT 3 the line UNITHL =&H00 must be selected (uncomment)
UNITHL = &H00 'UNITS 1 TO 8
'UNITHL = &H04 'UNITS 9 TO 16

'Select the ON or OFF command to be executed.
'-------------------------------------------
CMD = &H00 'ON
'CMD = &H20 'OFF

'Select the unit to switch on or off.
'-------------------------------------------
'UNIT = &H00 Or CMD '1 OR 9
'UNIT = &H10 Or CMD '2 OR 10
UNIT = &H08 Or CMD '3 OR 11
'UNIT = &H18 Or CMD '4 OR 12
'UNIT = &H40 Or CMD '5 OR 13
'UNIT = &H50 Or CMD '6 OR 14
'UNIT = &H48 Or CMD '7 OR 15
'UNIT = &H58 Or CMD '8 OR 16

'Select the house code (no more changes after this line)
'-------------------------------------------
HOUSE = &H60 Or UNITHL 'A
'HOUSE = &H70 Or UNITHL 'B
'HOUSE = &H40 Or UNITHL 'C
'HOUSE = &H50 Or UNITHL 'D
'HOUSE = &H80 Or UNITHL 'E
'HOUSE = &H90 Or UNITHL 'F
'HOUSE = &HA0 Or UNITHL 'G
'HOUSE = &HB0 Or UNITHL 'H
'HOUSE = &HE0 Or UNITHL 'I
'HOUSE = &HF0 Or UNITHL 'J
'HOUSE = &HC0 Or UNITHL 'K
'HOUSE = &HD0 Or UNITHL 'L
'HOUSE = &H00 Or UNITHL 'M
'HOUSE = &H10 Or UNITHL 'N
'HOUSE = &H20 Or UNITHL 'O
'HOUSE = &H30 Or UNITHL 'P

Goed, fijn, maar wat kan je hier nou mee?
Als je dus weet wat de RFXCOM er uit gooit en ontvangt kan zelf met je arduino met de rfxcom software praten. Het voordeel hiervan is dat de software voor alle gangbare huisautomatiseringssoftware al bestaat en het wordt ook nog bijgewerkt. Maar als je alles zelf wilt maken heeft het dus niet veel nut

Ik ben ook al verder dan allen de code, maar als er interesse is daarover later meer. Mijn arduino kan nu praten met de rfxcom plugin en ook signalen ontvangen van de KaKu afstandbediening, deze doorgeven aan de plugin, welke het weer doorgeeft aan xPLHal. Deze kan dan doen wat je maar wil, maar dat lijkt me duidelijk.
Mijn todo is nog een mooie 'code' omschrijving doen van KaKu naar rfxcom.X10 (nu werken alleen 3 kanalen omdat die 'hardcoded' erin zitten) en de zender moet is het volgende project. Tot nu toe ben ik zeer tevreden over de gekozen richting, het lijkt me aardig wat tijd aan de software kant te schelen, en dat is toch al niet mn allersterkste kant

Begrijp ik nu goed dat je niet de "native RFXCOM" mode gebruikt en ook niet de "32bit W800" mode maar dat er nog een mode is, de 48 bit mode?

http://www.rfxcom.com/supported_sw.htm


Wil het nu zeggen dat je eigenlijk geen RFXCOM signalen gebruikt, maar gewoon universele X10 signalen?

quote:

j-a-s-p-e-r schreef op woensdag 30 juli 2008 @ 01:39:
Ah leuk dat er nog meer mee bezig zijn!

<snip>

een heel erg waardevol verhaal! Ik zal ook eens op zoek en vanavond eens kijken in de source code van dit pakketje: http://www.heyu.org/download/ daar moet ook wel wat uit te halen zijn lijkt me!
edit:// ow - staat gewoon gedocumenteerd op de site natuurlijk (lang leve open source) http://www.heyu.org/docs/protocol.txt

quote:

Joozt schreef op woensdag 30 juli 2008 @ 13:45:
Begrijp ik nu goed dat je niet de "native RFXCOM" mode gebruikt en ook niet de "32bit W800" mode maar dat er nog een mode is, de 48 bit mode?
http://www.rfxcom.com/supported_sw.htm
Wil het nu zeggen dat je eigenlijk geen RFXCOM signalen gebruikt, maar gewoon universele X10 signalen?

Ik denk dat j-a-s-p-e-r gelijk heeft en dat de RFXCOM dus geen eigen protocol heeft maar X10 imiteerd. An sich zeer logisch want heeft RFXCOM gelijk de beschikking over een stapel software; welk principe j-a-s-p-e-r ook wil toepassen.

franssie wijzigde dit bericht 30-07-2008 14:42 (51%)

quote:

Joozt schreef op woensdag 30 juli 2008 @ 13:45:
Begrijp ik nu goed dat je niet de "native RFXCOM" mode gebruikt en ook niet de "32bit W800" mode maar dat er nog een mode is, de 48 bit mode?

http://www.rfxcom.com/supported_sw.htm


Wil het nu zeggen dat je eigenlijk geen RFXCOM signalen gebruikt, maar gewoon universele X10 signalen?

Ja ik denk dat je dat goed begrijpt. Maar ik heb geen rfxcom dus ervaring ermee heb ik alleen uit mn 'reverse engineering' zegmaar. Ik heb uit de handleiding begrepen dat oa. bij gebruik van de xPL plugin (zie http://www.xplmonkey.com/rf.html) dat de signalen 'vertaald' worden naar standaard x10.

quote:

Note - Standard X10 devices, including those that are mapped to X10 such as ELRO, NEXA, KlikOn-KlikOff and Domia Lite, do not require configuration and so do not appear here.

32 Bit is trouwens ook niet voldoende om 'nieuwe' KaKu signalen te ontvangen en diverse oregon sensoren. Maar het enige verschil tussen 32 en 48 bit (dat heet vaak 'variable bit mode') is dat het signaal wordt 'opgevuld' met 20 ervoor (dat is 2byte=16 bit dus 48 = 32+16bit) No big deal dus.

quote:

franssie schreef op woensdag 30 juli 2008 @ 13:54:
[...]


een heel erg waardevol verhaal! Ik zal ook eens op zoek en vanavond eens kijken in de source code van dit pakketje: http://www.heyu.org/download/ daar moet ook wel wat uit te halen zijn lijkt me!
edit:// ow - staat gewoon gedocumenteerd op de site natuurlijk (lang leve open source) http://www.heyu.org/docs/protocol.txt


[...]

Ik denk dat j-a-s-p-e-r gelijk heeft en dat de RFXCOM dus geen eigen protocol heeft maar X10 imiteerd. An sich zeer logisch want heeft RFXCOM gelijk de beschikking over een stapel software; welk principe j-a-s-p-e-r ook wil toepassen.

Dankje, leuk om te horen

Het lijkt me dat de rfxcom idd voor veel protocollen een 'ontvanger' en 'decoder' heeft, waarna hij het omzet naar x10 aan de 'computer' kant. De plugin maakt er dan weer x10 voor de automatiseringssoftware van.

Ik heb hieronder een sketch voor de arduino om signalen te ontvangen en 'hardcoded' bij A1ON en A1OFF en x10 signaal naar de computer te sturen. Verder kan hij reageren op de 'vragen' en moderequests van de rfxcom software. Het is wel echt voor de liefhebber, dus let aub niet op mijn programmeerkunsten
En nogmaals; de KaKu ontvang+decode opties zijn allemaal door P. Tonkes gemaakt, naar hem alle credits!!
code:

#include "pins_arduino.h"
#define KAKU_SignalPin 2 // Op deze input komt het signaal binnen. (Alleen pin 2 en 3 worden afgehandeld door interrupt) HIGH bij geen signaal.
#define KAKU_LedPin 13
#define KnipperLed 4
volatile int KAKU_Home, KAKU_Channel, KAKU_Command;
volatile unsigned long KAKU_Code;
void KAKU_Receive(void);

unsigned long IntervalTimer_1;
int status=HIGH;

int serIn;         // var that will hold the bytes-in read from the serialBuffer;
int serInString[10];     // array that will hold the different bytes  100=100characters;
int serInIndx  = 0;      // index of serInString[] in which to inser the next incoming byte;
int serOutIndx = 0;      // index of the outgoing serInString[] array;
int ledPin = 13;         // ledPin for diagnostics;

void setup()
{
  pinMode(KAKU_SignalPin,INPUT);                            // Define signalpin
  pinMode(KnipperLed,OUTPUT);
  pinMode(ledPin, OUTPUT);                                  // for diagnostics

  digitalWrite(ledPin, LOW);                                // diagnostic led off
  
  attachInterrupt(KAKU_SignalPin-2, KAKU_Receive, RISING);  // Interrupt voor detecteren signaal
                                                            // begin the serial communication
  Serial.begin(4800);                                       // RFXCOM praat 4800 of 38400

//  Serial.println("Arduino/RFXCOM test v.0.06") ;          // Prinln on start, may be commented out
}  //setup


void loop(){

  // Gebruik bijvoorkeur geen delay(). Dit vertraagt de reactietijd van de verwerking na een ontvangen IR_Code
  if(IntervalTimer_1<millis())
  {
  IntervalTimer_1=millis()+500;
//  digitalWrite(KnipperLed,status=!status);
  }  

if(KAKU_Code) // kijk of er iets ontvangen is.
{
  if (KAKU_Home == 1 && KAKU_Channel == 1 && KAKU_Command == 1) {
            int ans[5]={32,96,159,00,255}; //20609F00FF
            for (int i=0; i <= 4; i++){
              Serial.print(ans[i],BYTE);
              }
            } // if kaku H1C1C0
  if (KAKU_Home == 1 && KAKU_Channel == 1 && KAKU_Command == 0) {
            int ans[5]={32,96,159,32,223}; //20609F20DF
            for (int i=0; i <= 4; i++){
              Serial.print(ans[i],BYTE);
              } // if kaku H1C1C1
            } // if H1C1C0  

  KAKU_Code=0; // KAKU_Receive() doet niets zolang deze variabele niet terug is gezet naar nul. 

  /*Serial.print("Home=");
  Serial.print(KAKU_Home,DEC); 
  Serial.print(", Channel=");
  Serial.print(KAKU_Channel,DEC); 
  Serial.print(", Command=");
  Serial.println(KAKU_Command,DEC); */

}  //if KAKU_code
  
                                
  while (Serial.available()){         // keep reading from serial untill there are bytes in the serial buffer      
      serIn = Serial.read();          // read Serial      
      serInString[serInIndx] = serIn; // insert the byte you just read into the array at the specified index
      serInIndx++;              // update the new index
      digitalWrite(ledPin, HIGH);     // Feedback by led on received data
      delay(50);
   }  //while
  digitalWrite(ledPin, LOW);          // Turn the led off again


  if( serInIndx > 0) {                // print out later in the loop the sentence only if it has actually been collected;

    switch(serInString[0]){                 // Bekijk de eerste ontvangen byte

          case 0xf0:                        // Commando's beginnen met 0xF0 ofwel is de eerste byte een 0xf0?
          {  
            if (serInString[1]==0x20){      // F020 == Versie
            int ans[4]={77,16,83,16};       // Master(=77dec) 18(=24dec) en Slave(=83dec) 30(=48 dec)
              for (int i=0; i <= 3; i++){   
                Serial.print(ans[i],BYTE);  // print de array naar de poort
              }
            break;                          // Stop met de case, geen AcK nodig
            } // if 0x20

/*            if (serInString[1]==0x2c){      // F02C == variable bitmode
              int ans[1]={44};              // Stuur de AcK terug (laatste twee bytes) 0x2c == 44 dec
              for (int i=0; i <= 0; i++){   
                Serial.print(ans[i],BYTE);  // print de array naar de poort
              }
            } // if 0x2c */

            ACK();                          // Geef als ACK (ok) de tweede byte terug.
                                            // Nodig voor F02A, F02E, F02F, etc.
            break;
          } // case 0xf0
            break;

          case 0x20:
          //20 64 9B 58 A7 A16AAN
          //20 64 9B 78 87 A16UIT
            if (serInString[3]==0x58){ 
              digitalWrite(ledPin, HIGH); 
              delay(1000);
            }
            if (serInString[3]==0x78){ 
              digitalWrite(ledPin, LOW); 
              delay(1000);
           }            
            break; 

          default:
            {
            //int ans[5]={32,96,159,00,255}; //20609F00FF
            //for (int i=0; i <= 4; i++){
            //  Serial.print(ans[i],BYTE);
            //  }
            } // case default
            break;     
        } // switch

    //reset all the functions to be able to fill the string back with content
    serOutIndx = 0;
    serInIndx = 0;

  } // if
 
 
} //Loop

void ACK(void){
  Serial.print(serInString[1],BYTE);
} //Void ACK

void KAKU_Receive(void)// deze functie wordt uitsluitend aangesproken via een interrupt.
{
/* De data is gecodeerd in de vorm 1D0, waar D de databit is:

A B C 
| | |
xxxxxxxxxxxxxxxxx
x : x
x 1 : DATA x 0
x : x
xxxx ........xxxxxxxxx........
| | | |
0 0.42 0.85 1.28 mS.

De databits worden per 25 verstuurd. De hele reeks van 25 bits wordt in 32ms verzonden. Er zijn drie dezelfde 
reeksen binnen 500mSec nodig om een KAKU device te laten schakelen. Standaard 4ms rusttijd tussen de opeenvolgende reeksen. 

KAKU_code heeft het volgende formaat: (msb) 0H0H0H0H0K0K0K0K0001010C0 (lsb)

H: huis-installatie (A-P)
K: kanaal
C: commando (1=aan, 0=uit)

Van de h's en de k's staat de msb rechts.
Overige nullen en enen worden gebruikt als checksum.*/

// Waarde van Counter_HIGH is na één milliseconde 1599 (praktijk gemeten)
// Waarde van Counter_LOW is na één milliseconde 941 (praktijk gemeten) 

#define KAKU_CodeLength 25
#define KAKU_bit_Min 400 // A: alles kleiner wordt gezien als een stoorpuls
#define KAKU_bit_Max 2000 // C: goter is niet van KAKU afkomstig
#define KAKU_bit_Data 1000 // B: kleiner wordt gezien als een 0, groter als een 1
#define KAKU_TimeOut 1200

uint8_t bit=digitalPinToBitMask(KAKU_SignalPin);
uint8_t port=digitalPinToPort(KAKU_SignalPin);
unsigned int Counter_LOW=0, Counter_HIGH=0; // variabele alvast vullen zodat initialisatie niet in tijdkritische deel valt.
int BitCounter,x;

// TEST-1: voor als er timingproblemen zijn en de waarde van KAKU_bit_Max, KAKU_bit_Min en KAKU_bit_Data opnieuw bepaald moeten worden
// TEST-1: unsigned int KAKU_RawCode[KAKU_CodeLength];

if(KAKU_Code!=0)return; // ga direct terug als er nog niets uitgelezen is. Voorkomt herschrijven a.g.v. interrupt tijdens verwerking in loop()
BitCounter=0;
do{
Counter_HIGH=0;
while((*portInputRegister(port)&bit)==bit)Counter_HIGH++; // tel hoe lang signaal HOOG blijft
// TEST-1: KAKU_RawCode[BitCounter]=Counter_HIGH;
if(Counter_HIGH<KAKU_bit_Min || // <A: te kleine puls om een goed signaal te zijn. Steek hier verder geen cpu-tijd in en ga direct terug.
Counter_HIGH>KAKU_bit_Max) // >C: Te lang, kan niet van KAKU zijn. Steek hier verder geen cpu-tijd in en ga direct terug.
{
KAKU_Code=0;
return; 
}
KAKU_Code=(KAKU_Code<<1)|(Counter_HIGH>KAKU_bit_Data);
Counter_LOW=0;
while(Counter_LOW<KAKU_TimeOut &&(*portInputRegister(port)&bit)==0)Counter_LOW++; // wacht zolang puls LAAG is. 
}while(BitCounter++<KAKU_CodeLength && Counter_LOW<KAKU_TimeOut);// Zolang nog niet alle bits ontvangen en er niet vroegtijdig een timeout plaats vindt 

// TEST-1: // gebruik onderstaande TEST=1 code voor oplossen van problemen met de timing
// TEST-1: if(BitCounter>20) // niet op iedere puls een verslag doen
// TEST-1: {
// TEST-1: Serial.print("BitCounter=");
// TEST-1: Serial.print(BitCounter,DEC);
// TEST-1: Serial.print(", KAKU_RawCode[]="); 
// TEST-1: for(x=0;x<BitCounter;x++) 
// TEST-1: {
// TEST-1: Serial.print(KAKU_RawCode[x],DEC);
// TEST-1: Serial.print(",");
// TEST-1: }
// TEST-1: Serial.println();
// TEST-1: }

//digitalWrite(KAKU_LedPin, HIGH); // lampie aan om aan te geven dat er iets ontvangen is. 
if(BitCounter==KAKU_CodeLength)// we hebben een complete reeks te pakken
{
if((KAKU_Code&0x15555FD)==0x28) // Kijk of de checksum klopt.
{// filter home, kanaal en commando er uit.
KAKU_Home =((KAKU_Code&0x20000)>>14 | (KAKU_Code&0x80000)>>17 |(KAKU_Code&0x200000)>>20 |(KAKU_Code&0x800000)>>23)+1;
KAKU_Channel=((KAKU_Code&0x200)>>6 | (KAKU_Code&0x800)>>9 |(KAKU_Code&0x2000)>>12 |(KAKU_Code&0x8000)>>15)+1;
KAKU_Command=(KAKU_Code&2)>>1;
}
else
{
Serial.println("Checksum error");
KAKU_Code=0;
}
}
else
{// onjuist aantal bits ontvangen
KAKU_Code=0;
}
//digitalWrite(KAKU_LedPin,LOW); // lampie uit.
}

quote:

j-a-s-p-e-r schreef op woensdag 30 juli 2008 @ 17:29:
Ja ik denk dat je dat goed begrijpt. Maar ik heb geen rfxcom dus ervaring ermee heb ik alleen uit mn 'reverse engineering' zegmaar. Ik heb uit de handleiding begrepen dat oa. bij gebruik van de xPL plugin (zie http://www.xplmonkey.com/rf.html) dat de signalen 'vertaald' worden naar standaard x10.

Is het dan geen beter idee om de CM11 te gaan emuleren? Dat werkt native met veel meer pakketten. Ook xPL.

De Homeseer plugin voor RFXCOM is bijvoorbeeld ook niet vrij beschikbaar.

Ik vond op de site van Jaap Gordijn een CM11 emulator. Jaap heeft goed gedocumenteerde Java code.

Joozt wijzigde dit bericht 05-08-2008 10:32 (11%)

wanneer ik de code van de start post in mijn arduino wil laden met de software van arduino krijg ik deze fout melding: RemoteSwitch.h: No such file or directory In function 'void loop()': terwijl de bestanden allemaal in dezelfde map staan.

ik weet ook niet precies hoe ik alles moet aansluiten. ben pas nieuw in de uC vandaar.

kan iemand mij daarmee helpen?

quote:

stavast schreef op dinsdag 02 september 2008 @ 19:57:terwijl de bestanden allemaal in dezelfde map staan.

Ja en da's dus niet de bedoeling In de readme.txt staat waar je de bestanden neer moet zetten en hoe je het voorbeeld kunt openen. Het is een standaard Arduino library, dus je kunt ook bij de documentatie van Arduino kijken.

quote:

ik weet ook niet precies hoe ik alles moet aansluiten. ben pas nieuw in de uC vandaar.
kan iemand mij daarmee helpen?

Ah joh, het zijn drie draadjes. Voeding, en één datapin. Die datapin mag je ook nog zelf kiezen ook. Ik heb pin 11 gekozen in het bijgeleverde voorbeeld, dus als je dat ook doet, dan hoef je ook dat niet te veranderen. Of heb je soms een exotische transmitter te pakken?

bedankt voor je hulp mijn zender komt van samenkopen.net

het lukt me toch niet helemaal. de data zit op pin 11 de gnd op de gnd en de vcc op de 5V.

nu is het zo dat ik mijn afstands bediening met de dip switch zo heb ingesteld: 1 omlaag 2,3,4 omhoog en 5 omlaag (dit gezien van dat je de cijfers gewoon kan lezen) maar wat is dan mijn adres? ik heb dezelfde action unit als jij ook had; die van impuls

stavast wijzigde dit bericht 03-09-2008 18:47 (74%)

quote:

stavast schreef op woensdag 03 september 2008 @ 18:21:
bedankt voor je hulp mijn zender komt van samenkopen.net

het lukt me toch niet helemaal. de data zit op pin 11 de gnd op de gnd en de vcc op de 5V.

nu is het zo dat ik mijn afstands bediening met de dip switch zo heb ingesteld: 1 omlaag 2,3,4 omhoog en 5 omlaag (dit gezien van dat je de cijfers gewoon kan lezen) maar wat is dan mijn adres? ik heb dezelfde action unit als jij ook had; die van impuls

1+2+4+8=15. Zet 'm anders doodleuk op 0 of 1, moet ook werken.

quote:

Fuzzillogic schreef op woensdag 03 september 2008 @ 19:50:
[...]

1+2+4+8=15. Zet 'm anders doodleuk op 0 of 1, moet ook werken.

hmm met 15 werkte hij ook niet, maar met 1 ging hij idd goed :-)
zijn we weer een stap verder bedankt!

Hmmm.. De thread begint een beetje in de vergetelheid te geraken... Jammer..

Ik ben zelf nog steeds wel bezig met m'n Arduino en m'n RF-kit. Ik heb m'n code weer flink omgegooid en krijg steeds stabielere resultaten. Mijn laatste aanpassingen hebben er voor gezorgd dat ik geen hele lange buffers met pulses hoef op te bouwen. Ik liep namelijk tegen de geheugen limiet van de Arduino aan.

Maar.. De reden dat ik hier weer eens post is dat ik niet goed weet hoe ik Klik-Aan-Klik-Uit dimmers aan kan sturen. Het Aan en Uit schakelen gaat prima. Maar ik weet niet hoe ik kan dimmen naar een bepaalde dimstand. Het dimmen gebeurt namelijk door snel aan en uit te schakelen waarna de lamp langzaam de felheid van de lamp gaat veranderen. Door op de gewenste felheid de schakelaar weer te gebruiken, kan je de felheid kiezen.
Maar mijn Arduino kan nooit zien hoe fel de lamp is. Ik heb een manier nodig om een absolute waarde te kiezen.
Dus: dimmen naar 50%.

Heeft iemand hier een idee over?

gr. Sander

Ha een reply!
Ik werk er ook nog aan hoor. Ben nog steeds met mijn 'nep rfxcom' arduino project bezig. Het ellendige is dat ik al een heel stuk die weg in ben geslagen en het rfxcom-geval nogal een berg van patches en pleisters lijkt te zijn.. Ik moet nu bijv. een 2e compoort aan m'n arduino hangen omdat er maar één 'transmitter' of 'receiver' per compoort met de plugin mag praten.
Voordeel van 'mijn' methode is wel dat het direct geschikt is voor alle pakketten (vanaf homeseer t/m xpl).

Dus dood is het nog niet:p

Maar helaas kan ik je niet echt helpen met de kaku dimmer, aangezien ik die niet heb. Misschien is er bij de thread van emiel nog wat te vinden? Ik zal nog wel even zoeken of ik wat nuttigs kan vissen uit de aansturing van mijn aldi-setje vanuit winlirc. Maar ik vrees eigenlijk dat het nogal een ander protocol is.

Ik ben met een gelijkaardig project bezig.
Na het protocol uitgeplozen te hebben ben ik hier terecht gekomen.
Zelf heb ik de KaKu's van chacon, ze lijken sprekend op de "De natuurlijk KaKu:" er staat alleen ander tekst op.
Ik ben momenteel bezig mancherter code te implementeren in basic programmeertaal.

quote:

Shorty24 schreef op zaterdag 27 september 2008 @ 10:39:
Maar.. De reden dat ik hier weer eens post is dat ik niet goed weet hoe ik Klik-Aan-Klik-Uit dimmers aan kan sturen. Het Aan en Uit schakelen gaat prima. Maar ik weet niet hoe ik kan dimmen naar een bepaalde dimstand.

Voor zo ver ik weet is het met de meeste kaku's niet mogelijk een dim-waarde in te stellen.(de duurdere niet meegerekend)
Het dimmen gebeurt meestal door het "on" signaal continu te sturen(herhalen) waardoor de ontvangers na ong. 1s beginnen te dimmen.
(Na 7s indrukken stoppen de originelen zenders met uitzenden)

Grtz

Tortax wijzigde dit bericht 28-09-2008 19:12 (3%)

Dimmen van KaKu wordt idd lastig. Het grootste probleem is dat je niet (precies) weet wat de beginstand is; als je een andere helderheid wilt instellen dan begint het "jojo'en" vanaf de huidige helderheid, en niet vanaf bijv. helemaal donker of maximale helderheid. En om met LDR's te gaan klooien om zo de gewenste helderheid te bereiken lijkt me geen oplossing.

Ik weet eigenlijk niet of die dingen te resetten is door de spanning voor de apparaten zelf te onderbreken. Maarja, om nu een KaKu-switch te gebruiken om een KaKu-dimmer te resetten is wat overdreven

1 tip voor 433Mhz-communicatie: zorg voor een stabiele voeding!

Wij hadden als universiteitsproject het verzorgen van de communicatie met een draadloos treintje. Zodra de motorsturing werd aangesloten, flipte de hele schakeling voor draadloze communicatie...

Die KAKU dingen zijn inderdaad lastig te dimmen ja. Ik geloof dat de KOPPLA dingen van Ikea de enige (goekope) zijn die rechtstreeks naar een bepaalde dimstand kunnen, maar die worden inmiddels niet meer verkocht.


Wat ik voorheen wel eens heb gedaan is met 2 schakelmodules en een stekkerdimmer werken. Meestal gebruik je toch maar 1 dimstand en een felle stand.
Ik had een schakelmodule in het stopcontact. Daarin een verdeeldoos met de tweede schakelmodule en de stekkerdimmer er in. In de tweede schakelmodule en in de stekkerdimmer zaten dan weer twee stekkers die samen naar 1 lamp gingen. De schakelmodules beide op hetzelfde kanaal.

Resultaat: De eerste keer dat op de aan-knop wordt gedrukt schakelt de eerste schakelmodule in en geeft stroom aan de tweede schakelmodule en de dimmer waardoor het licht op de dimstand aangaat. De tweede keer dat op de aan-knop wordt gedrukt schakelt de tweede schakelmodule in en heb je de felle stand, de dimmer wordt gebypassed.

Let op: Erg goed oppassen met 2 stekkers aan 1 lamp. Als er 1 van de twee stekkers niet in zit komt er dus stroom te staan op de pinnen van die stekker! Ook goed opletten dat je beide stekkers op de juiste manier in de stekkerdimmer en de tweede schakelmodule steekt anders klapt je zekering

Na wat gegoogle op 433 MHz communicatie kwam ik dit topic op CO tegen. Best interessant als je net probeert om draadloze verbindingen met microcontrollers te begrijpen Ook kwam ik via dat topic bij deze zend/ontvangers uit. Weliswaar iets duurder dan de bekende 433 MHz apparaatjes, maar aangezien ze tweewegverkeer ondersteunen, zijn ze ook een stuk interessanter. Hiermee zou je dan bij een kaku-achtig systeem de status van een schakelaar kunnen uitlezen

Demoniac wijzigde dit bericht 02-10-2008 00:48 (4%)

quote:

Demoniac schreef op donderdag 02 oktober 2008 @ 00:47:
Na wat gegoogle op 433 MHz communicatie kwam ik dit topic op CO tegen. Best interessant als je net probeert om draadloze verbindingen met microcontrollers te begrijpen Ook kwam ik via dat topic bij deze zend/ontvangers uit. Weliswaar iets duurder dan de bekende 433 MHz apparaatjes, maar aangezien ze tweewegverkeer ondersteunen, zijn ze ook een stuk interessanter. Hiermee zou je dan bij een kaku-achtig systeem de status van een schakelaar kunnen uitlezen

+ dat ze 2,4 GHz zijn. Die zien er erg interessant uit! Voordeel met deze is dat je niet zelf meer je packet handeling hoeft te schrijven + te solderen!

Zijn er eigenlijk al tweakers bezig met een eigen kaku-systeem? Ik heb beperkte programmeer- en elektronicakennis maar het lijkt mij op zich wel te doen, zeker als je die 2,4 GHz modules gebruikt. Het enige wat mij lastig lijkt met meerdere transmitters, is zorgen dat ze niet door elkaar gaan lopen schreeuwen..

@Demoniac
De 2,4 Ghz modules bij Ideetron lijken dat zelf te regelen:

quote:

De hybride zendontvangermodule is een compleet RF subsysteem en geschikt om data te verzenden met een data rate tot 500 kbit/s. De module bevat hardware voor diverse protocollen voor het afhandelen van de verbinding zoals data buffering, CSMA-CA en CCA. De modules zijn ideaal voor toepassingen op batterijen.
De module kan uitvoerig worden geconfigureerd door een SPI interface.

Ik ben er zelf mee bezig, maar helaas door tijdgebrek niet meer aan te gekomen. Ik was bezig met die simpele 433rec van SK.net, maar ik denk dat ik over ga stappen op deze, want die kunnen zenden + ontvangen.

Omdat het bereik maar 50 meter is wilde ik er een mesh network van maken zodat alle nodes berichten kunnen repeaten.

Ook ben ik nog opzoek naar een klein chipje dat nauwkeurig stroom kan meter zodat ik van elke unit stroom kan meter.

Schakelmodules kunnen op een normaal 230v relais, maar dimmers weet ik nog niet precies. Het moet wel compact blijven, zodat het in de muur gemaakt kan worden.

Het probleem bij die CC2500 module is dat je ze via SPI moet benaderen, dat is lastiger dan de seriële communicatie bij die 433 modules.

De LivingColors lamp van Philips gebruikt ook deze CC2500. Ik heb er laatst ook een paar gekocht bij een samenkopen actie maar ben er nog niet aan toe gekomen om hier iets mee te doen. Ik geloof dat je ook level convertors moet gebruiken om hem aan de signaalniveaus van 5V van de Arduino te hangen.
Er loopt wel een animo check om een protobordje te maken met alles er op: http://www.samenkopen.net/topic/85286/237263/last

Maar voordeel is dat je wel weer een manchester encoding erin hebt zitten, én deze zijn rx/tx in 1 chip + dat ze kleiner zijn dan meeste 433 modules.

Alleen het bereik is iets kleiner weer, maar de bandbreedte is weer hoger