433MHz-communicatie met microcontrollers

[Anoniem: 435565]

De adres code voor de nieuwe zenders is gelijk voor de gewone toetsen en de groep toetsen.
Dus: startbit, 26 adres bits, groep bit (0 voor de gewone toetsen, 1 voor de groep toetsen), on/off bit (1 voor de linkse rij knoppen, 0 voor de rechtse rij), 4 unit bits (0000 tot 1111 voor de gewone toetsen, 0000 voor de groep toetsen), stopbit.
Ik heb dit nagezien met een Fluke PM3380B geheugenscoop en een AYCT-102 afstandbediening

Ook mijn dank voor jullie werk bij het decoderen van de signalen.

[Fuzzillogic]

Thanks RudA.

De code voor de "nieuwe" kaku heb ik nu in een losse library gezet, genaamd NewRemoteSwitch. Deze biedt ondersteuning voor ontvangen en verzenden van A-serie KAKU-apparaten. (Deze keer heb ik het wel getest ) Ook heb ik meer voorbeelden toegevoegd om je een idee te geven over het gebruik.

Enfin, de vier libraries kun je downloaden van de dev-branch.

Om snel te zien of jouw remotes met deze libraries werken kun je de InterruptChain > ReceiveRemoteAndSensor example sketch proberen. Deze toont via de seriele poort de ontvangen data van alle ondersteunde apparaten: nieuwe en oude remotes, en de Cresta weerstations.
Enige dat je daarvoor moet doen is de digitale uitgang van de 433MHz ontvanger aan te sluiten op pin 2 van de Arduino. Daarna start je de sketch en open je de Serial monitor @ 115200 baud. Druk nu op de knoppen van je remotes en/of wacht tot weerstation een update stuurt. De monitor geeft info weer. Krijg je output? Dan kun je met de overige examples onder (New)RemoteSwitch en RemoteSensor snel verder experimenteren.

Hoewel ik code nog in de dev-branch staat noem ik het "release candidate". Voor de "release" hoop ik dat jullie eerst nog wat bugs of problemen vinden (of niet). Ook wil ik de wiki bijwerken, o.a. met een quick start guide a la het bovenstaande. Het idee is iig om mensen snel te laten testen of de libraries met hun apparaten overweg kunnen.

P.s. ik heb het weer over "kaku", maar kaku is niet de enige die deze remotes maakt. HomeEasy/Elro heeft ook spul waarvan ik vermoed dat het hetzelfde protocol gebruikt. Mogelijk dat er nog veel meer systemen zijn waarbij de ontvanger de code van de remote kan "leren" met een knop compatible met deze nieuwe library. Let me know!

[sPENKMAN]

Sinds het weekend kan ik lichten in huis aansturen middels een XML-RPC verbinding naar een Python script welke de commando's via Serial naar de Arduino stuurt.

De stap naar mijn eerste Android app was dus erg klein en was dan ook in 2 uur werkend. Inmiddels kan ik dan ook de lichten in huis in en uit schakelen via mijn app mits er verbinding is met ons WiFi netwerk.


Binnenkort maar eens een ethernet shield kopen voor een wat directere aansturing, zit nu best veel vertraging in de lijn (circa 1,5 seconden)

[memphis]

Ik heb mijn 433mhz ontvanger via een Conrad USB UART interface aangesloten.
http://www.conrad.nl/ce/nl/product/197326/

Nu is het zo dat de ontvanger wat "ruis" opvangt als de zender niet aan staat en mijn muiscursor daardoor als een gek over het scherm gaat. Blijkbaar komen wat muiscursor commando's door.
Aangezien er een RSSI output op zit zit ik te denken aan een soort squelch schakeling op te bouwen om dit te onderdrukken maar als iemand een simpele software oplossing heeft hou ik mij aanbevolen.

[Righthere]

Ik heb net de nieuwe dev code uitgeprobeerd met mijn home easy remote. Deze werkt helaas niet. Het is een HE300WEU remote, dit is de "automatische" versie. Dus uit mijn ervaring blijkt dat de home easy niet hetzelfde werkt als de kaku. Het kan natuurlijk zijn dat ik nog iets fout doe. Maar ik kom hier nog op terug. Eerst is het bedtijd.

edit: de HE300WEU werkt weer net iets anders dan de rest. Ik moet het nog uitzoeken. Maar er is geen startpuls en het is geen manchester code. Maakt niet uit.... Maar het is dus niet compatible met KaKu. Ik neem aan dat andere Home Easy producten dat wel zijn van wat ik er online van zie.

[ Voor 30% gewijzigd door Righthere op 03-05-2012 20:21 ]

[Fuzzillogic]

Righthere schreef op dinsdag 01 mei 2012 @ 00:24:
edit: de HE300WEU werkt weer net iets anders dan de rest. Ik moet het nog uitzoeken. Maar er is geen startpuls en het is geen manchester code. Maakt niet uit.... Maar het is dus niet compatible met KaKu. Ik neem aan dat andere Home Easy producten dat wel zijn van wat ik er online van zie.

KAKU, zowel de oude en nieuwe, zijn geen manchester. Heb je toevallig een scope-dump of afbeelding van het signaal van de HE300WEU? Als het slechts een beetje anders is dan KAKU dan valt er nog wat aan te sleutelen. Maar als het complete protocol afwijkt, sja, dan is het lastig.

[Righthere]

Als ik binnenkort de spullen weer op tafel heb, maak ik wel even een mooie scan met een logic analyser. Mijn programeer kennis heeft nog wel wat oefening nodig. Jouw programma snap ik nog niet helemaal. Maar dat ligt aan mij. Qua hardware en metingen kom ik er wel uit. Mijn idee was eigenlijk om gewoon het signaal opnieuw op te bouwen met arduino (signaal hoog, delay, signaal laag, delay enz...) voor elke uitgang. Maar als je een beetje mee wilt kijken, dan komt er vast wat nuttigers qua code uit. De KAKU en de Home Easy verschillen iig niet heel veel.

[ Voor 5% gewijzigd door Righthere op 11-05-2012 21:58 ]

[memphis]

In dit lange weekend veel kleine dingetjes zitten repareren en oplossen en zo dus ook dit probleem. Omdat de zender met een analoge ingang werkt welke max 3v mag krijgen twijfelde ik aan mijn serieweerstand (hoewel de scoop een net 3v signaal liet zien) Een beetje spelen met deze serieweerstand gaf een iets beter resultaat maar niet bevredigend. Dit gaf mij wel het idee om meer naar de ontvanger te kijken.

De ontvanger heeft 2 uitgangen, een analoge en een digitale. Op de scoop bleek de digitale uitgang soms een ander signaal te vertonen dan op de analoge uitgang. Nu heb ik een eigen gemaakte dataslicer uit een vorig probeersel gepakt en na wat inregelen had ik een perfect signaal en ook geen ellende met de muiscursor als de zender uit staat. Eindelijk kan ik door gaan met het realiseren van de montage en sensoren.

memphis schreef op woensdag 25 april 2012 @ 16:04:
Ik heb mijn 433mhz ontvanger via een Conrad USB UART interface aangesloten.
http://www.conrad.nl/ce/nl/product/197326/

Nu is het zo dat de ontvanger wat "ruis" opvangt als de zender niet aan staat en mijn muiscursor daardoor als een gek over het scherm gaat. Blijkbaar komen wat muiscursor commando's door.
Aangezien er een RSSI output op zit zit ik te denken aan een soort squelch schakeling op te bouwen om dit te onderdrukken maar als iemand een simpele software oplossing heeft hou ik mij aanbevolen.

[-Tim-]

Fuzzillogic schreef op zaterdag 24 maart 2012 @ 01:42:
Caveats: ik heb precies 1 remote om mee te testen, en dat is nog de simpelste ook. Graag hoor ik of de code bij jullie ook werkt. Net als bij de "oude" kaku werkt de code met pulse-breedte-detectie, waarmee als het goed is een grotere compatibiliteit wordt bereikt. Ik vermoed dat het het ook met de HomeEasy remotes werkt!

http://www.kijkshop.nl/product/132081/elro-dimmer/
Weet iemand ook of het dimmen van deze Elro/HomeEasy zal gaan werken met de huidige code?

[Fuzzillogic]

-Tim- schreef op dinsdag 17 juli 2012 @ 15:57:
[...]

http://www.kijkshop.nl/product/132081/elro-dimmer/
Weet iemand ook of het dimmen van deze Elro/HomeEasy zal gaan werken met de huidige code?

Eerder in deze thread leek dat niet het geval te zijn helaas, hoewel de code wel grotendeels overeen zou komen. Bij gebrek aan HomeEasy-device kan ik het zelf niet verder bekijken.

[Atlas]

Ok even het goeie topic hier omhoogschoppen, ik kom er niet uit.....

Ik heb deze zender/ ontvanger:


Nu wil ik een simpele communicatie opzetten tussen een PC en een Atmega 8 maar ik krijg geen stabiele verbinding....Dus? Wat doe ik fout?

Situatie:
1200 baud (of 2400 maar dat maakt geen verschil).
Alles is 5 volt gevoed, FT232 kant via USB, de andere via de 7805.

Opstelling: FT232L - inverter (HCF4069) - zender {---------lucht ----------} ontvanger - inverter - max232 - compoort PC

Aan beide kanten 17cm antenna's. Zender en ontvanger liggen ongeveer een meter of 3 uit elkaar.
Als ik nu bv dit stuur: UUUUUUUUUUUUUU1UUUUUUUUUU, krijg ik dit terug UUUUUUUUUUUUUUgUUUUUUUUUU..... Dus ik snap er niets van....
Snappen deze IC's uberhaupt wel het TTl signaal? Of doe ik iets gruwelijk verkeerd....

help!

[Megamind]

Volgens mij tunen deze chipjes zichzelf toch? Laat ze eerst even een reeks rommel uitzenden. Als het nog niet goed werkt zorg ervoor dat je spanning voldoende is.

Ik heb deze library een tijdje gebruikt welke opzich prima werkte:
https://bitbucket.org/fuz...mhzforarduino/get/dev.zip

[CurlyMo]

Ik gebruik dezelfde zender/ontvanger. Krijg de zender goed werkend, maar de ontvanger niet. De ontvanger werkt alleen als de zender (zoals AB) binnen 50cm van de ontvanger wordt gehouden. Hierdoor kan ik prima de codes van mijn KaKu zender uitlezen. Het bedienen van mijn KaKu schakelaars/dimmers gaat ook perfect, maar dan met mijn Raspberry Pi. Dus waarschijnlijk ligt het aan de ontvanger die op een of andere manier niet goed werkt. Probeer het eens als ze dichter bij elkaar zitten.

Zie: [GPIO] Raspberry Pi

[Atlas]

Zonder de inverter (de HCF4069) lijkt hij het wel een stuk beter te doen

[Fuzzillogic]

CurlyMo schreef op dinsdag 09 oktober 2012 @ 22:11:
De ontvanger werkt alleen als de zender (zoals AB) binnen 50cm van de ontvanger wordt gehouden.

Op welke baudrate is je ontvanger gespecificeerd? Dat het alleen op zo'n korte afstand werkt klinkt alsof de pieken te kort worden op langere afstand, en/of dat er (te) veel ruis doorkomt. Een scope eraan is het makkelijkst, wellicht dat een RaspPi software heeft die als logic analyzer kan werken - dat apparaat heeft voldoende snelheid en plenty RAM.

[CurlyMo]

baudrate

Ik hang hem gewoon aan de GPIO pinnen en heb de signalen gedecodeerd.

[Fuzzillogic]

CurlyMo schreef op dinsdag 09 oktober 2012 @ 22:53:
baudrate

Ik hang hem gewoon aan de GPIO pinnen en heb de signalen gedecodeerd.

Die dingen worden nog steeds gemaakt voor een specifieke baudrate. Lijkt vooral te maken te hebben met de snelheid waarmee de auto-gain reageert. Modellen voor 2400baud lijken hier het beste te werken.

[CurlyMo]

Is dat afhankelijk van een specifieke aansluiting zoals uart, serieel, e.d.? Aangezien ik ze nu gewoon standaard aan de GPIO pinnen heb hangen en 1-en en 0-en 'tel'.

[Fuzzillogic]

CurlyMo schreef op dinsdag 09 oktober 2012 @ 23:05:
Is dat afhankelijk van een specifieke aansluiting zoals uart, serieel, e.d.? Aangezien ik ze nu gewoon standaard aan de GPIO pinnen heb hangen en 1-en en 0-en 'tel'.

Nope, het is de hardware zelf. Die dingen zijn best "dom", ze hebben zelf geen notie van het protocol. Of je ze nou aan UART hangt of zelf een protocol (kaku) voert, ze kennen dat onderscheid niet.

Maar even voor de duidelijkheid: je hebt het ding aan een RaspberryPi hangen en wilt kaku decoderen? Het helpt dan als je een low-pass filter maakt, precies wat ik in de RemoteSwitch library (dev branch) heb gedaan.

[CurlyMo]

Ik heb KaKu/Elro al gedecodeerd, en het werkt allemaal prima. Het bereik van de ontvanger is alleen een probleem.

ps. De serial functies van wiringPi ondersteunen wel de baudrate instelling. Zou ik die eens moeten proberen met 2400? Zie: https://projects.drogon.n.../wiringpi/serial-library/ Hoe zou ik zoiets dan moeten aansluiten.

[ Voor 50% gewijzigd door CurlyMo op 09-10-2012 23:54 ]

[TNW]

Ik zag dit laatst langskomen:

http://shop.ciseco.co.uk/...ee-shape-arduino-pic-etc/

RS232 naar RF, full duplex.

Wss duurder dan de meeste simpele eenrichtingsverkeer setjes via diverse kanalen, maar wel makkelijk, geen gedoe met libraries, gewoon rxd/txd naar je MCU en gaan

[Atlas]

TNW schreef op woensdag 10 oktober 2012 @ 10:53:
Ik zag dit laatst langskomen:

http://shop.ciseco.co.uk/...ee-shape-arduino-pic-etc/

RS232 naar RF, full duplex.

Wss duurder dan de meeste simpele eenrichtingsverkeer setjes via diverse kanalen, maar wel makkelijk, geen gedoe met libraries, gewoon rxd/txd naar je MCU en gaan

Die zijn gaaf en lekker simpel....
Maar eens 2 bestellen. Thanks voor de tip!

[CurlyMo]

Atlas schreef op woensdag 10 oktober 2012 @ 12:40:
[...]


Die zijn gaaf en lekker simpel....
Maar eens 2 bestellen. Thanks voor de tip!

Ik ben ook wel geïnteresseerd, misschien wel meerdere zodat we samen kunnen bestellen. Dit zou toch ook gewoon met KaKu moeten kunnen werken?

[SPT]

Ik wil graag een weerstation maken op basis van 433Mhz technologie, en ben daarom nu wat aan het experimenteren met een PIC microcontroller en deze RF ontvanger.

Ik heb nu even een simpel programmatje gemaakt dat signalen uit de ether opvangt, en deze weergeeft op een LCD schermpje. Ik lijk allerlei data op te vangen, met name veel pakketjes met reeksen 0xff, maar betwijfel of het wel goed werkt. Ik heb namelijk ook even een eenvoudige zender gemaakt, die 4x 0xff via een eenvoudig geblokt signaal verzend (heb allerlei verschillende bitrates geprobeerd), maar mijn ontvanger pikt het niet op. De ontvanger pikt wel wat op (er zit een ledje op de digitale uitgang), maar de verzonden data haalt hij er niet uit. Wel lijkt het net of als ik aan het zenden ben de ontvanger veel vaker datapakketjes oppikt. Enig idee wat hier mis kan zijn?

Hier staan de relevente delen van mijn programma:

code:

#define MAXLEN 32
#define TOLERANCE 20 // Lower is more tolerance.

unsigned char dat[MAXLEN];
unsigned int period_a, period_b, period; // In usec
int bitlen; // Number of bits received
int signal; // Signal strength from DATA_ANALOG

unsigned int getanalog(unsigned char channel)
{
    unsigned int t;
    ADCON0 = 0x00 + channel * 4; // Set ADC to AN5
    ADCON0bits.ADON = 1; // Turn adc on
    ADCON0bits.GO = 1;
    while (ADCON0bits.GO == 1);
    t  = (ADRESH << 8) | ADRESL;
    ADCON0bits.ADON = 0; //Turn adc off
    return t;
}

unsigned int read_TIMER0(void)
{
    unsigned char tmr0l = TMR0L, tmr0h = TMR0H;
    TMR0L = 0x00;
    TMR0H = 0x00;
    return (tmr0h << 8) | tmr0l;
}

int receive(void)
{
    int i, j = 0, byte = 0,bitpart = 0;
    unsigned char status_a = 1, status_b = 0; // E.g., the first bit of a package is always a '1'
    int tolerance;
    bitlen = 0;
    LED ^= 1; // Blink the led if we start receiving a new 'package' 
    
    // If the previous RF transition was from a 0 to a 1, we assume that the packet may have already started
    // In that case, the timer has already been started as well.
    if (DATA_IN == 0)
    {
        while (DATA_IN == 0);
        read_TIMER0(); //Reset timer
    }
    
    // Measure signal strength, probably reduces the maximum bitrate to <40kBit/s
    signal = (int)getanalog(5);
    
    // Wait until the end of the first half bit...
    while (status_a == DATA_IN);
    period_a = read_TIMER0(); // Here, we determine the duty period of the signal (actually, it's 1/2th of the period)
    dat[0] = 0x00;
    if (period_a < 38 | period_a > 7500) return 0; // We don't allow for bitrates lower than 100bit/s, or higher than 20kbit/s
    
    // Wait until the end of the second half bit...
    while (status_b == DATA_IN);
    period_b = read_TIMER0(); // This is the off_part of the period
    period = period_a + period_b;
    tolerance = 2 + period / TOLERANCE;
    if (period < 75 | period > 15000) return 0; // We don't allow for bitrates lower than 100bit/s, or higher than 20kbit/s
    LED = 0;

    dat[byte] += (status_a << j);
    bitlen++; j++;
     
    // If we enter here, we've just started the second half of the first bit
    while (bitlen < MAXLEN * 8)
    {
        // First half of bit
        if (bitpart == 0)
        {
            while (status_a == DATA_IN);
            i = read_TIMER0();
            if (status_a == 1 && (i < period_a - tolerance || i > period_a + tolerance)) return bitlen;
            if (status_a == 0 && (i < period_b - tolerance || i > period_b + tolerance)) return bitlen;
        }
        
        // Wait until the end of the second half bit...
        while (status_b == DATA_IN);
        i = read_TIMER0();
        if (status_b == 1 && (i < period_a - tolerance || (i > period_a + tolerance) && (i < period_a * 2 - tolerance * 2) || i > period_a * 2 + tolerance * 2)) return bitlen;        
        if (status_b == 0 && (i < period_b - tolerance || (i > period_b + tolerance) && (i < period_b * 2 - tolerance * 2) || i > period_b * 2 + tolerance * 2)) return bitlen;        

        dat[byte] += (status_a << j);
        bitlen++; j++;
        
        if (j == 8) // Here, we start at the next byte
        {
            j = 0;
            byte++;
            dat[byte] = 0x00;
        }
    
        // In case the data received for the second half of the bit has a length equal to the usual length of a half bit, 
        // we are at the beginning of the first half of the next bit and the next bit as the same logical value as the present.
        if (status_b == 1 && i < period_a + tolerance || status_b == 0 && i < period_b + tolerance) 
        {
            bitpart = 0;
            continue;
        }
        
        // In case the received data has twice the length of a half bit, we are at the first half of the next bit,
        // and the next bit has a logical value that is opposite to the present one.
        status_a ^= 1;
        status_b ^= 1;
        bitpart = 1;
    }
    return bitlen;
}

[Fuzzillogic]

Ik ken PIC niet, maar je lijkt niks meer te doen met de signal strength die je in regel 46 opvraagt. Ik zie geen goed ruisfilter. Regel 52 is wel heel erg riant bereik - niet heel vreemd dat je alsnog veel random data opvangt, want ruis.

Je zou idd signal strength als trigger laten werken, maar ik ga je nu al vertellen dat je daarmee zwakke signalen die je nog best zou kunnen decoderen niet meer zult oppikken. Been there done that Je weerstation, is dat een Cresta of andere Hideki-kloon? Dan zou je eens kunnen kijken naar mijn library. Weliswaar voor Arduino, maarja het is ook maar gewoon C++ en kan dus inspiratie leveren.

[Fuzzillogic]

CurlyMo schreef op woensdag 10 oktober 2012 @ 12:56:
[...]

Dit zou toch ook gewoon met KaKu moeten kunnen werken?

Nope. Nogmaals: die 433MHz modules die je voor kaku gebruikt zijn dom, ze kennen geen protocol. Enige dat ze doen is een 1 uitzenden. That's it, de rest mag je zelf doen. Merk op dat er dus ook geen '0' is. Je opmerking om de module "in te stellen op een baudrate" oid snijdt dan ook geen hout.

Ergo: wil je kaku, gebruik domme modules aan een GPIO en ga zelf timen. No alternative. Wil je betrouwbare communicatie tussen 2 microcontrollers dan is een module zoals TNW voorstelt erg eenvoudig, maar daarmee kun je de geen kaku aansturen omdat ze wél zelf voor het protocol zorgdragen.

[CurlyMo]

Duidelijk, met die 'domme' modules was het inderdaad al gelukt, behalve het ontvangen op grotere afstanden. Ik kan bijv. niet 'ontvangen' dat ik met mijn KaKu AB mijn lamp heb aangezet als ik te ver van de ontvanger zit.
Maar goed, ik ben nu met de Raspberry Pi voor het eerst aan het leren te werken met GPIO. Vind het dus al best netjes dat ik dit werkend heb gekregen. Baudrate zegt me dan dus nog weinig Ik vroeg dit omdat jij aangaf:

Fuzzillogic schreef op dinsdag 09 oktober 2012 @ 23:03:
[...]

Die dingen worden nog steeds gemaakt voor een specifieke baudrate. Lijkt vooral te maken te hebben met de snelheid waarmee de auto-gain reageert. Modellen voor 2400baud lijken hier het beste te werken.

[SPT]

Fuzzillogic schreef op woensdag 10 oktober 2012 @ 19:37:
Ik ken PIC niet, maar je lijkt niks meer te doen met de signal strength die je in regel 46 opvraagt. Ik zie geen goed ruisfilter. Regel 52 is wel heel erg riant bereik - niet heel vreemd dat je alsnog veel random data opvangt, want ruis.

Je zou idd signal strength als trigger laten werken, maar ik ga je nu al vertellen dat je daarmee zwakke signalen die je nog best zou kunnen decoderen niet meer zult oppikken. Been there done that Je weerstation, is dat een Cresta of andere Hideki-kloon? Dan zou je eens kunnen kijken naar mijn library. Weliswaar voor Arduino, maarja het is ook maar gewoon C++ en kan dus inspiratie leveren.

Ik heb net ook nog even gekeken, maar volgens mij zit er gewoon een fout in mijn code. Ik kan hem alleen niet vinden. De LED gaat uit als hij bezig is in de while-loop tijdens het ontvangen van een data-pakket. Ik zie dus dat het soms ook wel voorkomt dat die LED 1/10 seconde uitgaat, en dat hij daarna op het LCD scherm weergeeft dat hij 32byte met een bitrate van net iets meer dan 100b/s heeft ontvangen, terwijl dat in werkelijkheid een paar seconde zou moeten duren.

Als er trouwens geen filter voor de digitale uitgang van de RF ontvanger zit, is nog duidelijker dat er een probleem in het programma zit: dan zou hij nooit grote data paketten kunnen ontvangen waarbij hoog constant hoog blijft en laag laag.

Die signaalsterkte geeft hij trouwens alleen weer op het scherm, is verder niet voor gebruik door het programma.

Ik ben benieuwd naar jouw library, zal eens kijken of dat kan implementeren.

Nog een vraag: ik sta nu in mijn programma toe dat de duty cycle niet gelijk is aan 0.5 (dwz. dat de actieve staat minder of meer dan 50% van de periode is). Is dat eigenlijk gebruikelijk bij reguiliere 433Mhz apparatuur?

[ Voor 9% gewijzigd door SPT op 10-10-2012 22:35 ]

[Infant]

Kan het zo zijn dat je zuinige haakjes gebruik roet in het eten gooit?

C:

if (status_a == 1 && (i < period_a - tolerance || i > period_a + tolerance))

Ik zou hier, zelfs als ik een compiler was, helemaal kriegelig van worden.

[Megamind]

Infant schreef op donderdag 11 oktober 2012 @ 08:16:
Kan het zo zijn dat je zuinige haakjes gebruik roet in het eten gooit?

C:

if (status_a == 1 && (i < period_a - tolerance || i > period_a + tolerance))

Ik zou hier, zelfs als ik een compiler was, helemaal kriegelig van worden.

Volgens mij is dit een prima stukje code, waar zouden dan nog haakjes bij moeten komen?

[Infant]

Hm, ik moest er wel de order of precedence lijst bij pakken.

C:

// Wat willekeurige waardes.
i = 1;
status_b = 1;
period_a = 8;
tolerance = 4;
status_b = 6;
period_b = 4;
// Dit evaluate dan ... als ik het goed heb... ongeveer zo:
if (status_b == 1 && i < period_a + tolerance || status_b == 0 && i < period_b + tolerance) 
if (1 == 1 && i < 12 || 1 == 0 && i < 8) 
if (T && T || F && T) 
if (T || F)
True 

Ik weet niet wat je wilt dat er gebeurt. Het is mij niet in een oogopslag duidelijk. Is true goed?

Maar, ik heb ook altijd problemen in de AH bij het bordje 1+1 gratis. Het klopt wel, maar 1 + (1 Gratis) is toch gewoon duidelijker?

Binaire operaties, en ook logische expressies, zijn natuurlijk commutatief en associatief... dus het maakt waarschijnlijk niet uit...

[ Voor 8% gewijzigd door Infant op 11-10-2012 09:24 ]

[SPT]

Infant schreef op donderdag 11 oktober 2012 @ 09:06:
Hm, ik moest er wel de order of precedence lijst bij pakken.

C:

// Wat willekeurige waardes.
i = 1;
status_b = 1;
period_a = 8;
tolerance = 4;
status_b = 6; // Dit kan niet, het signaal is binair dus hoog (1) of laag (0).
period_b = 4;
// Dit evaluate dan ... als ik het goed heb... ongeveer zo:
if (status_b == 1 && i < period_a + tolerance || status_b == 0 && i < period_b + tolerance) 
if (1 == 1 && i < 12 || 1 == 0 && i < 8) 
if (T && T || F && T) 
if (T || F)
True 

Ik weet niet wat je wilt dat er gebeurt. Het is mij niet in een oogopslag duidelijk. Is true goed?

Maar, ik heb ook altijd problemen in de AH bij het bordje 1+1 gratis. Het klopt wel, maar 1 + (1 Gratis) is toch gewoon duidelijker?

Binaire operaties, en ook logische expressies, zijn natuurlijk commutatief en associatief... dus het maakt waarschijnlijk niet uit...

period_a bevat de tijd (in usec) waarbinnen het signaal hoog is, gemeten tijdens het eerste ontvangen bit. period_b de tijd waarin deze laag is. Omdat het niet gegarandeerd is dat de duty cycle 0.5 is (dat een signaal dus evenlang hoog als laag is), heb ik deze waarden apart opgeslagen. Mijn programma beschouwd ontvangen data als geldig indien de gemeten (halve) periode ongeveer gelijk is aan de (halve) periode die bij het eerste bit werd ontvangen, of als hij ongeveer gelijk is aan het dubbele hiervan (in dat geval zijn hoog/laag bij het volgende bit omgekeerd). Op deze manier wordt dus vastgesteld of het ontvangen signaal nog onderdeel vormt van het datapakket dat we aan het verwerken zijn.

In het bovenstaande if-statement wordt daarna geëvalueerd of de gemeten tijd waarin het ontvangen halve bit hoog of laag was (i) kleiner is dan de gemeten periode van het eerste bit dat is ontvangen. In dat geval hebben we alleen de tweede helft van het huidige bit ontvangen, en is de timer al bezig met het meten van de duur van de eerste helft van het volgende bit (of random noise).

Wanneer is dit if-statement waar?
- als het signaal hoog is (status_b == 1 ) en de gemeten periode (i) kleiner dan de tijdsduur die een hoog signaal de eerste keer had (period_a) + de toegestande tolerantie.
- of als het signaal laag is (status_b == 0 ) en de gemeten periode (i) kleiner dan de tijdsduur die een hoog signaal de eerste keer had (period_b) + de toegestande tolerantie.

In jouw voorbeeld is een hoog signaal gemeten (status_b == 1 ) gedurende 1 microseconde (i == 1 ). De eerste keer dat bij het verwerken van dit datapakket een hoog signaal was gemeten, duurde dat 8 microseconde (period_a == 8 ). Omdat we slechts een tolerantie van 4 microseconde toestaan, zou dit pakket nooit bij dit if-statement aan zijn gekomen. Zou hij echter toch bij dit if-statement aangekomen zijn, geldt dat hij minder lang hoog of laag was dan gebruikelijk, en dat het if-statement dus waar is.

Het is misschien goed om de uitgangspunten van mijn programma nog even toe te lichten:
- Zolang hij niet bezig is met het ontvangen van een datapakket, wordt elke overgang van laag naar hoog beschouwd als een mogelijk begin van een nieuw pakket (van een willekeurige zender op deze frequentie die Manchester encoding gebruikt).
- Tijdens het ontvangen van een pakket, houdt het programma in de gaten of de periode (en dus de bitrate) constant blijft in opeenvolgende bits.
- Een asymmetrische duty-cycle wordt wel toegestaan, mits deze assymetrie gelijk is in opeenvolgende bits.
- Als tenminste 8 opeenvolgende bits (1 byte) tot maximaal 32 bytes aan data is ontvangen, worden het aantal ontvangen bits, de frequentie, de signaalsterkte en de data op een LCD scherm weergegeven.

code:

if (receive() >= 8)
{
       lcd_clear();
       fontsize = 7;
       picprintf("Bits:    %5d\n", bitlen, 0);
       picprintf("Bitrate: %5d\n", 1000000/(int)(period * 0.6666667), 0);
       picprintf("Signaal: %5d\n\n", signal, 0);
       fontsize = 5;
       for (i = 0; i < 20; i++) // Nou, OK, alleen de eerste 20 bytes passen op het 128x64pixel schermpje...
       {
              if (i > (bitlen - 1) / 8) continue;
              picprintf("%3d ", dat[i], 0);
              if (i == 4 || i == 9 || i == 14) picprintf("\n", 0, 0);
       }
}

Met deze (test) opstelling wil ik nu eerst eens gaan kijken wat voor data er zoal in de lucht zit, en of ik zelf een datalink tot stand kan brengen met een zendertje. Met de opgedane kennis wil ik uiteindelijk een weerstation gaan bouwen.

[Anoniem: 492158]

are all Elro AB440 series devices supported?http://www.elro.eu/en/pro.../home_control/ontvangers1

are Built-in switch - AB440IS supported?http://www.elro.eu/en/pro...angers1/inbouw_schakelaar

thank you!

[gerardwr]

Is er hier iemand met ervaring met het decoderen van het signaal van Somfy Telis RF remotes. Deze worden vaak gebruikt bij zonneschermen en rolluiken.

Ik gebruik een Arduino met een "Niels" 433 Mhz ontvanger, met eigen software. Ik kan de signalen van veel remotes decoderen, Blokker, Action, KAKU, X10 RF, LaCrosse temperatuursensors, RF deurbellen, div noname RF remotes. Voor de meeste RF remotes krijg ik de decodering wel voor elkaar maar op de Somfy heb ik tot nu toe mijn tanden stuk gebeten. Mijn software herkent de RF signalen door naar de lengte van de startpuls en stoppuls te kijken, en het aantal tussenliggende pulsen, tot nu toe is dat voldoende geweest om de diverse remotes uit elkaar te houden.

Ik heb zelf een gedeeltelijke decodering van het Somfy signaal met een Arduino gedaan, maar kan wel wat hulp van buitenaf gebruiken. Op het internet vindt je weinig tot niks over de codering, anders dan dat het beveleigigd is dmv van een "rolling code" die bij elke kopdruk veranderd.

Hoe ver ben ik:
- is gewoon 433 Mhz, codering lijkt op andere remotes door het aan/uitschakelen van de zender.
- startpulse van ca. 4800 usec, stop pulse van meer dan 20000 usec
- bittreintje varierend in aantal bits, minimaal 76, maximaal 95??, pulslengte ca. 650 of ca. 1300
- Door op bovenstaande waardes te checken herkent mijn Arduino dat het om een Somfy code gaat, maar in de bittrein zelf zie ik nog geen licht.
- voor de "liefhebbers" hier een voorbeeld van de pulslengtes (in usec):
4816,648,644,640,644,1280,1292,648,640,640,648,644,644,640,648,644,640,648,640,1284,636,648,1292,
1288,632,648,640,644,1292,648,640,1288,1280,648,640,648,640,648,640,652,636,648,636,1288,
636,648,636,652,636,648,1288,1288,636,652,632,648,1288,652,636,1284,1288,1292,1280,
652,636,652,636,1288,1284,1288,1284,1288,1284,1292,1280,1288,1288,656,632,652,636,1288,1284,
652,636,28128

Ik ken maar 1 commercieel programma dat de code decodeert, namelijke homewizard, zie
http://www.homewizard.nl/somfy.html

De volgende website is eigenlijk het enige wat ik verder heb gevonden. Ik heb de eigenaar van de site gemaild, maar geen antwoord gekregen.
http://www.draaijer.com/somfy/

Toevoeging : Vond toevallig vandaag nog een patent van Somfy met daarin een beschrijving van de pulstrein. Mijn metingen van startpuls=ca 4800, en pulsperiode van ca. 1280 worden daarin bevestigd.
Zie : somfy patent

Wie kan me helpen met een hint voor de verdere decodering?

UPDATE : De beschrijving van de pulstrein in de patentaanvraag geeft wel meer inzicht. Het is Manchester codering volgens de patentaanvraag. Daar komt ook vast mijn geconstateerde variabele aantal pulsen vandaan.

[ Voor 11% gewijzigd door gerardwr op 21-12-2012 23:24 ]

[CurlyMo]

Zijn er mensen met somfy die het mijn RaspberryPi code kunnen proberen?

[gerardwr]

CurlyMo schreef op vrijdag 21 december 2012 @ 11:08:
Zijn er mensen met somfy die het mijn RaspberryPi code kunnen proberen?

Heb geen Rasberry PI, maar zou best wel eens de code willen zien om de code naar een Arduino te porten

Kan dat?

[CurlyMo]

https://github.com/CurlyMoo/433.92-Raspberry-Pi/

[gerardwr]

CurlyMo schreef op vrijdag 21 december 2012 @ 14:52:
https://github.com/CurlyMoo/433.92-Raspberry-Pi/

Heb de code zojuist even bekeken, ziet er keurig uit, maar zoals gezegd testen kan ik hem niet.

Ik zie trouwens code voor de KAKU en ELRO, code voor het SOMFY protocol heb ik niet gezien, heb ik iets gemist?

[CurlyMo]

Proberen om achter het protocol te komen bedoelde ik dus

[EEKthecat]

Hi @Fuzzillogic,

Waar in de code wordt PIN 2 als INPUT (digitalread) gedefinieerd? Ik krijg het niet gevonden en ik wil graag een andere PIN gebruiken ivm mijn EthernetShield.

Nog bedankt voor de code, werkt perfect!


EDIT: Never mind, interrupt 0 = pin 2. interrupt 1 = pin3..
( RemoteReceiver::init(1, 3, receive_commando); <-- waar 1 = interrupt = pin 3 )

gr bart

[ Voor 24% gewijzigd door EEKthecat op 03-02-2013 12:34 ]

[ThinkPad]

Wauw dit is fantastisch! Eerder kon ik m'n stekkerdozen al aansturen met dank aan dit topic, en een TX433N, maar nu kan ik het ook met Arduino

En ik heb m'n Arduino pas 1 dag binnen, en begon helemaal vanaf 0,0 (hoe laat ik LEDje knipperen etc.)

Ik heb met de RemoteSwitch code succesvol een KaKu stekkerdoos aan kunnen sturen die ik nog had liggen, maar ik zou eigenlijk de set die ik dagelijks gebruik willen aansturen. Dat is een Flamingo set.

Hieronder de foto's van mijn Flamingo afstandsbediening, typenummer FA815R

Chipje op de foto:

code:

BM 22P02
1026LT
F51 0216A

Klik voor groter

Wat anders is aan deze set, is dat je bij de eerste ingebruikname de stekkerdozen moet 'pairen' met de AB, door een knop op de stekkerdoos in te drukken. Maar ik heb ze nu al gekoppeld, dus dan zou ik het signaal ook met een Arduino moeten kunnen sturen denk ik?

De enige hit op 'Flamingo' in dit topic was deze post, maar hoe gebruik ik die code? Wat moet ik met dat .h en .cpp bestand?

Ik heb helaas ook geen RX433, dus de set afluisteren gaat ook niet lukken.

[ Voor 25% gewijzigd door ThinkPad op 12-04-2013 22:47 ]

[-Tim-]

Zojuist een artikel tegengekomen van iemand die het protocol van de Thierry Mugler weerstations van de Action heeft ontleedt. Ik snap er zelf weinig van, maar het zou leuk zijn als iemand hier wat mee kan als toevoeging voor de library van Fuzzilogic. Even voor de duidelijkheid, we hebben het over een weerstation van 8 euro

http://roel.reijerse.net/thierry/

[Anoniem: 244685]

-Tim- schreef op zondag 28 april 2013 @ 17:39:
Zojuist een artikel tegengekomen van iemand die het protocol van de Thierry Mugler weerstations van de Action heeft ontleedt. Ik snap er zelf weinig van, maar het zou leuk zijn als iemand hier wat mee kan als toevoeging voor de library van Fuzzilogic. Even voor de duidelijkheid, we hebben het over een weerstation van 8 euro

http://roel.reijerse.net/thierry/

Oh, dat figuur ken ik wel. Als je vragen hebt...

[jrsikken]

Ik heb ook zo'n Therry Mugler wireless weatherstation. Ik heb de code van Roel Reijerse naar Arduino omgezet en het werkt goed. Maar de credits gaan naar Roel.
http://jasper.sikken.nl/thierry/index.html

[ Voor 11% gewijzigd door jrsikken op 13-06-2013 22:08 ]

[Joop Visstick]

Hoi,

Ik ben bezig om een dimmer te bouwen die ik wil kunnen schakelen met mijn ICS-1000 van KaKu.
echter als ik met een arduino en de code van Simons (https://bitbucket.org/fuzzillogic/433mhzforarduino/wiki/Home)
Het signaal afluister, krijg ik wel de aan-uit signalen binnen van zowel een APA3-1500R AB als van de ICS-1000.
Echter het Dim-signaal wordt niet weergegeven, nu heb ik het vermoeden dat het weer gaat om een nieuwere versie van het protocol, voorheen had je 16 dimniveau's en van de ICS-1000 zeggen ze dat je procentueel kan dimmen.

Nu heb ik met Audacity het signaal opgenomen van de APA3-1500R AB, maar ik kom er niet uit om die te vertalen naar wat de ShowReceiverCode (NewReomteSwitch) mij geeft.

ShowReceivedCode geeft mij:

code:

Addr 4890942 unit 0 on, period: 252us.
Addr 4890942 unit 0 off, period: 252us.

Het bijbehoordende signaal in Audacity (reeds geinveteerd):


In de info die ik hier vond; http://www.circuitsonline...w/message/1181410#1181410 staat :

code:

        _   _
'0':    | |_| |____ (T,T,T,3T)
        _        _
'1':    | |____| |_ (T,3T,T,T)
        _   _
dim:    | |_| |_    (T,T,T,T) 

T = korte periode = 275 µs (of 375, werkt ook)
lange periode = 3 of 4*T (werkt ook allebei)

Het frame bestaat normaal uit 32 bits:
startpuls (T hoog, 9*laag)
26  adres
1   groep-bit
1   on/off/[dim]
4   unit (indien meerdere kanalen op één zender)
[4] [dimniveau]
stoppuls (T hoog, 40*laag)

Echter ik zie 3 verschillende lengtes:
De T en de 3T van hierboven, maar tussen 2 T's zit een hele korte puls, moet ik die ook meetellen, of moet ik die overslaan?
Maar ik krijg het niet voor elkaar om het adres bit er uit te halen, zoals hierboven vermeld is.

de start en stoppuls kan ik er wel uithalen, echter zijn de lengtes van de lange puls wel anders (lees korter) dan hierboven vermeld.

Zou iemand mij verder op weg kunnen helpen hoe ik deze code moet "lezen" en moet decoderen?

PS. het plaatje is express zo groot, dan kun je goed de signalen zien.[/quote]

[Fuzzillogic]

Het dim-signaal is een probleem ja, sommige devices sturen het wel, anderen niet. Ik had gehoopt dat het nu zou werken, maar helaas. Ik heb nog niet naar de rest van je post gekeken, geen tijd voor nu en komende week helaas ook niet Binnenkort wil ik het oppakken. Maar anderen mogen ook briljante ingevingen hebben

On a side note: Arduino Yún is uitgebracht. Standaard 5V arduino + Linux + wifi + ethernet + usb + sd. Ik vind het een interessant ding

[Joop Visstick]

Fuzzilogic, Als je tijd hebt om er naar te kijken graag, ikzelf heb de komende 2 weken ook weinig tijd , moet volgende week een evenemententerrein inrichten in Boxtel . . . Dus weinig tijd om te spelen met de Arduino en KaKu.

Maar de Arduino Yún lijkt me inderdaad wel weer een leuk speeltje, past leuk tussen me arduino's en Raspberry Pi in

[Joop Visstick]

Ik ben weer iets verder, mijn signaal klopt wel, ik was gewoon even niet helemaal bij de les, ik had de vraag ook hier http://www.circuitsonline...w/message/1543135#1543135 geplaatst en Wieltje (die ook al eerder het signaal heeft herkend op CO) kon mij op het goede spoor zetten, ik ga nu verder stoeien met de ICS-1000 en zijn dim-signaal.

[brsm]

Hoi,

Kan iemand mij vertellen wat het verschil is tussen de Arduino Uno en de Arduino Yún?
De Yún draait op linux, heeft wat extra poorten en heeft wifi maar het gaat mij om de performance.

Er is nog weinig bekend over de Yun

[Fuzzillogic]

Yún heeft 2 CPU's. Feitelijk is een een standaard AVR-based Arduino gekoppeld aan een krachtere CPU waarop Linux draait. Als je dikke performance wilt moet je naar RaspberryPi of zijn broertjes en neefjes gaan kijken, de Yún is met zijn MIPS @400MHz en 64MiB duidelijk minder krachtig.

Waar heb je de performance voor nodig? (Lees: heb je die performance écht nodig? 400MHz MIPS is veel krachter dan de PCs waar Windows 98 op draaide)

[Joop Visstick]

@FuzziLogic, heb (of kan je de bestaande aanpassen) je ook een versie die meer debug info kan weergeven, ivm de dim-problemen?

Dan kan ik die testen met mijn ICS-1000.

[brsm]

@Fuzzillogic dankjewel voor je reactie. Ik heb meerdere sensoren die ik draadloos zou willen besturen via een externe server. De Yún leek mij hier een goede oplossing voor.

[Strunkie]

Hi Mensen, ik heb AWMR-210 dimmers die ik graag wil koppelen aan de NewRemoteTransmitter library.
Het probleem is dat ik er niet uit kom hoe ik deze moet inleren.

Bij de RemoteTransmitter was het simpel

code:

kaKuTransmitter.sendSignal('a',1,true);

Nu gebruik ik de volgende regel om hem in te leren:

code:

transmitter.sendUnit(2, true);

maar de ontvanger doet er niets mee.

Wat doe ik verkeerd ?

[Fuzzillogic]

Mogelijk doe je niks verkeerd. Bij gebrek aan hardware kan ik echter heel lastig (zeg maar: niet) eraan debuggen. En om uit eigen zak hardware te gaan kopen om voor anderen te gaan debuggen... Op de site staat al een tijd een bitcoin-adres

Je kunt proberen je ontvanger te koppelen aan de code van een oude kaku, dus zoals je al deed met kaKuTransmitter.sendSignal('a',1,true); Het zou moeten werken.

[Strunkie]

Fuzzillogic schreef op vrijdag 22 november 2013 @ 22:50:
Mogelijk doe je niks verkeerd. Bij gebrek aan hardware kan ik echter heel lastig (zeg maar: niet) eraan debuggen. En om uit eigen zak hardware te gaan kopen om voor anderen te gaan debuggen... Op de site staat al een tijd een bitcoin-adres

Je kunt proberen je ontvanger te koppelen aan de code van een oude kaku, dus zoals je al deed met kaKuTransmitter.sendSignal('a',1,true); Het zou moeten werken.

Thanks voor je reply.
Ik kan mijn ontvanger wel gewoon koppelen met de oude code dat is geen probleem. Ik wil alleen de nieuwe gebruiken omdat je daar support hebt ingebouwd voor dim levels.

Ik heb nog gekeken welke code ik door krijg van mijn aan/uit knoppen van KaKu. Dit was:
Kanaal: 7924086
unit: 10
Period: 251

Aan de hand daarvan heb ik de volgende init code:

code:

NewRemoteTransmitter transmitter(7924086, 11, 251, 3);

en stuur ik zo het aan signaal:

code:

transmitter.sendUnit(10, true);

Ik ben bang dat ik het bij de "oude" library moet houden.

Welke hardware zou jij nodig hebben om te debuggen... ?

[cODAR]

Ik loop toevallig tegen hetzelfde probleem aan, mijn nieuwe inbouw dimmer wil ook niet inleren

Heb diverse methodes geprobeerd, waaronder kaKuTransmitter.sendSignal('a',1,true);

Ben erg benieuwd of dit een bug of een feature is, in het ergste geval kan ik altijd nog een originele zender kopen, maar dat lijkt zonde van het geld als je hem alleen voor inleren wilt gebruiken.

[cODAR]

Het is uiteindelijk gelukt, punt bij mij was dat ik te snel achter elkaar het "aan" signaal verstuurde.

[Joop Visstick]

Joop Visstick schreef op donderdag 12 september 2013 @ 13:13:
.... ik ga nu verder stoeien met de ICS-1000 en zijn dim-signaal.

Per toeval keek ik weer eens op de site van bitbucket bij Fuzzilogic, de 433mhzforarduino code en keek ook bij bugs, daar vond ik de issue 20 (link: issue 20 bug-in-remotereceivercpp-dim-level)
nadat ik de code heb overgenomen, ontvangt mijn Arduino ontvanger ook de dimwaarden van de ICS-1000, bovenstaande is dus de oplossing voor het niet dimmen met de ICS-1000.
Als Fuzzilogic deze code zou kunnen opnemen in de volgende release, dan komt het (waarschijnlijk) helemaal goed.

[Fuzzillogic]

Je zou bijna gaan twijfelen aan al het toeval, maar toch, het toeval wil dat vanavond voor het eerst sinds weken weer eens het project op kunnen pakken. De aanpassing heb ik al overgenomen. Maar voor release wil ik de examples ook nog even bijwerken, m.n. de retransmitter sketch zit me nog niet lekker.

Inmiddels heb ik wel een nieuwe kaku dimmer-ontvanger gekocht (medegefinancierd door een bitcoindonatie! ), dus ik kan daadwerkelijk dingen testen.

[Fuzzillogic]

De update staat op bitbucket. De dim-bits zijn nu volledig optioneel in een signaal, dus ik hoop dat het nu alle scenario's afdekt. Ik heb geen dim-zender, dus helaas kan ik dat niet echt testen. Wel is er nu een extra example, dimmer, die laat zien hoe je zelf directe dimmerniveaus kunt instellen. En dat werkt iig goed met de acm-100 ontvanger.

[Boinkie]

Ik ga even een tvp plaatsen. Arduino is binnen. Morgen breadboard en dan wil ik met KaKu gaan spelen

[Boinkie]

Ben al een eind gekomen maar zit nu even vast, zie vast iets over het hoofd maar kan even niet ontcijferen of iets vinden wat ik nu moet doen.

Ik heb de receiver aangesloten en deze ontvangt ook de codes van mijn KaKu afstandsbediening. Deze staat nu op C en de rest in mijn huis ook.

code:

UIT 1: Code: 118124, period duration: 370us.
AAN 1: Code: 118122, period duration: 369us.
UIT 2: Code: 122498, period duration: 369us.
AAN 2: Code: 122496, period duration: 370us.
UIT 3:Code: 119582, period duration: 370us.
AAN 3:Code: 119580, period duration: 370us.

Dit zijn de code's van de betreffende knoppen. Hoe kan ik nu mijn transmitter deze laten versturen? Ik heb de bitbucket library's al bekeken maar kan er niet wijs van worden

[ Voor 12% gewijzigd door Boinkie op 19-02-2014 14:19 ]

[Boinkie]

Niemand die mij een handje de goede richting wil in slaan?

[Fuzzillogic]

Kijk eens naar de Retransmitter voorbeelden. Daar kun je zien hoe je op basis van een code kunt verzenden.

[Boinkie]

Helaas, iets te hoog gegrepen dit. Krijg de transmitter niet werkend

[Fuzzillogic]

Boinkie schreef op dinsdag 25 februari 2014 @ 15:38:
Helaas, iets te hoog gegrepen dit. Krijg de transmitter niet werkend

Krijg je het qua programmeren niet voor elkaar of werkt ook Retransmitter niet? En welke zender gebruik je?

[Atmoz]

Is het probleem met het volledig ontvangen van het KAKU AMST-606 deurcontact nog steeds aanwezig?
Ik begreep namelijk uit diverse posts (ook op andere forums) dat alleen het "OFF" signaal goed werd ontvangen. Dit zou echter alleen optreden bij de "nieuwe" modellen AMST-606...

[Fuzzillogic]

atmoz schreef op zaterdag 01 maart 2014 @ 14:27:
Is het probleem met het volledig ontvangen van het KAKU AMST-606 deurcontact nog steeds aanwezig?
Ik begreep namelijk uit diverse posts (ook op andere forums) dat alleen het "OFF" signaal goed werd ontvangen. Dit zou echter alleen optreden bij de "nieuwe" modellen AMST-606...

In de recentste versie is de aanwezigheid van dim-level optioneel. Dat zou het probleem moeten oplossen - er wordt bij sommige (nieuwe?) varianten ook bij het "on"-signaal een dim-niveau meegestuurd waar de library voorheen niet op voorzien was. Mijn exemplaar van de AMST-0606 doet dat niet, vandaar dat het probleem mij ook niet opviel, maar ik kan de oplossing dus helaas ook niet met zekerheid testen. Op bitbucket heb ik geen bericht meer gezien dat het nu nog niet werkt, en ik ga er dan ook maar van uit dat het nu goed is.

[Atmoz]

Thanks voor je snelle reactie + email Randy
Top! Dan voel ik me weer een beetje "safer" met m'n vanmiddag bestelde 12 stuks magneetcontacen
Van de week gelijk testen. Nogmaals bedankt voor al je werk!

[NeFoRcE]

Even een oud topic openspijkeren. Maar ik heb afgelopen weekend een Home Easy inbouw dimmer gekocht, gemonteerd, en met een Home Easy HE844A 'm bediend. Echter, wat werkt dat onhandig zeg! Ik krijg het dimmen e.d. gewoon niet fatsoenlijk voor elkaar.

Mijn doe is om de eet/salontafel lampen te kunnen dimmen naar eigen wens, (zitten aan elkaar gekoppeld in't plafond met draad, dus het is allebei aan of uit, vandaar remote dimmers). Hebben jullie eventueel een betere oplossing? Ik wil gewoon zonder al te veel moeite de lampen wat feller/zachter laten branden, zonder daar 10 minuten mee bezig te moeten zijn...

[info49]

Probeer de NewRemoteReceiver.ino te compileren met 1.6.5 en Arduino Genuino Uno en krijg
deze melding. Kan iemand mij helpen met dir probleem. Op Arduino.cc site kom je veel de " collect2.exe: error: ld returned 1 exit status" melding tegen.

In function `setup':
E:\arduino-1.6.5-r5/ShowReceivedCode.ino:22: undefined reference to `NewRemoteReceiver::init(signed char, unsigned char, void (*)(NewRemoteCode))'
collect2.exe: error: ld returned 1 exit status

[spoilerdo]

Ik heb de NewRemoteSwitch library gedownload. De receiver werkt prima met de afstandsbediening. Alleen ik krijg mijn transmitter niet aan het werk zodat die ook werkt met het klikaanklikuit systeem. Kan iemand een code voorbeeld geven hoe je een transmitter laat werken?